Problems related to constrained wave in IEC DLCs 6.1 and 6.2

Wind & Water Computer-Aided Engineering Software Tools
1

Dear community,

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:

  1. 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.

    1. Is this numerical instability causes the weird ReactFZss?
    2. 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)?
    3. If MSL2SWL != 0, can I trust the outputs of other channels?

  2. 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?

Best regards,
Xingchao Wang

2

Hello, everyone.

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,
Xingchao Wang

3

Dear @Xingchao.Wang,

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.

Best regards,

4

Dear @Jason.Jonkman,

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.

Best regards,
Xingchao Wang

5

Hi @Xingchao.Wang,

Sorry for the delay, but, in case this is still relevant to you, please see my reply to your original post below:

  1. The issue you identified with MSL2SWL!=0 is caused by some bugs in the dev and 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 HydroFzi and 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 dev branch.

  2. 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.

  3. You interpretation of the N-year extreme wave height and your SeaState constrained wave settings are consistent with mine.

Best,
Lu

2 Likes
6

Dear @Lu.Wang ,

Thank you for the detailed explanation, it is very helpful.

Best regards,
Xingchao Wang