Bug report - SubDyn bug when modeling rigid platforms

[RBergua]

Bug description
When modeling a rigid platform in SubDyn (e.g., using rigid links and lumped masses), the buoyancy is not applied over the system and the structure sinks.
First, it's important to note that SubDyn somehow requests NPropSets > 0. So, at least one dummy section that is not going to be used must be defined.

To Reproduce
Any SubDyn model with only rigid links and lumped masses on it. For example, one SubDyn model with 5 joints conncted with rigid links between them: 1 joint for the interface, 1 joint for the lumped mass and 3 equally-spaced joints at the tip of three arms that would connect with the mooring lines. CBMod can be defined as False or True with Nmodes = 0. The system doesn't have internal DOFs, only the 6 DOFs corresponding to the rigid body motion.

Steps to reproduce the behavior:
Run one model with the above characteristics in OpenFAST v3.1.0 (compile already available from GitHub OpenFAST repo).

Expected behavior
The system to float.
Workaround: Introduce at least one beam in the model. Then the system will behave as expected.

Screenshots, if applicable

OpenFAST Version

[jjonkman]

Presumably this issue is related to issue #854, whereby the "loads and displacements are wrong when rigid links are connected [to] the interface [joint]". Until this issue is fixed, the workaround is to ensure that a beam element is connected to the interface joint. (You can still set Nmodes = 0 if you want to model a rigid substructure in SubDyn.)

[RBergua]

The issue #854 appears sometimes when there is a rigid link connected to the interface joint AND there are cables involved. The model that I'm working with doesn't have any cable. It only has rigid links and lumped masses.

Moreover, I have been using several models with rigid links at the interface joint and I have not encountered any problems. The issue here is that you must have, at least, one beam somewhere in your model. And this beam can be anywhere, it is not necessary to be connected to the interface joint.

[jjonkman]

OK, thanks for clarifying. I expect @ebranlard can comment on what he expects to be the cause of the issue.

[andrew-platt]

@luwang00 and @RBergua, is this fixed in 4.0.0?

[luwang00]

Hi @andrew-platt, I haven't worked on this problem, so I don't think it is fixed. Not sure if @RBergua has any update. Maybe we can address this in 4.0.1?

[andrew-platt]

I put it on a 4.0.1 milestone, but we may push this to 5.0

[luwang00]

Sounds good! There's also Issue #854 above. We probably need some time to better understand the problem.

[RBergua]

Hi @andrew-platt and @luwang00. As far as I know, this problem was never addressed. In my opinion, this issue and the #854 are different. This issue is about having to define, at least, one beam in the system to have the buoyancy force properly applied. While issue #854 is about avoiding several elements being connected at the interface joint.

I have these models available internally, so we can try to work on the code and see if the behavior is the expected one.