[Mesa-users] convergence problems in specific mass range
Thomas Steindl
Thomas.Steindl at student.uibk.ac.at
Tue Apr 9 12:19:46 EDT 2019
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
>>>>
>>>
>>
>>
>>
>
More information about the Mesa-users
mailing list