[mesa-users] Cepheid loops - comparison

[Radek Smolec]

Thanks a lot Aaron. I repeated the computation for some tracks with
which_atm_option='Eddington_grey'. Location of the RGB is now the same in
MESA and Padova tracks - the agreement is perfect!
Thanks,
Radek


2013/1/16 Aaron Dotter <aaron.dotter at gmail.com>

> Hi Radek,
>
> Thanks for providing these comparisons!  It is always encouraging to see
> that two codes doing almost the same thing obtain almost the same answer.
>
> If you add
>
> which_atm_option = 'Eddington_grey'
>
> to your inlist, then you should even more closely match the Padova code.
>  (I believe the version of FRANEC used for the BaSTI models uses instead
> 'Krishna_Swamy'.)  MESA uses 'simple_photosphere' by default for the
> atmosphere boundary condition; different atmosphere BCs will produce
> different temperature scales for the same mixing length parameter,
> particularly for cooler, more extended stars.
>
> The choice of atmosphere BC and solar-calibrated mixing length parameter
> are closely related.  We typically see values of alpha_MLT~1.7 for
> Eddington, while alpha_MLT~2 for Krisha-Swamy.  I'm not sure what
> corresponds to the simple photosphere...
>
> Aaron
>
>
> On Wed, Jan 16, 2013 at 9:24 PM, Radek Smolec <smolec at camk.edu.pl> wrote:
>
>> Dear MESA users,
>>
>> Since the issues of comparison between other codes and MESA, and the
>> sensitivity of the blue loops were raised recently in this forum I want to
>> share some results.
>>  In the attached pdf you can find the evolutionary tracks for
>> intermediate mass stars and different metallicities computed with MESA and
>> compared with the published tracks (Bertelli et al. 2009, Padova code). In
>> the inlist the parameters were set to match the ones used by Bertelli et al
>> (MLT alpha, overshooting, etc.) closely. The tracks are in a very good
>> agreement for all metallicities. I am a little concerned with the location
>> of RGB. The MESA tracks are shifted to the red; smaller the metallicity
>> larger the shift. The location of RGB depends primarily on the mixing
>> length - I used alpha=1.68, as adopted in the Padova code. Now I am also
>> checking different MLT options in MESA but so far it doesn't help. Any
>> other ideas how to shift the RGB (without changing alpha)?
>>
>> I have done similar comparison also for the BaSTI tracks (again adjusting
>> MESA parameters to match that used by Pietrinferni et al. closely) and got
>> similar agreement between MESA and BaSTI tracks.
>>
>> All computations were done with MESA 4631/SDK running on Ubuntu.
>> Exemplary inlist is attached - M, Z and name of the ZAMS model's file
>> (which I created) were changed for particular tracks.
>> Note that if this inlist is run with the current version of MESA the
>> error will be reported as the control "use_lnE_for_eps_grav = .true." is no
>> longer available. Is .true. the default value now?
>>
>> Now I investigate the effects of rotation on the loops and have some
>> problems with it, which I will address in a separate message.
>> cheers,
>> Radek
>>
>> ------------------------------------------------------------------------------
>> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
>> and much more. Keep your Java skills current with LearnJavaNow -
>> 200+ hours of step-by-step video tutorials by Java experts.
>> SALE $49.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122612
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130116/93cc9c26/attachment.html>