I’m working on the simulation of DLCs 6.1 and 6.2 in IEC 61400-3-1:2019, using OpenFAST and the NREL 5MW baseline wind turbine (5MW_OC3Mnpl_DLL_WTurb_WavesIrr). I’m confused about the following problems:
The IEC standard requires constrained wave simulations for DLCs 6.1 and 6.2. This functionality does not exist in the current release version of OpenFAST, but I noticed that the dev branch of OpenFAST (commit e6052f28744366ed19b89c9b81c7c0f495cffdd1) implements this feature and I compiled the binary myself. However, When I change the MSL2SWL in SeaState.dat and MSL2SWL in 5MW_OC3Mnpl_DLL_WTurb_WavesIrr.fst from 0 to other value, the result of ReactFZss seems weird: It fluctuates drastically and deviates from the regular Fz (about 8.4e6 N) which is controlled by gravity. I further noticed that the HydroDyn.dat file says HydroFzi has been removed due to numerical instability in regression tests.
- Is this numerical instability causes the weird ReactFZss?
- If MSL2SWL == 0, the results of ReactFZss look reasonable. Can I trust the results in this case (ReactFZss and other forces/moments on the foundation)?
- If MSL2SWL != 0, can I trust the outputs of other channels?
I’m also confused about the constrained wave height I should embed into the simulation. The standards says I should use “N-year return wave height, H_N”. If the metocean data is lacking, may I use H_N = 1.86 H_s,N (i.e., for 50 year return wave height, H_50=1.86H_s,50, in which H_s,50 is the significant wave height with a return period of 50 years assuming a 3-hour reference period) for CrestHmax in SeaState.dat with ConstWaveMod == 2? Or I should use other value and setting?
Sorry for using the reply function instead of editing post. The edit button vanished, which may be due to my frequent corrections to typos.
I notice that members in the forum say they are simulating the IEC DLCs 1.6, 6.1, 6.2 and 6.3. Also, the IEA Wind TCP Task 37 technical report “Definition of the IEA Wind 15-Megawatt Offshore Reference Wind Turbine” claims that OpenFAST was used to simulate DLCs 6.1 and 6.3 (Page 32). However, according to IEC 61400-3-1:2019, these DLCs require constrained wave simulation, which is not an available function in the current release version of OpenFAST, as far as I know. I think most users will choose the release version rather than compiling the dev version themselves.
So, is it possible to make the release version achieve the equivalent of the constrained wave with some settings?
Thanks in advance and best regards,
I’ve asked a colleague to respond to your prior questions from Sep 13.
Constrained NewWave theory was first added to OpenFAST in the following pull request: https://github.com/OpenFAST/openfast/pull/1008, which is slated to first be released in OpenFAST v4.0. Earlier versions of OpenFAST did not support constrained NewWave theory. That said, earlier versions of OpenFAST could support user-specified wave-elevation time series (
WaveMod = 5) or user-specified full wave kinematics time series (
WaveMod = 6), so, if the user provided their own waves with constrained NewWaves embedded, those could be applied to earlier versions of OpenFAST.
While I was not the author of the IEA Wind TCP Task 37 report you reference, my understanding though is that the Extreme Sea State (ESS) conditions were simulated with irregular waves without embedded constrained NewWaves, and so, did not follow IEC 61400-3-1 precisely.
Thank you for your reply; the information you provided is very helpful. Also, thanks to all the developers of OpenFAST for sharing the excellent software. Waiting for the release of OpenFAST v4.0.
Sorry for the delay, but, in case this is still relevant to you, please see my reply to your original post below:
The issue you identified with
MSL2SWL!=0 is caused by some bugs in the
dev-unstable-pointers branches of OpenFAST associated with the water depth. HydroDyn is not correctly detecting the member end joints below the seabed when
MSL2SWL!=0 and erroneously applies hydrodynamic and hydrostatic loads to the bottom of the monopile, thus causing the deviation and fluctuation of
ReactFZss. This issue is fixed as far as I can tell with a work-in-progress pull request. This pull request is for the
dev-unstable-pointers branch, which should be functionally the same as the
The “numerical instability” issue you are referring to is likely just poor terminology. My understanding is that because
HydroFzi is very close to zero with the monopile, small differences in the results due to numerical errors can cause the regression test to fail, even though the results are still valid. This is why
HydroFzi was removed from the regression test.
You interpretation of the N-year extreme wave height and your SeaState constrained wave settings are consistent with mine.
Dear @Lu.Wang ,
Thank you for the detailed explanation, it is very helpful.