InflowWind Hub Velocity Mapping for MHKs#3399
Conversation
|
I based my branch off of |
|
This is a good bugfix. I'm going to include it in 5.0.1 instead of 5.1.0 (we'll cross merge to |
There was a problem hiding this comment.
Pull request overview
This PR fixes InflowWind hub-velocity queries for MHK turbines by shifting the hub Z position from an MSL-referenced frame to a seabed-referenced frame before passing it into InflowWind, preventing Position(3) <= 0 from being treated as “below seabed” and zeroing the velocity.
Changes:
- Apply
WtrDpthoffset to the hub Z position during InflowWind initialization (FAST_Subs.f90) for MHK cases. - Apply the same
WtrDpthoffset to the hub Z position in the ED→IfW and SED→IfW custom input mappings (FAST_Mapping.f90) so runtime hub-velocity (and related) queries use the seabed-referenced hub position. - Includes additional changes outside the stated PR scope: YAML array formatting adjustments and a quaternion-to-DCM computation fix.
Reviewed changes
Copilot reviewed 51 out of 53 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| modules/openfast-library/src/FAST_Subs.f90 | Offsets initial InflowWind hub Z position by WtrDpth for MHK turbines. |
| modules/openfast-library/src/FAST_Mapping.f90 | Offsets mapped runtime InflowWind hub Z position by WtrDpth for MHK turbines (ED and SED paths). |
| modules/nwtc-library/src/YAML.f90 | Adjusts generated format strings when AllFmt is provided for YAML 2D real arrays. |
| modules/nwtc-library/src/NWTC_Num.f90 | Fixes Quaternion_to_DCM by correcting q3q3 to use q%v(3)**2. |
| modules/beamdyn/src/BeamDyn_IO.f90 | Updates AllFmt strings passed to YAML writer for BeamDyn summary output. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Feature or improvement description
Fix MHK hub-height wind speed (
HorWindV/avrSWAP(27)) and InflowWind hub velocity outputs (WindHubVelX/Y/Z) reporting zero for MHK turbines.For MHK turbines, ElastoDyn reports the hub position in the MSL reference frame (e.g., Z = -24 m for the RM1 floating turbine). When this position is passed to InflowWind for the hub velocity query,
IfW_FlowField_GetVelAccchecksPosition(3) > 0and returns zero velocity for any point at or below Z = 0. Since no coordinate offset was applied, the hub was seen as "underground" and the velocity was zeroed out.AeroDyn already handles this correctly by adding
PosOffset = [0, 0, WtrDpth]when querying InflowWind for blade/hub inflow. However, the separate hub velocity path used by ServoDyn (InflowWind_GetHubValues→HorWindV→avrSWAP(27)) did not apply this offset.This PR adds the
WtrDpthoffset toHubPosition(3)at the glue-code level before it is passed to InflowWind, consistent with the InflowWind documentation stating that all parameters should be "defined relative to the seabed" for MHK turbines. The fix is applied in:FAST_Mapping.f90: BothCustom_ED_to_IfWandCustom_SED_to_IfWmappingsFAST_Subs.f90: The InflowWind initialization path whereHubPositionis first setThis ensures all downstream InflowWind queries (HubVel, DiskVel, Lidar) receive the hub position in the seabed-referenced frame.
Related issue, if one exists
Impacted areas of the software
modules/openfast-library/src/FAST_Mapping.f90— ED→IfW and SED→IfW custom input solvemodules/openfast-library/src/FAST_Subs.f90— InflowWind initializationavrSWAP(27))Additional supporting information
Root cause trace:
FAST_Mapping.f90mapsHubPtMotion%Position(MSL frame, Z = -24 m for RM1) directly toIfW%Input%HubPositionInflowWind_GetHubValuespassesHubPositiontoIfW_FlowField_GetVelAccwith noPosOffsetIfW_FlowField.f90~line 160:if (Position(3, i) > 0.0)→ false → returnsVelocityUVW = 0FAST_Mapping.f90~line 3627:HorWindV = sqrt(HubVel(1)^2 + HubVel(2)^2)= 0BladedInterface.f90~line 933:avrSWAP(27) = u%HorWindV= 0AeroDyn does not have this problem because it applies
PosOffset = [0, 0, WtrDpth]inAD_CalcWind_Rotor.After fix,
WindHubVelXreports ~1.93 m/s (the expected current speed at hub height) for the MHK_RM1_Floating test case, instead of 0.I have a branch with
MHK_RM1_FloatingandMHK_RM1_Fixedregression tests updated to includeWindHubVelX/Y/Zin the InflowWindOutListto capture this behavior going forward.Generative AI usage
Assisted by: GitHub Copilot support@github.com
Test results, if applicable
MHK_RM1_FloatingandMHK_RM1_Fixedbaselines need updating due to:WindHubVelX/Y/Zoutput channels added to InflowWind OutList