[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