[Mesa-users] Convergence issues solved by changing a_mlt
Joergensen, Johannes Holm
Johannes.Joergensen at uibk.ac.at
Thu Mar 27 11:01:08 UTC 2025
Hi again Jared and Pablo,
thank you both for your detailed suggestions.
Tuning the "leak_frac_factor" actually helped my model overcome an episode of high accretion rate. I would need to investigate how it affects the model beyond this point. Would it make sense for this parameter to be tweaked on the fly? So that when high accretion rates are encountered I set this parameter to zero, else 1? In the earliest phases of my models fx - when the mass is only 0.01 MJupiter - this parameter does not seem to help (the radius starts oscillating).
I'm hesitant to implement this in all my models, so I will also check the time-step criteria as suggested by Jared. Rather than setting time_delta_coeff arbitrarily low, I have written a short routine in run_stars_extras to update the time-step limit based on the accretion rate:
if (s% mstar_dot/Msun*secyer > 5d-6) then
s% delta_mdot_limit = 0.2 !0.05
s% delta_mdot_hard_limit = 0.5 !0.25
else if (s% mstar_dot/Msun*secyer > 5d-5) then
s% delta_mdot_limit = 0.01
s% delta_mdot_hard_limit = 0.1
else
s% delta_mdot_limit = -1
s% delta_mdot_hard_limit = -1
end if
We are reading accretion rates from tables accretion histories and updating the accretion rate as the model reaches the next age value.
Thanks again for your replies, I will keep you updated on my progress.
Cheers! Johannes
________________________________
Fra: Jared Goldberg <jgoldberg at flatironinstitute.org>
Sendt: 26. marts 2025 18:50:13
Til: Pablo Marchant
Cc: Joergensen, Johannes Holm; mesa-users at lists.mesastar.org
Emne: Re: [Mesa-users] Convergence issues solved by changing a_mlt
We never mind reviving a thread with new considerations!
Ultimately, if your accretion timescale (~ Mstar/Mdot) is faster than a dynamical time or a thermal timescale, you will be out of hydrostatic or thermal equilibrium respectively, so you will need to have small enough timesteps to resolve those changes, and the code won't be so happy. Your timestep should never be anywhere close to Mstar/Mdot.
One thing I have found very helpful for variable accretion is pre-emptively setting smaller timesteps directly based on the accretion rate (e.g. setting dt for this step or the next step in run_star_extras), rather than tightening timesteps based off other numerical tolerances or targets (e.g. playing with time_delta_coeff or varcontrol_target). Specifically, if you know the accretion rate ahead of time (e.g. if you're calculating it or reading/interpolating from a table), you can limit your timestep in run_star_extras so that one timestep will always add only a small amount of mass. This helps prevent a few "lots of accretion" (relative to a thermal accretion rate) timesteps pushing the model to unphysical conditions and then choking. There are other controls that can do something like this (e.g. delta_mstar -- see timestepping controls <https://docs.mesastar.org/en/latest/reference/controls.html#timestep-controls> in controls.defaults), but some of them are reactionary rather than proactive (meaning you take a timestep, realize you've overshot the max delta_mstar, cut the timestep) and so they sometimes require more iterations to converge on a good timestep. It's true that this all leads to very small timesteps when the star mass is small or the accretion rate is high, but this is sometimes necessary to even attempt to resolve the phases of heavy accretion.
Resolving the composition boundaries is very good, and also useful for asteroseismic work and the mesh controls you point to are useful ones here. In Thomas Steindl's old setup I think he employed a meshing scheme that no longer exists in MESA by default. However, Mathias Michelsen has revived that meshing scheme in a run_star_extras routine, and I believe we used it in this paper<https://ui.adsabs.harvard.edu/abs/2024ApJ...964..170J/abstract> by Cole Johnston, Mathias Michielsen, Evan Anders et al (Zenodo<https://zenodo.org/records/10286503> here).
Hope this helps!
Cheers,
~Jared
On Wed, Mar 26, 2025 at 8:17 AM Pablo Marchant <pamarca at gmail.com<mailto:pamarca at gmail.com>> wrote:
Hi Johannes,
not sure if this might help, but ever since ~2019 there have been changes with how the energy equation is treated regarding mass changes, including a "leak fraction" related to the ratio between accretion timescale and a local thermal one (see equation 26 of Paxton et al. (2019)). At least in my experience this term mostly leads to significant numerical instability in the instances when it is physically relevant, although the situations where I've run into this issue are for high mass loss rather than high accretion, You can turn off this by setting this option to zero:
https://docs.mesastar.org/en/latest/reference/controls.html#eps-mdot-leak-frac-factor
and see if that helps.
Cheers
Pablo
On Wed, Mar 26, 2025 at 11:12 AM Joergensen, Johannes Holm via Mesa-users <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>> wrote:
Dear Jared and Ebraheem,
I hope you don't mind me reviving this thread!
I have had some time again getting into the nitty gritty of these accreting MESA models. This time around I have discovered a perhaps not so surprising fact; that the models become especially problematic during episodes of strong accretion.
Our accretion histories are episodic in the sense that we envision the surrounding disk fragmenting leading to rapid increase in mass accretion rate. As such we can have periods ~10d-5 - 10d-6 Msun/yr and sudden episodes of ~10d-4 Msun/yr. These rates seem to be problematic in the mass range we are interested in (~1 Msun).
During such episodes the star adjust accordingly:
- we have new material deposited in the star (eg deuterium) leading to changes in chemical composition.
- we have heat injected in the outer layers leading to off-center nuclear burning
- a significant increase in radius as the star responds to rapid accretion.
- surface luminosity and temperature are also affected.
- the surface layers might also become unstable - in the context of the entropy of the accreted material to the entropy of the surface layers.
As mentioned these episodes pose a problem for MESA; the model does not necessarily crash, but rather the computations practically come to a halt. I have tried to help MESA overcome some of these problems, to varying levels of succes:
- Increasing spatial and temporal resolution showed some promise, but in the end I was not able to overcome the episode of strong accretion. Additionally, as you hinted at previously, changing the resolution significantly altered the models.
- Playing around with MESAs dynamical mesh options: Fx setting the following controls I thought could maybe help MESA in the presence of steep chemical gradients from accreted material.
mesh_logX_species(2) = 'h2'
mesh_logX_min_for_extra(2) = -5
mesh_dlogX_dlogP_extra(2) = 0.2
- One tweak-able parameter in our setup is the depth (in mass coordinates) to which the extra heat is injected. I have had some succes extending this depth to fx the outer 25% of the stellar mass, but still run into trouble during strong accretion. I also suspect as we go to deeper injection dephts the models become unphysical.
- Using MESAs '*_function_weight' controls I thought could also help - although I'm unsure of the exact nature of these settings.
- Relying on higher mass initial stellar seeds: In our current setup we evolve the star starting from a stellar seed of 0.01 Msun. Starting instead from a seed of 0.1 Msun helped in some aspects - especially during the earliest evolution. We would ideally use seeds of mass ~0.01 Msun as this is what is commonly being used in the literature, so this 'fix' is also not ideal.
Thank you for taking the time to read my email. My question now would be along the lines of: "do you have any other tips/tricks for me to employ in helping MESA overcome these episodes of strong accretion?". I believe to some extent my models are still subject to numerical noise, hence why I for my research have reduced the number of models I attempt to calculate and instead try to find common ground with a few selected models.
All the best, Johannes
________________________________
Fra: Jared Goldberg <jgoldberg at flatironinstitute.org<mailto:jgoldberg at flatironinstitute.org>>
Sendt: 15. november 2024 17:22:23
Til: Joergensen, Johannes Holm
Cc: Farag, Ebraheem; mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
Emne: Re: [Mesa-users] Convergence issues solved by changing a_mlt
Yeah that looks pretty nasty! Do you have superad_reduction or MLT++ turned on or are both turned off?
Also, for diagnostics sake it might be worth plotting just gradT and grada separately, to see whether the jump is in the equation of state (grada) or the model (gradT).
By here you mean that changing amlt is a minor pertubation? I agree and suspect that I would've found similar results had I fx chosen to
perturb the masses of my models slightly instead of amlt.
Yes, I mean that basically any small change in your input or physics might help or hinder the solver converging on a next timestep due to stochastic numerical noise rather than physics. Unfortunately this also means that for a given set of inputs changing the resolution may change the answer significantly too.
I'm running the model that I expect to fail again, but now with "max_dq = 1d-3" in one case and "mesh_delta_coeff = 0.2" in another. The models are more computationally heavy, however, I'm noticing that the model with the "max-dq" criteria has actually managed to evolve pass the problematic age/mass, having now reached age = 20700 years.
Excellent! Increasing resolution isn't just a good idea because it checks if your old models are good, it can also help convergence for the solver too. It may seem counter-intuititve, but sometimes higher resolution means numerical errors per timestep are much smaller and don't balloon into big errors that cause failure down the line. Even if the models take longer, this may prevent failure. In this case high spatial resolution may help prevent jumps in gradT or grada
I have also found that setting a maximum timestep, especially one much shorter than an accretion variability timescale, helps a lot for convergence in accretion setups.
Cheers,
~Jared
On Fri, Nov 15, 2024 at 6:01 AM Joergensen, Johannes Holm <Johannes.Joergensen at uibk.ac.at<mailto:Johannes.Joergensen at uibk.ac.at>> wrote:
Hi again Ebraheem and Jared,
thanks for your suggestions - I've made some progress with them since.
> if the model is crashing right then or shortly after, it must be somewhat catastrophic as opposed to a slow decent
I have attached two figures illustrating gradT-grada for the last two profiles in my model that fails. To me, it does indeed look catastrophic, with values from -6 to 6.
> Turning on this control could spot the issue as well !report_ierr = .true
Yes, the output from this looks to be:
hydro_mtx: change too large, dlogT, logT, logT_start 4065 582 13 -1.5246921351765414D+02 -1.4732967808573136D+02 5.1395354319227664D+00
set_vars_for_solver failed: model, nz 4065 1716
eval_equations: set_solver_vars returned ierr -1
adjust_correction: eval_equations returned ierr -1 7.8236146823124006D-02 7.8236146823124006D-02
This is the last line from the solver:
"4065 40 coeff 0.3191 avg resid 0.183E-06 max resid equL 579 0.20933E-02 mix type 11111 avg corr 0.529E-07 max corr v 1 0.81727E-03 mix type xx111 max resid -- give up"
> minor perturbations to your model can cause you to avoid or encounter some of these spurious zones.
By here you mean that changing amlt is a minor pertubation? I agree and suspect that I would've found similar results had I fx chosen to perturb the masses of my models slightly instead of amlt.
> highly encourage running a resolution test varying spatial and temporal resolution.
I'm running the model that I expect to fail again, but now with "max_dq = 1d-3" in one case and "mesh_delta_coeff = 0.2" in another. The models are more computationally heavy, however, I'm noticing that the model with the "max-dq" criteria has actually managed to evolve pass the problematic age/mass, having now reached age = 20700 years.
Thanks again, I hope to get around to more of your suggestions as soon as possible.
Cheers, Johannes
________________________________
Fra: Farag, Ebraheem <ebraheem.farag at yale.edu<mailto:ebraheem.farag at yale.edu>>
Sendt: 7. november 2024 21:00:28
Til: Jared Goldberg; Joergensen, Johannes Holm
Cc: mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
Emne: Re: [Mesa-users] Convergence issues solved by changing a_mlt
All great points from jared,
*
When examining the MESA solver outputs, I believe one column should display the index of the problematic cell? Is there a way to connect a given cell index with a radius or mass coordinate to illustrate what is going in the problematic cell?
In particular if this is a result of a single or few superadiabatic zones crashing the solver, then one would expect that the largest residuals in the bad solver iterations would coincide with location (zone) of the largest values of gradT_sub_grada.
One can inspect the solver iterations by setting
report_solver_progress = .true.
This will report some info on the individual iterations contained within the timestep. Before a retry, the last solver iteration will display the largest residual quantity and zone.
For example
2126 19 coeff 0.1000 avg resid 0.230E-03 max resid dlnE_dt 1829 0.19703E+02 mix type 00000 avg corr 0.624E-08 max corr lnT 1829 0.34794E-05 mix type 00000 avg+max resid
This one line states that at timestep 2126 on the 19th iteration the the zone with maximum residual is zone 1829 where the largest residual is coming out of the energy equation.
Further debugging options are described here https://docs.mesastar.org/en/24.08.1/developing/debugging.html
If your investigation leads to you finding that the spurious zones of high gradT_sub_grada are indeed the source of your issue and if the pruning isn't helping you then likely your solutions will have to come from something like increasing alpha, turning on mlt++, or turning on superad_reduction, all are methods of bring delT closer to del_ad, therby decreasing the superadibicity. All of which will directly affect the radius of your star.
The fact that decreasing alpha is resulting in convergence, could just be from the fact that the superadiabatic zone is radiative instead of convective over the same timestep and so it doesn't suffer this issue, or that like Jared mentioned, minor perturbations to your model can cause you to avoid or encounter some of these spurious zones.
For context, I know Thomas ran into some similar issues when running some of his models, although i don't remember which. As you are really investigating a new larger parameter space, I'm not surprised you're encountering similar difficulty. I think he managed to get his models to work without any issue in some circumstances, but I remember him suffering some similar numerical issues, particularly for the more massive models or higher accretion rates. We experimented with using superad_reduction (turned higher than the default) and we were able to get some of his models to work that way at the cost of changing the structure. Although I don't know if those were the models used in his paper as I remember him being concerned about the affect this would have on the structure of the envelope and by extension the surface properties and pulsation of these accretion models.
p.s. I see that you have "prune_bad_cz_min_log_eps_nuc = 99", which appears to be set high enough that you are not pruning any bad zones. See the definition here<https://docs.mesastar.org/en/24.08.1/reference/controls.html#prune-bad-cz-min-log-eps-nuc>, where the default is "=-99",
One more solver hack to try which can sometimes help convergence is to prevent zones from flipping back and forth between convective and radiative over a solver iteration.
Try "make_gradr_sticky_in_solver_iters = .true.", described here<https://docs.mesastar.org/en/24.08.1/reference/controls.html#min-logt-for-make-gradr-sticky-in-solver-iters>
-EbF
________________________________
From: Jared Goldberg <jgoldberg at flatironinstitute.org<mailto:jgoldberg at flatironinstitute.org>>
Sent: Thursday, November 7, 2024 2:58 PM
To: Joergensen, Johannes Holm <Johannes.Joergensen at uibk.ac.at<mailto:Johannes.Joergensen at uibk.ac.at>>
Cc: Farag, Ebraheem <ebraheem.farag at yale.edu<mailto:ebraheem.farag at yale.edu>>; mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org> <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>>
Subject: Re: [Mesa-users] Convergence issues solved by changing a_mlt
I'm using MESA-r22.11.1 where Steindl+ 2022 used v12778. The scheme is the same as in that paper, with an initial stellar seed.
Got it. And indeed, a fair amount has changed between 12778 and 22.11.1 in terms of the treatment of convection and the turb module in general. Some of the advances are described in MESA VI (Jermyn+2023).
I follow your intuition as well; that more efficient convection should help with the small convection zones.
Yes, and the behavior you show strongly appears to be numerics rather than physics for why one alpha is happier than the other. For engineering purposes, it might be OK to use the value of alpha that works, but I'm not sure we'll find a good physical justification because one likely doesn't exist. With whatever value you choose, I highly encourage running a resolution test varying spatial and temporal resolution (generally following best practices https://docs.mesastar.org/en/24.08.1/using_mesa/best_practices.html ).
For the MESA inlist controls in question, I can tell the following:
- 'relax_until_radiative_core' is not in my inlist. I guess it's set to 'true' by default? https://docs.mesastar.org/en/22.11.1/reference/star_job.html#pre-ms-relax-to-start-radiative-core
Got it. Since you're starting with a very small seed mass, this doesn't kick in, but for posterity it may be a nuisance (i.e. it should be set to .false.) for other cases where you're trying to create accreting pre-MS stars. This is only activated with an initial mass that's > 0.3 Msun, and also not starting from a seed mass.
- 'do_conv_premix' is set to 'True'.
- 'prune_bad_cz*' and 'min_convective_gap' have the following controls:
i) prune_bad_cz_min_Hp_height = 0.1
ii) prune_bad_cz_min_log_eps_nuc = 99
iii) min_convective_gap = 0.1
Great, then these will already be taking effect.
> If I'm understanding correctly, by decreasing 'alpha_mlt' from 'alpha_mlt = 1.9' to 'alpha_mlt = 1.85', you were able to solver most of your convergence issues?
In general yes, but sometimes I had the case where I also increased 'alpha_mlt' slightly and solved my issues. Overall I have a grid of models from 0.5-1.5 solar masses with 35 different accretion scenarios that gives a total of 735 models. I wanted to keep 'alpha_mlt' fixed at 1.9, but ended up varying it between 1.8-2.0 to get better grid coverage. In the end I ended up with ~85% grid coverage.
Got it. This might be OK, but this sounds like your issues are likely numerical rather than physical. Run a resolution test!
Also, for science results, it's important to be aware that varying alpha_MLT will change the temperature of your pre-main-sequence descending Hayashi track for a convective envelope. This may be important to be aware of depending on your science application. See review by Joyce & Tayar: https://ui.adsabs.harvard.edu/abs/2023Galax..11...75J/abstract
Notice the faint hayashi tracks here:
[image.png]
> Finally, do the tiny spurious convection zones pop up near the base of the convective envelope, or the surface?
As far as I can tell, the zones show up throughout the entire interior.
Looks like they are present at larger T, so they're seeded at the base, but yes they're popping up throughout the envelope. From the kippenhahn diagram you can see that this is when the star develops a radiative envelope, not at the top of the outer subsurface convection zone.
> I think two plots could help in diagnosing what's happening.
I have attached the plots, although I have plotted the MESA 'schwarzschild criteria' against logT instead of ∇−∇ad, but this should convey the same information right? (I hope my naming scheme makes sense)
The schwarzschild criterion typically is a "yes or no" -- is it stable to convection or not? So grad - grad_ad contains much more information, namely, how close your thermodynamic gradient is to the adiabat. See gradT_sub_grada in your pgstar panels, it is very ratty.
One thing I noticed, when examining the Kippenhahn diagrams in the MESA pngs, is that the model that fails with 'alpha_mlt'=1.9 has a larger region of strong burning in the outer parts than the model with lower 'alpha_mlt' at the same age. At later stages the the model with lower 'alpha_mlt' will also develop strong off-center burning, yet still converges, so I'm not sure this is the cause of the problem in the model with higher 'alpha_mlt'.
The off-center burning is deuterium burning at the base of the H-rich envelope. So, yes, it looks like the onset of deuterium burning may not be playing nicely with MLT. See also the change in h3 abundance in the abundance plot. I was looking for rattier behavior, though, which doesn't seem to be the issue, so I agree this likely isn't the fundamental problem.
> I would also encourage you to stare at power profile plots.
Yes, thanks for the tip, I will get around to these plots as soon as I can, but I wanted to get the first plots to you both right now.
As with grad - grad_ad profiles, you also have this in your pgstar (and therefore, for your own diagnostics, in profileN.data files).
Final question for now: When examining the MESA solver outputs, I believe one column should display the index of the problematic cell? Is there a way to connect a given cell index with a radius or mass coordinate to illustrate what is going in the problematic cell?
The profile.data files for that and adjacent timesteps contain a bunch of information and map from zone to mass/radius. Sometimes it's helpful to increase your profile output to every timestep just around the crash. For information during the solve step, you can tell MESA to print information in extras_check_model in run_star_extras.
Note that this "problematic cell" is just the one with the highest residual, there may be multiple cells where there are issues.
Thanks to both of you for taking the time to help me, I really appreciate it
No problem!
Cheers,
~Jared
Cheers, Johannes
________________________________
Fra: Jared Goldberg <jgoldberg at flatironinstitute.org<mailto:jgoldberg at flatironinstitute.org>>
Sendt: 6. november 2024 20:38:52
Til: Farag, Ebraheem
Cc: mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>; Joergensen, Johannes Holm
Emne: Re: [Mesa-users] Convergence issues solved by changing a_mlt
Hi Johannes,
I've been playing around with accretion on the pre-main-sequence in support of a student's project this past summer, and we've been breaking MESA in many interesting ways. The tiny convection zones popping in and out of existence definitely become a problem in this regime. Like Eb speculated, in my experience making convection more efficient (increasing alpha_MLT) tended to behave slightly better near the convective boundary, which I justified intuitively by thinking that it brings convective gradients closer to the adiabatic gradient, and also may be a bit better for composition gradients which may cause the tiny convection zones popping in and out of existence. I have less intuition for why a lower alpha_mlt might help the solver -- perhaps this is a sign that some of the numerics are ill-converged in general, and kicking the solver around (e.g. by changing alpha) could help with convergence.
Convective boundaries are a notorious problem, and have had much work in MESA IV and V devoted to doing better and better, though there's still room for improvement. One work-around here is setting prune_bad_cz_* and min_convective_gap to prune these numerical jitters. Similarly do_conv_premix = .true. seems to help with numerical stability. Playing with overshooting may also help to this end.
A few more questions to be more helpful and gauge what's going on:
> First, what MESA revision are you using? Are you using the old revision from Steindl+2022 (9000s, I think?) or are you using a recent revision?
A number of changes have been made since then which have put resolution away from composition gradients, and similarly there have been changes with convective boundary mixing schemes and the turbulence module in general which may impact the setup. There were also resolution controls near the core boundaries / composition boundaries in that old revision (useful for asteroseismology) which Steindl et al used that don't exist in modern revisions.
> Also, what are you initial conditions? (E.g. We found that things are better-converged if relax_until_reach_radiative_core = .false. on the pre-MS.)
Are you starting from a seed stellar model as in Steindl et al, or from one of MESA's built-in constructors for pre-ms initial conditions?
> Finally, do the tiny spurious convection zones pop up near the base of the convective envelope, or the surface?
I agree with Eb that
1- logT vs logRho profile of the whole model (a pgstar will work well, and it shows where convection operates along the profile)
2- superadiabicity (∇−∇ad) vs logT (so we can match the superadiabatic regions with regions in trho profile)
are good plots to make.
I would also encourage you to stare at power profile plots (are Li and Deuterium burning messing things up?) and composition profile plots (does jagged behavior in the composition profile cause local Ledoux-unstable behavior) as a function of mass coordinate. A kippenhahn diagram would also be helpful to see *when* in the star's evolution these spurious convection zones start to appear.
Cheers,
~Jared
On Wed, Nov 6, 2024 at 10:41 AM Farag, Ebraheem via Mesa-users <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>> wrote:
Hello Johannes,
> For context, I am running some "complicated" accreting pre-MS models with the framework developed by Steindl+ 2022.
Very cool! Thomas did some nice work on developing a framework for pre-MS accretion.
> From examining the output of the solver I see that the issues arise in convection zones. By trial and error I solved a lot of my convergence issues by simply changing the mixing length parameter slightly (e.g. from 1.9 to 1.85). My question is: Is there any way to interpret this? My models show interesting interiors with often many tiny convection cells which I imagine are difficult to handle; could a change in a_mlt help in this regard?
If I'm understanding correctly, by decreasing 'alpha_mlt' from 'alpha_mlt = 1.9' to 'alpha_mlt = 1.85', you were able to solver most of your convergence issues?
if decreasing alpha_mlt is indeed solving your issue, are these problematic convective zones becoming radiative in the improved working model? Naively, I would imagine the problem would become worse with lower alpha_mlt unless the zone becomes entirely radiative.
I think two plots could help in diagnosing what's happening.
1- logT vs logRho profile of the whole model (a pgstar will work well, and it shows where convection operates along the profile)
2- superadiabicity (∇−∇ad) vs logT (so we can match the superadiabatic regions with regions in trho profile)
If you can answer these questions, I can attempt to provide an explanation.
-EbF
________________________________
From: Mesa-users <mesa-users-bounces at lists.mesastar.org<mailto:mesa-users-bounces at lists.mesastar.org>> on behalf of Joergensen, Johannes Holm via Mesa-users <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>>
Sent: Wednesday, November 6, 2024 4:50 AM
To: mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org> <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>>
Subject: [Mesa-users] Convergence issues solved by changing a_mlt
Hi everyone,
I am having convergence issues in MESA. For context, I am running some "complicated" accreting pre-MS models with the framework developed by Steindl+ 2022. From examining the output of the solver I see that the issues arise in convection zones. By trial and error I solved a lot of my convergence issues by simply changing the mixing length parameter slightly (e.g. from 1.9 to 1.85). My question is: Is there any way to interpret this? My models show interesting interiors with often many tiny convection cells which I imagine are difficult to handle; could a change in a_mlt help in this regard? I would gladly provide figures that showcase this, or my inlists. Much gratitude for any help!
Cheers, Johannes
_______________________________________________
mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
https://lists.mesastar.org/mailman/listinfo/mesa-users
_______________________________________________
mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
https://lists.mesastar.org/mailman/listinfo/mesa-users
--
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250327/368f7338/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 518533 bytes
Desc: image.png
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250327/368f7338/attachment.png>
More information about the Mesa-users
mailing list