Diffrences in free-decay response OpenFAST v2.3 - v3.0

[frp09]

Hi everyone,

I am updating a model of a floating wind turbine from OpenFAST v2.3 to OpenFAST v3.0.

While running some free-decay tests I’ve noticed large differences in damping between the two OpenFAST versions. The v3.0 model seems to have less quadratic damping that the v2.3 one.

Moorings are modelled with MoorDyn, hydrodynamics are handled trough potential-flow + Morrison drag terms for second order damping. The ElastoDyn files are identical, and aerodynamics and control are switched off.

Potential-flow input files were supplied to me with the model, but I even attempted at re-calculating them with AQWA and I am getting very similar results.

I am using compiled binary executables downloaded from the “Releases” page. The files should be equivalent.

Have any changes been made to the code between these two OpenFAST versions that could explain such a behavior? I have looked at the documentation, NWTC forum and the open GitHub issues but haven't found anything. I am going over my input files again, but I’m quite certain that they are identical, apart from the parts that have been added/removed from the newer version.

I have noticed issue #824 , where a difference in linearization is reported, maybe this could be related?

Thanks in advance to anyone that may help.

[jjonkman]

Dear @frp09,

Nothing comes to mind immediately as to what would cause these differences in damping level. It looks like the quadratic drag (dominant for larger amplitude motion) is quite similar between the two versions; the differences appear mostly at low amplitude, where radiation damping (from the potential-flow solution) likely dominates over quadratic drag.

Is the model you are running your own, or is one of the public model NREL provides? If the former, have you seen similar behavior in one of the public models?

There were many changes and several releases between OpenFAST v2.3 and OpenFAST v3.0. Have you tried stepping through each release to better isolate when the change occurs?

Best regards,

[frp09]

Dear @jjonkman ,

Thank you for the reply.

The model I'm running is not an NREL public model. For context, it is a model of the DTU 10MW on a spar-buoy. However, I have updated a model of the NREL 5MW on OC5 DeepCWind semi-sub that I created from OpenFAST v2.4 to OpenFAST v3.0 and there is no difference in free-decay results for this model, as expected. I would consider this model close to a public NREL model, since the HydroDyn part is the same as OC4 with tweaks to the Morrison drag coefficients.

Going back to the spar-buoy, based on your suggestion, I have tried to run the model with multiple versions of OpenFAST, the results I'm getting are in the figure attached. Results from v2.4 and v2.5 and from v2.6 and v3.0 are the same respectively.

It seems like I'm seeing differences when there is an API change for HydroDyn. In particular:

• from v2.3 to v2.4 ExctnMod was added (I'm using option 1 in v2.4 and latter, this should be consistent with v2.3 right?)
• from v2.4 to v2.5 an extra column was added to the line properties table in MoorDyn, but this seems to make no difference
• from v2.5 to v2.6 several enhancements have been implemented in HydroDyn
• from v2.6 to v3.0 there are no API differences for HydroDyn/ElastoDyn/MoorDyn

Also, this may or may not be relevant, but I've noticed that v2.3 to v2.5 throw an error if I try to lad the .8 WAMIT file to account for slow-drift force while v2.6 and v3.0 run with no errors/warnings. Below is the error message from OpenFAST v2.4:

FAST_InitializeAll:HydroDyn_Init:WAMIT2_Init:CheckInitInput: Warning: the .8 WAMIT output file
does not contain information that can be used for second order force calculations of platform
heave.
No second order heave forces will be calculated within the Newman's Approximation
calculations.
CheckInitInput: Warning: the .8 WAMIT output file does not contain information that can be used
for second order force calculations of platform roll.
No second order roll forces will be calculated within the Newman's Approximation
calculations.
CheckInitInput: Warning: the .8 WAMIT output file does not contain information that can be used
for second order force calculations of platform pitch.
No second order pitching forces will be calculated within the Newman's Approximation
calculations.
WAMIT2_Init:NewmanApp_InitCalc: Maximum wave direction required of 0 is notfound in the WAMIT
data file .\HD_files/HDB/sw_spar.8 for the first wave direction.
NewmanApp_InitCalc: Maximum wave direction re

FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

Any idea of what could be causing such differences? It is particularly puzzling that the OC5 testcase does not show these differences, in contrast to what I'm seeing here, so I don't know what to think, since the two cases should be quite similar from a methodological standpoint (both used potential+Morrison hydrodynamics).

Any indication, as always, is helpful

Best

[andrew-platt]

Dear @frp09,

The error from the 2nd order HydroDynamics in v2.4.0 is due to a bug in a check of the angles for multi-directional waves. This was corrected in v2.5.0, which is why you only see this issue in v2.4.0 (issue report: #9).

Does your model by any chance contain any tapered elements that are crossing the free surface?

Regards,
Andy

[frp09]

Dear @andrew-platt ,

Thanks for the reply. Just for your information, I'm seeing the error related to the second-order hydro in v2.5 too (see screen output below:

---

OpenFAST

Copyright (C) 2021 National Renewable Energy Laboratory
Copyright (C) 2021 Envision Energy USA LTD

is program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.

---

OpenFAST-v2.5.0
Compile Info:

• Compiler: Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R)
  64, Version 2021.1 Build 20201112_000000
• Architecture: 64 bit
• Precision: single
• Date: Jan 14 2021
• Time: 12:12:37
  Execution Info:
• Date: 03/03/2022
• Time: 17:10:25+0100

OpenFAST input file heading:
SOFTWIND SPAR 10MW, LHEEA, CENTRALE NANTES, Sept. 2020

Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
Running HydroDyn.
Setting WaveTMax to 0.0 since WaveMod = 0
Reading in WAMIT output with root name
"D:\Wind\FLOATING\FLOATECH\SOFTWIND\SOFTWIND_UNIFI_FD_TRIAL_v2.5\HD_files/HDB/sw_spar".
Computing radiation impulse response functions and wave diffraction forces.
Calculating second order difference-frequency force using the Newman's approximation.

FAST_InitializeAll:HydroDyn_Init:WAMIT2_Init:CheckInitInput: Warning: the .8 WAMIT output file
does not contain information that can be used for second order force calculations of platform
heave.
No second order heave forces will be calculated within the Newman's Approximation
calculations.
CheckInitInput: Warning: the .8 WAMIT output file does not contain information that can be used
for second order force calculations of platform roll.
No second order roll forces will be calculated within the Newman's Approximation
calculations.
CheckInitInput: Warning: the .8 WAMIT output file does not contain information that can be used
for second order force calculations of platform pitch.
No second order pitching forces will be calculated within the Newman's Approximation
calculations.
WAMIT2_Init:NewmanApp_InitCalc: Maximum wave direction required of 0 is notfound in the WAMIT
data file D:\Wind\FLOATING\FLOATECH\SOFTWIND\SOFTWIND_UNIFI_FD_TRIAL_v2.5\HD_files/HDB/sw_spar.8
for the first

FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

Regarding your second question, the model has a tapered element close below the surface but it's not intersecting the free surface. I had seen the issue I think you are referring to here on GitHub but didn't pay much attention to it since the tapered element in my model is not intersecting the free surface. Could this be related to what I'm seeing in the model?

Thanks,
Francesco

[andrew-platt]

Dear Francesco,

My apologies. The wave direction check didn't get fixed until v2.6.0 (I incorrectly stated that it was fixed in v2.5.0).

We've had some strange issues with tapered elements in the past, so that got me wondering if there is another issue with them that we aren't aware of. If you remove the taper on that element, does the problem go away?

Regards,
Andy

[frp09]

Dear Andy,

No worries, it's good to know that this makes sense.

I could try removing the tapering and let you know. Would you just try to remove tapering from the Morrison part or also generate new potential flow inputs without the tapering? Of course the latter requires more work because the displacement of the platform changes at that point.

Thanks again,

Francesco

[andrew-platt]

Dear Francesco,

All the issues we've seen so far are with tapered elements are in Morrison. So I would just remove it from that section.

Do you have any additional damping terms (AddCLin etc) defined?

Andy

[jjonkman]

Dear Francesco,

It is interesting that the damping level changes in two separate releases (from v2.3 to v2.4 and again from v2.5 to v2.6). So, there are two changes to track down.

I'd first like to understand if these changes in damping levels are tied to damping from the potential-flow solution or to drag from the strip-theory solution (or perhaps through AddBLin or AddBQuad if you've set those nonzero). Could you generate separate models with potential-flow only and with strip-theory only to better isolate the issue(s)?

Best regards,

[frp09]

Dear Andy and Jason,

Thank you for the very useful suggestions.

There is some additional quadratic drag (AddBQuad) for the pitch and roll DOFs only.

Removing the tapering makes no difference at all.

I also tried running with strip-theory only and with potential flow only and in both cases I was seeing similar differences between versions (v2.3 different from v2.4 and v2.5 different from v2.6 and v3.0). This got me thinking that perhaps the issue was in the moorings. The mooring system is kind of complex as each catenary chain is split in two and connects to the spar-buoy in two points to improve yaw stability. Also, the way this model is set there is significant damping in the moorings. To see if the issue is related to moorings I switched from MoorDyn to MAP++ and ran the different version of OF with Strip theory only, with potential flow only and with potential flow + strip theory for Cd. Below are the results I got:

It seems that the issue is in the MoorDyn module. When using potential flow only and potential flow + strip theory for Cd all of the versions are in agreement. When using Strip theory only v2.6 and v3.0 do not agree with the rest. The model uses Simple coefficients. This is how they are set for the two models:
OF v2.3, v2.4, v2.5:

---------------------- SIMPLE HYDRODYNAMIC COEFFICIENTS (model 1) --------------
SimplCd SimplCdMG SimplCa SimplCaMG SimplCp SimplCpMG SimplAxCa SimplAxCaMG SimplAxCp SimplAxCpMG
(-) (-) (-) (-) (-) (-) (-) (-) (-) (-)
0.5 0.00 0.40 0.00 1.00 1.00 0.0 0.00 1.00 1.00

OF v2.6, v3.0:

---------------------- SIMPLE HYDRODYNAMIC COEFFICIENTS (model 1) --------------
SimplCd SimplCdMG SimplCa SimplCaMG SimplCp SimplCpMG SimplAxCd SimplAxCdMG SimplAxCa SimplAxCaMG SimplAxCp SimplAxCpMG
(-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-) (-)
0.5 0.00 0.40 0.00 1.00 1.00 0.00 0.00 0.00 0.00 1.00 1.00

Perhaps I got something wrog here? The rest of the Morison part of the HydroDyn file is the same.

I will also try to understand if there are settings I can change to solve this issue related to MoorDyn. I must not that no errors or warnings are thrown when using MoorDyn. Do you have any suggestions?

Thanks,

Francesco

[jjonkman]

Dear Francesco,

Regarding your solution with MAP++ in place of MoorDyn, the only real difference I see is in the natural frequency predicted by the strip-theory only model in OpenFAST v2.6 and v3.0. Can you clarify what type of free-decay test you are simulating (surge or pitch?) and which DOFs are enabled? One big difference between OpenFAST v2.5 and OpenFAST v2.6 is in how hydrostatics are solved by the strip-theory solution. In OpenFAST v2.5 and earlier, the strip-theory solution only solved hydrostatics at the undisplaced position of the body, add AddCLin in HydroDyn was used to specify the hydrostatic stiffness matrix. In OpenFAST v2.6 and newer, the hydrostatics are solved by HydroDyn in the displaced position, so, nonzero AddCLin is no longer needed. If you specifying hydrostatic stiffness through AddCLin in both models that would be a problem (double counting the hydrostatic stiffness in OpenFAST v2.6 and newer). This would mainly effect the natural frequencies in roll and pitch.

Regarding changes to MoorDyn between these versions, I'm not sure. Hopefully @mattEhall can comment on that.

Best regards,

[mattEhall]

Hi Francesco,
I can't think of a change in MoorDyn that would explain differences in damping between versions, but it's something we can look into more. Considering what you found about differences in strip theory, could you provide a plot that isolates the difference you think must be caused by MoorDyn? And could you share more information about the mooring system setup?
Matt

[andrew-platt]

Possibly related #992 and #999

[frp09]

Dear Jason, Matthew and Andy,

Thank you again for the answers. @jjonkman I was not aware of this change, so I removed the hydrostatic stiffness from Hydrodyn in OF2.6 and OF3.0. However, since the results I am showing are for a surge decay test, removing the hydro stiffness made little difference. As I mentioned, I do not see any differences in the free-decay test if I run the case with MAP++ and strip theory only for drag (PropPot = TRUE), so maybe what I'm seeing is related to added mass computation?

If I look at the platform pitch recorded for the free decay test using MAP++ and strip theory only, the plot looks like this:

The timeseries from OF v2.6 & v3.0 are qualitatively more similar to what I see in experiments for this testcase, since there is isgnificant coupling between pitch and surge.

@mattEhall below you can see the surge decay test run with MAP (left) and with MoorDyn (right). All other settings are the same (in particular, hydrodynamics are trated with potential flow + strip theory for drag). All tested OF versions agree if I use MAP, but they dont if I use MoorDyn.

The mooring setup can be described as follows:
Three catenary mooring chains 120° degrees apart. One chain is directed directly downwind. The fairleads of the three chains are connected to two bridle chains, for a total of six bridle chains (2 per main mooring line). The six bridle chains are connected to the spar floater in three points. A schematic representation below:

Hope this helps,

Best,

Francesco

[jjonkman]

Dear Francesco,

I agree that if the free-decay results are changing between OF v2.5 and v2.6 for the strip-theory only model, while these versions compare well for a hybrid strip-theory plus potential flow model, then the difference is likely associated with the strip-theory added mass. This effect can likely be isolated by setting up a strip-theory only model with all hydrodynamics coefficients zeroed except added mass. Would you mind trying that? It may also help to perform the surge free-decay test with one DOF (surge only) to fully isolate the effect.

I let @mattEhall comment on the changes associated with MoorDyn.

Best regards,