OpenFAST rc 5.0.1: motion and load differences between commits in a floating platform

These days I'm wrapping up the OC7 Phase II project (floating system) and wanted to upload two OpenFAST models to the r-test repo.

For the project, I used OpenFAST rc 5.0.1 commit 723b5a7 from January 23, 2026.

Before uploading these models, I wanted to rerun them using the latest commit bd79998 from October 20, 2026.

Issue 1: When looking at the platform motion, I can see some [relatively small] differences depending if the solver is compiled in single or double precision. See below for reference:

Issue 2: The yaw motion shows significant differences between commit regardless of the use of single or double precision:

For reference, the hydrodynamic yaw moment also show differences:

Issue 3: The solver using the last commit shows significantly higher frequency content in the loads. For reference, this is a wave-only condition and the wind turbine is not operating (there is no aero at all and the rotor is locked).

Loads within the platform in SubDyn:

For reference, this is not just an artifact in the output loads within SubDyn. When looking at HydroDyn, we can see similar oscillations as well:

Something similar can be observed in the roll moments as well. However, in this case is not straight-forward because the reference point used to compute this loading has changed between commits. In the first commit, the loads are expressed at the (0,0,0) m location with the corresponding lever arm distances. In the last commit, the hydrodynamic loads in HydroDyn are referenced to the platform reference point defined in SubDyn (so, it moves with the platform motion).

@RBergua

Hi @RBergua,

We have not had great success with single precision in OpenFAST v5 with tight coupling, so, I'm not sure I'd worry about issue 1.

Regarding issues 2 and 3, I'm curious if you've ran this case in OpenFAST v4.2.1; which commit is closer to that? Also, what tight coupling solver settings are you using?

Best regards,

@jjonkman

Hi @jjonkman,

Thanks for the feedback.

I did not run this model in OpenFAST v4.2.1. I only ran it in OpenFAST v5 and OpenFAST rc5.0.1.

These are the seetings used for the solver:

       0.01   DT              - Recommended module time step (s)
          3   ModCoupling     - Module coupling method (switch) {1=loose; 2=tight with fixed Jacobian updates (DT_UJac); 3=tight with automatic Jacobian updates}
          2   InterpOrder     - Interpolation order for input/output time history (-) {1=linear, 2=quadratic}
          0   NumCrctn        - Number of correction iterations (-) {0=explicit calculation, i.e., no corrections}
        0.5   RhoInf          - Numerical damping parameter for tight coupling generalized-alpha integrator (-) [0.0 to 1.0]
       1e-3   ConvTol         - Convergence iteration error tolerance for tight coupling generalized alpha integrator (-)
         15   MaxConvIter     - Maximum number of convergence iterations for tight coupling generalized alpha integrator (-)          
      99999   DT_UJac         - Time between calls to get Jacobians (s)
    1000000   UJacSclFact     - Scaling factor used in Jacobians (-)

I'm guessing the automatic Jacobian updating (ModCoupling = 3) may have changed between January and October, 2026. There are other changes that may be influencing these results, such as PR #3385, #3304, #3297.

Adding results from OpenFAST v4.2.1 may help is figure out which commit is better.

I tried using OpenFAST v4.2.1, but it'svery difficult to make the system run. I reduced the time step (from 0.01 to 0.001 s), increased the number of correction iterations to 2, and recomputed the Jacobians every 2.5 s.

      0.001   DT              - Recommended module time step (s)
          2   InterpOrder     - Interpolation order for input/output time history (-) {1=linear, 2=quadratic}
          2   NumCrctn        - Number of correction iterations (-) {0=explicit calculation, i.e., no corrections}
        2.5   DT_UJac         - Time between calls to get Jacobians (s)

By doing so, I was able to run the system up to 506 s out of 9754 s and it took +10h of computational time.

Unfortunately, the results are difficult to compare given the very significant differences between versions. For example, the OpenFAST model includes the flexible tower and floating platform as part of SubDyn. In OpenFAST v4.2.1, SubDyn does not use the rigid-body reference point. This has direct implications in the system dynamics. For reference, as part of the paper Implementation of Rectangular Members in OpenFAST for Hydroelastic Simulations (in press) we performed a code-to-code comparison agaisnt a third code and confirmed that the results from OpenFAST v 5.x are significantly better than earlier OpenFAST versions.

Looking at the yaw behavior, we have:

And looking at the hydro loading:

The higher frequency observed in OpenFAST rc 5.0.1 commit bd79998 corresponds to the first tower bending mode (0.41 Hz).

@RBergua

Dear @RBergua,

Good point about the introduction of the rigid-body reference point (TP0) in OpenFAST v5.0, not available in v4.2.1; I'm not surprised the results differ (and I'm not surprised v4.2.1 is more numerically challenged).

Unfortunately, to identify where the difference comes from, it may be necessary to check commits between the two, e.g., between each PR I mentioned in my prior comment.

Best regards,

@jjonkman

Thanks for the feedback, @jjonkman.

For reference, the 3 PRs commented above cannot change the physical results of the system.
PR; SubDyn: add per-member discretization support to align meshes with HydroDyn is not used in this OpenFAST model. This is an optional 8th column (MDivSize) in the MEMBERS table.
PR: SubDyn: Y3 mesh only applies to fixed-bottom systems.
PR: Fix SubDyn reaction load output only impacts SubDyn self-weight of the reaction joint(s). So, this applies to bottom-fixed systems as well.

I would expect that if there is a PR impacting these outputs is the #3356. But this would only show differences in the SubDyn outputs. It does not change the physics. So, it could not explain the differences observed in platform yaw and HydroDyn loads. Also, as a clarification, M2N1FKze above is the output from a spring element and it's therefore not impacted by this PR.

Since the different behavior appears between Jan 23, 2026 and Oct 20, 2026, I compiled the code at many different points and ran the model to identify when the differences showed up. The behavior changes from the code on Feb 4, 2026 (commit 72d272a) to Feb 5, 2026 (commit 992b2f0). As observed below, the differences are very significant.

Update: The loads are mainly different at the tower base (M2N1 sensor) and the hydrodynamic outputs from HydroDyn. However, in the pontoons (VolturnsUS-S design), the outputs are almost identical.

@RBergua

Hi @RBergua,

It looks like the relevant change is indeed the new SeaState wave-field interpolation (cubic instead of linear). Along with it, the free-surface normal used for the instantaneous hydrostatic loads changed from a finite difference over ± the member radius to the exact slope of the interpolated surface at a point.

On its own the exact slope is more accurate and computationally more efficient, requiring fewer interpolation calls. However, what's missing compared to the previous approach is the implicit filtering over the characteristic dimension of a section. This is necessary because the hydrostatic loads are computed assuming planarized local free surface in the vicinity of a member section/element, so they need a slope that is representative across the whole section, not the slope at its center.

The new point slope lets waves shorter than the column diameter tilt the waterplane. In your case the grid is also coarse for the shortest waves: with dx = 5 m and the 0.4 Hz cutoff (10-m wavelength), there are only about 2 grid points per wavelength. In that band the point slope gets amplified, exciting the tower mode at 0.42 Hz.

Proposed fix: the free-surface normal should again be computed by central differencing over +/- the section half-width, now on the cubic surface. With this change the high-frequency oscillation should be gone. The cubic interpolation should still be retained. To achieve 1% error in wave elevation for example, the cubic interpolation only needs 8 grid points per wavelength whereas the original linear interpolation requires 22 points. The same applies to the time interpolation, so, for a 3D grid, memory saving is very significant. We only need ~5% of the data/memory to achieve the same accuracy. For the full 4D grid, it can be more significant. I'll open a PR shortly.

Wow, thanks for tracking that down! I'm happy to hear it is not tied to some unexpected glue code change!

@RBergua

The fix is now in this branch https://github.com/luwang00/openfast/tree/SeaSt_HD_Finite_Difference_Wave_Normal. @RBergua It seems to be working based on my testing. Let me know how it performs on your end.

@luwang00

Thanks for looking into this, @luwang00. I confirm that the SeaState fix reproduces more closely the legacy behavior.

Below you can see the comparison in terms of hydrodynamic loads:

Here the comparison regarding the structural loads:

And finally the yaw motion:

For the yaw motion, there are still some differences between 500 and 700 seconds. But it looks much closer than before.

For reference, the outputs from OpenFAST rc-5.0.1 for October 30, 2026 without the fix are the exact same as for February 5, 2026.

HD/SS: use section-averaged free-surface normal for hydrostatics

Fixed with #3503

Navigation Menu

Repository navigation

OpenFAST rc 5.0.1: motion and load differences between commits in a floating platform #3496

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OpenFAST rc 5.0.1: motion and load differences between commits in a floating platform #3496

Description

Activity

jjonkman commented on Oct 22, 2026

RBergua commented on Oct 22, 2026

jjonkman commented on Oct 22, 2026

RBergua commented on Oct 26, 2026

jjonkman commented on Oct 26, 2026

RBergua commented on Oct 28, 2026

luwang00 commented on Oct 30, 2026

jjonkman commented on Oct 30, 2026

luwang00 commented on Oct 30, 2026

RBergua commented on Nov 2, 2026

andrew-platt commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions