libdiscon.dylib for the IEA15MW UMaine Semi-Sub Model

[QusayHawari]

Hi,

I am working on MACOS, and wanted to ask if there's a libdiscon.dylib 64-bit for the semi-sub model available, or do I have to generate it myself via cmake?

Thanks in Advance,
Qusay

[gbarter]

Hello Qusay,

There is a mac-compiled version of ROSCO associated with our pending updates in the development branch:
https://github.com/IEAWindTask37/IEA-15-240-RWT/tree/openfast_dev/OpenFAST/IEA-15-240-RWT/ServoData

See the Release Notes in that branch for further description of changes there.

Cheers,
Garrett

[QusayHawari]

Thanks for your reply!

I used the *.dylib file on the UMaine, and I got the following error!

Regards,
Qusay.

---

forrtl: No such file or directory
forrtl: severe (29): file not found, unit 89, file /Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/./DISCON-UMaineSemi.IN
Image PC Routine Line Source
libdiscon.dylib 000000010B018302 for__io_return Unknown Unknown
libdiscon.dylib 000000010B0307C9 for_open Unknown Unknown
libdiscon.dylib 000000010AFFD465 readsetparameters Unknown Unknown
libdiscon.dylib 000000010AFFBA48 readsetparameters Unknown Unknown
libdiscon.dylib 000000010AFF2F1F DISCON Unknown Unknown
openfast 0000000109E0A3A0 __bladedinterface Unknown Unknown
openfast 0000000109E0A527 __bladedinterface Unknown Unknown
openfast 0000000109E0AB09 __bladedinterface Unknown Unknown
openfast 0000000109E2D766 __servodyn_MOD_dl Unknown Unknown
openfast 0000000109E33675 __servodyn_MOD_sr Unknown Unknown
openfast 000000010927AE65 __fast_solver_MOD Unknown Unknown
openfast 000000010927B145 __fast_solver_MOD Unknown Unknown
openfast 00000001091FEF95 __fast_subs_MOD_f Unknown Unknown
openfast 00000001091FF569 fast_subs_MOD_f Unknown Unknown
openfast 000000010911BBC7 MAIN Unknown Unknown
openfast 000000010A6043AF main Unknown Unknown

[gbarter]

@dzalkind does this look familiar to you?

[dzalkind]

It looks like ROSCO isn't finding the DISCON.IN file, and it's looking for it here: /Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/./DISCON-UMaineSemi.IN

Is this a valid file path?

[QusayHawari]

Hi,

Yes, my bad!

Through the past week I have been trying to obtain the linearized state matrices for the UMaine 15MW model without success! The closest I got was I generated a .lin file, but the simulation stops "normally" on the first DT when I set NLinTimes = 1. When I set NLinTimes >1 I get a FATAL error due to a low TSR.

Dr. Jason recommended to go back a step, and check the simulation without using the linearization feature with including the controller. So I did that. The simulation ran in full (10s), but gave the same error of a low TSR.

DT: 0.025s
TMax: 10s

WindType:1
HWindWSpeed:14
RefHt:150
PLexp:0.2

PCMode:5
VScontl:5

A blade pitch initial condition of 9.5 deg, and a rotor speed initial condition of 5rpm. The rest are 0.

Lastly, the simulation crashes if I include DOFs other than GenDOF and DrTrDOF. The following OpenFAST message was using a run for those DOFs only.

Thanks in Advance

OpenFAST input file heading:
IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform

Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
Running AeroDyn.
AD15 Nodal Outputs: Nodal output section of AeroDyn input file not found or improperly formatted.
Skipping nodal outputs.
Running InflowWind.
Running ServoDyn.
Running ServoDyn Interface for Bladed Controllers (using GNU Fortran for Linux, ).
Using legacy Bladed DLL interface.
Running HydroDyn.
Setting WaveTMax to 0.0 since WaveMod = 0
WARNING: The random number generator in use differs from the original code provided by NREL.
This pRNG uses 8 seeds instead of the 2 in the input file.
Reading in WAMIT output with root name
"/Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/HydroData/IEA-15-240-RW
T-UMaineSemi".
Computing radiation impulse response functions and wave diffraction forces.

Using SS_Excitation Module, with 36 excitation states

Using SS_Radiation Module, with 60 of 60 radiation states

MAP++ (Mooring Analysis Program++) Ver. 1.20.10 Jun-26-2021
MAP Input file section definitions:
Line dictionary definitions:
-LineType, --User-defined name of line [-]
-Diam, --Line diameter, used to calculate area and line displacement per unit length [m]
-MassDen, --Mass (in air) per unit length [kg/m]
-EA, --Axial stiffness [N]
-CB, --Cable/seabed Coulumb friction coefficient [-]
-CIntDamp, --Internal structural damping coefficient [Pa-s]
-Ca, --Cross-flow added-mass coefficient [-]
-Cdn, --Cross-flow drag coefficient [-]
-Cdt, --Tangent (skin) drag coefficient[-]
Node property definitions:
-Node, --Node number; first starts at 1 [-]
-Type, --Type of node. Must be one of: VESSEL, FIX, CONNECT [-]
-X, --Node X position. '#' must prefix CONNECT nodes; constitutes user initial guess [m]
-Y, --Node Y position. '#' must prefix CONNECT nodes; constitutes user initial guess [m]
-Z, --Node Z position. '#' must prefix CONNECT nodes; constitutes user initial guess [m]
-M, --Applied point mass at node [kg]
-B, --Applied point buoyancy module at node [m^3]
-FX, --Applied X external force at node. '#' must prefix VESSEL and FIX nodes [N]
-FY, --Applied Y external force at node. '#' must prefix VESSEL and FIX nodes [N]
-FZ, --Applied Z external force at node. '#' must prefix VESSEL and FIX nodes [N]
Line property definitions:
-Line, --Line number; first starts at 1 [-]
-LineType, --Must match property defined in 'Line Dictions'[-]
-UnstrLen, --Unstretched line length [m]
-NodeAnch, --Anchor node number corresponding to 'Node Property Definitions' section [-]
-NodeFair, --Fairlead node number corresponding to 'Node Property Definitions' section [-]
-Flags, --User run-time flag; see below [-]

Line run-time options definitions
Outputs:
-gx_pos, --Fairlead position in global X [m]
-gy_pos, --Fairlead position in global Y [m]
-gx_pos, --Fairlead position in global Z [m]
-gx_a_pos, --Anchor position in global X [m]
-gy_a_pos, --Anchor position in global Y [m]
-gz_a_pos, --Anchor position in global Z [m]
-gx_force, --Fairlead force in global X (include applied forces) [N]
-gy_force, --Fairlead force in global Y (include applied forces) [N]
-gz_force, --Fairlead force in global Z (include applied forces) [N]
-h_fair, --Horizontal force at fairlead (does NOT include applied forces) [N]
-v_fair, --Vertical force at fairlead (does NOT include applied forces) [N]
-h_anch, --Horizontal force at anchor (does NOT include applied forces) [N]
-v_anch, --Vertical force at anchor (does NOT include applied forces) [N]
-tension_fair, --Line force-magnitude at fairlead (include applied loads) [N]
-tension_anch, --Line force-magnitude at anchor (include applied loads) [N]
-azimuth, --Line lateral offset angle global X axis [deg]
-altitude, --Line inclination angle relative to global XY plane at fairlead [deg]
-lay_length, --Length of line on seabed [m]
-line_tension, --
Model features:
-omit_contact, --Ignore cable/seabed contact
-seg_size <10>, --Number of discrete lines in line
-damage_time , --Line breakage occurs at specified time [s]
-diagnostic , --Run line solver diagnostics until specified time [s] is reached

Model option definitions
General model features:
-ref_position <0.0> <0.0> <0.0>
-repeat ...
MSQS solver options:
-inner_ftol ,
-inner_gtol ,
-inner_xtol ,
-inner_max_its ,
-outer_tol ,
-outer_max_its ,
-outer_epsilon ,
-outer_bd,
-outer_cd,
-outer_fd,
-pg_cooked <1000.0> <1.0>,
-krylov_accelerator <3>,
-integration_dt <0.01>,
LM model feature (not suported yet):
-kb_default --Seabed stiffness parameter
-cb_default --Seabed damping parameter
-wave_kinematics --Enables wave kinematics to drag interaction from surface waves
-lm_model --Enable the lumped-mass model

MAP++ Copyright (C) 2014 and Apache'd by Marco Masciola and others
SimCList Copyright (C) 2010 by Mij http://mij.oltrelinux.com/devel/simclist/
MinPack Copyright (C) 1999 by the University of Chicago
Modifications to MinPack by Frederic Devernay http://devernay.free.fr/hacks/cminpack/

MAP++ is free software; see the source for copying conditions.
This software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES
OR CONDITIONS OF ANY KIND, either express or implied. See
http://www.apache.org/licenses/LICENSE-2.0 forr more details.

MAP++ environment properties (set externally)...
Gravity constant [m/s^2] : 9.81
Sea density [kg/m^3] : 1025.00
Water depth [m] : 100.00
Vessel reference position [m] : 0.00 , 0.00 , 0.00
Time: 0 of 10 seconds.

FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:SrvD_CalcOutput:DLL_controller_call:

Running a controller implemented through NREL's ROSCO Toolbox
A wind turbine controller framework for public use in the scientific field
Developed in collaboration: National Renewable Energy Laboratory
Delft University of Technology, The Netherlands
Primary development by (listed alphabetically): Nikhar J. Abbas
Sebastiaan P. Mulders
Jan-Willem van Wingerden
Visit our GitHub-page to contribute to this project:
https://github.com/NREL/ROSCO

FAST_Solution:FAST_AdvanceStates:SrvD_UpdateStates:DLL_controller_call:BladedInterface option was
designed for an explicit-loose coupling scheme. Using last calculated values from DLL on all
subsequent calls until time is advanced. Warning will not be displayed again.

The BEM solution is being turned off due to low TSR. (TSR = -14.144). This warning will not be
repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates:UpdatePhi(node 3, blade
1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx =
13.972, Vy = -3101.1, rlocal = 7.6641, theta = 0.42607, geometric phi = 3.1371. This warning will
not be repeated though the condition may persist. (See GeomPhi output channel.)

Generator speed: NaN RPM, Pitch angle: 0.0 deg, Power: NaN kW, Est. wind Speed: NaN m/s

Total Real Time: 16.75 seconds
Total CPU Time: 16.737 seconds
Simulation CPU Time: 16.593 seconds
Simulated Time: 10 seconds
Time Ratio (Sim/CPU): 0.60267

OpenFAST terminated normally.

[dzalkind]

Are you sure you haven't made any other changes to the input files?

It also helps to plot the outputs .out from the OpenFAST simulation to get an idea of what is causing the simulation to crash.

[QusayHawari]

Hi,

Other than updating the input files to OpenFAST v3.0 (because the files on github are for v2.4) I haven't done any further changes.

I will double check and let you know, and if there's a repository that contains the input files for the UMaine for v3.0 that would be helpful.

Regards,
Qusay.

[gbarter]

If you consistently use the files in the develop branch, those should be consistent with the latest OpenFAST

[QusayHawari]

Hi,

I just realized the dev input files existed. Thanks for the clarification :)

I ran a 10 second simulation (no linearization),and it worked as seen below in run A(using steady input wind at 15m/s).

I also checked if I can get the linearized state mats, so I did the appropriate changes as recommended from the prompt. I had to change the MoorDyn file to be the same as the MAP++ in order to linearize. I received the following error when I ran the model.

I have attached the .fst file I used for you to look at if you can.

IEA-15-240-RWT-UMaineSemi.txt

Thanks in advance,
Qusay.

-----------------RUN A----------------

Generator speed: 7.3 RPM, Pitch angle: 12.9 deg, Power: 13478.5 kW, Est. wind Speed: 15.1 m/s
Time: 10 of 10 seconds. Estimated final completion at 20:44:14.
Total Real Time: 5.331 seconds
Total CPU Time: 5.3165 seconds
Simulation CPU Time: 2.9302 seconds
Simulated Time: 10 seconds
Time Ratio (Sim/CPU): 3.4127

OpenFAST terminated normally.

------------Linearization Run-----------
.....
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x110c98d3e
#1 0x110c97f4d
#2 0x7fff2047ed7c

[dzalkind]

Seg faults in openfast might be better addressed in that repository. Be sure to include all the input files and compiler info and packaging up your example helps with debugging a lot.

I made a few changes to the inputs in a branch over here and I'm not getting seg faults with linearizations. Maybe try this first?

[QusayHawari]

Hi,

Thanks for the changes you did!

I applied said changes to the input file, and I got this error coming from Aerdyn15:

FAST_InitializeAll:AD_Init:ValidateInputData:When AFAeroMod=2, UAMod must be 4 for linearization.
Set AFAeroMod=1 or UAMod=4.

OpenFAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

They were set to 1, and 3 for AFAeroMod and UAMod respectively.

I changed AFAeroMod=2 and UAMod=4, but got the same exact error.

Thanks in advance,
Qusay.

[dzalkind]

Are you sure you're pointing to the correct AeroDyn file? It should work fine when AFAeroMod = 1. Your error message makes me think that the value that openfast sees is the same.

[QusayHawari]

Hi,

The previous error I sent through is now gone after I cloned the exact input files that you updated.

Talking about linearization only, I think my problem is with the ServoDyn file on lines 28-31. I did several runs by changing those settings and the summary is below.

---

All simulations where run for TMax = 1000s, DT = 0.02s, NlinTimes = 2, and LinTimes at 500s, 1000s.

---

When:

7.56 VS_RtGnSp
19947760.56251191 VS_RtTq
437898.87522915896 VS_Rgn2K
10.0 VS_SlPc

Simulation crashes with the following message :
FAST_InitializeAll:SrvD_Init:ValidatePrimaryData:VS_Rgn2K*VS_RtGnSp^2 must not be greater than

VS_RtTq.
OpenFAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

It was recommended by Dr. Jason in OpenFAST/openfast#812 (Commented on Aug-30th) to use the following settings:

0.001 VS_RtGnSp
19947760.56251191 VS_RtTq
0.001 VS_Rgn2K
0.001 VS_SlPc

Simulation time ran to 60s out of TMax = 1000s with a FATAL error due to a low TSR.

---

The last thing I tried was just changing VS_RtGnSp = 7.56, and the rest as Dr.Jason recommenced. The simulation ran in full, but didn't reach a steady state solution.

Thanks in Advance,
Qusay.

[dzalkind]

Hi @QusayHawari,

It looks like there are a few things going on here:

• The error warning from OpenFAST is suggesting that you either reduce VS_RtGnSp or VS_Rgn2K in ServoDyn.
• It also looks like the heave of this model is way too high, it's about 20 m. @gbarter, I think we need to fix the platform mass values; we can work on that in Fix platform mass #68.
• I had to tweak some settings in the main OpenFAST input. The TrimGain was too high. By reducing that, it will take longer to converge to steady-state, but is more stable. I think this was the primary issue. We typically use a time step of 0.01 s with this model and that will have a similar effect.

I pushed all of these changes to this branch. In the coming days, we can work on PR to more easily set up linearizations of this model from the default configuration.

I hope this helps.

Best, Dan

[QusayHawari]

Hi,

I changed the mass and inertia definitions in the ServoDyn as you did, and reduced the TrimGain to 0.0001 with a DT of 0.01s.

The linearization is working well, and OpenFAST terminates normally :)

The only issue is that linearizations takes place at random times that don't agree with LinTimes in .fst, but generates the correct number of linearizations as defined in NlinTimes.

Thanks for your help, it was much appreciated,
Qusay.

[dzalkind]

If CalcSteady is False, the linearizations will occur at the specified times. Otherwise, OpenFAST searches for a steady-state solution before linearizing.

[QusayHawari]

Ah, I see.

Working perfectly now.

Thanks!

[QusayHawari]

Hi,

I am not sure what went wrong in the simulation, but now linearization does not reach a steady state solution. Simulation runs in full.

I didn't change anything in the recent update from the linearize branch, except adding Beamdyn.dat file in the .fst.

I set CalcSteady to true, TMax to 2000s, DT to 0.01s, and steady wind of 15m/s.

---

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption
violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The
solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will
be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans(): 2.75 s

Time: 10 of 2000 seconds. Estimated final completion at 19:54:40. Time: 20 of 2000 seconds. Estimated final completion at 19:55:03.
........
Time: 1990 of 2000 seconds. Estimated final completion at 19:54:41. Time: 2000 of 2000 seconds. Estimated final completion at 19:54:41.
Unable to find steady-state solution.

OpenFAST encountered an error at simulation time 2000 of 2000 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

---

My guess is that initial conditions should be close to the steady state value at the input wind speed.

Thanks in Advance,
Qusay.

[dzalkind]

Are you using BeamDyn in the simulation? It helps to look at the OpenFAST outputs and see if there is convergence to steady-state. If it's close enough, you can try different TrimTol values.

@ptrbortolotti, have you linearized this model with BeamDyn (and I'm assuming blade DOFs) on? If so, are 2000 seconds enough for convergence, and what value for TrimTol do you typically use?

[QusayHawari]

Hi,

I checked from the output file that results converge to a final value.

I reduced TrimTol to 0.01, but linearization still doesn't reach a steady state solution.

I also tried using Beamdyn_c2.dat instead, but the same happened.

I am not sure what't the problem as a earlier, a steady state solution was reached using Beamdyn.dat, TrimTol of 0.001. The steady state solution was reached at around 150s.

Regards,
Qusay.

[QusayHawari]

Hi,

Thanks for your recommendation about increasing TrimTol. The simulations runs well now using a tolerance of 0.015. Under CalcSteady = T, the first steady state solution took place after 4800s. This high time has to do with the low TrimGain of 0.0001 I am using.

I performed frequency response analysis on the linearized state space models, and I got the following:

The Bode represents:

• Uniform wind input of 15m/s.
• Four linearizations that took place after 4800 seconds, and are very close to each other (approx 10s apart).
• The response is from the command collective pitch angle to the platform pitch.
• No wave excitation matrices were included.
• All 6 platform DOFs were on.

My question is that shouldn't all responses be identical or closely related to one another since steady state is reached, and the same wind is applied. I also tried running a 7000s simulation without using CalcSteady, and linearized the model well into it's steady state condition at 5000s,5500s,6500s,and 7000s but the linearized Bodes are still different.

The other question is that the frequency response is not found if I plot the Bode from the commanded collective pitch to the output rotor speed. I have also tried the individual pitch angles, but nothing was shown.

---

Another thing I have checked was the time response of the platform pitch. The natural frequency for the platform pitch (IEA15MW UMaine ActiveFloat/Semi-sub) is around 0.03Hz. From the .out file, I plotted the pitch, and it looks like the frequency is a little lower (around 0.01Hz).

Thanks in Advance.

[lqw075]

Ah, I see.

Working perfectly now.

Thanks!

Hi @QusayHawari
I'm learning how to linearize "IEA-15-240-RWT-UMaineSemi". Looks like you've succeeded. Congratulations! I'd like to know the specific operation procedure.
Thanks a lot.
lqw