Wind-wave misalignment in OpenFAST

Hi everyone,

For my MS thesis, I am working with OpenFAST to model the IEA 15MW reference turbine, on the VolturnUS semisubmersible platform, experiencing wind-wave misalignment (waves coming from a different direction than wind). I ran a few initial simulations in OpenFAST v2.4 to compare the FOWT’s response to aligned vs misaligned conditions. For these runs, the only parameter I changed between aligned and misaligned cases was WaveDir in HydroDyn (and then, of course, I altered the .fst to reference the new HydroDyn .dat file). However, my results showed exactly no difference in FOWT response between the aligned and misaligned runs.

After checking over my input files and pre- and post-processing scripts and finding no clerical errors, I was wondering if you all could offer some advice on how I should model the IEA 15MW on semisub in the misaligned wind-wave conditions that I am interested in.

To my understanding, the various parameters relevant to changing the headings of wind and waves in OpenFAST are…

  • PropagationDir in InflowWind
  • WaveDir in HydroDyn
  • WaveDirMod in HydroDyn
  • WaveDirSpread in HydroDyn
  • Orientation of semisub model in HydroDyn
  • Orientation of moring system coordinates in MoorDyn
  • (platform and/or mooring system can be rotated to change relative metocean headings)

So far, all I have tried is changing WaveDir and holding everything else constant/default, but this did not create the simulations I wanted. You can see below an example of a HydroDyn file I used. What would you all recommend for the simplest way to change the wind and wave headings relative to each other and relative to the FOWT?

Thank you so much for the help,
Doron

Example HydroDyn file I used in initial sims, intended headings are 0 deg wind and 30 deg waves

------- HydroDyn v2.03.* Input File -------------------------------------------- IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform True Echo - Echo the input file data (flag) ---------------------- ENVIRONMENTAL CONDITIONS -------------------------------- 1025 WtrDens - Water density (kg/m^3) 150 WtrDpth - Water depth (meters) 0 MSL2SWL - Offset between still-water level and mean sea level (meters) [positive upward; unused when WaveMod = 6; must be zero if PotMod=1 or 2] ---------------------- WAVES --------------------------------------------------- 2 WaveMod - Incident wave kinematics model {0: none=still water, 1: plane progressive (regular), 2: JONSWAP/Pierson-Moskowitz spectrum (irregular), 3: user-defind spectrum from routine UserWaveSpctrm (irregular)} (switch) 0 WaveStMod - Model for stretching incident wave kinematics to instantaneous free surface {0: none=no stretching, 1: vertical stretching, 2: extrapolation stretching, 3: Wheeler stretching} (switch) [unused when WaveMod=0 or when PotMod/=0] 4200.00 WaveTMax - Analysis time for incident wave calculations (sec) [unused when WaveMod=0; determines WaveDOmega=2Pi/WaveTMax in the IFFT] 0.25 WaveDT - Time step for incident wave calculations (sec) [unused when WaveMod=0; 0.1<=WaveDT<=1.0 recommended; determines WaveOmegaMax=Pi/WaveDT in the IFFT] 7.6 WaveHs - Significant wave height of incident waves (meters) [used only when WaveMod=1 or 2] 10.3 WaveTp - Peak spectral period of incident waves (sec) [used only when WaveMod=1 or 2] 2 WavePkShp - Peak-shape parameter of incident wave spectrum (-) or DEFAULT (string) [used only when WaveMod=2; use 1.0 for Pierson-Moskowitz] 0.111527 WvLowCOff - Low cut-off frequency or lower frequency limit of the wave spectrum beyond which the wave spectrum is zeroed (rad/s) [unused when WaveMod=0, 1, or 6] 0.783827 WvHiCOff - High cut-off frequency or upper frequency limit of the wave spectrum beyond which the wave spectrum is zeroed (rad/s) [unused when WaveMod=0, 1, or 6] 30.0 WaveDir - Incident wave propagation heading direction (degrees) [unused when WaveMod=0 or 6] 0 WaveDirMod - Directional spreading function {0: none, 1: COS2S} (-) [only used when WaveMod=2,3, or 4] 1 WaveDirSpread - Wave direction spreading coefficient ( > 0 ) (-) [only used when WaveMod=2,3, or 4 and WaveDirMod=1] 1 WaveNDir - Number of wave directions (-) [only used when WaveMod=2,3, or 4 and WaveDirMod=1; odd number only] 0 WaveDirRange - Range of wave directions (full range: WaveDir +/- 1/2*WaveDirRange) (degrees) [only used when WaveMod=2,3,or 4 and WaveDirMod=1] 1275333541 WaveSeed(1) - First random seed of incident waves [-2147483648 to 2147483647] (-) [unused when WaveMod=0, 5, or 6] -1885485676 WaveSeed(2) - Second random seed of incident waves [-2147483648 to 2147483647] (-) [unused when WaveMod=0, 5, or 6] FALSE WaveNDAmp - Flag for normally distributed amplitudes (flag) [only used when WaveMod=2, 3, or 4] "none" WvKinFile - Root name of externally generated wave data file(s) (quoted string) [used only when WaveMod=5 or 6] 1 NWaveElev - Number of points where the incident wave elevations can be computed (-) [maximum of 9 output locations] 0 WaveElevxi - List of xi-coordinates for points where the incident wave elevations can be output (meters) [NWaveElev points, separated by commas or white space; usused if NWaveElev = 0] 0 WaveElevyi - List of yi-coordinates for points where the incident wave elevations can be output (meters) [NWaveElev points, separated by commas or white space; usused if NWaveElev = 0] ---------------------- 2ND-ORDER WAVES ----------------------------------------- [unused with WaveMod=0 or 6] False WvDiffQTF - Full difference-frequency 2nd-order wave kinematics (flag) False WvSumQTF - Full summation-frequency 2nd-order wave kinematics (flag) 0 WvLowCOffD - Low frequency cutoff used in the difference-frequencies (rad/s) [Only used with a difference-frequency method] 0.737863 WvHiCOffD - High frequency cutoff used in the difference-frequencies (rad/s) [Only used with a difference-frequency method] 0.314159 WvLowCOffS - Low frequency cutoff used in the summation-frequencies (rad/s) [Only used with a summation-frequency method] 3.2 WvHiCOffS - High frequency cutoff used in the summation-frequencies (rad/s) [Only used with a summation-frequency method] ---------------------- CURRENT ------------------------------------------------- [unused with WaveMod=6] 1 CurrMod - Current profile model {0: none=no current, 1: standard, 2: user-defined from routine UserCurrent} (switch) 0 CurrSSV0 - Sub-surface current velocity at still water level (m/s) [used only when CurrMod=1] "DEFAULT" CurrSSDir - Sub-surface current heading direction (degrees) or DEFAULT (string) [used only when CurrMod=1] 40 CurrNSRef - Near-surface current reference depth (meters) [used only when CurrMod=1] 0.41 CurrNSV0 - Near-surface current velocity at still water level (m/s) [used only when CurrMod=1] 0 CurrNSDir - Near-surface current heading direction (degrees) [used only when CurrMod=1] 0 CurrDIV - Depth-independent current velocity (m/s) [used only when CurrMod=1] 0 CurrDIDir - Depth-independent current heading direction (degrees) [used only when CurrMod=1] ---------------------- FLOATING PLATFORM --------------------------------------- [unused with WaveMod=6] 1 PotMod - Potential-flow model {0: none=no potential flow, 1: frequency-to-time-domain transforms based on WAMIT output, 2: fluid-impulse theory (FIT)} (switch) "HydroData/IEA-15-240-RWT-UMaineSemi" PotFile - Root name of potential-flow model data; WAMIT output files containing the linear, nondimensionalized, hydrostatic restoring matrix (.hst), frequency-dependent hydrodynamic added mass matrix and damping matrix (.1), and frequency- and direction-dependent wave excitation force vector per unit wave amplitude (.3) (quoted string) [MAKE SURE THE FREQUENCIES INHERENT IN THESE WAMIT FILES SPAN THE PHYSICALLY-SIGNIFICANT RANGE OF FREQUENCIES FOR THE GIVEN PLATFORM; THEY MUST CONTAIN THE ZERO- AND INFINITE-FREQUENCY LIMITS!] 1 WAMITULEN - Characteristic body length scale used to redimensionalize WAMIT output (meters) [only used when PotMod=1] 20206.34889 PtfmVol0 - Displaced volume of water when the platform is in its undisplaced position (m^3) [only used when PotMod=1; USE THE SAME VALUE COMPUTED BY WAMIT AS OUTPUT IN THE .OUT FILE!] 0 PtfmCOBxt - The xt offset of the center of buoyancy (COB) from the platform reference point (meters) [only used when PotMod=1] 0 PtfmCOByt - The yt offset of the center of buoyancy (COB) from the platform reference point (meters) [only used when PotMod=1] 0 ExctnMod - Wave Excitation model {0: None, 1: DFT, 2: state-space} (switch) [only used when PotMod=1; STATE-SPACE REQUIRES *.ssexctn INPUT FILE] 1 RdtnMod - Radiation memory-effect model {0: no memory-effect calculation, 1: convolution, 2: state-space} (switch) [only used when PotMod=1; STATE-SPACE REQUIRES *.ss INPUT FILE] 60 RdtnTMax - Analysis time for wave radiation kernel calculations (sec) [only used when PotMod=1; determines RdtnDOmega=Pi/RdtnTMax in the cosine transform; MAKE SURE THIS IS LONG ENOUGH FOR THE RADIATION IMPULSE RESPONSE FUNCTIONS TO DECAY TO NEAR-ZERO FOR THE GIVEN PLATFORM!] "DEFAULT" RdtnDT - Time step for wave radiation kernel calculations (sec) [only used when PotMod=1; DT<=RdtnDT<=0.1 recommended; determines RdtnOmegaMax=Pi/RdtnDT in the cosine transform] ---------------------- 2ND-ORDER FLOATING PLATFORM FORCES ---------------------- [unused with WaveMod=0 or 6, or PotMod=0 or 2] 0 MnDrift - Mean-drift 2nd-order forces computed {0: None; [7, 8, 9, 10, 11, or 12]: WAMIT file to use} [Only one of MnDrift, NewmanApp, or DiffQTF can be non-zero] 0 NewmanApp - Mean- and slow-drift 2nd-order forces computed with Newman's approximation {0: None; [7, 8, 9, 10, 11, or 12]: WAMIT file to use} [Only one of MnDrift, NewmanApp, or DiffQTF can be non-zero. Used only when WaveDirMod=0] 12 DiffQTF - Full difference-frequency 2nd-order forces computed with full QTF {0: None; [10, 11, or 12]: WAMIT file to use} [Only one of MnDrift, NewmanApp, or DiffQTF can be non-zero] 12 SumQTF - Full summation -frequency 2nd-order forces computed with full QTF {0: None; [10, 11, or 12]: WAMIT file to use} ---------------------- FLOATING PLATFORM FORCE FLAGS -------------------------- [unused with WaveMod=6] True PtfmSgF - Platform horizontal surge translation force (flag) or DEFAULT True PtfmSwF - Platform horizontal sway translation force (flag) or DEFAULT True PtfmHvF - Platform vertical heave translation force (flag) or DEFAULT True PtfmRF - Platform roll tilt rotation force (flag) or DEFAULT True PtfmPF - Platform pitch tilt rotation force (flag) or DEFAULT True PtfmYF - Platform yaw rotation force (flag) or DEFAULT ---------------------- PLATFORM ADDITIONAL STIFFNESS AND DAMPING -------------- 0 0 0 0 0 0 AddF0 - Additional preload (N, N-m) 0 0 0 0 0 0 AddCLin - Additional linear stiffness (N/m, N/rad, N-m/m, N-m/rad) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 AddBLin - Additional linear damping(N/(m/s), N/(rad/s), N-m/(m/s), N-m/(rad/s)) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9.23E+05 0.00E+00 0.00E+00 0.00E+00 -8.92E+06 0.00E+00 AddBQuad - Additional quadratic drag(N/(m/s)^2, N/(rad/s)^2, N-m(m/s)^2, N-m/(rad/s)^2) 0.00E+00 9.23E+05 0.00E+00 8.92E+06 0.00E+00 0.00E+00 0.00E+00 0.00E+00 2.30E+06 0.00E+00 0.00E+00 0.00E+00 0.00E+00 8.92E+06 0.00E+00 1.68E+10 0.00E+00 0.00E+00 -8.92E+06 0.00E+00 0.00E+00 0.00E+00 1.68E+10 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 4.80E+10 ---------------------- AXIAL COEFFICIENTS -------------------------------------- 1 NAxCoef - Number of axial coefficients (-) AxCoefID AxCd AxCa AxCp (-) (-) (-) (-) 1 0.00 0.00 0.00 ---------------------- MEMBER JOINTS ------------------------------------------- 2 NJoints - Number of joints (-) [must be exactly 0 or at least 2] JointID Jointxi Jointyi Jointzi JointAxID JointOvrlp [JointOvrlp= 0: do nothing at joint, 1: eliminate overlaps by calculating super member] (-) (m) (m) (m) (-) (switch) 1 0.00000 0.00000 -13.18 1 0 2 0.00000 0.00000 -14.18 1 0 ---------------------- MEMBER CROSS-SECTION PROPERTIES ------------------------- 1 NPropSets - Number of member property sets (-) PropSetID PropD PropThck (-) (m) (m) 1 .00001 0.000001 ---------------------- SIMPLE HYDRODYNAMIC COEFFICIENTS (model 1) -------------- SimplCd SimplCdMG SimplCa SimplCaMG SimplCp SimplCpMG SimplAxCa SimplAxCaMG SimplAxCp SimplAxCpMG (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ---------------------- DEPTH-BASED HYDRODYNAMIC COEFFICIENTS (model 2) --------- 0 NCoefDpth - Number of depth-dependent coefficients (-) Dpth DpthCd DpthCdMG DpthCa DpthCaMG DpthCp DpthCpMG DpthAxCa DpthAxCaMG DpthAxCp DpthAxCpMG (m) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) ---------------------- MEMBER-BASED HYDRODYNAMIC COEFFICIENTS (model 3) -------- 0 NCoefMembers - Number of member-based coefficients (-) MemberID MemberCd1 MemberCd2 MemberCdMG1 MemberCdMG2 MemberCa1 MemberCa2 MemberCaMG1 MemberCaMG2 MemberCp1 MemberCp2 MemberCpMG1 MemberCpMG2 MemberAxCa1 MemberAxCa2 MemberAxCaMG1 MemberAxCaMG2 MemberAxCp1 MemberAxCp2 MemberAxCpMG1 MemberAxCpMG2 (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) -------------------- MEMBERS ------------------------------------------------- 1 NMembers - Number of members (-) MemberID MJointID1 MJointID2 MPropSetID1 MPropSetID2 MDivSize MCoefMod PropPot [MCoefMod=1: use simple coeff table, 2: use depth-based coeff table, 3: use member-based coeff table] [ PropPot/=0 if member is modeled with potential-flow theory] (-) (-) (-) (-) (-) (m) (switch) (flag) 1 1 2 1 1 1 1 TRUE ---------------------- FILLED MEMBERS ------------------------------------------ 0 NFillGroups - Number of filled member groups (-) [If FillDens = DEFAULT, then FillDens = WtrDens; FillFSLoc is related to MSL2SWL] FillNumM FillMList FillFSLoc FillDens (-) (-) (m) (kg/m^3) ---------------------- MARINE GROWTH ------------------------------------------- 0 NMGDepths - Number of marine-growth depths specified (-) MGDpth MGThck MGDens (m) (m) (kg/m^3) ---------------------- MEMBER OUTPUT LIST -------------------------------------- 0 NMOutputs - Number of member outputs (-) [must be < 10] MemberID NOutLoc NodeLocs [NOutLoc < 10; node locations are normalized distance from the start of the member, and must be >=0 and <= 1] [unused if NMOutputs=0] (-) (-) (-) ---------------------- JOINT OUTPUT LIST --------------------------------------- 0 NJOutputs - Number of joint outputs [Must be < 10] 1, 2 JOutLst - List of JointIDs which are to be output (-)[unused if NJOutputs=0] ---------------------- OUTPUT -------------------------------------------------- TRUE HDSum - Output a summary file [flag] False OutAll - Output all user-specified member and joint loads (only at each member end, not interior locations) [flag] 2 OutSwtch - Output requested channels to: [1=Hydrodyn.out, 2=GlueCode.out, 3=both files] "ES11.4e2" OutFmt - Output format for numerical results (quoted string) [not checked for validity!] "A11" OutSFmt - Output format for header strings (quoted string) [not checked for validity!] ---------------------- OUTPUT CHANNELS ----------------------------------------- "Wave1Elev" - Wave elevation at the platform reference point ( 0, 0) "WavesF1xi" "WavesF1zi" "WavesM1yi" "WavesF2xi" "WavesF2zi" "WavesM2yi" "WavesF2xi" "WavesF2yi" "WavesF2zi" "WavesM2xi" "WavesM2yi" "WavesM2zi" END of output channels and end of file. (the word "END" must appear in the first 3 columns of this line)

Dear Doron,

I agree that setting WaveDir in HydroDyn is the only thing you need to do to run simulations with wind-wave misalignment, but in your case, I see that the wave-excitation calculation has been disabled from potential-flow solution (ExctnMod = 0) and that all hydrodynamic coefficients in the strip-theory solution are zero. So, in this model, the waves will not excite the structure. A similar issue was raised on the issues page of the IEA Wind 15-MW reference wind turbine github site: github.com/IEAWindTask37/IEA-15 … /issues/52.

However, setting ExctnMod = 1 will cause another problem in your case. I see that the WAMIT output available on that github site (github.com/IEAWindTask37/IEA-15 … /HydroData) was only generated for a single wave direction (WaveDir = 0). This WAMIT data would need to be generated for a full range of wave directions to be able to model wind-wave misalignment.

Best regards,

Thank you so much for the insight, Dr. Jonkman, and for pointing me to the related github issue.

I am not too familiar with the types of hydrodynamic calculations in HydroDyn, so I have a few follow-up questions I was hoping you would answer.

  1. If ExctnMod = 0, does that mean that waves have no effect whatsoever on this UMaine semisub system? I was not able to find information specifically about ExctnMod in the OpenFAST documentation.

  2. And just to confirm, if I do set ExctnMod = 1 and set WaveDir = 0 degrees, will the waves then affect the semisub as normal? Are there any other flags or parameters–such as the strip-theory hydrodynamic coefficients–that I would need to change, as well? (In the issue on github, you say that no strip-theory solution is used at all, so I assume no other changes are needed.)

  3. Regarding wind-wave misalignment modeling, since WaveDir must remain at 0 degrees for this semisub model, would it be reasonable to vary PropagationDir within InflowWind, instead? Doing so could create a relative misalignment between wind and wave directions, but would this also create other issues in the simulation?

  4. Finally, for a previous project, my collaborators and I wanted to simulate the UMaine semisub experiencing various directions of all three environmental loads, wind, wave, and current (WWC were all aligned in this case). I learned from the HydroDyn manual that current requires a strip-theory solution, so it would not be able to contribute to loading. But aside from this issue, is it possible to vary the WWC directions with this UMaine semisub model? Possibly by rotating the platform and mooring relative to the WWC?

Thank you again for your help and advice!

Best,
Doron

Dear Doron,

Here are my answers to your questions:

  1. The HydroDyn documentation (from: nrel.gov/wind/nwtc/assets/d … Manual.pdf) has not yet been migrated to the online documentation on OpenFAST and updated to reflect changes made in OpenFAST. Regardless, ExctnMod is quite straightforward. ExctnMod = 0 disables the calculation of wave excitation from the potential-flow solution. ExctnMod = 1 enables the calculation of wave excitation from the potential-flow solution, implemented via Discrete Fourier Transform. ExctnMod = 1 enables the calculation of wave excitation from the potential-flow solution, implemented via a state-space model. So, yes, in a potential-flow only solution, setting ExctnMod = 0 will eliminate all excitation from waves (as if WaveMod = 0).

  2. Yes, those settings would yield the expected response. Modeling the UMaine semisubmersible as a hybrid model with a combination of a potential-flow solution and viscous drag through a strip-theory solution would likely be a more accurate model, but the strip-theory solution has not been enabled in this model for some reason (I’m not sure why, as I was not the one to make it). But you could certainly improve the model yourself.

  3. Yes, you could model wind-wave misalignment by setting a nonzero PropogationDir, but you should then set the nacelle-yaw angle in ElastoDyn so as to align the rotor with the wind direction, i.e., NacYaw in ElastoDyn = -PropogationDir in InflowWind (due to the opposite sign convention between InflowWind and ElastoDyn).

  4. Correct; the inclusion of current only effects models with a strip-theory solution. To include current, I recommend adding the strip-theory solution, as I also recommend in (2) above. To vary the wave direction, I would recommend generating the hydrodynamic data for a full range of wave directions (requires running WAMIT or an open-source equivalent, such as HAMS, in a pre-processing step).

Best regards,

Dear all,

I am trying as well to model wind/wave misalignment of the IEA 15 MW RWT on the UMaine Volturn US-S Reference Platform, while using the paper of Steward et al. (2016), “The creation of a comprehensive metocean data set for offshore wind turbine simulations” and its associated .xlsx database. I am investigating the effect of wind/wave misalignment on the power produced by the wind turbine on the basis of wind speed, Hs and Tp combinations calculated in the database.

However, this will require the change of turbine yaw by various angles (with the max absolute angle being 27 degrees) in order for the turbine axis to be aligned with the incoming wind. My question is: Will the change of inertia of the turbine in the roll and pitch degrees of freedom distort the response of the turbine and hence have a negative impact on the quality of the results regarding power production?

Best regards,
Ioannis Voultsos.

Dear Ioannis,

I’m not sure I fully understand your question. Are you asking about how the inertia of the floating platform?

Given the symmetric Y-shape of the UMaine semisubmersible, the roll and pitch inertias of the floater are identical, and so, shouldn’t be effected by the axis of the heal angle (similar to how the transverse inertia of a three-blade rotor is independent of azimuth angle). Given mooring system nonlinearities, there may be some asymmetry in the mooring restoring, but I would not expect this to be significant.

Best regards,

Dear Jason,

Thank you for your answer. It covered another question that I had in mind. However, my first question was indeed a bit confusing.

More specifically, I want to model wind/wave misallignment conditions of the IEA 15 MW RWT, so, since wave direction should be set to 0 deg for the UMaine floater, the wind direction should be altered, together with the nacelle yaw, so as to have the turbine axis aligned with the incoming wind.

However, this rotation will alter the distance of the blades from both x and y axes, which will have an effect on the turbine’s inertia as far as the roll and pitch DoFs are concerned. Therefore, the turbine response is going to change. I was wondering whether this change in the turbine response is going to significantly affect the power production of the turbine under wind/wave misalignment conditions, which I will be investigating. If I had WAMIT data for other wave directions, I would keep the wind direction at 0 deg, with the rotor axis aligned with the wind and create the wind/wave misalignment by changing the wave heading angle.

To put this in another way: Will my results be significantly affected if I create the wind/wave misallignment by changing the wind direction and setting the turbine yaw equal to it?

Best regards,
Ioannis Voultsos.

Dear Ioannis,

I have not ran such a comparison myself, but I would expect the two approaches would yield similar, but not identical, results. As I said in my prior post, given the symmetric Y-shape of the UMaine semisubmersible, the inertia should be identical in various orientations. However, there is likely some non axisymmetric response in the mooring system. There is also likely some non axisymmetric response in the hydrodynamic loading.

Best regards,

Dear Jason,

Thank you for your answer. I understand what you mean about the platform, so I will keep in mind that the results will be similar but not identical.

However, I had the idea that the global inertial frame of OpenFAST is rotating with the wind propagation direction, based on OpenFAST manual, p.148: "The positions must be specified in the OpenFAST global inertial frame coordinate system, which is located at the tower base and has the x-axis pointing downwind, the y-axis pointing laterally, and the z-axis pointing vertically upward."

But according to your response on this thread: Coordinate System

"The inertial frame coordinate system used in OpenFAST has the origin at the intersection of the undisplaced tower centerline and mean sea level, with the X-axis along the zero-degree wind/wave direction, the Z-axis vertical (opposite gravity), and the Y-axis directed to the left when looking along the zero-degree wind/wave direction."

So, according to the first sentence, it is implied that the coordinate system is aligned with the wind at any case, whereas on the second that it is fixed at 0 deg wind and wave direction.

I tried to test this hypothesis via running simulations for the afforementioned configuration:
1.) Steady wind field of 10 m/s and a PLexp of 1.1
2.) HydroDyn,MoorDyn and platform 6 DoFs turned off
3.) The DISCON.IN controller is the one for the IEA 15 MW monopile configuration
4.) Nacelle yaw DoF is turned on
5.) Two wind directions,0 deg and -20 deg. For the latter, I used PropagationDir=-20 deg, NacYaw IC =20 deg and YawNeut=20 deg in ServoDyn.
6.) Simulation time of 600 s (total simulation time 1000 s, where the first 400 s are discarded).

In addition to the mean power produced by the turbine in that windspeed, I wanted to see the response of the turbine and, for that reason I used the flapwise moment at the blade root and the out of plane tip deflection. Below, you can see some zoomed charts with the aforementioned responses.


As far as the mean power is concerned, it is 14.47 MW in the case of a -20 deg wind misalignment and 14.44 MW in the case of the 0 deg wind direction. All three results suggest that, indeed, although there are discrepancies between the two cases, they are more or less identical, so whether the coordinate system rotates or not does not influence much the results.

However my issue is the Wind1VelX output. Currently it is set at the point (0,0,150) (m) as I want to output the wind speed at the IEA 15 MW hub height. In the case of the misaligned case, the mean wind speed drops to 9.4 m/s. I tried to move the point along the x-y plane, but again the wind speed results were the same. In my opinion, it is strange because, not only the coordinates specified in InflowWind are in the global system, but also, due to steady wind, all points in the same height should have the same wind speed. Also, the points do not feel the rotor wake as, if it is considered that the points are set in the global coordinate system, the point (0,0,150) should be behind the rotor, so it would experience lower wind speed, which is not the case.

Therefore, I am a bit confused on explaining the results I get and I would like to have your opinion on these.

Best regards,
Ioannis Voultsos.

Dear Ioannis,

Just a few comments:

  • Can you clarify what you mean by “OpenFAST manual, p.148”; where exactly did you find that statement? My guess is this meant to refer to “the nominal downwind” direction rather than “downwind”. The latter definition of the inertial frame coordinate system (following the zero-degree wind/wave direction) is more accurate.
  • For the simulation settings you describe, I would actually have expected identical results for the blade response, so, I’m I bit puzzled why the two cases are not even closer. What does a plot of the nacelle-yaw angle look like in each case?
  • Your description of the Wind1VelX output makes sense to me. Because the inertial frame coordinate system does not rotate with the wind direction, outputting Wind1VelX in the first case is along the wind direction and in the second case is misaligned with the wind direction, resulting in 10*COS(-20) = 9.4 m/s. Wind1VelX is an output from the InflowWind module, which is a module that only processes ambient wind, and so, does not include any induction/wake effects from the rotor.

Best regards,

Dear Jason,

Thank you for your quick answer.

  1. The definition of about the global inertial frame coordinate system was found in OpenFAST Documentation Release v3.0.0 and more specifically under ‘Section 4.2.3-Aeroacoustics Noise Model of OpenFast/Using the Aeroacoustics Model in AeroDyn/Observer Positions’.

  2. For the simulation with the Nacelle Yaw DoF disabled and the wind direction at 0 deg, the nacelle yaw angle has a value of 0 as expected. For the simulation with a wind direction of -20 deg, the nacelle yaw angle is constant at +20.02 deg for the whole 600 of the simulation.

  3. Just for clarification, even if Wind1VelX is misaligned with the inertial frame, therefore being lower than the set value, the wind speed experienced by the rotor is the set value. Is this correct?

Best regards,
Ioannis Voultsos.

Dear Ioannis Voultsos,

Regarding item 1, the statement in that aeroacoustics documentation is only precise for zero-degree wind propagation direction.

Regarding item 3, that is correct. You’ve aligned the rotor with the wind by yawing the rotor with the wind direction, so, the wind should be aligned with the rotor in both cases. You could confirm that by looking at the wind speed in the rotor frame, e.g. via AeroDyn write output RtVAvgxh.

Best regards,