[mesa-users] Experimenting with adjust_mlt_gradT_fraction

Ehsan Moravveji e.moravveji at gmail.com
Mon Aug 11 13:34:07 EDT 2014


Dear Bill,
I'm so excited by your quick patch. That's amazing.
I prefer to fetch the latest unofficial version that you just modified to find other_adjust_mlt_gradT_fraction from /star/others/ directory, and set the relevant flag in my inlist, and call/use it very canonically in my run_star_extras. Would you please pass the version number?

Let me also share another concern but along the same line.
I look at the other_mlt hook as a "bridge" between the users and the very core of MESA solver. Different users may cross this bridge for different reasons. E.g. today, I experimented with adjust_mlt_gradT_fraction, but tomorrow, who knows, I may need other_mlt for a different reason.
Instead of adding yet another hook, now called other_adjust_mlt_gradT_fraction, isn't it possible to "generalize" the use of other_mlt?
In other words, if a user calls other_mlt, then the whole private variables be updated by their public counterparts, before the start of the newton iterations.

Maybe for technical reasons, you do not prefer this, and I totally rely on that.
I hope I'm not asking for too much; just liked to share a thought.

Once again I appreciate your support.

Ehsan.



On Aug 11, 2014, at 7:03 PM, Bill Paxton wrote:

> Hi,
> 
> Okay --- now I understand your question.   The answer is that I've only used adjust_mlt_gradT_fraction from inside the star private modules, and I haven't set things up to let user's easily make use of it.  I'll need to add another hook since you'll need to set the values after the model has been remeshed at the start of the step but before the start of the newton iterations.  Currently the adjust_mlt_gradT_fraction vector is initialized to all -1's after remeshing, so the values you carefully set in your run_star_extras are never used.  We need to give you a chance to change the values after they are initialized for the new mesh and before the solve.  
> 
> I've made the change for the next release, but if you'd like to make a temporary patch, here's how.
> In hydro_vars you'll find these lines:
> 
>         if (dbg) write(*, *) 'call set_mlt_vars'
>         call set_mlt_vars(s, nzlo, nzhi, ierr)
>         if (failed('set_mlt_vars')) return
> 
> We need to add something just before those lines to call the new hook.  But we only want to call the hook routine once at the start of the step rather than at each iteration (if the fraction values change during the iterations, then we'd require partial derivatives of the fractions! -- let's not go there).  So here's the fix that will be in the next release -- just before calling set_mlt_vars, call the hook routine if we are doing the mixing vars (they only are evaluated at the start of the iterations).
> 
>         if (.not. skip_mixing) then
>            if (dbg) write(*, *) 'call other_adjust_mlt_gradT_fraction'
>            call s% other_adjust_mlt_gradT_fraction(s% id,ierr)
>            if (failed('other_adjust_mlt_gradT_fraction')) return
>         end if
> 
>         if (dbg) write(*, *) 'call set_mlt_vars'
>         call set_mlt_vars(s, nzlo, nzhi, ierr)
>         if (failed('set_mlt_vars')) return
> 
> So as a termporary patch, you could put your code in hydro_vars in place of the call of other_adjust_mlt_gradT_fraction.
> Then when you get the new release you can move that code back into your run_star_extras where it belongs.
> 
> Thanks for pointing out this issue.   I hope you can sleep well now. ;D
> 
> Cheers,
> Bill
> 
> 
> On Aug 11, 2014, at 8:58 AM, Ehsan Moravveji wrote:
> 
>> Dear Bill,
>> Thanks for your reply. Actually, you rephrased my question precisely:
>> The fact that gradT together with P and T are implicitly coupled together in the structure equations gives me the expectation that "tweaking" one (here gradT, using adjust_mlt_gradT_fraction) would have noticeable influence on the profiles of other structure variables. However, my plots in the former email prove that the solver does not sense the change to gradT; otherwise, T and P profiles should have changed even slightly, where gradT was locally modified. 
>> Do you agree with me?
>> 
>> Aren't you surprised that changing adjust_mlt_gradT_fraction from 0.0 to 0.25 and 0.50 has absolutely no effect on P, T and Rho profiles?
>> 
>> I have the "assumption" that changing adjust_mlt_gradT_fraction has shallow effects, and the updated values of gradients do not parse deep down the solver level, although during calling other_mlt, I update all gradients (lines 100 to 108 in my run_star_extras; attached):
>> 
>>           s% gradT(k) = mlt_basics(mlt_gradT)
>>           s% gradr(k) = mlt_basics(mlt_gradr)
>>           s% gradL(k) = mlt_basics(mlt_gradL)
>>           s% scale_height(k) = mlt_basics(mlt_scale_height)
>>           s% mlt_mixing_length(k) = mlt_basics(mlt_Lambda)
>>           s% mlt_vc(k)= mlt_basics(mlt_convection_velocity)
>>           s% mlt_D(k) = mlt_basics(mlt_D)
>>           s% mlt_Gamma(k) = mlt_basics(mlt_Gamma)
>>           s% mixing_type(k) = mixing_type
>> 
>> I would like to test my assumption (and honestly disprove it for a better sleep tonight!): 
>> Is there a debugging flag or a method available that a user checks if "local" modifications to gradT is understood all the way down the solver level?
>> 
>> Happy Summer School,
>> Ehsan.
>> <run_star_extras.f>
>> 
>> On Aug 11, 2014, at 5:18 PM, Bill Paxton wrote:
>> 
>>> 
>>> On Aug 11, 2014, at 5:50 AM, Ehsan Moravveji wrote:
>>> 
>>>> Dear all,
>>>> Special greetings to those of us who already started their morning in the exciting Summer School. 
>>>> 
>>>> I was thinking of a gedankenexperiment to modify the temperature gradient in the semi-convective layers of a 15Msun main sequence star. There is a wonderful variable already implemented to vary gradT between gradr and grad_ad, called "adjust_mlt_gradT_fraction" (hereafter called f in the plots and the following text). I have traced this variable in hydro_vars.f and mlt_info.f in /star/private. 
>>>> I took three values of f = 0.00, 0.25 and 0.50. Then, I use the other_mlt hook in my run_star_extras to change the value of f "only" in the semi-convective zones. Indeed, it works. Please see the attached gradT.png plot. 
>>>> 
>>>> However, the temperature and pressure profiles and all other hydro variables should be modified as well to be consistent with ad-hoc modifications in gradT.
>>> 
>>> Hi Ehsan,
>>> 
>>> The pressure and temperature profiles are set by the newton solver to approximate solutions to the structure equations.  The value of gradT appears in the temperature equation, so changing gradT will cause the solver to come up with a different solution for the temperature profile, and since everything depends on everything else that will cause a change in the pressure profile which is also a product of the solve.
>>> 
>>> In other words, gradT is one of the inputs while temperature and pressure are outputs of the solve.  Since gradT and the other right hand sides depend on the values of the variables such as T and P, i.e. we have an implicit system to solve, the values of the variables that will give a good enough solution must be found iteratively.   But it is the solver that determine profiles for T and P; you only indirectly influence the outcome by setting the values for gradT. 
>>> 
>>> hope that helps,
>>> Bill
>>> 
>>> 
>>> 
>>> 
>>>> In other words, direct differentiation of temperature and pressure profiles must consistently result in gradT for any arbitrary value of f == adjust_mlt_gradT_fraction.
>>>> Currently, this is not the case. To convince myself, I did three other plots of T, P and Rho in the same semi-convective zone; see the attachments, please.
>>>> 
>>>> I totally understand that gradT and hydro_vars are evaluated across different modules, and that can make life complicated. But, I desire having self-consistent outcome in my profile files.
>>>> In case one likes to reproduce the results, I have attached my inlist and run_star_extras.f (compatible with v.6794).
>>>> 
>>>> I would be grateful if you enlighten me with your comments/feedbacks. 
>>>> 
>>>> Kind regards,
>>>> Ehsan.
>>>> 
>>>> <gradT.png>
>>>> 
>>>> <Density.png><Pressure.png><Temperature.png>
>>>> <inlist_general><run_star_extras.f>
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
>> 
> 





More information about the Mesa-users mailing list