SD: Fix a bug where interface DoF loads are incomplete if the interface joint is part of a rigid assembly

[luwang00]

This PR is ready to be merged.

Feature or improvement description
This PR fixes a bug where the external loads on SubDyn interface degrees of freedom are incomplete if the interface joint is part of a rigid assembly. Previously, only the loads on the interface joint itself are computed. This is incomplete. We instead need to include the external loads on all nodes belonging to the same rigid assembly due to DoF reduction.

Related issue, if one exists
Addresses both Issue #854 and Issue #1081 (verified by @RBergua below). Both issues can now be closed. The corresponding warning message in SubDyn is also deleted.

Additional information
This appears to be a very old bug present since rigid links were first added to SubDyn. We can consider backporting to v4.x.

Impacted areas of the software
SubDyn

Test results, if applicable
No change to existing test results.

[andrew-platt]

Backport to 4.2

Edit: backporting this is not as trivial as initially thought. We will leave this in 5.0

[RBergua]

I performed an easy test to check if the behavior is the expected one. Similar to #1081, I wanted to model a rigid platform in SubDyn simply as a rigid link with a lumped mass and inertia. It is known, that this test in the past resulted in issues.

In this case, I took the model from r-test (https://github.com/OpenFAST/r-test/tree/main/glue-codes/openfast/5MW_OC4Semi_WSt_WavesWN). I simplified the system by disabling InflowWind and AeroDyn (i.e., no aero), disabling ServoDyn (i.e., no controller), and defined still water conditions in SeaState. I also defined all initial conditions as 0 in ElastoDyn and setup the YawDOF as False.

The original model from r-test has the platform defined in ElastoDyn. I defined an equivalent system in SubDyn by defining two joints and the corresponding mass and inertia. Basically:

---- STRUCTURE JOINTS: joints connect structure members (~Hydrodyn Input File) --------
             2   NJoints     - Number of joints (-)
JointID          JointXss               JointYss               JointZss     JointType JointDirX  JointDirY JointDirZ JointStiff    ![Coordinates of Member joints in SS-Coordinate System][JointType={1:cantilever, 2:universal joint, 3:revolute joint, 4:spherical joint}]
  (-)               (m)                    (m)                    (m)         (-)        (-)        (-)       (-)     (Nm/rad) 
   1              0.00000                0.00000                0.00000        1         0.0        0.0       0.0       0.0    
   2              0.00000                0.00000               -8.65880        1         0.0        0.0       0.0       0.0    

----------------------- RIGID LINK PROPERTIES -----------------------------------------
             1   NRigidPropSets - Number of rigid link properties
PropSetID   MatDens   
  (-)       (kg/m)
   1           0    # Massless rigid link

------------------------ JOINT ADDITIONAL CONCENTRATED MASSES--------------------------
             1   NCmass      - Number of joints with concentrated masses; Global Coordinate System
CMJointID       JMass            JMXX             JMYY             JMZZ          JMXY        JMXZ         JMYZ        MCGX      MCGY        MCGZ
  (-)            (kg)          (kg*m^2)         (kg*m^2)         (kg*m^2)      (kg*m^2)    (kg*m^2)     (kg*m^2)       (m)      (m)          (m)
   2           3852180        2.56193E9         2.56193E9         4.24265E9       0            0           0            0        0            0

When using OpenFAST dev-tc without the fix (https://github.com/OpenFAST/openfast/tree/dev-tc), I can see that the behavior of the SubDyn approach is wrong:

When using OpenFAST dev-tc with the fix proposed here, the behavior is the proper one:

For reference, the output using ElastoDyn or SubDyn is not exactly the same. But the bug not accounting for the proper buoyancy or mass when a rigid link was connected to the interface joint in SubDyn has been fixed.

Next, I will test the issue #854 and will check if this fix addresses that issue as well.

[RBergua]

After compiling the SubDyn driver and running the standalone version, I can confirm that the issue #854 has been fixed as well. Yay!

For reference, the model included 2 rigid links and one beam connected to the interface joint. See below for reference:

The original issue was described as "rigid links connected to the interface and cable elements". However, the real problem were the rigid links connected to the interface joint.

The results are:

As can be observed, SubDyn with the fix returns the expected forces: IntfZss around 2.23e7 N.

[andrew-platt]

Backport to 4.1.2