updated the values of functions such as zeta, psi, etc.

[Xsmos]

Since the temperature q[-1] keeps changing, ChemicalNetwork.py needs to update the values of functions zeta, psi, etc., otherwise the subsequent calculation will always call these functions with the original value of q[-1], which will potentially lead to negative temperature q[-1].

[mirochaj]

Hi @Xsmos , thanks for diving into this, and my apologies for the massive delay in getting back to you.

It has been awhile since I looked at this corner of the code, but it looks like it's setup in such a way that these coefficients are updated at a higher level. For example, in ares.simulations.GasParcel, there's a routine called update_rate_coefficients that calls the routine which resets these attributes (SourceIndependentCoefficients, which sets, e.g., Beta, alpha, etc.). It does look like they are changing with time in tests. This setup of course requires care for users who are trying to use the ChemicalNetwork directly, so perhaps there are better ways of alerting the user to that possibility or re-organizing things in a more failsafe way. I'd be curious to hear your thoughts about that if that's the boat you're in.

This might also get at a deeper point about how the calculations are done. The fact that the coefficients are updated at a "higher level" than in ChemicalNetwork is a reflection of there being two different kinds of timesteps. There's a "global" timestep, which controls how often we update the radiation background and things like the photoionization and photoheating rate coefficients (k_ion, k_heat, etc), but then the ODE solver is operating on timescales smaller than that, over which k_ion, k_heat etc are assumed to not change very much. The reason for that is that it would be computationally expensive to recompute anything having to do with the radiation field so frequently. The coefficients you've identified are actually not that expensive to compute and so in principle could be updated within each global step, but the code currently lumps them in with the coefficients involving the radiation field. To deal with rapidly evolving quantities in a scheme like this, one can change what is the biggest fractional change that is allowed in any quantity in a single timestep. That's the parameter epsilon_dt, set to 0.05 by default. If a quantity changes by more than that, then the timestep is reduced and the step re-done, i.e., the global timestep is adjusted adaptively.

I'm definitely open to discussion on this -- at the moment I'm waffling on which approach is most correct. If you have concrete examples / parameter choices that make it clear, let me know! I'd also be curious to know if reducing the value of epsilon_dt helps. Anyways, thanks again, and sorry for the delay.