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

[Bill Paxton]

Hi,

The same alpha is used everywhere in the star (except for exceptionally small zones as you pointed out).

The mixing length at each point is alpha times the local scale height at that point (NOT an average scale height).
So the mixing length will change in a convection zone as the local scale height changes.

-B


On Mar 27, 2013, at 10:41 AM, Josh Shiode wrote:

> 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
>> 
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users