A two floating bodies problem

[juleshd]

Hi everyone,

I am working on the simulation of a boat attached to a buoy, moored to the seabed, in various sea states, and I am struggling a bit. I am a newbie in the use of OpenFast so a few help would be really appreciated.
I started with the 5MW_OC4 semi-sub FWT example and i have been able to run an analysis of this model in a periodic seastate to compute the tensions in the anchors and in the fairleads of the moorings. Next step would be to add another floating body, attached to the semi-sub platform with a line, and to compute the same tensions at the extremity of it. I really don't know if this is in the scope of OpenFast and I would be glad to have an external point of view about the feasibility of such a simulation case.

Thank you in advance and have a great day,

Jules

[jjonkman]

Dear @juleshd,

I presume you are modeling the boat structure in ElastoDyn, the waves and hydrodynamic loads on the boat in SeaState/HydroDyn, and the moorings in MoorDyn; is that correct?

To model the buoy (the second body), I would expect that you could model that in MoorDyn directly, given that MoorDyn can already model 6-DOF buoys (called "bodies" in MoorDyn). This approach will allow the buoy to interact with the boat only through the underlying dynamics of the line connecting the buoy to the boat.

If you are seeking hydrodynamic coupling (interaction of radiation and diffraction effects) between the boat and buoy, this is possible if the both the buoy and boat are represented in HydroDyn using the potential-flow solution with more than one body. However, MoorDyn is not currently coupled to HydroDyn. Rather, the structural coupling between these bodies would have to take place through the SubDyn module, which is limited to small linear elasticity.

Best regards,

[juleshd]

Dear @jjonkman,

You are right about the way I am configuring OpenFast for my problem. I took as a base the example of the 5MW_OC4Semi_MD_Linear use case and I removed the tower and the turbine in order to have a simple floater moored to the seabed.

Like you suggested, I tried to model the buoy via MoorDyn directly but I don't think that I managed to write a correct .dat file. The geometry I visualize on Paraview seems kind of strange to me. Tell me if I am wrong but I think that this would be simplier to model the buoy in HydroDyn and then the boat in MoorDyn through the "BODIES" section ? So the buoy and the body representing the boat would be attached to each other with a rod defined in the "RODS" section.

I am not sure to fully understand your last paragraph but wouldn't it be possible to run this case as a two bodies problem like you said, and configuring through MoorDyn anchor lines and another line from the buoy to the boat that would represent the hawser. Then, by running MoorDyn, it would compute the loads in the hawser just like it does for the mooring lines. Maybe I am missing something in the workflow that would make it unfeasible.

Thank you in advance, best regards,

Jules

[jjonkman]

Dear @juleshd,

Thanks for clarifying.

Regarding your second paragraph, I would presume you'd connect your buoy body in MoorDyn to the boat in ElastoDyn through a line (rather than a rod) in MoorDyn to represent the hawser. I agree with how you describe this coupling in your third paragraph.

My last paragraph was noting that representing the hydrodynamics of the boat in HydroDyn with the hydrodynamics of the buoy in MoorDyn will not result in any hydrodynamic coupling between these bodies (though there will be structural coupling via the line in MoorDyn connecting the boat and buoy). So, if you wanted this hydrodynamic coupling, it would be better to represent the hydrodynamics of the buoy in HydroDyn, but then there is limitations in how the hawser can be modeled via SubDyn, which may not be desired.

Best regards,

[juleshd]

Dear @jjonkman,

Thanks for your detailled answer ! Indeed the idea would be to compute the loads in the hawser by representing it in MoorDyn. For now, I am still struggling to add a boat in the whole case. To simplify it, I am considering a rectangular-member from which I computed the WAMIT outputs files, that I specified in the HydroDyn .dat file. I don't know why but I keep having an error that says : "MPropSetID1 in the Members table does not appear in the Member cross-section properties table.", and yet, MPropSetID1 is well defined (see the document attached). I can't figure out where the problem is so if you have any idea, it would help me a lot.

Thank you in advance and have a great day,

Jules

NRELOffshrBsline5MW_OC4DeepCwindSemi_HydroDyn.txt

[jjonkman]

Dear @juleshd,

When I open the file you shared, it is actually an OpenFAST primary (.fst) input file, not a HydroDyn file, so, I can't review that.

Perhaps enabling the Echo option will help you debug issues with the HydroDyn input file processing?

Best regards,

[juleshd]

Dear @jjonkman,

Oups indeed I didn't paste the right file sorry. Here is the right HydroDyn file attached to this message. As you suggested, I tried to enable the Echo file (the Echo file is attached to this message too) but it does not to seem to encounter an error while parsing the HydroDyn input file...

Best regards,

NRELOffshrBsline5MW_OC4DeepCwindSemi_HydroDyn.txt

5MW_OC4Semi_MD_Linear.HD_echofile.txt

[jjonkman]

Dear @juleshd,

Now I see the issue. It looks like you've specified member-level properties for a rectangular cross-section but you have defined your member as having a cylindrical cross section; you should change MSecGeom for your member from 1 (cylindrical) to 2 (rectangular).

Best regards,

[juleshd]

Dear @jjonkman,

Haaa indeed thanks for your answer you are really helping me a lot here ! So for now, I have been able to set a rectangular floater, for which I specified its WAMIT files on HydroDyn. I have configured 4 mooring lines attached from the floater to the seabed in the MoorDyn file. And from this step I face some issues. Indeed, if I set WrVTK variable to 0 in the .fst file, the computation goes through and OpenFast outputs the tension in the moorings. But if I set this same variable to 2 in order to visualize the simulation, an error shows saying "forrtl: severe (157): Program Exception - access violation". For now I still can't figure this out, and your advice would be helpful.

Best regards,

Jules

[andrew-platt]

I suspect the issue with visualization in your case is from the specifics of your configuration. A segmentation fault like this is typically due to a variable being accessed when it wasn't allocated properly. I have my suspicions of what module is triggering it.

[juleshd]

Dear @andrew-platt,

I have tried to look for this variable that isn't allocated properly like you suggested but I can't figure this out... Do you have any additional hint that would lead me to the right corrections ?

Thank you in advance,

Jules

[RBergua]

I understand that the issue is the rectangular element used for your floater. From the new OpenFAST v5.0.0 release (in the known issues section):
No visualization of rectangular members from HydroDyn or SubDyn through the VTK output options.

[juleshd]

Ohhh right I see, indeed I didn't check the known issues section, thanks for your answer @RBergua

[andrew-platt]

The rectangular member shouldn't be causing a segmentation fault with WrVTK. It should throw an error or warning in this case, so there is bug somewhere in addition to the limitation in visualizing.

[juleshd]

Dear all,

I am still working on my two floating bodies problem and I am facing an error I can't resolve on my own... For now, I have been able to compute the hydrodynamic coefficients of the two bodies jointly and I tried running the simulation on OpenFast but I keep having the "Nan state dected at time..." error. If I check my results, I can clearly see that my whole problem is diverging from a certain time. I am not sure about the way I am configuring my 2 bodies problem in the ElastoDyn.dat file, especially for the mass and inertia parameters.

The final idea is the set up of a hawser from my first body to my second, and to compute its tension, hence the fifth line configured in the MoorDyn.dat file.

Here are my set up files :
2Bodies.fst.txt
2Bodies_ElastoDyn.txt
2Bodies_Hydrodyn.txt
2Bodies_MoorDyn.txt

If you have any idea about the source of the problem or suggestions about how to set up a multiple bodies problem like mine, I would be really thankful !

Thank you in advance and have a nice day !

Jules

[juleshd]

Dear @jjonkman,

The final part for the design of my study loop is to implement the interaction between the buoy and the boat. By "interaction", I am here thinking about the movements of the buoy due to the displacements of the boat, and vice versa. Does setting the attachement of the boat at "Free" in MoorDyn is sufficient or is there a way to do it more precisely ? You rapidly mentionned it earlier in the discussion but I am not sure to fully understand what you were explaining sorry.
I was thinking that I could compute the mouvements of the fairlead of the boat, considered free in the water, and set these displacements as a mouvement constraint for the extremity of the hawser linked to the buoy. But I am not sure about the feasibility and realism of such a method.

Thank you in advance,

Jules

[jjonkman]

Dear @juleshd,

I agree that the hydrodynamics of MoorDyn are simplistic compared to HydroDyn, e.g., HydoDyn can consider radiation/diffraction coupling between multiple potential-flow bodies that is not possible to capture in MoorDyn. The problem though, is that while HydroDyn supports multiple bodies, OpenFAST requires that the structural connection between these bodies be considered through SubDyn, which cannot model a hawser. To take advantage of the advanced hydrodynamic capabilities of the multi-body solution of HydroDyn while connecting these bodies with a hawser would require a source code change to OpenFAST.

This is why I suggested the simple plan to model the boat in ElastoDyn/HydroDyn and the buoy in MoorDyn. From my brief review of your 2Bodies_MoorDyn.txt file file, it looks like you are now representing the buoy and hawser properly in MoorDyn. Within OpenFAST, the boat (in ElastoDyn) can move and tug on the buoy through the hawser modeled in MoorDyn. With this implementation, the coupling will be through the hawser line in MoorDyn, but without direct hydrodynamic coupling.

Best regards,

[juleshd]

Dear @jjonkman,

Thank you very much for your detailled answer, it helped me comprehend the whole structure between the different modules. I understood why it wasn't possible for my use case to enjoy the hydrodynamic coupling by HydroDyn. In my 2Bodies_MoorDyn.txt file, the body defined models the boat itself. My study focuses on the buoy so I thought that using HydroDyn to model it would let me take advantage of its advanced hydrodynamic capabilities. But maybe the problem isn't symmetric and I can't catch the interaction between the buoy and the boat through the hawser that way ?

Moreover, I think that the mecanical interaction between the two bodies through the hawser would be sufficient in the first place as long as the dimensions of the boat are significantly bigger than the buoy ones. The hydrodynamic coupling could be added later by considering additionnal damping/stiffness matrixes maybe ?

Thank you in advance et have a great day,

Jules

[jjonkman]

Dear @juleshd,

Whether or not the hydrodynamic interaction between the boat and the buoy is important probably depends on the spacing between them and the length of the hawser. You could try to approximate the hawser as a flexible beam in SubDyn with the boat and buoy modeled as two potential-flow bodies in HydroDyn to study the hydrodynamic interaction and compare that to the solution where the hawser and buoy are modeled in MoorDyn. Depending on the difference between those two solutions could perhaps tell you if an OpenFAST source code change is warranted for your application.

Best regards,

[juleshd]

Dear @jjonkman,

Thanks for your detailled answer. Indeed, this seems to be a great idea in order to evaluate the contribution of the hydrodynamic coupling in the final results. I will try to do so and come back to you after.

Have a great day,

Jules

[juleshd]

Dear @jjonkman,

Like you suggested, I tried to set up a two bodies problem with Hydrodyn and configure a circular beam between the two free floating bodies in order to compute the hydrodynamic coupling between the two bodies. I wrote the SubDyn.dat file based on my understanding of the User manual for the SubDyn module but I think I am missing something. Indeed, the results are always diverging and I can't find a way to fix this. The error I got is :

forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
openfast_x64.exe   00007FF7CCE3E124  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CD2A9E9F  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CD012CE2  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC874356  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC9C7789  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC9E7E7C  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC9E6450  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC578722  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC57784D  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CC5774C8  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CE3CF391  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CE3CE8DB  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7CE4DFA38  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFBB116E8D7  Unknown               Unknown  Unknown
ntdll.dll          00007FFBB14AC40C  Unknown               Unknown  Unknown

I attached my simulation files if you have some spare time to look for the probable mistake I made in it. Thank you very much in advance and have a great day !

Jules Houot

2Bodies_Hydrodyn.txt
2Bodies_SubDyn.txt
2Bodies.txt

[jjonkman]

Dear @juleshd,

Can you share the full set of messages you receive when you execute OpenFAST? I'm trying to understand when this program exception is triggered.

From my quick look at your input files, I see your SubDyn model has one member connecting two spherical joints without stiffness. This would not be allowed because the elastic SubDyn model cannot support rigid-body modes. What does OpenFAST do if you change the JointType of both joints from 4 to 1 (cantilevered)?

Best regards,

[juleshd]

Dear @jjonkman,

Thank you for your answer. The full message I received is this one :

**************************************************************************************************
OpenFAST

Copyright (C) 2026 National Renewable Energy Laboratory
Copyright (C) 2026 Envision Energy USA LTD

This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.
**************************************************************************************************

OpenFAST-v4.2.1
Compile Info:
 - Compiler: Intel(R) Fortran Compiler 20250300
 - Architecture: 64 bit
 - Precision: single
 - OpenMP: No
 - Date: Mar 10 2026
 - Time: 20:35:11
Execution Info:
 - Date: 04/02/2026
 - Time: 16:04:53+0200

OpenFAST input file heading:
    FAST Certification Test #25: 2Bodies, for use in offshore analysis

 Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
 Running InflowWind.
 Running SeaState.
  Setting WaveTMax to TMax since WaveMod = 0
 Running HydroDyn.
 Reading in WAMIT output with root name ".\HydroData/2Bodies".
 Computing radiation impulse response functions and wave diffraction forces.
 Running SubDyn.
   Floating case detected, Guyan modes will be rigid body modes
    Node    1 is a ball joint, number of members involved:     1
    Node    2 is a ball joint, number of members involved:     1
   Guyan extra moment and rotated CB-frame will be used (floating case detected)
   Performing Craig-Bampton reduction 18 DOFs -> 0 modes + 6 DOFs
   Using static improvement method for gravity and ext. loads
   Calculating Full System Modes for output files
   Exporting Summary file

FAST_InitializeAll:ED_Init:ED_ReadInput:ReadBladeInputs:ReadBladeFile:The ElastoDyn Blade file,
.\2Bodies_Blade.dat, DISTRIBUTED BLADE PROPERTIES table contains the PitchAxis column.  This
column is unused and will be removed in future releases
FAST_InitializeAll:InflowWind_Init:InflowWind_ValidateInput: Requested wind velocity at point (
0, 0, 0) is below ground (wind turbine) or below seabed (MHK turbine). Ignoring this point.
FAST_InitializeAll:SeaSt_Init:SeaStateInput_ProcessInitData:WvHiCOff adjusted to 5.23599E-02
rad/s, based on WaveDT.
SeaSt_Init:SeaSt_Init:Setting wavefield visualization grid to 9 x 9points
SeaSt_Init:WaveField_GetNodeTotalWaveElev:WaveField_GetNodeWaveElev1:WaveField_Interp_Setup3D:Grid
InterpSetup3D:SetIndex:Position has been clamped to the grid boundary. Warning will not be
repeated though condition may persist.

Using generic blade surfaces for ElastoDyn (rectangular airfoil, constant chord).
 Time: 0 of 60 seconds.

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


FAST_Solution:FAST_UpdateStates:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSo
lve:HydroDyn_CalcOutput:WAMIT_Init:Pitch angle of a potential-flow body violated the small angle
assumption. The solution might be inaccurate. Simulation continuing, but future warnings will be
suppressed.


FAST_Solution:FAST_UpdateStates:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSo
lve:HydroDyn_CalcOutput:Yaw angle at PRP relative to the reference yaw position (PtfmRefY)
violated the small angle assumption. The solution might be inaccurate. Consider using PtfmYMod=1
and adjust PtfmYCutoff. Simulation continuing, but future warnings will be suppressed.
HydroDyn_CalcOutput:WAMIT_Init:Roll angle of a potential-flow body violated the small angle
assumption. The solution might be inaccurate. Simulation continuing, but future warnings will be
suppressed.
WAMIT_Init:Yaw angle of a potential-flow body relative to the reference yaw position (PtfmRefY)
violated the small angle assumption. The solution might be inaccurate. Consider using PtfmYMod=1
and adjust PtfmYCutoff. Simulation continuing, but future warnings will be suppressed.
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
openfast_x64.exe   00007FF7F285E124  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F2CC9E9F  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F2A32CE2  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F2294356  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F23E7789  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F2407E7C  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F2406450  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F1F98722  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F1F9784D  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F1F974C8  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F3DEF391  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F3DEE8DB  Unknown               Unknown  Unknown
openfast_x64.exe   00007FF7F3EFFA38  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFBB116E8D7  Unknown               Unknown  Unknown
ntdll.dll                  00007FFBB14AC40C  Unknown               Unknown  Unknown

I tried to set up the JointType to 1 but the same message error appears.

Best regards,

Jules

[jjonkman]

Dear @juleshd,

I see many warnings before the program exception error, which seem to be triggered by the spherical joints. You mention receiving the same error for the cantilevered joints, but what are the messages before that?

Best regards,

[juleshd]

Dear @jjonkman,

For the cantilevered joints, I have the exact same message, except that these two lines :

    Node    1 is a ball joint, number of members involved:     1
    Node    2 is a ball joint, number of members involved:     1

are removed.

Best regards,

Jules

[jjonkman]

Dear @juleshd,

In that case I expect your model is numerical unstable even with cantilevered joints. I would first play around with solver settings, such as adding a correction step (NumCrctn > 0) and reducing the time step (DT) to see if you can get the simulation to at least start properly.

Best regards,

[juleshd]

Dear @jjonkman,

In the continuity of my case study, I tried to simplify the whole problem through a first approach in which I evaluate the dynamic of my boat by mooring it at the seawater level with MoorDyn (the boat is modeled with ElastoDyn/HydroDyn). This way, I approximate the buoy as a fix point and I can study various mooring configurations. By doing so, I am regularly facing two main errors:

I have red the "Troubleshooting" section in the Moordyn doc, dealing with these two errors but I can't figure out the way to fix it. Here is my MoorDyn file : Aerostat_MoorDyn2.txt

Thank you in advance,

Jules

[jjonkman]

Dear @juleshd,

I would first try reducing the number of mooring line segments in MoorDyn (e.g., NumSegs = 20). I would also try fixing the platform DOFs in ElastoDyn. Do you then get the MoorDyn response you expect?

Best regards,

[juleshd]

Dear @jjonkman,

Thanks for your help, indeed, by reducing the number of segments, the computation terminates normally. For my case, I set NumSegs at 6 and OpenFast did great. I was wondering if reducing that much the number of segments did not have a negative impact on the precision of the results ?

From my understanding of the set up of the MoorDyn.dat file, it seems that I need the UnstrLen value for each line as close as possible to the distance between the two extemities of the line, in order to limitate the catenary shape that leads to slack effect in the line, causing the abort of OpenFast. Once this is done, I have to set the NumSegs at a value that makes OpenFast complete the computations. Am I mistaken on something ?

Thank you in advance and have a great day,

Jules

[jjonkman]

Dear @juleshd,

MoorDyn should be able to handle the catenary shape of mooring lines, but the slack to taut transition (if happening) may be difficult to solve numerically and may require adaption of the solver settings. My guess is as you increase the number of line segments (NumSegs), you would need to change solver settings such as reducing the mooring time step (dtM).

Best regards,

[juleshd]

Dear @jjonkman,

Ok right I see, I will keep looking into the adaptation of the solver settings for my use case.

Thank you for your help and have a great week-end,

Jules