Tiny Time Steps During High Mass Transfer Rates in Star & Binary (r24.08.1)

[pzyao]

What were you trying to do?
I am working on a problem that leads to high mass transfer rates for a solar-type star orbiting an SMBH. When the mass transfer rate is above 10^-4 Msun/year, the timestep in MESA becomes very small (dt ~ 10^-5 yrs). This would require ~10^8 timesteps to lose 0.1 Msun. However, when the mdot is below 3e-5 Msun/year, the timesteps are generally very reasonable (dt >10-100 years) and the whole evolution can be completed within a reasonable time.

Other information
We also did the same test in a single star case with a range of stellar masses (1, 2, 3 Msun) starting from ZAMS by using the command
mass_change=-1d-4
This problem persists with timesteps remaining small.

Any input would be greatly appreciated!

Best,
Philippe

[mathren]

Hi Philippe! I don't think you have provided enough info for us to help...what is limiting the timestep (dt_limit string in the terminal output is a good starting point, they are explained in $MESA_DIR/star/defaults/controls.defaults)? Are you using superadiabaticity reduction (which is known to help for high mass transfer rates) or not? What MESA version? Could you share a minimal working example?

Without knowing those, it's hard to help. You may also want to send this (with the extra info) to the MESA mailing list, where it's likely more people will see and be able to chime in to help you.

[pzyao]

Hi Mathieu, thanks for the response. We are using MESA ver r24.08.1 and I have tried superadiabaticity reduction via
okay_to_reduce_gradT_excess = .true., which did not help with the timesteps

the dt_limit in a lower mdot (10^-5 Msun/year) regular timestep case is just "max increase", but in the higher mdot (10^-4 Msun/year) case is first "rety" then "hold" then "max increase" accompanied by
solver rejected trial model
retry: max residual jumped -- give up in solver

I have attached a minimal working example. Thanks again!

simple_mdot.zip

[mathren]

Hi Philippe,

Thanks for the extra information, this is helpful!
Some further thoughts:

okay_to_reduce_gradT_excess is what is described in Paxton+13 and informally referred to as "MLT++" which adds flux to the MLT-predicted convective flux mimicing another process. I was suggesting to try the use_superad_reduction which achieves the same but calculating implicitly the amount of flux that needs to be added (see the relevant section in Jermyn+23), which at least anecdotally (and this is also my experience) is more stable when it kicks in during mass transfer (though it has its drawbacks elsewhere).

Those dt_limit indicate (as explicitly said) the solver struggles, one thing you can also try is the procedure described here:
https://docs.mesastar.org/en/latest/developing/debugging.html#diagnosing-solver-struggles
to determine what equation and where in the star you have the biggest residuals.

I will not have time to play with your setup in the near future, so I still encourage you to send your zipped folder to the mailing list, where it's likely more people will see it (there are several hundreds people subscribed there, I doubt as many monitor the github issues!).

Hope this helps a bit!
Mathieu

[sunnywong314]

Hi Phillipe! I played around with your setup a bit. It looks like most of the numerical problems come from the surface convection zone, particularly in the eps_mdot term in the energy equation which redistributes heat due to mass loss. I haven't played around with superad reduction (with the default parameters the solver still struggles a lot), but the solver is much happier if you turn MLT++ full on ( okay_to_reduce_gradT_excess = .true. and gradT_excess_lambda1 = -1 ).

[pzyao]

Hi Mathieu and Sunny,

Thank you both so much for the new suggestions! Sunny's suggestion is indeed working magic for the test case I attached. Will try it on our full problem as well.

Best,
Philippe