[mesa-users] implementation changes of the overshooting
Bill Paxton
paxton at kitp.ucsb.edu
Wed Jul 29 11:52:28 EDT 2015
On Jul 29, 2015, at 2:24 AM, Jean-Claude Passy wrote:
> Hi Bill,
>
> I hope you are doing well.
> I did not receive any comment on the subject, I was wondering if you had followed the thread and agree on the changes that I suggested.
>
> Cheers,
>
> JC
>
> Begin forwarded message:
>
>> From: Jean-Claude Passy <jcpassy at gmail.com>
>> Subject: Re: [mesa-users] implementation changes of the overshooting
>> Date: July 22, 2015 at 5:10:57 PM GMT+2
>> ...
>> 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?
Hi,
I don't recall there ever being a time when f0 was not involved in the implementation of overshooting in mesa. Perhaps you mean the old default where f0 < 0 implied the use of f for f0? I got rid of that default since it allowed users to have an incorrect idea that they actually knew what they were doing when in fact they did not -- better to bring the issue out into the open and force the user to confront the issue rather than hide it away. For example, some users might even fail to read the documentation and think that there was no use of f0 at all -- in spite of comments like this from controls.defaults back in version 5576 (an old version i just happen to have on my machine at the moment):
! the switch from convective mixing to overshooting happens
! at a distance f0*Hp into the convection zone
For multiple f's, see the experimental "double f overshooting" that was added years ago for Falk to play with -- I don't believe anything ever was published using it, and I have come close to removing it several times. The control parameters are still hidden away in star/private/private_defaults.inc, but you are welcome to try them to see if it still works.
! optional 2nd scale length for exponential overshooting
! `f0*Hp` determines location r0 where we switch from convection to overshooting.
! Let D0 = diffusion coefficient D at point r0.
! Let Hp0 = the scale height at r0.
! In the standard version of exponential overshooting,
! there is a single length scale = `f*Hp0`
! and at a distance dr from r0, `D(dr) = D0*exp(-2*dr/(f*Hp0))`.
! In the extended version there is a second length scale = `f2*Hp0`.
! The second length scale takes effect for distances dr > dr2
! where dr2 is defined by `D2 = D0*exp(-2*dr2/(f*Hp0))`.
! + for dr <= dr2, D(dr) = `D0*exp(-2*dr/(f*Hp0))`
! + for dr > dr2, D(dr) = `D2*exp(-2*(dr-dr2)/(f2*Hp0))`
! = `D0*exp(-2*dr2/(f*Hp0))*exp(-2*(dr-dr2)/(f2*Hp0))`
! = `D0*exp(-2*(dr2/(f*Hp0) + (dr-dr2)/(f2*Hp0)))`
overshoot_D2_above_nonburn = -1
overshoot_D2_below_nonburn = -1
overshoot_D2_above_burn_h = -1
overshoot_D2_below_burn_h = -1
overshoot_D2_above_burn_he = -1
overshoot_D2_below_burn_he = -1
overshoot_D2_above_burn_z = -1
overshoot_D2_below_burn_z = -1
overshoot_f2_above_nonburn = 1
overshoot_f2_below_nonburn = 1
overshoot_f2_above_burn_h = 1
overshoot_f2_below_burn_h = 1
overshoot_f2_above_burn_he = 1
overshoot_f2_below_burn_he = 1
overshoot_f2_above_burn_z = 1
overshoot_f2_below_burn_z = 1
Cheers,
Bill
> Begin forwarded message:
>
>> From: Jean-Claude Passy <jcpassy at gmail.com>
>> Subject: Re: [mesa-users] implementation changes of the overshooting
>> Date: July 22, 2015 at 5:10:57 PM GMT+2
>> To: "mesa-users at lists.sourceforge.net users" <mesa-users at lists.sourceforge.net>
>> Cc: Pablo Marchant <pamarca at gmail.com>
>>
>> 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
>>
> <ov2.eps>
>>
>> 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/20150729/dde7989f/attachment.html>
More information about the Mesa-users
mailing list