lanl / singularity-eos

Performance portable equations of state and mixed cell closures
https://lanl.github.io/singularity-eos/
BSD 3-Clause "New" or "Revised" License
26 stars 8 forks source link

Fortify function input values #153

Open mauneyc-LANL opened 2 years ago

mauneyc-LANL commented 2 years ago

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.

jhp-lanl commented 2 years ago

Perhaps a modifier class can be used here?

mauneyc-LANL commented 2 years ago

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?

jhp-lanl commented 2 years ago

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

jhp-lanl commented 2 years ago

Related issue: https://github.com/lanl/singularity-eos/issues/69

Yurlungur commented 2 years ago

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.

mauneyc-LANL commented 2 years ago

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

Yurlungur commented 2 years ago