[mesa-users] How does MLT handle core convection?

[Josh Shiode]

Thanks, Bill!

One clarifying question, the same alpha & mixing length (whether rescaled or not) is used for an entire convection zone, right? That is, for a core convection zone, most of the zone will have Hp > r (using the usual definition of Hp), but at the outer edge this may no longer be true. So if dr > Hp(top of core CZ), then use whatever mixing_length_alpha was input and same mixing length throughout? 

And then what about an envelope convection zone where you would expect the mixing length to change significantly with radius?

Thanks,
Josh




On Mar 26, 2013, at 7:13 PM, Bill Paxton wrote:

> Hi Josh,
> 
> On Mar 26, 2013, at 3:20 PM, Josh Shiode wrote:
> 
>> Hey users,
>> 
>> Been trying to figure out exactly what MESA does with the mixing length when scale_height(k) > r(k) as in a stellar core. 
> 
> You are undoubtedly familiar with the "alt" scale height, but for the record let me remind folks about it.
> It is a clever idea I got from Peter Eggleton (thanks again Peter).  It prevents the r -> 0 blow up of the standard def.
> 
>         alt_scale_height_flag = .true.
>            ! if false, then stick to the usual definition -- P/(g*rho)
>            ! if true, use min of the usual and sound speed * hydro time scale, sqrt(P/G)/rho
> 
>> 
>> So I've been rooting around in mlt/private and star/private.
> 
> Excellent!!!!
> 
>> I believe I found the answer in star/private/mix_info.f, but I'm looking for some verification..
>> 
>> It seems that in the subroutine end_of_convective_region it checks to see if the r(ktop) - r(kbot) for the convection zone is smaller than the initial guess at mixing length (s% mixing_length_alpha * s% scale_height). If dr < Hp, but not so small as to be pruned, then it recalculates the mlt info using a smaller alpha set so that Lambda = 0.5 * dr... 
> 
> Almost -- the test is dr < alpha*Hp where dr is the size of the convective zone and Hp is the smaller of the
> scale heights at the top and bottom of the zone.  I think Dave Arnett suggested this addition -- it makes
> sure that we don't use a mixing length that exceeds the size of the convection zone (sounds reasonable).
> 
> As out noticed, if the flag "remove_mixing_glitches" is true and the size of the zone (dr) is < 0.1 the mixing length,
> we just convert the zone to radiative -- i.e., we consider the zone to be a "false alarm" from the MLT.
> 
> Otherwise, we use a reduced alpha to recompute the mlt info for the "bad" convection zone.
> The reduced alpha ensures that the new mixing length <= 0.5*dr.
> 
>> 
>> Is this prescription used both for shell convection zones and core convection zones (where r(kbot) --> 0)?
> 
> The code in question is used with all convection zones -- it doesn't know a shell zone from a core zone.
> 
> Great job finding this.   I hope others will follow your example -- root around in the code, then confirm what you think you've found by a email to the list.   ;-D
> 
> Cheers,
> Bill
> 
> 
>