[mesa-users] create_pre_ms_model sometimes slow with T(tau) atmosphere relations

Bill Paxton paxton at kitp.ucsb.edu
Wed Oct 7 12:57:39 EDT 2015


Hi Warrick,

Yup --- that one requires a work around for now --- the create_pre_ms routines does a good job, but it isn't perfect.  The 1st model will still need some adjustments by the normal newton solver to get it into a form that is a happy solution to use further evolution.  If you stray from simple vanilla options at the start, it can sometimes make the initial convergence too difficult.  Someday someone will modify the create pre ms scheme to include the necessary convergence with vanilla parameters before it hands off the 1st model in a form that might survive parameter changes.  Until that happens, create the model with parameters that are "simple" so that you get convergence, save that model, and restart using that as starting model and change parameters as desired.  Or avoid the start-stop-start by doing it in your run_star_extras.  Or write the changes for create_pre_ms model and everyone will benefit. ;D

Cheers,
Bill




On Oct 7, 2015, at 8:51 AM, Warrick Ball wrote:

> Hi all,
> 
> This issue isn't a dealbreaker for me, but I figured it's probably worth bringing up in case someone else knows a solution.  Attached is an inlist for a typical work directory (r7624), which uses the create_pre_ms_model option in &star_job to create a pre-main-sequence stellar model with central temperature around 8.5e5 K.
> 
> If I run with the default atmosphere (i.e. by commenting out which_atm_option), everything runs just fine.  However, if I try with
> 
> which_atm_option = 'Eddington_grey'
> 
> MESA seems to have a hard time converging the first model.
> 
> create pre-main-sequence model
>                                                species           8
> abundances
>                                                     h1    7.0000000000000007D-01
>                                                    he3    2.9797635251138625D-05
>                                                    he4    2.7997020236474895D-01
>                                                    c12    3.4416106108120410D-03
>                                                    n14    1.0081585468366043D-03
>                                                    o16    9.3604466091399760D-03
>                                                   ne20    2.0994599496976492D-03
>                                                   mg24    4.0903242835137509D-03
> 
> 
>                                        relax_num_steps
> 
> hydro_newton_step returned ierr       retry cnt, step, log10(dt/yr), retry_factor     1     1       -5.602060        0.500000
> hydro_newton_step returned ierr       retry cnt, step, log10(dt/yr), retry_factor     2     1       -5.903090        0.500000
> have reached retry limit so now backup
> hydro_newton_step returned ierr       retry cnt, step, log10(dt/yr), retry_factor     1     1       -8.204120        0.500000
> hydro_newton_step returned ierr       retry cnt, step, log10(dt/yr), retry_factor     2     1       -8.505150        0.500000
> first model is slow to converge: num tries          70
> first model is slow to converge: num tries          80
> first model is slow to converge: num tries          90
> first model is slow to converge: num tries         100
> first model is slow to converge: num tries         110
> first model is slow to converge: num tries         120
> first model is slow to converge: num tries         130
> first model is slow to converge: num tries         140
> first model is slow to converge: num tries         150
> first model is slow to converge: num tries         160
> first model is slow to converge: num tries         170
> first model is slow to converge: num tries         180
> have reached retry limit so now backup
> first model is slow to converge: num tries         190
> <snip>
> first model is slow to converge: num tries         350
> 
> after which it gets going as usual.  Things are similarly slow if which_atm_option is set to the other T(tau) relations: 'solar_Hopf_grey' or 'Krishna_Swamy'.  In my experience, this is more of a problem at masses between about 1.4 and 1.9 solar.  I haven't experimented much at higher masses.
> 
> So, why would the T(tau) relations cause such problems?
> 
> I've tried to track down where exactly the problem comes in, but I didn't really get anywhere.  The error message is generated in star/private/hydro_mtx.f90, but that's not terribly useful.  I think that's just where the matrix for the relaxation iterations is set up.  So I'm currently trying to follow my way through all the function calls to see where the atmosphere is called and what effect that has.  I'm trying to work backwards from calls to the atmosphere T(tau) relations and forwards from the pre-main-sequence model routines, but the two threads haven't connected yet...
> 
> Anyway, has anyone else come across this problem and, if so, worked around it?  Or is there somewhere obvious I should look to try to fix things?
> 
> Cheers,
> Warrick
> 
> 
> 
> ------------
> Warrick Ball
> Postdoc, Institut für Astrophysik Göttingen
> wball at astro.physik.uni-goettingen.de
> +49 (0) 551 39 5069<inlist_project.txt>------------------------------------------------------------------------------
> Full-scale, agent-less Infrastructure Monitoring from a single dashboard
> Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
> Physical-Virtual-Cloud Infrastructure monitoring from one console
> Real user monitoring with APM Insights and performance trend reports 
> Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users





More information about the Mesa-users mailing list