<div dir="ltr">Hi Antoine,<div><br></div><div>In addition to guaranteeing stability with modifications to the timestep limiter, you can try using a non-explicit solver. The Townsend solver is pretty easy to implement and quite stable:Â <a href="https://iopscience.iop.org/article/10.1088/0067-0049/181/2/391/meta">https://iopscience.iop.org/article/10.1088/0067-0049/181/2/391/meta</a></div><div><br></div><div>Best,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">--------<div>Ryan</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020 at 11:17 AM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu">klaus@flash.uchicago.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 22 Oct 2020, Tomasz Plewa wrote:<br>
<br>
> If there is no timestep limiter due to cooling, implement one following the approach used in Burn_computeDt (or whatever the module name is). You should be able to<br>
> stabilize calculations by limiting the source term contribution to about 10% of the internal energy.<br>
> <br>
Just adding to that:<br>
<br>
The presence of the 'dt_Cool' column in Antoine's output indicates that a <br>
timestep limiter for cooling was in effect; it may just not be aggressive <br>
enough. So you may want to modify the file Cool_computeDt.F90.<br>
<br>
There is a hardwired factor of 0.5 in the version that I am looking at;<br>
you may want to change that to a smaller value, and/or add code for<br>
some additional timestep-limiting criteria.<br>
<br>
Klaus<br>
</blockquote></div>