OpenFAST
Bug report - SubDyn bug when modeling rigid platforms
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 behaves as expected.
Screenshots, if applicable
OpenFAST Version
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.)
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.
OK, thanks for clarifying. I expect @ebranlard can comment on what he expects to be the cause of the issue.