[Mesa-users] Standard Solar Model initialization

[Aaron Dotter]

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/0676264f/attachment.html>