[Mesa-users] Unable to change temperature gradient when atomic diffusion is turned on

[Evan Bauer]

Hi Joey,

I think it's clear to me what is going on now. The issue is that you can't always rely on s%D_mix to be set by the time that your other_adjust_mlt_gradT routine is called. In fact, the other_adjust_mlt_gradT_fraction hook is designed to be called before the mlt info gets set, because s% adjust_mlt_gradT_fraction is input for setting the mlt info. So this line is often causing your routine to bail out before setting adjust_mlt_gradT_fraction:

        if (s%D_mix(1) .ne. s%D_mix(1)) return  ! To ignore iterations where Dmix and gradT are NaNs

The reason that you don't see this when do_conv_premix = .true. is that the code comes back to call other_adjust_mlt_fraction again after conv_premix, and s%D_mix has now been set by a previous call to do_set_vars.

Bottom line: trying to set adjust_mlt_gradT_fraction based on the contents of s%D_mix is not consistent with how this hook is designed. Using do_conv_premix helps you get around this to some extent, but even then I'm not sure the operation is entirely well-defined, because s%D_mix could possibly change after its contents are used to set adjust_mlt_gradT_fraction.

Cheers,
Evan


> On Aug 24, 2021, at 12:01 PM, Joey Mombarg <joey.mombarg at kuleuven.be> wrote:
> 
> Hi Evan,
> 
> Attached an inlist and run_star_extras to reproduce the problem (diffusion on/off seems to be irrelevant, so I left it out).
> If you put a write-statement within the if-statement around line 565 in hydro_vars.f90, you can see that it comes after the run_star_extras routine has been called.
> 
> Cheers,
> Joey
> 
> <inlist_gradT><run_star_extras_gradT.f>
> 
>> On 24 Aug 2021, at 17:06, Evan Bauer <evan.bauer.astro at gmail.com> wrote:
>> 
>> Hi Joey,
>> 
>> I don't think there's a bug in 11701, but I'm interested to look closer and see if I can reproduce the problem you're describing. Can you send me an inlist and run_star_extras to reproduce the issue? And point to where exactly I should print out adjust_mlt_gradT_fraction to see that it's not set properly? I'm surprised to hear that do_conv_premix seems to make a difference here as well, so I'm curious to look at that.
>> 
>> One other note: the lines you've quoted aren't the only place in hydro_vars.f90 where adjust_mlt_gradT_fraction gets touched. There's also this section:
>> 
>>        if (.not. skip_mixing_info) 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
>> 
>>           if (s% u_flag) then
>>              if (dbg) write(*,*) 'call set_abs_du_div_cs'
>>              call set_abs_du_div_cs(s)
>>           end if
>> 
>>        end if
>> 
>> So even if the earlier block gets called setting s% adjust_mlt_gradT_fraction(1:nz) = -1, I think your other_adjust_mlt_gradT_fraction routine should still get called after that to reset s% adjust_mlt_gradT_fraction to what you want it to be.
>> 
>> Cheers,
>> Evan
>> 
>> 
>>> On Aug 24, 2021, at 10:26 AM, Joey Mombarg <joey.mombarg at kuleuven.be> wrote:
>>> 
>>> Hi Evan,
>>> 
>>> Thank you for your answer!
>>> 
>>> I am using release 11701 (with some modifications to the radiative levitation routines I have done myself, but only at the level of star/private/diffusion_procs, so this should not make a difference).
>>> 
>>> I have done some additional tests, and I can confirm that for my setup the lines I quoted are executed though. However, I now also see that when ‘do_conv_premix = .true.’, the gradient is indeed changed and not overwritten afterwards. Thus, if I understand you correctly, the fact that changing the temperature gradient without premixing does not work is because of a bug in MESA?
>>> 
>>> Cheers,
>>> Joey
>>> 
>>>> On 23 Aug 2021, at 22:42, Evan Bauer <evan.bauer.astro at gmail.com> wrote:
>>>> 
>>>> After digging around for a bit, I have a correction on the timeline of the bug I was referring to...
>>>> 
>>>> The bug was introduced in some dev versions between 12778 and 15140, but was fixed in svn revision 14984, so it never did impact any release versions.
>>>> 
>>>> Cheers,
>>>> Evan
>>>> 
>>>>> On Aug 23, 2021, at 4:19 PM, Evan Bauer <evan.bauer.astro at gmail.com> wrote:
>>>>> 
>>>>> Hi Joey,
>>>>> 
>>>>> What MESA version are you using? In 11701 (and other release versions), when diffusion is on, there is a call to update_vars after diffusion updating things to reflect the new composition, but it should also be setting skip_mixing_info = .true. for that call after diffusion. So the lines you've quoted in your email should be skipped for that particular call to update_vars, and diffusion should have no impact on adjust_mlt_gradT_fraction.
>>>>> 
>>>>> There WAS a bug in some dev versions (soon after 15140) that broke some of this logic, but as far as I recall, that bug was fixed fairly promptly and never impacted a release version. So if you're using a dev version, can you point me to the commit number/hash? I should probably be able to help you diagnose a fix.
>>>>> 
>>>>> Cheers,
>>>>> Evan
>>>>> 
>>>>> 
>>>>>> On Aug 23, 2021, at 12:26 PM, Joey Mombarg <joey.mombarg at kuleuven.be> wrote:
>>>>>> 
>>>>>> Dear mesa-users,
>>>>>> 
>>>>>> I am trying to change the temperature gradient to the adiabatic one in the overshoot zone using the run_star_extras routine from Michielsen et al. 2019, where also atomic diffusion and radiative levitation are turned on. While mesa does indeed report that s% adjust_mlt_gradT_fraction(k) = 1 just before calling adjust_gradT_fraction (around line 668 in star/private/mlt_info.f90, r11701), it seems to be overwritten later in star/private/hydro_vars.f90, around line 565:
>>>>>> 
>>>>>>       if (.not. skip_mixing_info) then
>>>>>>          s% mixing_type(1:nz) = no_mixing
>>>>>>          s% adjust_mlt_gradT_fraction(1:nz) = -1
>>>>>>       end if
>>>>>> 
>>>>>> This condition seems to be fulfilled during the main-sequence evolution when atomic diffusion is turned on. I was wondering why adjust_mlt_gradT_fraction is changed to -1 here, and if there are any objections in removing this behaviour for this particular case? 
>>>>>> 
>>>>>> Kind regards,
>>>>>> Joey
>>>>>> _______________________________________________
>>>>>> mesa-users at lists.mesastar.org
>>>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210824/0960b1f9/attachment.htm>