SoilDyn issues in OpenFAST v5.0.0

[RBergua]

I am woking with the SoilDyn module and the REDWIN DLL. I'm using the recently released OpenFAST v5.0.0 and comparing the results against OpenFAST v2.x that was used in the OC6 Phase II project (https://docs.nlr.gov/docs/fy21osti/79938.pdf).

For reference, the OpenFAST model accounts for a rigid RNA and a flexible tower (in ElastoDyn), a flexible monopile (in SubDyn) and soil-structure interaction (in SoilDyn).

I'm running a case with irregular waves and imposing a time serie of Fx, Fy, Fz, Mx, My, Mz loads at the nacelle through the structural control.

When comparing both numerical models, I can see that most results at the tower base location are very close between versions (as expected). See below for reference:

However, when I look at the seabed location [-30 m] (SoilDyn sensor), I can see significant differences between both numerical models:

Based on the data at the tower base location, I can perform some simple verifications. The first one, the force in the x direction at the seabed should be aligned to the tower base one, but containing more dynamics. For example, the seabed will be influenced by the waves loading the monopile. Basically, I would expect the same moving average between Fx at the tower base and seabed and different dynamics. In addition, the moving average should be pretty well aligned with the Fx that I prescribe at the nacelle.

Looking at OpenFAST v2.x, I can see the expected behavior:

However, OpenFAST v5.0.0 shows an unexpected behavior with the moving average being off.

It's also quite interesting to compare the Fz loading at the seabed since we saw an offset in the mean value in the above plot comparing OpenFAST v2.x vs OpenFAST v5.0.0. I extracted the loading from SubDyn and SoilDyn for the Z direction.

In OpenFAST v2.x these two outputs are aligned:

However, in OpenFAST v5.0.0. these two outputs show clear differences:

Something seems to be clearly off with SoilDyn in OpenFAST v5.0.0.

[jjonkman]

Thanks, @RBergua, for reporting this issue.

Can you clarify what solver settings you used in OpenFAST v5 (ModCoupling, NumCrctn, etc.) and if there is any sensitivity to these?

Best regards,

[RBergua]

@jjonkman, I used ModCoupling = 3 (tight coupling with automatic Jacobian updates) and no correction iterations (NumCrctn).

For reference, the original OpenFAST v2.x was using:
0.001 DT - Recommended module time step (s)
0 NumCrctn - Number of correction iterations (-) {0=explicit calculation, i.e., no corrections}

And it didn't have anything special regarding Jacobians.

But I cannot make OpenFAST v5.0.0 work with those settings. The solver blows up.

I tried with ModCoupling = 3 and NumCrctn = 1 and the results are the same.

I also tried: ModCoupling = 1 (loose coupling) and NumCrctn = 3. But the solver blows up as well.

[jjonkman]

Thanks for clarifying. Unfortunately, this issue sounds serious.

[FYHQZH]

Hi OpenFAST team,

I also encountered a similar issue when coupling SoilDyn with OpenFAST 3.5.5, thought this might be relevant. My suspicion is that it could be related to the changes introduced in #1526. In particular, the smaller reaction forces in the z-direction observed in OpenFAST 5.0.0 seem to point in that direction.

Hope this helps narrow things down.

[RBergua]

Thanks for the feedback, @FYHQZH

Are you running SoilDyn with the REDWIN DLL or to account for a linear stiffness matrix?

I guess checking the behavior of a numerical model that uses SoilDyn vs SubDyn considering a stiffness matrix at the seabed would be the easiest verification here. I will try to take a look tomorrow at this.

[FYHQZH]

Sorry, I’m not using the REDWIN DLL. I modified the code to use p–y curves instead. I think disabling SttcSolve might bring the OpenFAST 5.0.0 results closer to those from earlier versions.

[jjonkman]

Thanks for the insight, @FYHQZH!

@RBergua -- Does disabling SttcSolve and/or increasing the number of modes (Nmodes) in SubDyn bring your OpenFAST v5 solution closer to your original solution?

Best regards,

[RBergua]

Let's go step by step since there seems to be a lot to unpack in here...

First, I got rid of SoilDyn module completely and included a linear stiffness at the seabed as part of SubDyn.

In this model (called NREL2 in the OC6 phase II project), monopile and tower are included in SubDyn. The above results were for NREL1 model (tower in ElastoDyn and monopile in SubDyn).

Looking at the tower top, the trends are similar although the dynamics are different.

If I look at the seabed location, I can see again the Fz offset (the same phenomena is obserbed at the tower base location):

I guess this brings the first question: if SttcSolve changed at some point, did these changes pass the r-test properly?

Also, how related are these issues of SttcSolve and Nmodes with this other issue: #3085 (comment)?

Next, I will compare the stiffness matrix in SubDyn vs the same stiffness matrix in SoilDyn to ensure that we are reproducing the same outputs between this identical boundary conditions for the system.

[jjonkman]

Dear @RBergua,

Just a couple comments:

• My understanding of PR SD: removing static improvement method (SIM) from SubDyn elastic output mesh (y3 mesh) #1526 is that SttcSolve within SubDyn itself did not itself, but the impact on SttcCSolve on the Y3 mesh output of SubDyn (used by MoorDyn and SoilDyn) changed, so, this change is more related to module-to-module coupling between SubDyn, MoorDyn, and SoilDyn. As far as I know, there are no r-tests that capture this coupling.
• My understanding of issue Large number of Craig Bampton modes for flexible floating systems #3085 is that when Guyan modes represent elastic modes, it is important to consider a similar frequency range of Craig-Bampton modes. Can you clarify what Guyan modes you have in your SubDyn model, e.g., if you are tracking the rigid-body mode in SubDyn with TPID = 0?

Best regards,

[RBergua]

@jjonkman, thanks for the feedback.

I'm asking about r-test and SttcSolve because what we have in here is not a coupling between SubDyn and MoorDyn or a coupling with SoilDyn. The difference in vertical force (driven by weight) comes from SubDyn itself. The above results are for a monopile + tower in SubDyn. There is no SoilDyn. Therefore, I would expect this issue to be observed in all systems (e.g., a simple monopile).

Regarding the Guyan modes, I'm only using 6 Guyan modes in SubDyn that come from 1 interface joint (i.e., TPID = 1). My understanding is that the rigid-body reference point is only available for floating structures: https://openfast.readthedocs.io/en/main/source/user/subdyn/input_files.html#interface-joints

[jjonkman]

I'm not aware of any SubDyn changes that would effect how SttcSolve is handled internally within SubDyn itself. That said, I'm not sure what is causing the change in your NREL2 solution between OpenFAST v2.x and v5.0.

My comment about the Guyan modes was related to your original issue with SoilDyn. When SoilDyn is enabled, my guess is you don't have any reaction joint defined in SubDyn, so, SubDyn will consider this a floating case, which allows you to decide if you want SubDyn to track the rigid body mode internally or not. Based on your response, I understand you are not, so, issue #3085 doesn't apply.

[RBergua]

For reference, when using SoilDyn, I have no reaction joint in SubDyn. However, the stiffness matrix from SoilDyn is passed to SubDyn as boundary condition. Accordingly, SubDyn categorizes this as a fixed-bottom case (as expected) instead of a floating case.

The printed messages from SubDyn make physical sense:

[jjonkman]

Thanks for clarifying! I totally forgot that SoilDyn passed SubDyn this stiffness matrix, so, the results should be equivalent whether the stiffness matrix is specified in SubDyn or SoilDyn.