[Mesa-users] convergence problems in specific mass range

Tue Apr 9 14:34:35 EDT 2019

Hello Bill,

thank you for your help!

I have tried what you suggested and found that the problem does not  
arise as long as I exclude the varcontrol target.

Interestingly, the 0.56 solar mass model converges for one inlist but  
not for another one, for which i struggle to find the difference.  
While mesh_delta_coefficient=0.1 yields a spatial resolution big  
enough that the model again converges, even a value of 0.05 is not  
sufficient for the 0.55 solar mass model. Well, I think this is a good  
time to stop for today. I will come back to you tomorrow.

Meanwhile, thanks again for your help.

Thomas

Zitat von Bill Paxton <paxton at kitp.ucsb.edu>:

> 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
>>
>
>