[Mesa-users] Finding ZAMS
RICHARD H D TOWNSEND
townsend at astro.wisc.edu
Fri Mar 15 13:16:15 EDT 2019
Hi Thomas --
What physical processes or properties in a (real) star could one use, to tell whether the star is pre-MS or on the main sequence? If you can answer this question, then it will be possible to implement a 'better' definition of the ZAMS in MESA.
cheers,
Rich
> On Mar 15, 2019, at 12:03 PM, Thomas Steindl <Thomas.Steindl at student.uibk.ac.at> wrote:
>
> Hi Aaron,
>
> I am sorry, I forgot that. I am trying to investigate the probing power of g-modes on the pre-MS and I would like to compare models that have the same percental age in respect to the model's age at ZAMS ( age(model)/(age(ZAMS_model) ). Without a proper definition of ZAMS I am not able to be certain I am comparing the 'matching models'.
>
> Thomas
>
> Zitat von Aaron Dotter <aaron.dotter at gmail.com>:
>
>> Hi Thomas,
>>
>> In order for us to advise you, it would be helpful for you to answer my
>> first question:
>>
>> "The ZAMS is a hard thing to define precisely. What does it mean for the
>> project you're working on?"
>>
>> Why do you need a precise ZAMS definition? I think you're finding, as
>> others have before, that it is not something that is easily and succinctly
>> defined for the full range of stellar masses.
>>
>> Cheers,
>> Aaron
>>
>> On Fri, Mar 15, 2019 at 12:24 PM Thomas Steindl <
>> Thomas.Steindl at student.uibk.ac.at> wrote:
>>
>>> Hello,
>>>
>>> I have now tried your stopping condition. Therefore, I calculated 21
>>> models in a mass range of 0.5 to 6 solar masses (the 0.775 M_sun
>>> modelled would not converge). The stopping condition works well for
>>> the masses 1.05 - 5ish solar masses depending on where you define the
>>> cut off criterion. For the models with higher masses the ratio L_H/L
>>> never drops below 1 after it first rises above 1. I could avoid this
>>> problem by fitting a linear function in the points on the main
>>> sequence and determine the ZAMS by the first point which is below this
>>> linear fit. Unfortunately, this would not work for the 0.5 -1ish solar
>>> mass as the ratio converges from values above the main sequence value.
>>> What I could do is determing the ZAMS by finding the point which
>>> differs from the linear fit using the main sequence point by some
>>> value. Yet, I wonder if this stopping criterion would still be
>>> physical and not just some way to deal numerical issues?
>>>
>>> I have again attached a zipped folder of the plots that show what I
>>> refer to. Here i have plotted log_L and log_LH in the upper pannel and
>>> LH/L in ther lower pannel. Also the green line shows the determined
>>> ZAMS timestep which is the point on which the ratio drops below 0.9995
>>> when looking at the inverse time.
>>>
>>> Thank you in advance for any help!
>>>
>>> Thomas Steindl
>>>
>>>
>>> Zitat von Aaron Dotter <aaron.dotter at gmail.com>:
>>>
>>> > Hi Thomas,
>>> >
>>> > [Josiah beat me to it!]
>>> >
>>> > The ZAMS is a hard thing to define precisely. What does it mean for the
>>> > project you're working on?
>>> >
>>> > You're seeing the different behavior because of the transition from
>>> > H-burning dominated by the pp chain vs. the CNO cycle. The basic net
>>> > ignores several lesser species that equilibrate once the core gets hot
>>> > enough for the reactions to proceed.
>>> >
>>> > If it's acceptable for you to evolve slightly past the ZAMS and then
>>> > identify a previous timestep as the ZAMS, the following is the procedure
>>> I
>>> > use (in post-processing a MESA history file).
>>> >
>>> > Stop once the central H mass fraction has been reduced by 0.0015 from its
>>> > initial value. Move backward from this point until you find the timestep
>>> > for which the model first L_H/L_tot crosses 0.99, or whatever you want
>>> your
>>> > ZAMS definition to be.
>>> >
>>> >
>>> > Cheers,
>>> > Aaron
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Mar 14, 2019 at 5:30 PM Thomas Steindl <
>>> > Thomas.Steindl at student.uibk.ac.at> wrote:
>>> >
>>> >> Hello,
>>> >>
>>> >> I am working on pre-MS Asteroseismology. Therefore, I am calculating
>>> >> MESA models which I use as input for GYRE. In my analysis, I need to
>>> >> know the timestep at which the star reaches ZAMS. Unfortunately, I
>>> >> fear the stopping conditions implemented in MESA do not work. To show
>>> >> this I have used three different inlists. A first, very simple inlist
>>> >> (Basic_inlist), an inlist with additional varcontrol
>>> >> (additional_varcontrol) and one with additional varcontrol and using
>>> >> the ppandcnoextras net instead of the basic net
>>> >> (additional_varcontrol_and_net). I have also attached the
>>> >> corresponding inlists. In the corresponding png files, I have plotted
>>> >> the values for log_L and log_Lnuc in the upper panel and the ratio
>>> >> L/Lnuc in the lower panel. As you can see, the ratio seems to converge
>>> >> to the value 1 for the first two inlists (for which this stopping
>>> >> criterion works). But for the latter of the three inlists, Lnuc
>>> >> exceeds L at some point in the evolution and the stopping criterion
>>> >> fails.
>>> >>
>>> >> The zip folder 'ZAMS_second_stop_option' contains plots for 30 stellar
>>> >> models computed with the 'additional_varcontrol_and_net' inlist and
>>> >> different masses. In the 30 pngs in this folder I have plotted log_L
>>> >> and log_Lnuc in the upper pannel and
>>> >> abs(log(power_hburn)-log_surface_luminosity) in the lower panel. The
>>> >> title shows the mass of a specific model and the value of
>>> >> L_nuc_counter which states how many timesteps Lnuc/L has been between
>>> >> 0.99 and 1.01. As you can see, the value for the second stop option
>>> >> exhibits drops (mostly while log_Lnuc > log_L) which in terms makes
>>> >> this stop option unreliable and I don't see how it can function as
>>> >> global stop option for all masses.
>>> >>
>>> >> I have tried other options (gravitational energy, contraction speed,
>>> >> etc.), yet I cannot find a criterion. Do you have any idea on which
>>> >> stellar properties I could use? Any help would be greatly appreciated.
>>> >>
>>> >> Thank you in advance,
>>> >> Thomas Steindl
>>> >>
>>> >> _______________________________________________
>>> >> mesa-users at lists.mesastar.org
>>> >> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>
>
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
More information about the Mesa-users
mailing list