Part of a set of structural observations — see #1695 (index) for context.
Describe the bug
The sampled/tabulated compressor models (domain/process/compressor/core/sampled/) interpolate user-supplied performance data and explicitly reason about the convex hull of the input points — compressor_model_sampled_3d.py has substantial comment blocks walking through the hull-projection logic. When a query point falls outside that hull, nothing raises, nothing logs, and there's no aggregate summary anywhere in the CLI or output.
The only signal is a per-timestep, per-component boolean is_valid field, set in compressor_model_sampled.py from:
np.logical_and(~np.isnan(energy_usage), turbine_energy_result.is_valid)
To find out that part of a model was extrapolated (or zeroed) outside its calibrated range, a user has to already know to check the <component>.is_valid column, per component, per timestep, in a result set that can run to thousands of rows.
To Reproduce
I don't have a live environment to hand right now to produce an exact minimal YAML repro, but the path to confirm is straightforward: define a sampled/tabulated compressor chart with a query variable (e.g. rate or pressure ratio) that goes outside the range of the supplied calibration points, run it, and check that is_valid goes False for those timesteps with no accompanying log line or exception anywhere in stdout/stderr.
Expected behavior
At minimum, a log warning at the point of detection (compressor_model_sampled.py, where is_valid is computed), and ideally an aggregate summary surfaced in CLI/output — e.g. "N of M timesteps for component X fell outside the calibrated envelope" — rather than requiring a per-row scan of is_valid to discover it happened at all.
Additional context
This isn't about the interpolation/extrapolation behavior itself (returning a value outside the hull may well be the right default) — it's specifically that the failure mode is silent. Given how much logic already goes into detecting the hull boundary correctly, surfacing that detection seems like a small addition relative to the value: it's the difference between a user possibly noticing a data-quality problem and reliably being told about one.
Part of a set of structural observations — see #1695 (index) for context.
Describe the bug
The sampled/tabulated compressor models (
domain/process/compressor/core/sampled/) interpolate user-supplied performance data and explicitly reason about the convex hull of the input points —compressor_model_sampled_3d.pyhas substantial comment blocks walking through the hull-projection logic. When a query point falls outside that hull, nothing raises, nothing logs, and there's no aggregate summary anywhere in the CLI or output.The only signal is a per-timestep, per-component boolean
is_validfield, set incompressor_model_sampled.pyfrom:To find out that part of a model was extrapolated (or zeroed) outside its calibrated range, a user has to already know to check the
<component>.is_validcolumn, per component, per timestep, in a result set that can run to thousands of rows.To Reproduce
I don't have a live environment to hand right now to produce an exact minimal YAML repro, but the path to confirm is straightforward: define a sampled/tabulated compressor chart with a query variable (e.g. rate or pressure ratio) that goes outside the range of the supplied calibration points, run it, and check that
is_validgoesFalsefor those timesteps with no accompanying log line or exception anywhere in stdout/stderr.Expected behavior
At minimum, a log warning at the point of detection (
compressor_model_sampled.py, whereis_validis computed), and ideally an aggregate summary surfaced in CLI/output — e.g. "N of M timesteps for component X fell outside the calibrated envelope" — rather than requiring a per-row scan ofis_validto discover it happened at all.Additional context
This isn't about the interpolation/extrapolation behavior itself (returning a value outside the hull may well be the right default) — it's specifically that the failure mode is silent. Given how much logic already goes into detecting the hull boundary correctly, surfacing that detection seems like a small addition relative to the value: it's the difference between a user possibly noticing a data-quality problem and reliably being told about one.