[Mesa-users] Standard Solar Model initialization

[Francis Timmes]

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


i see such warnings on many of the "initial cloud" to to pre-ms models that i run
(i.e., create_pre_main_sequence_model = .true.). i'm not too concerned that 
the zeroth order initial guess that mesa makes might take a bit more effort 
on the first step to bring the initial guess in-line with the equations being solved.

fxt








> On Oct 9, 2018, at 8:15 PM, Noah Tuchow <nxt5109 at psu.edu> wrote:
> 
> 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 Tuchow
> Penn State University
> Department of Astronomy and Astrophysics
> 532C Davey Lab
> University 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
> <inlist><inlist_init>_______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users