Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug report: MoorDyn Driver with time-series inputs #2623

Open
arodriguezluis opened this issue Jan 31, 2025 · 1 comment
Open

Bug report: MoorDyn Driver with time-series inputs #2623

arodriguezluis opened this issue Jan 31, 2025 · 1 comment

Comments

@arodriguezluis
Copy link

arodriguezluis commented Jan 31, 2025

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
  1. Run moordyn_driver case with attached inputs. test_case.zip
moordyn_driver ./md_driver.inp
  1. 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.

Image

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants