[Mesa-users] too small timesteps - a way to solve it?
Farag, Eb
farag.11 at buckeyemail.osu.edu
Mon May 30 14:04:26 UTC 2022
Hello Amedeo and Warrick,
In 15140, I have found it difficult to get very massive stars off the main-sequence without adopting some sort of time dependent convective treatment, (e.g 'conv_vel_flag' in r15140). If not turned on, you might encounter strange behavior like the mixing of the h-envelope back into the H-depleted core over and over, going through multiple main-sequence phases until you are left with a 100 Msol He-core. I believe you can add 'conv_vel_flag' to account for decaying (dark blue, 'leftover' in the kipp diagram ') convection, not handled by the standard mlt solver. However, I believe this is a sort of bandage fix with some assumptions, and perhaps the TDC solver in r21.12.1 can handles this better? I'm not very informed on exactly how this is implemented, so perhaps a more experience mesa user can correct me.
As for getting past your time step dive, try adopting the following in your star job:
&star_job
logT_for_conv_vel_flag = 7d0 ! turn on conv_vel after logT>= 7d0
/ ! end of star_job namelist
By adding this to the basic inlist provided by Warrick, I managed to get the star to h-depletion at model_number 1131, with no hiccups.
Cheers,
Eb
________________________________
From: Mesa-users <mesa-users-bounces at lists.mesastar.org> on behalf of Warrick Ball <W.H.Ball at bham.ac.uk>
Sent: Monday, May 30, 2022 8:32 AM
To: amedeoromagnolo at gmail.com <amedeoromagnolo at gmail.com>
Cc: mesa-users <mesa-users at lists.mesastar.org>
Subject: Re: [Mesa-users] too small timesteps - a way to solve it?
Hi Amedeo,
I've been experimenting with simple inlists for stars around 90-100 Msun. I agree with you that there's an issue here. I find that runs often stall near the end of the main sequence, when the central hydrogen abundance is around 0.1. The following short inlist for r15140 demonstrates this:
&star_job
create_pre_main_sequence_model = .true.
pre_ms_T_c = 9d5
/ ! end of star_job namelist
&eos
/ ! end of eos namelist
&kap
use_Type2_opacities = .true.
Zbase = 0.02
/ ! end of kap namelist
&controls
! starting specifications
initial_mass = 100 ! in Msun units
initial_z = 0.02
! options for energy conservation (see MESA V, Section 3)
use_dedt_form_of_energy_eqn = .true.
use_gold_tolerances = .true.
! stop when the center mass fraction of h1 drops below this limit
xa_central_lower_limit_species(1) = 'h1'
xa_central_lower_limit(1) = 1d-3
/
This does eventually finish at model number 5030.
We probably need someone more experienced with such massive stars to progress further. Here are a few notes on what I've run into so far but I think I've used up all the time I can spare on MESA issues. I apologise if these are unhelpfully incoherent but I hope there's something a (very) massive star expert can latch on to.
I noticed that following the star in detail from a pre-MS model works better than letting that model evolve until a radiative core develops (usually at the bottom of the Hayashi track). So try adding
pre_ms_relax_to_start_radiative_core = .false. ! instead of .true.
to your `&star_job` namelist. When added to the inlist above, the run still starts struggling at a central hydrogen abundance of 0.02 but it reaches the stopping condition (Xc<0.001) at model number 1824.
Though I haven't tested extensively, I get similar stalling behaviour in r21.12.1 and r22.05.1 but whether or not I follow the pre-MS evolution doesn't seem to matter.
If you want to try to progress on your own, I can only suggest perhaps starting at a mass that does work and then slowly increase it. e.g. I had no problems at M = 60 Msun. Also, have a close look at what's happening in the profiles, either with PGstar or by plotting them afterwards. I haven't had a close look at anything but I also noticed that for masses greater than 90 Msun, the pre-MS builder creates a 90 Msun model and adds mass (using `do_relax_mass_scale`). Perhaps that's leaving artifacts that affect these stars later.
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 Mon, 30 May 2022, amedeoromagnolo at gmail.com wrote:
> Hi!
>
> I have run a few models with all the potential combinations of mixing processes. Even by taking everything off unfortunately I get always the same small dt .
> Could it be that MESA cannot simply simulate stars this massive at this metallicity?
>
> Because for other setups, like ZAMS mass = 100 + Z = 0.00142 or ZAMS mass = 20 + Z = 0.03 it was actually running pretty smoothly, even with all the active mixing processes
>
> Have a nice beginning of the week,
>
> Amedeo
>
> On Fri, 27 May 2022 at 15:46, Warrick Ball <W.H.Ball at bham.ac.uk> wrote:
> Hi Amadeo,
>
> Thanks for removing all the mesh and timestep controls. That already helps a bit.
>
> I haven't run anything yet but I'm quite suspicious about the number of different mixing processes you have going on. In particular, you've got all of thermohaline, semiconvection, convective premixing *and* two overshoot schemes, so my
> gut feeling is that these are interacting in some unexpected way.
>
> Can you try removing convective premixing? If that doesn't help, try turning off/removing all the extra mixing controls then adding each component in one at a time.
>
> If we can figure out which set or combination of controls causes the problem, it'll help a lot to figure out why dt drops.
>
> 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 Fri, 27 May 2022, amedeoromagnolo at gmail.com wrote:
>
> > Hi Warrick,
> >
> > as a matter of fact you are correct: the inlist I sent was just a template. Attached an inilist of a "minimal working example" with some extreme situations, i.e., initial mass = 100 Msun and initial metallicity = 0.03.
> >
> > Like in the previous case, I get stuck in the Main Sequence at log(dt) ~ 1.2
> >
> > Cheers and have a nice weekend,
> >
> > Amedeo
> >
> > On Thu, 26 May 2022 at 13:00, Warrick Ball <W.H.Ball at bham.ac.uk> wrote:
> > Hi Amedeo,
> >
> > Timesteps decreasing to zero is usually a symptom of MESA struggling with something happening in your star, so the first thing we're trying to do is guide you to figure out *why* that's happening. I just had a look at your
> inlist, and
> > there is a *lot* going on in there, which will make this hard to decipher. You also haven't really told us what you're trying to model other than "very massive stars at high metallicity", and your inlist has
> >
> > initial_z = 0.00142
> >
> > which implies *low* metallicity, rather than high.
> >
> > I would suggest cutting your inlist right back down to almost nothing, then slowly add controls back in until you get your problem again, then remove irrelevant controls that you added so that we end up with what we call a
> "minimal
> > working example": a small inlist that reproduces the problem. Then we can probably start looking at detailed output and figuring out why the run stalls halfway along the main-sequence, with a better idea of which controls are
> causing a
> > problem.
> >
> > 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 Thu, 26 May 2022, mesa-users at lists.mesastar.org wrote:
> >
> > > Hi Anne,
> > >
> > > I did indeed put those lines to see what happens, but unfortunately I'm not familiar enough with MESA debugging to actually understand what it does mean.
> > >
> > > First of all any reference on this regard would be much appreciated.
> > >
> > > Secondly, here attached is an example of the debugging output
> > >
> > > Amedeo
> > >
> > > On Tue, 24 May 2022 at 16:19, Anne Thoul <anne.thoul at gmail.com> wrote:
> > > Dear Amadeo,
> > > Thank you.
> > >
> > > Have you looked at which criterion defines the timestep when it gets tiny?
> > > This appears as dt_limit on your screen while you run the code.
> > >
> > > You might want to see what happens when you use a higher value for varcontrol_target; the (recommended) default is now 1d-3.
> > > See the docs for changes in r15140:
> > > "The option varcontrol_target is NOT the recommended way to push time resolution to convergence levels. To perform temporal convergence studies, use the new control time_delta_coeff, which acts as a multiplier for timestep
> limits
> > (analogous
> > > to mesh_delta_coeff for spatial resolution).
> > >
> > > One strategy for choosing effective timestep limits is to first set varcontrol_target = 1d-3."
> > >
> > > You could also use the following for info about what limits the timestep:
> > > "Summary information about the conditions that limited the timestep can be printed at the end of run using the star_job option show_timestep_limit_counts_when_terminate. «
> > >
> > > I see that you have the following debugging lines in your inlist:
> > > "report_all_dt_limits = .true.
> > > report_why_dt_limits = .true.
> > > report_solver_dt_info = .true. »
> > > What do these say?
> > >
> > > I am not an expert for stars that are that massive, but I am sure others with more knowledge will chime in.
> > >
> > > Anne
> > >
> > >
> > >
> > >
> > >
> > >
> > > Le 24 mai 2022 à 13:00, Amedeo Romagnolo <amedeoromagnolo at gmail.com> a écrit :
> > >
> > > Dear Anne,
> > >
> > > Thanks for pointing this out. My version is 15140 .
> > > I made a movie with all that's happening in my simulations (I put it in filesharing because it was too big as an attachment).
> > > Attached the inlist.
> > >
> > > Amedeo
> > >
> > > https://urldefense.com/v3/__https://wetransfer.com/downloads/17a09e08cd19ff9b74af3414fdb6da8b20220524105620/d047a9a16bd2965bb27894027e95281920220524105630/82dbc6__;!!KGKeukY!zrTO4TTu2ScVzzhHFO52j5Bb4khOvdse2OG0lzMJIZcs87k1tX_0CZkWljv63ULgShB-JLVcp1Bs7uIVi4wMqby5bS0BFm0$
> > >
> > >
> > > On Tue, 24 May 2022 at 09:37, Anne Thoul <anne.thoul at gmail.com> wrote:
> > > Hi Amadeo,
> > >
> > > Your message lacks the necessary information that might make it possible for someone to help you, such as inlists, some figures, exact time when the problem starts, mesa version you are using etc.
> > >
> > > Anne
> > >
> > > > Le 24 mai 2022 à 09:33, Amedeo Romagnolo via Mesa-users <mesa-users at lists.mesastar.org> a écrit :
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I have a problem regarding simulating very massive stars at high metallicity.
> > > > The problem is that, despite not getting any abrupt end of the simulation, The stellar evolution seems to be stuck in the middle of the main sequence with so little timesteps that nothing ever changes.
> > > >
> > > > So my question would be: is there any way one could compensate for this problem in any possible way?
> > > >
> > > > Cheers,
> > > >
> > > > Amedeo
> > > > _______________________________________________
> > > > mesa-users at lists.mesastar.org
> > > > https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!zrTO4TTu2ScVzzhHFO52j5Bb4khOvdse2OG0lzMJIZcs87k1tX_0CZkWljv63ULgShB-JLVcp1Bs7uIVi4wMqby5LY7hhiM$
> > > >
> > >
> > > <inlist_project>
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
_______________________________________________
mesa-users at lists.mesastar.org
https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!zrTO4TTu2ScVzzhHFO52j5Bb4khOvdse2OG0lzMJIZcs87k1tX_0CZkWljv63ULgShB-JLVcp1Bs7uIVi4wMqby5LY7hhiM$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220530/3261b67c/attachment.htm>
More information about the Mesa-users
mailing list