[Mesa-users] Standard Solar Model initialization

Tue Oct 9 23:15:42 EDT 2018

Hello again,

I tried setting create_pre_main_sequence_model = .true. and adding the
lines to save at model 370, while turning off the part that loads from a
model, and I've encountered some problems. When I run the model, I find
that I get the same warnings that I did last time:
"first model is slow to converge: num tries         250"
"hydro_newton_step failed to accept"
and  "have reached retry limit so now backup"
It doesn't sound like I'm supposed to receive these warnings if the model
were working properly. Are some of the more advanced physics getting in the
way when I try to initialize from a pre-main sequence model? It appears to
be struggling before the first step as many warnings appear after
"relax_num_steps" and before "finished relax_num_steps".

Furthermore, it seems that my timestep sizes are much larger than those of
the solar_calibration_input.mod model because at model number 370 the
example model is 1.4 million years old, but my model is already ~ 3 billion
years old. Do you know how the example model controlled the size of its
time steps, and if not do you have advice on how to take small enough steps
to avoid these errors, but large enough ones to not spend forever on the
pre-main sequence?

I've attached my new inlists to make a pre-main sequence model if you want
to reproduce the errors I found.

Thanks so much for your help,
Noah Tuchow

On Tue, Oct 9, 2018 at 9:29 PM Aaron Dotter <aaron.dotter at gmail.com> wrote:

> Hi Noah,
>
> You can start with create_pre_main_sequence_model = .true. add the
> following lines:
>
> save_model_number = 370
> save_model_filename = 'my_model.mod'
>
> in the star_job section of your inlist.  Of course, 370 can be any number
> you choose.  I'd recommend saving a model that is still on the Hayashi line
> but beyond that the exact reason for 370 is lost to time.
>
> I don't think there was anything special or different about the inlist
> used to create the solar_calibration_input.mod.  I think it was the same
> inlist but run starting from create_pre_main_sequence_model=.true. and then
> saving a model at a certain point.  Again the point is only to save time
> that it takes the test_suite to run.
>
> Your case with changing mass complicates things, certainly.  You can
> either generate a grid of starting masses and compositions, etc. that will
> cover everything you need or just begin from
> create_pre_main_sequence_model.  That has the advantage of being flexible
> enough to accommodate changing initial mass and so on.
>
> Aaron
>
>
> On Tue, Oct 9, 2018 at 5:28 PM Noah Tuchow <nxt5109 at psu.edu> wrote:
>
>> Thanks for the quick reply.
>>
>> I suppose that rather than recreating this model file exactly, using the
>> 2010 version of MESA, I would like to try and use the current version of
>> MESA to create a very similar model which incorporates the same physics. To
>> do this, I am interested to know how exactly the length of the first 370
>> timesteps was specified, and which modern inlist arguments would be
>> analogous to those used back in 2010.
>>
>> When I referred to MESA crashing, I realize that I was referring to an
>> earlier version of my inlist where in the first few steps it would reach
>> the max number of retries and quit. Now if I run MESA while setting
>> load_saved_model= .false., it struggles on the first steps giving me
>> multiple messages that the first model is slow to converge after 250 tries,
>> and that the hydro_newton_step failed to accept. It will still run until I
>> tell it to stop at the current age, but the output will be a bit off. It
>> makes sense why one would use a separate inlist for the first few steps to
>> avoid these errors and save a model file. I would like to know how I can
>> best replicate the type of pre-main sequence contraction that was used to
>> make the earlier model file in order to make my own model files starting
>> from slightly different initial conditions. For instance, if I wanted to
>> consider the sun as having an initial mass of 1.01 solar masses and losing
>> 0.01 msun from some custom mass loss mechanism, I imagine I would have to
>> use a different model file than the solar_calibration_input.mod.  How would
>> you recommend that I model the first few timesteps of pre-main sequence
>> contraction in a way consistent to the methods used to create the
>> solar_calibration_input.mod model file?
>>
>> Thanks for your assistance,
>> Noah Tuchow
>>
>> Noah TuchowPenn State UniversityDepartment of Astronomy and Astrophysics532C
>> Davey LabUniversity Park, PA 16802
>>
>>
>> On Tue, Oct 9, 2018 at 8:38 AM Aaron Dotter <aaron.dotter at gmail.com>
>> wrote:
>>
>>> Hi Noah,
>>>
>>>
>>>
>>>  but find that both my model and the test_suite example don't appear to
>>>> be initialized from the premain sequence and instead load a model from the
>>>> file 'solar_calibration_input.mod'. I'd like to know how exactly this model
>>>> file was made and with what inlist
>>>>
>>>
>>> solar_calibration_input.mod was made using a previous version of the
>>> inlist used in the solar calibration test suite case you're running.  Also
>>> a previous version of MESA and (likely pre-MESA SDK) compiler.  If you look
>>> at the contents of the file, you'll see the creation date is 20100823 so
>>> it's 8 years old.
>>>
>>> I'm a bit confused as to what exactly the model I'm loading is, because
>>>> some of the arguments used in the solar calibration inlist in the example
>>>> appear to be for initializing a premain sequence model with from a cloud
>>>> with uniform composition, specified mass fractions and abundances.
>>>>
>>>
>>> The purpose of using such a model is to skip over the first 370
>>> timesteps (model number is 371) of pre-main sequence contraction and the
>>> construction of the pre-main sequence structure.  This saves a fair amount
>>> of time without causing egregious errors in the results.
>>>
>>>
>>>> I've noticed that MESA crashes if I keep all the inlist arguments the
>>>> same values and just start with set_uniform_initial_composition = .true.
>>>> without loading the model, and I think that this is likely due to
>>>> having which_atm_option = 'photosphere_tables'.
>>>>
>>>
>>> What do you mean by "MESA crashes"?  What does the terminal output say?
>>> If you try to run the solar calibration inlist without loading a model AND
>>> without setting create_pre_main_sequence_model = .true., MESA will try to
>>> load a ZAMS model but it's unlikely to have one with your specific
>>> composition.  It's unlikely that this has anything to do with
>>> photosphere_tables for the atm.
>>>
>>>
>>>
>>>> Since this example doesn't appear to have any documentation, I'm
>>>> curious to know how this model file was made and what I should do to
>>>> initialize a model for a slightly different sun.  Does anyone have the
>>>> inlists used to make the model file?
>>>>
>>>
>>> See my first response above.  It's possible that the model could be
>>> recreated with MESA circa mid-2010 but I don't think it's worth the
>>> trouble.
>>>
>>> Aaron
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20181009/84cd6981/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist
Type: application/octet-stream
Size: 652 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20181009/84cd6981/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_init
Type: application/octet-stream
Size: 5800 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20181009/84cd6981/attachment-0001.obj>