[mesa-users] Experimenting with adjust_mlt_gradT_fraction

[Bill Paxton]

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
>> 
>