Bug report: MoorDyn Driver with time-series inputs

[arodriguezluis]

Bug description

While running MoorDyn Driver with time-series inputs for a simple case, the node with prescribed motion does not follow the prescribed motion. Also, the initial condition is not properly obtained, and a straight line between anchor and fairlead is generated instead of a catenary curve.

To Reproduce

Steps to reproduce the behavior:

1. Compiled with Centos Linux 7, using EasyBuild foss/2020b and CMake/3.18.4-GCCcore-10.2.0. Followed documentation tutorial.

mkdir install
mkdir build
cd build
cmake .. -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_INSTALL_PREFIX="/my_path/install/"
make openfast
make install

3. Run moordyn_driver case with attached inputs. test_case.zip

moordyn_driver ./md_driver.inp

4. See the error while comparing node 10 motion in 'driver.MD.out' with prescribed motion in 'ptfm_motion.dat'. Attached python script to plot comparison. Also, in output file, it is seen how all outputs L1N#PZ are of order 1e-8 at t=0.

Expected behavior

It was expected to observe the same time series for 'ptfm_motion.dat' and node 10 output. This is not convenient for validation with other models or experimental data. Also, it was expected to obtain a stable initial condition.

OpenFAST Version

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

 Copyright (C) 2025 National Renewable Energy Laboratory
 Copyright (C) 2025 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.0.1
 Compile Info:
  - Compiler: GCC version 10.2.0
  - Architecture: 64 bit
  - Precision: double
  - OpenMP: No
  - Date: Jan 31 2025
  - Time: 08:42:47
 Execution Info:
  - Date: 01/31/2025
  - Time: 14:01:18+0100

[RyanDavies19]

Hi @arodriguezluis,

Thank you for the detailed information and example case, it's super helpful for figuring these things out. I noted a couple things that could be causing issues for you.

With regards to the initial condition failing to be obtained: This is likely because of your dynamic relaxation settings you are using. When MoorDyn’s static catenary solver fails, it defaults to a linear line. After this, the dynamic relaxation process occurs. With dtIC set to 0.001, MoorDyn determines convergence if the fairlead tensions are constant over that interval. Using a larger value, like dtIC = 1, will make the initial condition solver more sensitive to a true steady state. Additionally, using drag scaling of 10 will make the line “fall” into place slowly. In your case, this combination tricked MoorDyn into thinking steady state had been reached. This is also why all the L1N#PZ values are zero at the start of the simulation, the line was horizontal at the surface. I changed dtIC to 1 and CdScaleIC to 3 on your input file and saw the initial state of a hanging line was reached.

As for the discrepancy between Node10 and the input data file: This is likely due to the interpolation routines used by the MoorDyn driver and not MoorDyn itself. I double checked with your files and the Point2 positions match Line1N10 positions exactly. The driver will interpolate and filter the input data to generate the time series for driving MoorDyn. If you change your dtC value in your driver input file to 0.001 you should see much nicer matching. Further decreasing that time step (dtC) to the moordyn internal time step you are using (dtM = 0.0001), shows exact matching in the quick comparisons I looked at.

P.S. If you add the flag p to the Outputs column in the line list, MoorDyn with generate a time series file of all the node positions. The docs has a list of all the flags you can put here: https://moordyn.readthedocs.io/en/latest/inputs.html#id3

[arodriguezluis]

Hi @RyanDavies19 ,

Thank you for your answer and suggestions, it is a pleasure to raise questions like this when you get excelent feedback.

As you said, setting dtIC=1 and CdScaleIC=3 fixed the issue with the initial position and lowering dtC to the dtM value fixed the issue of the discrepancy at node 10.

However, now I get some asterisk strings '***************' in de driver.MD.out file that I need to replace with zeroes in the scripts that I use for plotting. Maybe it is a problem of my system and the machine precision, because I also see some O(e-19) in the output file.

Finally, I noticed that decreasing dtC increased the oscillations in the tension signal, as if it had an effect on reducing the internal damping, and I am not sure if that was expected.

Anyway, my initial issue is fixed, so thank you again for your answer.

[RyanDavies19]

@arodriguezluis I'm glad you got things working. The **** characters have been on the radar for a bit to fix, but you are correct in replacing them with 0's.

I don't have an immediate answer for you with the dtC but if you really wanted to remove the vibrations I would play around with the three time steps you have (dtC, dtM, and the time step in the platform motions file) to see if some combo there reduced them without loosing accuracy. I suspect they have something to do with that combo.

[RyanDavies19]

@arodriguezluis, just a note the *** bug has been fixed with #2658