Question on Sigma-Coordinate System for External Wave Field Input (WaveMod = 6)

[birdie888]

Hello everyone,

I hope this message finds you well.

I am currently investigating the influence of extreme nonlinear waves on the dynamic response of offshore structures. To represent strong wave nonlinearity more accurately, I plan to use an externally prescribed wave field, i.e. setting WaveMod = 6, to input precomputed wave kinematics.

In the user manual, I noticed the following description for WaveMod = 6:
“The wave kinematics data specified are not limited to the domain between a flat seabed and SWL and may consider wave stretching, higher-order wave theories, or an uneven seabed.”
I would like to ask how this statement should be interpreted in practice. Specifically, does this imply that instantaneous free-surface effects can be accounted by prescribing the external wave field, for example by defining wave kinematics above the still water level or using sigma coordinate in the input data?

If a sigma-coordinate formulation is not supported, I would also like to ask whether applying Wheeler stretching to the input wave kinematics is considered an appropriate or commonly accepted approach to achieve a similar effect, especially when modeling extreme or strongly nonlinear waves.

From my understanding, if wave stretching is not enabled, OpenFAST does not evaluate hydrodynamic loads for ( z > 0 ), which may lead to a loss of part of the nonlinear wave effects, particularly under large wave heights. On the other hand, when wave stretching is enabled, I frequently encounter warnings related to the buoyancy calculation, because my study focuses on a fixed-bottom jacket-supported wind turbine, where structural members may repeatedly enter and exit the free surface under extreme waves.

In this context, I would like to ask whether there are recommended or robust approaches to handle this issue.

Thank you very much for your time and kind help.

[jjonkman]

Dear @birdie888,

I gather you are referring to the documentation of WaveMod = 6 from the Modeling Guidance section of the HydroDyn documentation on readthedocs: https://openfast.readthedocs.io/en/main/source/user/hydrodyn/modeling_considerations.html#waves. However, I see that this documentation is now outdated (and thus a bug in the documentation). This outdated documentation was applicable to old versions of OpenFAST when the wave kinematics were calculated within HydroDyn at hydrodynamic analysis nodes, which could have been both below and above the still water level (SWL).

Now that wave kinematics are calculated on a predefined grid in the SeaState module, WaveMod = 6 allows the user to prescribe the wave kinematics only at the grid points, which only exist at and below SWL. If you want to use WaveMod = 6 and have wave kinematics up to the instantaneous wave elevation, you must select one of the wave-stretching options (Wheeler or vertical only). See the SeaState documentation here for more information: https://openfast.readthedocs.io/en/main/source/user/seastate/input_files.html. Depending the degree of free-surface nonlinearity you are considering, this may have limitations to your application because the wave stretching approaches are not accurate near the breaking wave limit.

Best regards,

[birdie888]

Dear @jjonkman

Thank you very much for your detailed reply and for pointing out the documentation issue.

After carefully reading the updated SeaState documentation and examining the WaveMod = 6 implementation, I found that using Wheeler stretching still does not fully address the issue I am encountering.

My main concern is that I would like the wave kinematics to be evaluated up to the actual instantaneous free surface (η), rather than being fundamentally limited to the still water level (z = 0). While Wheeler stretching maps the physical vertical range from ([-h, η]) back to the computational range ([-h, 0]), the kinematics are still interpolated from the original wave field grid that only exists over ([-h, 0]). As a result, the velocity at the actual free surface is never directly represented.

For example, consider a wave with amplitude (a = 5m) in water depth (h = 50m). Suppose I want to compute Morison-type loads at a fixed point on a wind turbine located at ((x,y,z) = (0,0,3) m). Physically, when the instantaneous free surface elevation (η) is between 3 and 5 m, this point is submerged, and its velocity should correspond to the wave kinematics evaluated at (z = 3).

If wave stretching is disabled, wave kinematics above the SWL are not computed, so no wave load is applied at this point.

If Wheeler stretching is enabled, the vertical mapping gives

z' = -1.82 m,

meaning that the velocity used in the Morison equation is actually taken from (z'=-1.82) m. This leads to a systematic underestimation of the true velocity that should exist near the free surface.

In other words, Wheeler stretching adjusts the evaluation location but does not extend the wave field grid itself to the instantaneous free surface, which is the core limitation for my application.

Given this, I would like to ask whether this issue could, in principle, be addressed by modifying the SeaState source code — for example, by extending the wave kinematics grid dynamically up to (η), or by allowing direct evaluation of kinematics at (z > 0) when points are temporarily submerged. If this is feasible, could you please advise which (.f90) files would be most relevant to investigate?

Thank you again for your time and guidance.

Best regards,
Birdie

[birdie888]

Alternatively, I was wondering whether this limitation could be addressed by reformulating the wave field using a sigma-coordinate system (σ=z+h/η+h ∈[0,1]), such that the wave kinematics are computed on a dynamic grid
(x,y,σ) that moves with the instantaneous free surface. In this formulation, the physical vertical coordinate z would be recovered from
𝜎 and η(x,y,t), allowing the wave field itself — rather than only the evaluation point — to extend up to the actual free surface. I am curious whether such a sigma-coordinate-based approach would be compatible with the current SeaState design, or whether there are fundamental architectural reasons why the wave field grid is restricted to fixed z-levels at and below the SWL.

[luwang00]

Hi @birdie888, if I'm not mistaken, you can use the existing WaveMod=6 and Wheeler stretching to achieve what you wanted with the $\sigma$-coordinate system. With this combination, you are effectively populating the input wavefield based on the scale $Z'$ coordinate, and $Z'=h( \sigma -1)$. This means you just need to convert your $\sigma$-based wavefield to $Z'$-based, and Wheeler stretching will take care of the rest.

[birdie888]

Hi @luwang00
Thank you very much for the suggestion, this is very helpful. I will convert my external wavefield to a Z′-based representation and using it as input to WaveMod = 6 with Wheeler stretching enabled. Thanks again for the guidance.