Fix power scaling in open_source_scada example + add README and sanity test#63
Open
kilojoules wants to merge 1 commit into
Open
Fix power scaling in open_source_scada example + add README and sanity test#63kilojoules wants to merge 1 commit into
kilojoules wants to merge 1 commit into
Conversation
…y test The observed power timeseries in examples/cases/open_source_scada/outputs/observedPower.nc previously contained power values multiplied by the rated power numerical value in MW (1.65), producing a hard cap at 2722.5 kW that is inconsistent with the Vestas V82 1.65 MW power curve packaged in plant_energy_turbine/. This commit: 1. Re-saves observedPower.nc with power values divided by 1.65, restoring a hard rated cap at 1650 kW and bin-median agreement with the OEM V82 power curve within 1-15% across operational wind speeds. 2. Adds a README.md documenting the source (Twin Groves Wind Farm, McLean County, Illinois, Invenergy), units, conventions, license, and the pre-PR scaling history. 3. Adds an executable sanity-check script (tests/sanity_open_source_scada.py) that asserts max(power) is at or below rated and that bin-median power agrees with the OEM curve to within 20% across WS bins 5-13 m/s. This catches regressions of the historical scaling bug. After this change, the open_source_scada example is directly usable for benchmarking flow models against a real onshore SCADA reference with a publicly known turbine type.
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The observed power timeseries in
examples/cases/open_source_scada/outputs/observedPower.ncpreviouslycontained power values multiplied by the rated-power numerical value in MW
(1.65), producing a hard cap at 2722.5 kW. This is inconsistent with the
Vestas V82 1.65 MW power curve packaged in
plant_energy_turbine/,which has a rated cap at 1650 kW.
This PR makes the dataset directly consistent with the packaged OEM curve
and adds documentation + a regression test.
What changes
outputs/observedPower.nc— power values divided by 1.65. Hard caprestored to 1650 kW; bin-median agreement with OEM V82 curve within
1–15% across operational wind speeds (e.g. WS=13 m/s: OEM 1650 kW,
observed median 1644 kW). Attributes updated with units, source,
and license.
README.md— documents the source farm (Twin Groves, McLean County,IL; Invenergy), turbine type, time range, units, conventions, and the
pre-PR scaling history.
tests/sanity_open_source_scada.py— assertsmax(power) ≤ ratedand
|bin-median - OEM| / OEM ≤ 0.20across WS bins 5–13 m/s. Catchesfuture regressions of the scaling bug.
Verification
Why this matters
Without the fix, any downstream code that uses the packaged OEM curve to
reason about this case (e.g. power-curve inversion for inflow estimation,
or per-bin error metrics) silently produces nonsensical results because
the observed values are 65% higher than what the curve predicts at every
WS bin. After the fix, the example is directly usable as a real-onshore
SCADA benchmark with a known V82 turbine.
Notes
by 1.65 reproduces the new values exactly. The README documents this so
users with cached copies can recover.
rotor_effective_velocityvariable name is left unchanged forcompatibility, but the README clarifies it is the raw nacelle-anemometer
reading (no NTF correction applied).
Test plan
sanity_open_source_scada.pypasses after the fixobservedPower.ncopens cleanly withxarray