check_state: check_state=False skips check of FABM state variables

[knutaros]

No description provided.

[jornbr]

I'm curious why you'd want to activate this new option. If BGC models specify lower or upper boundaries for their state variables, the idea is that the host+FABM then guarantee that the variable values are within these boundaries when the BGC routines are called. For some BGC models, the behaviour is ill defined if not, e.g. they can generate NaNs. Thus, I'd either check and repair, which is already activated with repair_state, or check and stop (if repair_state is off). Or the BGC model could simply not register any lower or upper bounds. Setting this new check_state=False seems likely to generate hard-to-debug issues. What need does it serve?

[knutaros]

Dear Jorn, I need a fast (hidden expert) switch to avoid the crashes due to out-of-bounds values. Some thoughts: 1) We are using passive tracers for volume budgets and in this context negative values are reasonable. 2) I agree, that a switch "continue_with_invalid_values" would be better. I.e. instead of skipping check_state completely, just log out-of-bound values but do not crash. 3) even better would be configurable minimum values during runtime, instead of the hardcoded ones (in my case bb/passive). Cheers, Knut

…

On 10/9/25 09:37, Jorn Bruggeman wrote: *jornbr* left a comment (gotm-model/code#72) <#72 (comment)> I'm curious why you'd want to activate this new option. If BGC models specify lower or upper boundaries for their state variables, the idea is that the host+FABM then /guarantee/ that the variable values are within these boundaries when the BGC routines are called. For some BGC models, the behaviour is ill defined if not, e.g. they can generate NaNs. Thus, I'd either check and repair, which is already activated with |repair_state|, or check and stop (if |repair_state| is off). Or the BGC model could simply not register any lower or upper bounds. Setting this new |check_state=False| seems likely to generate hard-to-debug issues. What need does it serve? — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2RV6TG2G4S5NNXIZIZSML3WYGC7AVCNFSM6AAAAACIVVLTZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBUGU2DQNJRGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>