Floating Turbine in Extreme Events with SubDyn enabled

[Bart.Klootwijk]

Dear all,

I am running a subset of formal DLC simulations on the OC4 DeepCWind semisubmersible platform with the 5MW offshore reference turbine, including computation of the sub-structural dynamics with SubDyn. More precisely, I am running DLC’s 1.2, 1.6, 6.1 and 6.3 for the Buchan Deep site. Most of them run without any problems, but for a specific extreme event modeled in 6.3, the simulation is aborted.

Firstly, after some previous inquiries on a different forum topic on how to model the floating platform in SubDyn, I followed the guidelines and verified the SubDyn implementation against the OC4 certification test #25 and got a very close match between cases with and w/out SubDyn enabled (see picture below, blue line is w/out SubDyn, orange line is w/ SubDyn), therefore I would suspect my implementation in SubDyn is correct.

Now, moving on to my problem, I am trying to simulate DLC 6.3 with the following conditions:

• Turbsim EWM 1yr (mean Vhub = 40m/s)
• JONSWAP sea with Hs = 7.8 m, Tp = 12.4 s, peak shape factor = 2.24
• Aligned wind and waves, no currents
• Fixed yaw angle of ± 20 deg

After consulting posts related to simulating a parked rotor on this forum, I set the following (initial) conditions for the simulation:

• elastodyn[‘RotSpeed’] = 0 # [rpm] parked rotor
• elastodyn[‘BlPitch(1)’] = 90 # [deg] pitch-to-vane
• elastodyn[‘BlPitch(2)’] = 90 # [deg] pitch-to-vane
• elastodyn[‘BlPitch(3)’] = 90 # [deg] pitch-to-vane
• elastodyn[‘GenDOF’] = False
• elastodyn[‘YawDOF’] = False
• elastodyn[‘NacYaw’] = -20 # [deg] fixed nacelle yaw
• elastodyn[‘PtfmSurge’] = 5.0 # [m] initial platform surge
• elastodyn[‘PtfmSway’] = -5.0 # [m] initial platform sway
• elastodyn[‘PtfmPitch’] = 2.0 # [deg] initial platform pitch
• aerodyn[‘WakeMod’] = 0
• aerodyn[‘AFAeroMod’] = 1
• servodyn[‘PCMode’] = 0

I am running this simulation twice, with different wind- and wave seeds for each simulation. The first simulation (sim0) runs without errors (see below). Could you please confirm that the platform motions and turbine performance indicators are as expected for DLC 6.3?

The second simulation (sim1) however, stops just after 40 seconds:

The error message from OpenFAST reads the following:

FAST_Solution:CalcOutputs_And_SolveForInputs:SD_CalcOutput:Small angle assumption violated in
SUBROUTINE SmllRotTrans() due to a large UR_bar input angles. The solution may be inaccurate.
Simulation continuing, but future warnings from SmllRotTrans() will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans():

NaN detected at time 40.1966346153846 in Line 3 in MoorDyn
.
NaN detected at time 40.197 in MoorDyn.
NaN detected at time 40.197 in MoorDyn.

FAST_Solution:FAST_AdvanceStates: NaN state detected.

OpenFAST encountered an error at simulation time 40.188 of 1000 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

Indeed, when I plot the results from t=38 to t=40, an instability is observed, which as it seems to me originates from the fairlead tension:

I am puzzled as to how this could occur. The other 51 simulations ran without errors. I have tried decreasing the time step for this simulation from 0.0125 to 0.0025 but this didn’t solve the problem. When I re-run the same simulation (sim1) with SubDyn disabled, it does terminate normally:

Does this mean that the SubDyn module is set up incorrectly?

I would truly appreciate your help, as I have been unable to find a solution by my own efforts.
Please let me know in case you need me to share the OpenFAST files to verify the inputs.

[Jason.Jonkman]

Dear @Bart.Klootwijk,

Overall, it sounds like your model is set up correctly. Have you set solver settings typical for floating offshore wind turbines with SubDyn enabled, e.g., NumCrctn = 1, DT_UJac = 1/(10*natural frequency in Hz of the roll, pitch, or yaw mode with excessive motion), and UJacSclFact equal to a value roughly the same order of magnitude as the total system mass in kg? Because the issue seems to originate within MoorDyn, perhaps try dropping just the time step within MoorDyn (dtM)?

I’m excited to hear that you’ve developed an elastically flexible model of the OC4-DeepCwind semisubmersible. Developing a elastically flexible version of one or more of our reference floating wind substructures is an open issue in our OpenFAST r-test: Add Test case for flexible platforms · Issue #39 · OpenFAST/r-test · GitHub. Would you be willing to share your OpenFAST model publicly?

Best regards,

[Bart.Klootwijk]

Hi Jason,

Thank you for the quick reply. Your advice is much appreciated.

Yes, I have set NumCrctn = 1, however I realise I had forgotten about the DT_UJac setting. Should this value be rather precise, or could it be a rough estimate? I didn’t know I had to adjust UJacSclFact as well. When you talk about total system mass, do you mean including ballast mass? I will adjust these values and try again. As for the MoorDyn time step, I had reduced this value previously for other simulations that had gone unstable, but without success. I will try again if your other suggestions don’t solve the problem.

As for the elastically flexible model of the OC4-DeepCWind semisub; I should point out that for now it is still set up as a rigid body (Nmodes = 0). I have yet to test it as a flexible model. My model is part of a bigger programming framework (written in Python) to design and optimise a semi-submersible platform for floating offshore wind, using OpenFAST as a higher-fidelity analysis tool, as opposed to using simplified engineering models. I am doing this work as part of my master thesis; I should run it by my supervisor first, but I agree with you that it would be helpful to the community if it can be shared publicly.

Best regards,

[Bart.Klootwijk]

Dear Jason,

I have set the following in SubDyn:

• DT_UJac = 1/(10*0.037) where the value fn_pitch = 0.037 Hz was taken from the DeepCWind platform definition report. (My question about how precise this fn value should be remains…)
• UJacSclFact = 1.4e7 which is the same order of magnitude of the total system mass incl. ballast

And, although at considerably increased computational cost, the simulation runs without errors! That is, for a rigid platform (Nmodes = 0). I plan to test with an elastically flexible platform model soon. Thank you for your guidance.

Best regards,

[Jason.Jonkman]

Dear @Bart.Klootwijk,

I’m glad to hear that solved the issue!

For UJacSclFact, the total mass including ballast is appropriate. Approximating DT_UJac and UJacSclFact is fine, as long as the values are in the ballpark.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Thank you for clarifying.

I have one follow-up question on the flexible model, and one minor question related to the physical platform properties:

1. I started testing the flexible model. I have tried different values for Nmodes, but my findings are that Nmodes = 5 is the maximum number that I can choose to avoid the simulation becoming numerically unstable. From 6 or higher, the simulation crashes after about 0.5 seconds, with a number of error messages (see below). I suspect (although I’m not exactly sure) they originate again from the moordyn module, as in some cases, NaN states are detected (which is the problem I experienced previously)

FAST_Solution:CalcOutputs_And_SolveForInputs:SD_CalcOutput:Small angle assumption violated in
SUBROUTINE SmllRotTrans() due to a large UR_bar input angles. The solution may be inaccurate.
Simulation continuing, but future warnings from SmllRotTrans() will be suppressed.

Additional debugging message from SUBROUTINE SmllRotTrans():
Warning: SkewedWakeCorrection encountered a large value of chi (93.482 deg), so the yaw
correction will be limited. This warning will not be repeated though the condition may persist.
See the AD15 chi output channels, and consider turning off the Pitt/Peters skew model (set
SkewMod=1) if this condition persists.

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will be suppressed.

Additional debugging message from SUBROUTINE SmllRotTrans(): 0.56375 s
The BEM solution is being turned off due to low TSR. (TSR = -1.5559). This warning will not be
repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 18, blade 1):UA_UpdateStates:UA_UpdateDiscOtherState:ComputeKelvinChain:Mach number exceeds 1.0. Equations cannot be evaluated.

OpenFAST encountered an error at simulation time 0.56375 of 100 seconds.

Simulation error level: FATAL ERROR

Aborting OpenFAST.

The plots of the platform motion and turbine KPI’s show the unstable behavior:
These plots are for DLC 1.2 with a mean wind speed of 11 m/s, but similar errors/behaviour is observed across the whole range of wind speeds / wave heights.

I have tried reducing the time steps of both OpenFAST and MoorDyn, without success. In a previous reply to a different post, you mentioned that Nmodes should be set “large enough to capture the lowest modes of the substructure, say up to 5-10 Hz, as calculated by SubDyn. This is typically less than 10-20 for most floating substructures.” When I inspect the Craig-Bampton modes in the JSON output file, the 5th mode has a frequency of about 2.4 Hz, which is apparently still too low. Do you have any suggestions as to how can I increase the number of modes in SubDyn while keeping the simulation stable?
Currently in SubDyn I use JDampings = 1 and NDiv = 1

2. I am trying to compute the submerged volume of the floating platform based on the geometry specification in HydroDyn (Members, Member Joints and Member Cross-Section Properties). I do this simply by computing the volume of the submerged part of each member (discarding anything above SWL), and then taking the sum of all the volumes to get the total displaced volume of the platform. However, in doing so I end up with a total displacement volume of 13873 m3, which differs from the value reported in the OC4 definition report, which is 13917 m3. This is somewhat problematic, as I need the displacement volume to compute the vertical mooring pre-tension, and in the hydrostatic equilibrium equation, the difference in this buoyancy volume results in a considerable difference in the computed mooring pre-tension. If my understanding is correct, the displacement volume reported in the technical report is an output of the WAMIT simulation. This leaves me wondering what the mesh geometry has been for the WAMIT simulation, and if it is any different from the geometry specified in HydroDyn. When I inspect the geometry defined in HydroDyn for example (see first two pictures below), the connection points of the cross braces are different compared to figure 1-1 of the report (also shown below). Please, could you clarify if there is any discrepancy between the displacement volume reported in the OC4 definition document and the geometry defined in HydroDyn?

[Jason.Jonkman]

Dear @Bart.Klootwijk,

It sounds like your model is numerically unstable such that reducing the OpenFAST time step (DT) should solve the problem, considering that you’ve already set appropriate values for NumCrctn, DT_UJac, and UJacSclFact. Can you summarize your solver settings?

Regarding (2), I’m not aware of any discrepancies between the WAMIT and HydroDyn inputs, but I was not the one to make this model either. You can find the WAMIT input files for the OC4-DeepCwind semisubmerisble in my post dated May 15, 2023, in the following forum topic: OC4-DeepCwind semisubmersible - WAMIT Files.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Please find my solver settings below.

One thing about the instability that popped into my mind is the way that the structure is defined in SubDyn. I am starting to think that this might play a role as well. Currently I make use of a number of virtual members to connect the joints, to avoid introducing extra mass to the platform. The picture below shows in red the virtual members, which I modeled with an extra entry for the beam properties. Following the guidelines in the SubDyn documentation, I reduced the material density and increased the stiffness parameters (by a factor 1000). The beam properties for the virtual members are:

PropSetID: 5
YoungE (N/m2) : 2.1000e+14
ShearG (N/m2) : 8.0769e+13
MatDens (kg/m) : 1
XsecT (m) : 0.0175
XsecD (m) : 1.6

Thank you for sharing the WAMIT files, but unfortunately I don’t have a WAMIT license. Is there a way to inspect the mesh geometry without using WAMIT? In the meantime I will go over my calculation methods once again.

main fast file:

---------------------- SIMULATION CONTROL --------------------------------------
True          Echo          - Echo input data to <RootName>.ech (flag)
"FATAL"       AbortLevel    - Error level when simulation should abort (string) {"WARNING", "SEVERE", "FATAL"}
1000          TMax          - Total run time (s)
0.0125        DT            - Recommended module time step (s)
2             InterpOrder   - Interpolation order for input/output time history (-) {1=linear, 2=quadratic}
1             NumCrctn      - Number of correction iterations (-) {0=explicit calculation, i.e., no corrections}
2.7027        DT_UJac       - Time between calls to get Jacobians (s)
14000000.0    UJacSclFact   - Scaling factor used in Jacobians (-)

subdyn file:

---------------------- SIMULATION CONTROL --------------------------------------
True          Echo          - Echo input data to "<rootname>.SD.ech" (flag)
"DEFAULT"     SDdeltaT      - Local Integration Step. If "default", the glue-code integration step will be used.
3             IntMethod     - Integration Method [1/2/3/4 = RK4/AB4/ABM4/AM2].
True          SttcSolve     - Solve dynamics about static equilibrium point
True          GuyanLoadCorrection - Include extra moment from lever arm at interface and rotate FEM for floating.
-------------------- FEA and CRAIG-BAMPTON PARAMETERS---------------------------
3             FEMMod        - FEM switch: element model in the FEM. [1= Euler-Bernoulli(E-B); 2=Tapered E-B (unavailable); 3= 2-node Timoshenko; 4= 2-node tapered Timoshenko (unavailable)]
1             NDiv          - Number of sub-elements per member
True          CBMod         - [T/F] If True perform C-B reduction, else full FEM dofs will be retained. If True, select Nmodes to retain in C-B reduced system.
6             Nmodes        - Number of internal modes to retain (ignored if CBMod=False). If Nmodes=0 --> Guyan Reduction.
1             JDampings     - Damping Ratios for each retained mode (% of critical) If Nmodes>0, list Nmodes structural damping ratios for each retained mode (% of critical), or a single damping ratio to be applied to all retained modes. (last entered value will be used for all remaining modes).
0             GuyanDampMod  - Guyan damping {0=none, 1=Rayleigh Damping, 2=user specified 6x6 matrix}

moordyn file:

---------------------- SOLVER OPTIONS ---------------------------------------
0.001         dtM           - time step to use in mooring integration (s)
3000000.0     kbot          - bottom stiffness (Pa/m)
300000.0      cbot          - bottom damping (Pa-s/m)
2.0           dtIC          - time interval for analyzing convergence during IC gen (s)
60.0          TmaxIC        - max time for ic gen (s)
4.0           CdScaleIC     - factor by which to scale drag coefficients during dynamic relaxation (-)
0.01          threshIC      - threshold for IC convergence (-)

elastodyn file:

---------------------- SIMULATION CONTROL --------------------------------------
True          Echo          - Echo input data to "<RootName>.ech" (flag)
3             Method        - Integration method: {1: RK4, 2: AB4, or 3: ABM4} (-)
"DEFAULT"     DT            - Integration time step (s)

[Jason.Jonkman]

Dear @Bart.Klootwijk,

Your solver settings look OK, but dropping the glue code time step (DT) is always useful when checking convergence.

I’m a bit concerned with the high stiffness and low mass of the virtual members, which could result in issues in the eignsolution used by SubDyn in its modal reduction. Have you checked the reasonable of the 6 modes you’ve selected by visualizing them via: Mode shape visualization? (The higher-frequency modes cannot be visualized with this app, even though they are used quasi-statically when SttcSolve = True; but you could see if these modes are causing a problem by setting SttcSolve = False, although this may lead to inaccurate internal member-level loads). Another (likely preferred) option is to replace the virtual members by rigid link elements in SubDyn.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Thank you for your kind help.

I replaced the virtual members by rigid links, but it unfortunately didn’t help. I think the root of the problem is somewhere else. So I went a few steps back to try and find the root of the instability problem.

For the moment I am interested only in the rigid body case ( Nmodes=0 ).
Starting from the certification case #25, I tried to add the SubDyn module to the simulation. I did so by taking the following steps:

In the main Fast file:

• CompSub = 1
• NumCrctn = 1
• DT_UJac = 2.7027
• UJacSclFact = 1.4E+07
• DT = 0.0125

In the SubDyn file:

• FEAMod = 3
• NDiv = 1
• CBMod = True
• Nmodes = 0
• JDampings = 1
• GuyanDampMod = 0
• SttcSolve = True
• GuyanLoadCorrection = True

In the ElastoDyn file:

• PtfmMass = 0
• PtfmRIner = 0
• PtfmPIner = 0
• PtfmYIner = 1.638890E+06

Following your previous advise, I set the platform Y inertia equal to the tower rotational inertia about its centerline, which I calculated to be the value mentioned above. The structural members are defined as in the picture from my previous post, where the red ‘virtual’ members have been defined as rigid links with a mass density of 1 [kg/m]. When I run the model, I run into NaN states within 1 second:

Time: 0 of 1000 seconds.

FAST_Solution:FAST_AdvanceStates:SrvD_UpdateStates:DLL_controller_call:BladedInterface option was
designed for an explicit-loose coupling scheme. Using last calculated values from DLL on all
subsequent calls until time is advanced. Warning will not be displayed again.

FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSolve:SD_CalcOutput:
Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large UR_bar input angles.
The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans()
will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans():

Warning: SkewedWakeCorrection encountered a large value of chi (91.351 deg), so the yaw
correction will be limited. This warning will not be repeated though the condition may persist.
See the AD15 chi output channels, and consider turning off the Pitt/Peters skew model (set
SkewMod=1) if this condition persists.

NaN detected at time 0.729326923076923 in Line 1 in MoorDyn
.
NaN detected at time 0.729326923076923 in Line 2 in MoorDyn
.
NaN detected at time 0.729326923076923 in Line 3 in MoorDyn
.
NaN detected at time 0.72981 in MoorDyn.
NaN detected at time 0.72981 in MoorDyn.

FAST_Solution:FAST_AdvanceStates: NaN state detected.

OpenFAST encountered an error at simulation time 0.725 of 1000 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

I have tried different approaches to resolve the instability and noticed the following behaviour:

• when I set all the RNA and tower DOFs (except the generator) to False, it runs without problems. However, as I am interested in the internal loads in the platform, this is not a desired solution because they are likely inaccurate without turbine/tower flexibility
• when I increase the platform inertia’s in ElastoDyn, the model runs without problems. However, this might lead to unrealistic platform motions as the total inertias are overestimated.

Please, could you share your insights on this matter? I could share the files in case you’d need to review them.

Lastly I was wondering if setting appropriate values for DT_UJac and UJacSclFact is absolutely necessary when Nmodes = 0, because it would save me some precious CPU time.

Your help is much appreciated!
Best,

[Jason.Jonkman]

Dear @Bart.Klootwijk,

To answer your last question, appropriate values of DT_UJac and UJacSclFact are important when SubDyn is enabled, even if the model is rigid.

Regarding your model instability, does your model run fine with all of your settings, except with SttcSolve = False in SubDyn? This would mean that the substructure is modeled fully rigidly, where it could have easily have been modeled solely as the platform in ElastoDyn.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Thank you for the quick answer.

With all of my settings, except with SttcSolve = False, and for this specific case (steady wind of 8m/s, random WN waves of Hs=1.265m), the model seems to work only after dropping the time step to DT = 0.01 seconds (I ran it up to 100 seconds now)

I will have to check though if it is robust enough for the other load cases I am running for my project

Best,

[Jason.Jonkman]

Dear @Bart.Klootwijk,

Does your model run with SttcSolve = True and a smaller DT?

Best regards,

[Bart.Klootwijk]

Hi Jason,

Yes, when I drop DT to 0.00125 seconds, the simulation seems to be running with SttcSolve = True for this case. Is it common that the time step has to be this low in order for subdyn to be stable when modelling floating platforms?

However, when I run a simulation with DLC 6.3 (parked rotor, yaw misalignment of -8 deg, turbulent wind of V_mean = 45 m/s and a severe sea state of Hs = 10.9m, Tp = 14.60, and considering all the aspects that have previously been mentioned on this forum topic), it fails even though DT = 0.00125 and SttcSolve = False, with the following error message:

FAST_Solution:FAST_AdvanceStates:SrvD_UpdateStates:DLL_controller_call:BladedInterface option was
designed for an explicit-loose coupling scheme. Using last calculated values from DLL on all
subsequent calls until time is advanced. Warning will not be displayed again.
Time: 15 of 100 seconds. Estimated final completion at 22:36:54.

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption
violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The
solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will
be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans(): 15.33 s

FAST_Solution:FAST_AdvanceStates:SolveOption2c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_FF
Wind_CalcOutput [position=(-2011.8, -270.77, 295.65) in wind-file coordinates]: FF wind array
boundaries violated. Grid too small in Z direction (Z=295.65 m is above the grid).
InflowWind_CalcOutput:InflowWind_GetSpatialAverage:CalcOutput:IfW_FFWind_CalcOutput
[position=(-2054.4, -277.48, 294.95) in wind-file coordinates]: FF wind array boundaries
violated. Grid too small in Z direction (Z=294.95 m is above the grid).
InflowWind_CalcOutput:InflowWind_GetSpatialAverage:CalcOutput:IfW_FFWind_CalcOutput
[position=(-2011.8, -270.77, 295.65) in wind-file coordinates]: FF wind array boundaries
violated. Grid too small in Z direction (Z=295.65 m is above the grid).

OpenFAST encountered an error at simulation time 15.33 of 100 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

Best,

[Jason.Jonkman]

Dear @Bart.Klootwijk,

The time step requirements of OpenFAST are driven by system natural frequencies, not whether the system is floating or not. Have you assessed the full-system natural frequencies to determine why such a small time step is required? Perhaps eliminating highest-frequency modes could allow you to use a larger time step?

Regarding your OpenFAST error, this seems tied to the very large blade deflections. Are your system displacements/deflections exorbitantly large?

FYI: We are currently working on implementation of a tight coupling algorithm in OpenFAST that should enable the use of much larger time steps and faster execution times. I’ll present the results at the upcoming NAWEA / WindTech 2023 conference.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Thank you, that is understood.

To answer your question about the full-system natural frequencies: I have not done such an analysis. Do I understand correctly that when enabling subdyn, the time step should be:
DT <= 1 / ( 10 * <highest full system natural frequency in Hz )
And I need to do a linearization analysis as explained in this post?

I presume that elimination of modes is synonymous to setting the respecive DOFs to False in ElastoDyn, or am I missing something here?

Regarding the OpenFAST error, the platform and turbine behaviour are shown below. I suspect the large blade deflection is not the cause but rather a consequence of a numerical instability

Best,

[Jason.Jonkman]

Dear @Bart.Klootwijk,

I agree with both of your points. Indeed, the large deflection only occurs right at the end of the simulation, pointing to a numerical instability.

Best regards,

[Bart.Klootwijk]

Dear Jason,

Thank you for confirming. I’ll be interested to see the results of the tight coupling algorithm.

Best,

[Bart.Klootwijk]

Dear Jason,

I previously overlooked the comment in the OC4 DeepCWind definition report about increasing the YoungE by a factor 100 for all members. After changing this in the beam properties, it runs better. Unfortunately I can’t verify the system frequencies because a linearization analysis is outside the scope of my project.

I have two follow-up questions. I was further investigating the platform roll, pitch and yaw inertia values. I modeled each individual member in the subdyn input file, and included the cylinder caps on the main and offset columns as joint additional masses (mass and self-inertias). The mass matrix about the platform c.o.m. from the SD.sum.yaml file is:

Mass:    3.854282E+06 # Total Mass
CM_point: [   7.420378E-09,  -1.259945E-10,  -8.602516E+00] # Center of mass coordinates (Xcm,Ycm,Zcm)
M_G: # 6 x 6 Rigid Body Equivalent Mass Matrix w.r.t. CM (Xcm,Ycm,Zcm).
  - [   3.854282E+06,   0.000000E+00,   0.000000E+00,   0.000000E+00,   0.000000E+00,   0.000000E+00]
  - [   0.000000E+00,   3.854282E+06,   0.000000E+00,   0.000000E+00,   0.000000E+00,   0.000000E+00]
  - [   0.000000E+00,   0.000000E+00,   3.854282E+06,   0.000000E+00,   0.000000E+00,   0.000000E+00]
  - [   0.000000E+00,   0.000000E+00,   0.000000E+00,   1.972568E+09,   1.799269E-02,  -2.449802E+00]
  - [   0.000000E+00,   0.000000E+00,   0.000000E+00,   1.799269E-02,   1.972568E+09,   7.169434E-02]
  - [   0.000000E+00,   0.000000E+00,   0.000000E+00,  -2.449802E+00,   7.169434E-02,   3.071508E+09]

Using a python script, I performed manual calculations to verify the platform mass and inertias, and found nearly identical results as the ones from the summary file above.

In the OC4 reference ElastoDyn file, the following values are reported. And although the mass is similar, the inertia values show a clear difference:
3.85218E+06 PtfmMass
2.56193E+09 PtfmRIner
2.56193E+09 PtfmPIner
4.24265E+09 PtfmYIner

(1) What could be the cause of this difference? In my understanding only the steel mass and inertia of the platform should be modeled.

(2) What are the conventions used in the member force outputs? – and do pCrunch/MLife use the same conventions? – I was under the impression that positive axial forces are tensile and negative axial forces are compressive. But when I look at the output signals for different members, the signs are exactly opposite to what I would expect. For example, the axial force in the cross-braces are negative, and the forces in the columns are positive. Intuitively, the columns should be loaded in compression and the cross braces should be loaded in tension

[Jason.Jonkman]

Dear @Bart.Klootwijk,

Regarding (1), I agree that the platform mass, center of mass, and inertia values in the ElastoDyn file of the OC4-DeepCwind semisubmersible are only for the steel mass and inertia (not including the water ballast. I don’t know enough about your SubDyn model to comment, but it looks like your inertias are about 25% lower than in ElastoDyn and your vertical center of mass is about 0.5% higher.

Regarding (2), see the following documentation regarding how the nodal outputs of SubDyn are calculated: 4.2.5.6. SubDyn Theory — OpenFAST v3.5.0 documentation. pCrunch and MLife do not have a specific sign convention for post-processing loads.

Best regards,