MoorDyn - SeaState runtime improvements

[RyanDavies19]

Feature or improvement description
This has a couple of small improvements to working with the MoorDyn-SeaState coupling. It adds a linear ramp time that is specific to MoorDyn for external water kinematics, which is helpful for starting up simulations with VIV where "instant on" kinematics after initialization can cause numerical instabilities. It defaults to disabled. It is enabled by adding the following to the MoorDyn options section:

-------- OPTIONS --------
100              waveKin_rampT

This PR also changes how often the SeaState pointer is called by rod and line objects. Previously, it was called once per internal MoorDyn timestep, resulting in extremely slow runtimes when dt_moordyn << dt_coupling. The update now only updates the water kinematics once per coupling timestep if MoorDyn is not initializing. The below screenshot is a runtime comparison for some work I am doing right now. It compares running v4.2.0, v5 (v5 run 1 and run 3), both versions without MoorDyn using SeaState (v4.2.0 no SS, v5 no SS), and v5 with SeaState called by MoorDyn at the coupling level (v5 SS at dtC). In my case this change led to a 24x speed increase.

This PR also enables the output of the line node accelerations, which has been possible since VIV was added. That PR created a rdd_old array to store the line accelerations at the module level. Node accelerations are called with an a in the line outputs:

--- LINES ---
... LineOutputs
... (-)
... a   

Lastly I cleaned up some warnings that were over specific with their suggestions.

Related issue, if one exists
n/a

Impacted areas of the software
MoorDyn

Additional supporting information

Generative AI usage
Assisted by: GitHub Copilot support@github.com

Test results, if applicable
MHK_RM1_Floating_Tank-scaled is currently failing on the AnchTen1 channel:

I suspect that the baseline may not be correct. My understanding of this test is it is an MHK w/ 4 mooring lines, two in the -X direction and two in the +X direction. The incoming flow is along the x axis. In that case, AnchTen1 and AnchTen2 should be very similar because they are symmetric and equally loaded. At t=0.3 the AnchTen1 baseline shows an almost slack load where AnchTen2 does not. The local results for AnchTen1 seem to show better matching of the AnchTen2 loads. Curious if others have more insight into this test, and if my read of things is correct.

[andrew-platt]

This case is a 1/49 scaled down version of the MHK_RM1_Floating. There may be some values incorrectly scaled, so I am not surprised if it is a bit overly sensitive to some environmental changes.

In the baseline, the FairTen1 and FairTen2 loads are a little different. The platform has some motion (including yaw) due to no initial displacement, so that may be why the loads are slightly different.

The new results look good though, so I'm not particularly worried about a change here given how this case was developed.

[andrew-platt]

@RyanDavies19, since the input file change is an optional one, how do you feel about adding this into the 5.0.1 release instead of the 5.1.0 release? The speedup in performance is rather significant and would be beneficial to get out sooner rather than waiting for 5.1.0.

[andrew-platt]

Great work!

Only the print statements need changing.

[andrew-platt]

• update r-test
• consider putting into 5.0.1 instead?

[RyanDavies19]

Hi @andrew-platt,

5.0.1 sounds good to me, I am not in the loop on dev timelines so happy with whatever seems best on your end. I will remove those print statements, they were left over from debugging. Thanks for the catch!

Remind me the process for updating the r-test again? Do I regenerate the test results for MHK_RM1_Floating_Tank-scaled on my r-test fork using this version and then open a PR to OpenFAST/r-test?

[andrew-platt]

Thanks @RyanDavies19!

I can update the regression tests.