Handling of zero input parameters

[nkoukpaizan]

Several phasor dynamics models currently use != 0, == 0, != ZERO<RealT> or == ZERO<RealT> for some input parameters to enable/disable some features. This is ill advised for floating point values.

The models currently affected are:

• ESDC1A
• HYGOV
• IEEEST
• IEEET1
• REECB
• REPCA

isEqual with a tolerance or splitting == into isfinite(), <= and >= are inadequate here. The desired behavior really is to check if the value is zero, and the underlying purpose is to enable/disable some options.

One proposed solution is to expose the enabled/disabled options directly as integers (e.g., order for a stabilizer or booleans (e.g. saturation_disabled for an exciter). While this duplicates some information in the input file, this should make the model implementation cleaner. As long as the enabled/disabled features don't change during the simulation, it can be argued that we are mathematically dealing with different models.

cc @pelesh @superwhiskers

[lukelowry]

My primary justification for directly comparing parameters to zero (e.g., gain, time constants, etc.) is that this reflects the model's actual behavior per IEEE Recommended Practice for Excitation System Models. I would advise us against changing the input parameters from the IEEE specification, which grants our models a level of legitimacy (especially since we are already smoothing their behaviour, as opposed to the typical discrete formulation)

Otherwise I agree there is a friction here that needs to be resolved

cc @abirchfield

[nkoukpaizan]

Thanks for linking to the specification document.

[abirchfield]

This is often an issue where some parameter a is in an equation such that if it is small enough, it has numerical problems with the original model, but there is a modified model assuming a=0 that is numerically good and equivalent to the original in the limit.

The core question is: what do we do if the user specifies a=1e-9? If we're going "by the book" we would put it directly into the original model, which will almost certainly cause numerical problems. If we want to be user-friendly (though a bit opaque), we could set some tolerance and assume if a<tol, then a=0. A third option is to raise a parameter validation error for 0 < a < tol and force the user to fix it.

Which option we choose in each case may depend on the specific model. I would not advocate adding additional integer parameters like a_is_zero. Then what do we do if the user sets a_is_zero=1 and a=4.3? It opens the door for even more ambiguity.

[superwhiskers]

implementation-side, i think one potential solution to this would be to add an std::optional-like type wrapper that explicitly distinguishes disabling the thing from providing a value. if ieee model compatibility is desired, then this wrapper could additionally treat a literal 0 as equivalent to disabling the thing when consumed from a parsing pathway (such as our json format).

this would allow people interfacing with gridkit from the c++ interface to have a more c++ish interface while being familiar for people expecting it to behave like the specification. additionally, this would make the implementation more superficially straightforward as there would no longer be semantically loaded == ZERO<T> comparisons: these could be replaced with a .is_disabled() call or something like that.

i don't think we should have a tolerance for the zero check. a literal zero, to my understanding, is always equal to zero when it comes to floating points, and we don't want some byproduct of a computation to inadvertently disable the computation later on even if it could lead to stability issues. i think this would be unexpected behavior.