Summary
wifa/wayve_api.py::flow_io_abl reads the capping inversion from a nested block in the wind resource:
wind_resource:
thermal_stratification:
capping_inversion:
ABL_height: {dims: [time], data: [...]}
dH: {dims: [time], data: [...]}
dtheta: {dims: [time], data: [...]}
lapse_rate: {dims: [time], data: [...]}
(see wayve_api.py lines ~761-764 for the scalar/Nieuwstadt branch and ~815-820 for the vertical-profile branch on current main).
The windIO schema (windIO/schemas/plant/energy_resource.yaml, EUFLOW/windIO) instead declares flat keys at the wind-resource level:
ABL_height
capping_inversion_thickness (m)
capping_inversion_strength (K)
capping_inversion_height (m)
lapse_rate (K/m)
thermal_stratification / capping_inversion as a nested object appears nowhere in the schemas, and the flat capping_inversion_* keys are read nowhere in the wayve adapter. So:
- a windIO file that is schema-conformant (flat keys) silently gets WIFA's hard-coded defaults (H=1500 m, dH=100 m, dtheta=5 K, lapse_rate=2e-3 K/m) or the internal
ci_fitting fallback;
- the input the adapter actually consumes (nested block) does not validate against the schema. This currently goes unnoticed because the wayve path loads the YAML without schema validation.
There is also a naming/semantics mismatch to resolve while at it: the schema's capping_inversion_height vs the adapter's ABL_height (both meaning the inversion-center height h), _thickness vs dH, _strength vs dtheta.
Suggested resolution
Either
- teach the adapter to read the schema's flat
capping_inversion_* / lapse_rate keys (possibly keeping the nested spelling as a deprecated alias), or
- change the windIO schema (EUFLOW/windIO) to define the nested
thermal_stratification.capping_inversion object and drop/deprecate the flat keys,
and in either case enable schema validation on the wayve input path so the mismatch cannot silently recur.
Context
Found while grounding the FLOW model-chain Twin Groves wayve example in per-state ERA5-derived capping inversions (flow_model_chain, gitlab.windenergy.dtu.dk:eu-flow/wp5/flow_model_chain). We currently write the nested spelling because that is what the adapter reads, and document the non-conformance in the example. Happy to contribute a PR for either direction once maintainers pick one.
🤖 Generated with Claude Code
Summary
wifa/wayve_api.py::flow_io_ablreads the capping inversion from a nested block in the wind resource:(see
wayve_api.pylines ~761-764 for the scalar/Nieuwstadt branch and ~815-820 for the vertical-profile branch on currentmain).The windIO schema (
windIO/schemas/plant/energy_resource.yaml, EUFLOW/windIO) instead declares flat keys at the wind-resource level:ABL_heightcapping_inversion_thickness(m)capping_inversion_strength(K)capping_inversion_height(m)lapse_rate(K/m)thermal_stratification/capping_inversionas a nested object appears nowhere in the schemas, and the flatcapping_inversion_*keys are read nowhere in the wayve adapter. So:ci_fittingfallback;There is also a naming/semantics mismatch to resolve while at it: the schema's
capping_inversion_heightvs the adapter'sABL_height(both meaning the inversion-center height h),_thicknessvsdH,_strengthvsdtheta.Suggested resolution
Either
capping_inversion_*/lapse_ratekeys (possibly keeping the nested spelling as a deprecated alias), orthermal_stratification.capping_inversionobject and drop/deprecate the flat keys,and in either case enable schema validation on the wayve input path so the mismatch cannot silently recur.
Context
Found while grounding the FLOW model-chain Twin Groves wayve example in per-state ERA5-derived capping inversions (flow_model_chain,
gitlab.windenergy.dtu.dk:eu-flow/wp5/flow_model_chain). We currently write the nested spelling because that is what the adapter reads, and document the non-conformance in the example. Happy to contribute a PR for either direction once maintainers pick one.🤖 Generated with Claude Code