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

Josh Shiode jhshiode at berkeley.edu
Wed Mar 27 13:54:04 EDT 2013


I see, so the consideration of min(Hp(kbot), Hp(ktop)) is only used when determining whether this is an anomalously small convection zone (as compared to dr). 

Thanks again, Bill!

--Josh



On Mar 27, 2013, at 10:51 AM, Bill Paxton wrote:

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





More information about the Mesa-users mailing list