[Mesa-users] convergence problems in specific mass range

Bill Paxton paxton at kitp.ucsb.edu
Tue Apr 9 13:01:40 EDT 2019 

Hi Thomas,

It is a good strategy in situations like this to see if simplifications in the inlist can give something that runs ok.

You’ve started this process by considering a different net and turning off convective premixing.

But don’t stop there!   A quick check of your inlist suggests several more things to try.

Here’s a list of changes that i find to be sufficient to get the 0.55M case to run through the pre_ms in 972 steps, with 0 retries or backups.  You might start from this and then restore your desired settings one-by-one to determine where things break.

comment out these lines:

    !which_atm_option = 'Eddington_grey'
    !do_conv_premix = .true.
    !mesh_delta_coeff = 0.3 !0.3 
    !scale_max_correction=0.1d0
    !varcontrol_target=3d-5

Try that and see if it runs similarly to what i found.

If so, then uncomment start uncommenting those lines to see which ones are causing the problems.

If not, let us know.

-B






> On Apr 9, 2019, at 9:19 AM, Thomas Steindl <Thomas.Steindl at student.uibk.ac.at> wrote:
> 
> Hi Warrick,
> 
> I have been playing around with nets for some hours now. What I have found is:
> 
> Using pp_extras.net helps that the convergence problems occur later + it runs longer with very small timesteps (log dt ~ -10). Therefore even the change from pp_extras.net to pp_and_cno_extras.net has influence on how the model converges in this evolutionary area. Yet, I do not find anything that differs in the 0.55 solar mass model in comparison to the other models..
> 
> Thanks again,
> Thomas
> 
> Zitat von Warrick Ball <W.H.Ball at bham.ac.uk>:
> 
>> Hi Thomas,
>> 
>>> Changing the net to basic.net resolves the problem, so the issue might be correlated to the net. Even if I run from step 1500 with a photo from the evolution with basic net, the problem doesn't arise. So something from the deuterium burning phase?
>> 
>> Aha!  That's a useful clue.  To keep new runs faster, I'd suggest turning off convective premixing for the time being.  You can turn it back on again once we've got past our potentially deuterium-related issues.  What happens if you run with the net `pp_extras.net`?  I presume that halts at the same point but it's worth checking.
>> 
>> Try adding all the species in your net to the profiles and looking at whether they evolve sensibly.  You can do this by adding/uncommenting `add_abundances` in `profile_columns.list`, in which case the profile will have columns like `h1`, `h2`, `he3`, etc. for all the species in the net. You should probably check the first profile too, to make sure that all the abundances are being set to valid/specified values.
>> 
>> I'd also suggest searching the MESA users archive for messages about deuterium burning, in case someone has run into a similar issue before.
>> 
>> Such low-mass stars aren't my speciality, so I can only make suggestions to guide you toward a potential solution.  Good luck!
>> 
>> Cheers,
>> Warrick
>> 
>> 
>> ------------
>> Warrick Ball
>> Postdoc, School of Physics and Astronomy
>> University of Birmingham, Edgbaston, Birmingham B15 2TT
>> W.H.Ball at bham.ac.uk
>> +44 (0)121 414 4552
>> 
>> 
>> On Tue, 9 Apr 2019, Thomas.Steindl at student.uibk.ac.at wrote:
>> 
>>> Hello Warrick,
>>> 
>>> First, thank you for help!
>>> I am attaching some files to provide the missing context.
>>> 
>>> 1. When the problems arises, the star is still in it's pre-main sequence phase, but beyond the phase in which it is exhibiting strong deuterium burning. The first retry comes at step 1741, when log_LH is still around -4. It is at the point of evolution in which the temperature starts to rise again (see tracks.png). The big points corresponds to step 1741 in all three evolutions, and they seem to correspond well to each other. Concerning profiles, the opacity profile looks exactly the same for all three masses at this step (opacities.png). The same holds for logT and logP (see logT.png and logP.png).
>>> 
>>> 2. 'Working' means for me, that the evolution finished at the point where central hydrogen abundance reaches the value 0.66. The models with 0.54 and 0.56 solar masses reach this point after ~2380 steps.
>>> 
>>> Switching of convective premixing will of course make the evolution run much faster but it still shows the same convergence problems. Changing the net to basic.net resolves the problem, so the issue might be correlated to the net. Even if I run from step 1500 with a photo from the evolution with basic net, the problem doesn't arise. So something from the deuterium burning phase?
>>> 
>>> You are right, the inlist is kind of a mess. This has it's reasons, but i forgot to check it before sending this mail, I am sorry. I am resending a more tidy version of it.
>>> 
>>> Again, thank you for your help!
>>> 
>>> Zitat von Warrick Ball <W.H.Ball at bham.ac.uk>:
>>> 
>>>> Hi Thomas,
>>>> 
>>>> I've started running your inlist but it's quite slow and it would anyway be helpful if you could provide a lot more context.  For example, you've said that MESA starts doing retries and backups "at some point", which you've also mentioned is around model number 1800.  But what point in the star's evolution is this? e.g. has it started burning hydrogen yet?
>>>> 
>>>> You've also mentioned that your inlist "works" (without having told us in the email what it means to "work", though the inlist has a stopping condition of X_c=0.66) for masses M/Msun = 0.54 or 0.56.  What's the difference between these three runs? i.e. if you compare the histories of the three runs at M/Msun = 0.54, 0.55 and 0.56, what changes?  What about profiles for each mass around model number 1800?  And the corresponding age (or central hydrogen abundance)?
>>>> 
>>>> Another typical thing to do is try switching off your non-default options and build back up to the inlist that's not working the way you expect. For example, I noticed you're using convective premixing.  Have you tried switching that off?  What does that tell you?
>>>> 
>>>> These are just some ideas for the kinds of things you can look into that will make it easier for someone (yourself included!) to identify a solution to your problem.  It sounds like you've already computed enough data to ask these more specific questions.
>>>> 
>>>> It's also a good idea to clean up your inlists to only contain values that have been changed from the defaults.*  It makes it easier for others to identify potential issues and rules out some.  For example, you're using the non-default reaction network (`pp_cno_extras_o18_ne22.net`).  Does the problem persist if you use `basic.net`?  If so, you can just remove all of that from the inlist (and it'll allow us to reproduce the problem faster).
>>>> 
>>>> Cheers,
>>>> Warrick
>>>> 
>>>> * Similar advice is given at the beginning of the default `star/work/inlist_project` file:
>>>> 
>>>> !  For the sake of future readers of this file (yourself included),
>>>> !  ONLY include the controls you are actually using.  DO NOT include
>>>> !  all of the other controls that simply have their default values.
>>>> 
>>>> 
>>>> ------------
>>>> Warrick Ball
>>>> Postdoc, School of Physics and Astronomy
>>>> University of Birmingham, Edgbaston, Birmingham B15 2TT
>>>> W.H.Ball at bham.ac.uk
>>>> +44 (0)121 414 4552
>>>> 
>>>> 
>>>> On Tue, 9 Apr 2019, Thomas.Steindl at student.uibk.ac.at wrote:
>>>> 
>>>>> Hello everyone,
>>>>> 
>>>>> I am running the same inlist for masses between 0.5 and 6 solar masses with steps of 0.05 solar masses. For some reason, the evolution of the 0.55 solar mass model stops after roughly 1800 steps. All other masses work. If I change the mass to 0.54 solar masses, it works (same for 0.56). Therefore, there is something weird happening in the mass range around 0.55. I have been looking at the temperature, pressure, opacity and density profiles, yet I cannot find unexpected behavior.
>>>>> 
>>>>> To clarify what happens: I am using MESA version r11532. At some point MESA starts doing retrys and backups until the timestep is to small. Taking a smaller limit for min_timestep_limit does not work - it will still stop. I have been checking the output of the newton solver - it takes up to 25 iterations at the end until giving up either because of average, max resid or tiny corrections. Additionally, using things like soften_grad_T do not improve the convergence substantially, the evolution just stops a few steps later.
>>>>> 
>>>>> I am attaching the inlist. I would appreciate any help for resolving this problem. Thank you very much in advance.
>>>>> 
>>>>> kind regards,
>>>>> Thomas
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>

More information about the Mesa-users mailing list