HydroFzi exceptionally high when SubDyn is ENABLED, while the data in HD.sum remains normal and identical to the data while SubDyn is DISABLED

[yxy636363]

I am currently working on an OpenFAST(v5.0.0) simulation of the OC4 semi-submersible platform with the NREL 5MW wind turbine. My model is based on the r-test reference, but I am rebuilding it to enable SubDyn for flexible substructure analysis, because I need to compute the internal forces and bending moments at various locations within the substructure members (columns, pontoons, braces). I'd greatly appreciate any insights from the community.

When SubDyn is DISABLED (CompSub = 0 in the main .fst file), the model runs smoothly for 60 seconds with reasonable platform motion and visualization output.

However, when SubDyn is ENABLED (CompSub = 1), the simulation fails immediately at the first time step with convergence error NaN (or occasionally error=20+) and the following warning:

Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large Nodal rotation.
Angles in GetSmllRotAngs() are larger than 0.4 radians.
The solver fails to converge within the maximum number of iterations (currently 6), and MoorDyn subsequently reports NaN states.What I Have Already Tried (Based on Forum and Documentation)
Following recommendations from the OpenFAST documentation and NREL forum discussions , I have attempted:

1. Transferred all platform mass from ElastoDyn to SubDyn (set PtfmMass = 0 in ElastoDyn)

2. Added concentrated masses at column ends to simulate cylinder caps (following Roger Bergua's approach)

3. Enabled static improvement method (SttcSolve = True)

4. Reduced time step (DT = 0.01, 0.005, and even 0.001 s)

5. Increased correction iterations (NumCrctn = 3, 5)

6. Relaxed convergence tolerance (ConvTol = 1e-3)

7. Temporarily disabled ServoDyn and AeroDyn to isolate the issue

8. Tested Nmodes = 0 (Guyan reduction, treating platform as rigid) – still diverges

9. Adjusted quasi-rigid beam properties (diameter from 2.5m → 5.0m)

10. Enabled Guyan damping via AddBLin in HydroDyn (1% critical damping for heave DOF, as recommended in the modeling guide )

11. Extreme simplification of the SubDyn model – Following the guidance in the modeling documentation that virtual members should be characterized by "low self-mass and high stiffness" , I simplified the entire platform to a single concentrated mass at its center of gravity, connected by a single quasi-rigid beam to the tower interface node.

My core questions:

Mooring force transfer: How are mooring forces from MoorDyn applied to the platform when fairlead points are NOT explicitly modeled as joints in SubDyn? Does FAST's mesh-mapping utility automatically transfer these forces to the SubDyn structural mesh based on coordinates, or must I define corresponding joints at the fairlead locations? Could missing explicit fairlead joints cause the forces to be applied at incorrect locations or not applied at all?

Mass and force integration: When SubDyn is enabled, where should each component be defined, and how are they integrated?

Platform structural mass: SubDyn (beam density + concentrated masses) - ElastoDyn PtfmMass set to zero - is this correct?

Ballast water: HydroDyn FILLED MEMBERS - is this mass automatically added to the system's total mass matrix, or does SubDyn need to account for it separately? The HydroDyn summary shows negative internal buoyancy, indicating ballast weight is subtracted from buoyancy, but is the inertia also correctly accounted for?

Tower: Should remain in ElastoDyn with DOFs enabled, or move to SubDyn with tower DOFs disabled in ElastoDyn? (My tower is tubular, not lattice - documentation suggests ElastoDyn may be more accurate for tubular towers due to geometric nonlinearities)

Hydrodynamic loads: Transferred via mesh-mapping - confirmed by documentation

Given that even the extreme simplification (single point mass + one quasi-rigid beam) still diverges, this seems to rule out issues with complex mode shapes or member connectivity. Could this indicate a fundamental issue with how loads are integrated across modules when SubDyn is enabled, particularly the transfer of mooring forces or the handling of ballast mass?

I have attached the following files for reference:

Main input file
SubDyn input file and summary file
HydroDyn input file and summary file
ElastoDyn input file and summary file
error output

NREL_OC4_4body_sub_files.zip

Any insights or suggestions would be greatly appreciated. Thank you for your time and expertise.

————————————————————————————————————————————————

Recently, while checking the output files, I noticed a data inconsistency. When SubDyn is disabled, the HydroFzi output matches the net buoyancy calculated from the HydroDyn summary file (approximately 4.59e7 N). However, when SubDyn is enabled, the initial HydroFzi value becomes 1.3456e11 N—nearly 3000 times larger—even though the summary file shows identical values for the displaced volumes of the four WAMIT bodies and the net buoyancy (excluding WAMIT contributions) in both cases. I guess this could be the main cause of my problems, but still wondering how to solve it.

[jjonkman]

Dear @yxy636363,

I haven't reviewed your input files in great detail, but I do see one obvious problem that could explain why your model with SubDyn fails quickly. I see that you've initialized the platform degrees of freedom (DOF) in ElastoDyn to have an initial platform surge of 5 m and an initial platform pitch of 1.9degrees. However, your rigid body in SubDyn is initialized without any displacement. This mismatch would cause extreme deflection of the SubDyn Guyan modes and probable model failure.

Regarding step 10 of steps 1-11 you've tried, this recommendation for AddBLin only applies to fixed-bottom substructures modeled in SubDyn, not floating substructures. Your other steps make sense to me, but I expect the mismatched initial conditions between ElastoDyn and SubDyn are still the cause of the error.

To answer your core questions:

• Mooring force transfer: Indeed, OpenFAST's internal mesh-to-mesh transfer allows the fairleads in MoorDyn to be offset from joints in SubDyn. Essentially, the point-to-point mesh mapping within OpenFAST will use a nearest neighbor mapping, and preserve rigid-body kinematics and kinetics in the process.
• Mass and force integration: I'm not sure what you mean by "each component".
• Platform structural mass: I agree that PtfmMass in ElastoDyn can be zero if the full floating substructure is modeled in SubDyn.
• Ballast water: If the ballast water is considered in HydroDyn, it should not also be considered in the structural modules (ElastoDyn or SubDyn) to avoid double-counting the effect. In HydroDyn, the full mass and inertias of the ballast water are considered.
• Tower: I agree that tubular towers are better considered ElastoDyn than SubDyn, but you could choose to model the full support structure in SubDyn. For the latter, geometric nonlinearities and tower aerodynamic influence and loading are neglected (although we are currently working to address the latter by upgrades to AeroDyn and by enabling a coupling between AeroDyn and SubDyn).
• Hydrodynamic loads: Correct.

Best regards,

[jjonkman]

Dear @yxy636363,

From my quick look at your time series, I do see the heave motions of the various bodies heading off and not returning, which could be indicative of the problem, though I'm not sure. Again, I recommend checking the Craig-Bampton modes you are using for physical correctness.

Regarding the INVALID nodal outputs, you have set NOutCnt at most 2 in the MEMBER OUTPUT LIST, with the 2nd output node corresponding to the 3rd node along the member, so, output node N3 does not exist.

Best regards,

[yxy636363]

Dear @jjonkman,

Thank you for your continued help and detailed explanation.

Regarding the divergence around 24 seconds: Based on my output file when SubDyn was disabled, the motion at 24 seconds still appears normal (it was at a minimum of the heave curve). I have attached that output files for your reference.
NREL_OC4_4body_without_sub.zip
NREL_OC4_4body_with_sub.zip

I am still a beginner in finite element software, so I am not very familiar with Craig-Bampton modes. However, I imported the JSON file into the website you provided, and the mode shapes look reasonable to me—they seem consistent with my modeling in HydroDyn and SubDyn.

Regarding the INVALID nodal outputs: I am still confused. According to the OpenFAST documentation (Section 4.8.3.3.15. Member Output List), it says: "SubDyn can output load and kinematic quantities at up to nine locations for up to nine different members... NOutCnt specifies how many nodes along the member will generate output. NodeCnt specifies those node numbers ... from the start-joint (node 1) to the end-joint (node NDiv + 1) of the member." With NDiv=2, the nodes are 1, 2, 3. So NOutCnt=2 should mean that two nodes will be output (in my case, nodes 1 and 3). Then why does "M2N1FKXe" work but "M2N3FKXe" shows INVALID? For other members (e.g., member 23 and 24), both node 1 and node 3 are INVALID, which is even more puzzling. Could there be another reason for this behavior?

Thank you again for your patience and guidance. I really appreciate it.

[jjonkman]

Dear @yxy636363,

Thanks for clarifying. For the next test, I would try to get your model with SubDyn to match your model without SubDyn closely by making the model rigid in SubDyn, i.e., remove the interface joint with TPID = 0 and set Nmodes = 0; how do the two solutions compare then and does the model with SubDyn get past 24 s?

With NOutCnt = 2 and NodeCnt = 1, 3, output node N1 corresponds to the 1st structural analysis node and output node N2 corresponds to the 3rd structural analysis node, and N3 is invalid. To output N3, you should set NOutCnt = 3 and list 3 nodes in NodeCnt.

Best regards,

[yxy636363]

Dear @jjonkman,

Thank you for your detailed guidance.

I have now conducted the tests you suggested. I found that when I removed the TPID=0 joint and set Nmodes=0, the SubDyn model ran successfully for 60 seconds. Then I restored the TPID=0 joint and gradually increased Nmodes. With Nmodes=0 or 1, the model still runs for 60 seconds. However, when Nmodes >= 2, the simulation consistently returns NaN results around the peaks of the heave motion. For reference, I have attached the .out files for Nmodes=0 through 4 below.

outputs.zip

Regarding the INVALID outputs, thank you very much for the clarification. I verified that the issue was exactly as you described. I would strongly suggest highlighting this point more explicitly in the SDOutList section of the SubDyn manual, as it would help other OpenFAST users avoid similar confusion.

On a related note, members M1 ~ M6 can output data correctly for their nodes, but M23 and M24 show INVALID for all nodes. According to the manual, SubDyn supports up to 9 members and 9 nodes per member, totaling 81 output channels. My settings should not exceed that limit. My current guess (though I have not verified it) is that only members 1 ~ 9 are supported for output—i.e., the output capability is limited to the first 9 members, rather than any 9 members. If this is correct, I may need to renumber my members, though that would not fundamentally change the modeling approach.

Thank you again for your patience and insights.

Best regards

[jjonkman]

Dear @yxy636363,

I'm not sure why your solution is diverging when adding TPID = 0 or increasing Nmodes, but I would guess it is tied to how your SubDyn model is set up.

I'm not sure there is much benefit specifying an interface joint in SubDyn with TPID = 0 for an OpenFAST model with a single instance of ElastoDyn where the tower is modeled in ElastoDyn. Do you get more success increasing Nmodes if you don't add the TIPID = 0 joint?

Regarding the nodal outputs, while there is limit to 9 nodes of 9 members, but the specific nodes and members that can be output are specified directly in the MEMBER OUTPUT LIST table, so, there is never a need to renumber the members. Output member Mα corresponds to row α in the MEMBER OUTPUT LIST table and output node Nβ corresponds to node β in the NodeCnt list of that table. This is well documented here: https://openfast.readthedocs.io/en/main/source/user/subdyn/appendixD.html.

Best regards,