[Mesa-users] convergence problems in specific mass range
W.H.Ball at bham.ac.uk
Tue Apr 9 07:20:02 EDT 2019
> 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!
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
> 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).
>> * 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,
More information about the Mesa-users