Open mauneyc-LANL opened 2 years ago
Perhaps a modifier class can be used here?
Perhaps a modifier class can be used here?
I like it as an approach; per the Gruneisen issue's we've discussed, it would also allow for flexible handling of "numerically-valid-but-physically-vague" domains.
There's a maybe overlapping issue about "code-invalid" inputs, e.g. out-of-bounds or negative array indices that modifiers may not be well suited to. Would it be worth making this a separate issue?
The two issues you bring up, i.e. negative densities and temperatures, I think relate to ideas @Yurlungur has had about production-hardening layers. It may be possible to go beyond general conditions such as this to constraining inputs to be within some valid domain (for example you can place a lower energy bound on most analytic EOS).
There's a maybe overlapping issue about "code-invalid" inputs, e.g. out-of-bounds or negative array indices that modifiers may not be well suited to. Would it be worth making this a separate issue?
Yes I think you're right that the "code-invalid" inputs might need a different treatment
Related issue: https://github.com/lanl/singularity-eos/issues/69
I think this kind of stuff is exactly what I had in mind as far as production hardening. But I wouldn't put an energy bound in a modifier, as @jhp-lanl points out.
I think this kind of stuff is exactly what I had in mind as far as production hardening. But I wouldn't put an energy bound in a modifier, as @jhp-lanl points out.
Would it be prudent to close this issue? I would like some more focus in this - I keep running into it and eventually I'll (or Anna) are gonna be locally rewriting specific instances, and we'll have mostly retouched files in eos
Code in the wild can supply values to routines that are accidentally or intentionally invalid, for example
Currently, there is very little runtime checking to sort out garbage values from useful ones.