NLTE_CHROMOSPHERE prone to crashes

[jwreep]

Running simulations with/without NLTE_CHROMOSPHERE makes a major difference in how often the code crashes or misbehaves. I suspect that the radiative timescale is the general culprit, and needs to be noticeably reduced for numerical stability when this option is switched on. Reducing SAFETY_RADIATION sufficiently will generally get it running, but at the cost of slowing the code considerably.

I don't know if this is a bug per se as numerical stability is always a concern, but it's something we ought to spend some time trying to improve.

(1) Is there a better approximation for the timescale?

(2) Could a new timescale of some sort be introduced that might alleviate the problem?

(3) Other options?

[sjbradshaw]

Yes, the radiative timescale is the issue. The electron energy turns negative over a timestep unless the timestep is carefully controlled. The problem is that the relevant propagation speed is the speed of light (transmission by photons), which we certainly don’t want to use in a Courant-type condition. Choosing a very small safety factor gets the code past difficult parts but, as you say, at the cost of execution time. One can interrupt the code and change the safety factor back to larger values, which may require a bit of trial and error. I suppose we could try setting some minimum timescale for radiation (tau_Rmin), such that if (SAFETY)*Ee/|R| < tau_Rmin then R is adjusted such that (SAFETY)*Ee/|R| = tau_Rmin. If tau_Rmin << output interval then there shouldn’t be much/anything in the way of noticeable differences. I use this technique to manage thermal conduction. There are probably other methods for dealing with it too. Cheers, Steve From: jwreep ***@***.***> Sent: Wednesday, June 23, 2021 3:15 PM To: rice-solar-physics/HYDRAD ***@***.***> Cc: Subscribed ***@***.***> Subject: [rice-solar-physics/HYDRAD] NLTE_CHROMOSPHERE prone to crashes (#92) Running simulations with/without NLTE_CHROMOSPHERE makes a major difference in how often the code crashes or misbehaves. I suspect that the radiative timescale is the general culprit, and needs to be noticeably reduced for numerical stability when this option is switched on. Reducing SAFETY_RADIATION sufficiently will generally get it running, but at the cost of slowing the code considerably. I don't know if this is a bug per se as numerical stability is always a concern, but it's something we ought to spend some time trying to improve. (1) Is there a better approximation for the timescale? (2) Could a new timescale of some sort be introduced that might alleviate the problem? (3) Other options? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#92> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACC6C7T63WZJCQEZX3KWU6TTUI6EZANCNFSM47GQDAJQ> . <https://github.com/notifications/beacon/ACC6C7WEAOOCLA7XUTPDOR3TUI6EZA5CNFSM47GQDAJ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4N2ZLYQQ.gif>