[mesa-users] implementation changes of the overshooting

[Jean-Claude Passy]

Hi guys,

thanks for your suggestions.

Rob, f0 needs to be set > 0. 
Pablo, yes, I have tried that for other combinations (see the plot attached) and I think I understand what is going on.

The solid lines represent D_ovr, the dashed lines D_conv. 
In the OV region, the red, green and purple curves have the same slope. So the slope is determined by f only (no f0). Then, depending on f0, D0 is calculated at -f0*Hp, location at which D_conv is replaced by D_ov with an exponential decay of factor -2/(f*Hp). It surprised me a little, but I guess this is done to obtain a smooth transition between D_conv and D_ovr across the convective boundary. However, the problem is that the exponential factor in the OV region is still -2/(f*Hp), which leads to much more OV. Changing f0 (while keeping (f-f0) constant) should only shift the solid lines vertically as we get a different D0. Looking at the cyan, yellow, black, cyan and purple lines, that is clearly not the case. 

The bottom line is, I think the issue is in the factor in the exponential in the OV region: it should be -2/[(f-f0)*Hp)] (there should be a discontinuity in the derivative at the convective boundary).

Also, while it is nice to give the user the possibility to choose f0, one has to be a little careful. If it is set so low that it picks out D0 after D_conv is falling to 0, the OV region will be much smaller (purple line). I personally prefer the way OV was implemented in v6208 (no f0 involved), I think it was much safer. May be one could have this option back in MESA in a future version?

Cheers,

JC



On Jul 22, 2015, at 1:57 AM, Pablo Marchant <pamarca at gmail.com> wrote:

> Simple experiment, did you tried reducing f and f0 so f is closer to 0.03? something like f=0.031, f0=0.001?
> 
> Am 22.07.2015 12:07 vorm. schrieb "Jean-Claude Passy" <jcpassy at gmail.com>:
> Hi all,
> 
> I have a few questions regarding how the implementation of overshooting has changed in MESA. I am seeing some inconsistency between different versions so I would like to make sure that I did not miss anything.
> 
> I am starting a run with an ~ 3 Msun ZAMS (’start.mod'), evolve it for one timestep, and look at the overshooting region of the output model. I do that with two versions, v6208 and v7503.
> 
> In version 6208, D_0 was calculated by interpolation using the nearest cells to the convective boundary. One only had to supply the f factor, so my inlist would contain something like:
> 
> #---------------------------------------------------------------
>       overshoot_f_above_nonburn = 0.030
>       overshoot_f_below_nonburn = 0.030
>       overshoot_f_above_burn_h = 0.030
>       overshoot_f_below_burn_h = 0.030
> #---------------------------------------------------------------
> 
> In version 7503, D_0 is now calculated at a distance f0*Hp inside the convective zone, location which then becomes the new convective boundary. We thus need to add “f0” to the “new f”. So to be consistent with version 6208, I would have in my inlist something like:
> 
> #---------------------------------------------------------------
> overshoot_f_above_burn_h_core = 0.040
> overshoot_f_above_burn_h_shell = 0.040
> overshoot_f_below_burn_h_shell = 0.040
> 
> overshoot_f0_above_burn_h_core = 0.010
> overshoot_f0_above_burn_h_shell = 0.010
> overshoot_f0_below_burn_h_shell = 0.010
> #---------------------------------------------------------------
> 
> The results I get are shown on the figure attached. The overshooting region extends much further with the new version (green) in comparison with the old one (blue). If I compare the different slopes, they correspond to a difference of about 30% in f. If I then change f from 0.040 to 0.030, I get the red curve which seems to better agree with the blue line.
> 
> I looked at overshoot.f90 and could not find any mistake regarding how Dov, D_0, or even f were called/calculated. However two things puzzle me:
>         - I expected the overshooting region to go deeper in the new code (there is no difference in radius either), since some of the convective region is effectively ‘transformed’ into overshooting;
>         - that said, it would be fine if we used a (f-f0) under the exponential to calculate Dov. But that is not the case (at least from what I can see).
> 
> All the inlists are attached. You will need the run_star_extra.f for the version 7503 to set up f and f0 more rapidly.
> 
> Hope that someone will help me to solve this mystery!
> 
> Cheers,
> 
> JC
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150722/e4c56fa7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ov2.eps
Type: image/eps
Size: 31189 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150722/e4c56fa7/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150722/e4c56fa7/attachment-0001.html>