IEA 15MW model with Simulink Errors

Dear Jason,

Thank you for your reply. After much trial and error, I have managed to get the model to run with Simulink using OpenFAST v2.6. For anyone facing similar issues, what I did was tweak the formatting of the AeroDyn, HydroDyn and MoorDyn files to match what is required by the v2.6 executable.

Best Wishes,

Andrew

Dear Andrew and Jason,
I want to ask where I can download the IEA 15MW example file that can be executed by Openfast like r-test.

Best regards,

FuHang

Dear FuHang,

The OpenFAST model of the IEA Wind 15-MW reference wind turbine is available in the following github site: github.com/IEAWindTask37/IEA-15-240-RWT.

Best regards,

Dear Jason,

Thank you for your reply. I got it.

Best Wishes,

Dear Jason,

By the way, I am finding the post or instruction that illustrates computational formula of aero power, aero torque to turbine’s rotor.
Could you give me the link?
Thank you.

Best regards,

Dear FuHang,

Are you asking what aerodynamic equations are implemented in AeroDyn?

Best regards,

Dear Jason,

Yes,maybe. I want to know how to calculate the power and torque the turbine receives from wind.

Best regards,

Dear FuHang,

While not fully up-to-date with the current code base, the main blade-element / momentum (BEM) solution of AeroDyn v15 is documented in the following paper: nrel.gov/docs/fy15osti/63217.pdf.

Best regards,

Dear Jason,

Thank you very much!
I meet some problem when reading “AeroDyn v15 User’s Guide and Theory Manual”. Some symbols is hard to understand without annotation. So, I want to ask for your help once again.
Look the screenshot and the ones with red frame. I can not to find out what these symbols represent.

Dear FuHang,

These are variables used in the unsteady airfoil aerodynamics submodel of AeroDyn v15. The unsteady airfoil aerodynamics theory is not discussed in the paper I linked to; instead, the unsteady airfoil aerodynamics theory is discussed in following paper: nrel.gov/docs/fy20osti/66347.pdf. Please note, however, that I would not expect unsteady airfoil aerodynamics to have much effect on wind turbine performance, which is more driven by mean conditions. Unsteady airfoil aerodynamics will, however, effect wind turbine structural loading under dynamic conditions.

Best regards,

1 Like

Dear Jason,

Thank you very much again for your patience. I have another question that how to calulate the input parameters “BldFlDmp, BldEdDmp, TwrFADmp, TwrSSDmp” of “NRELOffshrBsline5MW_Onshore_ElastoDyn_Tower.dat” and “NRELOffshrBsline5MW_Onshore_ElastoDyn_Blade.dat”, used by Elastodyn. These are not be mentioned in the "Definition of a 5-MW Reference Wind Turbine for Offshore System Development ".

Best regard,

Dear FuHang,

These values are given in Tables 6-2 and 2-2 of the NREL 5-MW specifications report you reference, respectively.

Best regards,

Hi Jason,

Recently I am working the openfast with the IEA-15MW wind turbine atop with monopile foundation, and the version of openfast is 3.1.0, the IEA-15MW wind turbine is version 1.1.2. when I read the ElastoDyn file, I realized both the DrTrDOF and YawDOF are disable by default. Since turbulent winds are essential for the following study, I turned YawDOF on for a simple test. hence, I turn YawDOF on and set the step size to 0.0025 or even smaller, however, some error occured and the message in the command as followings:

Running InflowWind.
Running HydroDyn.
** Generating incident wave kinematics and current time history.**
Running SubDyn.
** Fixed bottom case detected**
** Performing Craig-Bampton reduction 60 DOFs → 0 modes + 6 DOFs**
** Using static improvement method for gravity and ext. loads**
** Calculating Full System Modes for output files**
** Exporting Summary file**
Running ServoDyn.
Running ServoDyn Interface for Bladed Controllers (using Intel Visual Fortran for Windows, ).
Using legacy Bladed DLL interface.

------------------------------------------------------------------------------
Running ROSCO-v2.5.0
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**
------------------------------------------------------------------------------

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_AB4:ED_RK4:ED_CalcContStateDeriv:SetCoordSy:Small
angle assumption violated in SUBROUTINE SmllRotTrans() due to a large platform displacement
(ElastoDyn SetCoordSy). The solution may be inaccurate. Simulation continuing, but future
warnings from SmllRotTrans() will be suppressed.
** Additional debugging message from SUBROUTINE SmllRotTrans(): 2.50000E-03 s**
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSolve:SD_CalcOutput:
Angles in GetSmllRotAngs() are larger than 0.4 radians.
SD_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4 radians.
FullOpt1_InputOutputSolve:HydroDyn_CalcOutput:HDOut_MapOutputs: Angles in GetSmllRotAngs() are
larger than 0.4 radians.
FullOpt1_InputOutputSolve:SD_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4 radians.
SD_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4 radians.
FullOpt1_InputOutputSolve:HydroDyn_CalcOutput:HDOut_MapOutputs: Angles in GetSmllRotAngs() are
larger than 0.

Warning: SkewedWakeCorrection encountered a large value of chi (-161.47 deg), so the yaw
correction will be limited. This warning will not be repeated though the condition may persist.
See the AD15 chi output channels, and consider turning off the Pitt/Peters skew model (set
SkewMod=1) if this condition persists.

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

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 3, blade
1):UA_UpdateStates:UA_UpdateDiscOtherState:ComputeKelvinChain:Mach number exceeds 1.0. Equations
cannot be evaluated.

** OpenFAST encountered an error at simulation time 2.50000E-03 of 300 seconds.**
** Simulation error level: FATAL ERROR**

** Aborting OpenFAST.**

I made a lot of attempts to address the above errors. At first, I looked it up and found that it needed to set PtfmYIner to a specific value if enable YawDOF. So I set an initial value to PtfmYIner, and the error did disappear. However, https://github.com/IEAWindTask37/IEA-15-240-RWT/blob/master/ReleaseNotes.md says that PtfmYIner zeroed out because transition piece is accounted for in SubDyn. It seems that it is not necessary to set a value to the PtfmYIner.

I was confused,and I can’t solve that by myself, hoping you could give me some suggestion.

Best regard,

Yiqi

Dear @Han.Yiqi,

So, did setting PtfmYIner nonzero solve the numerical instability you are seeing?

When you enable both PtfmYDOF and YawDOF in ElastoDyn, it is necessary to set PtfrmYIner nonzero as discussed recently in the following forum topic: Wind Veer Parameter - #55 by Jason.Jonkman.

Best regards,

Dear jason,

Yes, it works well when i set a value to the PtfmYIner.

However, my following research focus is to explore the impact of marine growth thickness on the structural response of offshore wind turbines. IEA 15MW monopile OWT is selected as the prototype, and the thickness of marine organisms are 25mm,50mm,75mm and 100mm in turn. When i am trying to model the 25mm marine growth, I encountered an error similar to https://forums.nrel.gov/t/modelling-marine-growth-on-5mw-oc3-hywind-spar-errors/2515 described, but unlike the above error, my simulation failed at the beginning. Also, it should be noted that I have set the simulation step size to 0.001s to eliminate instability.

First I will explain the setup I have used, and then secondly the errors I’m seeing as a result.
Marine Growth modelling
So in the HydroDyn.dat input file, I have entered the below:
---------------------- MARINE GROWTH -------------------------------------------
2 NMGDepths - Number of marine-growth depths specified (-)
MGDpth MGThck MGDens
(m) (m) (kg/m^3)
2 0.025 1400
-20 0.025 1400
---------------------- MEMBER OUTPUT LIST --------------------------------------

No changes have been made other than those added above.

Errors Encountered

Running ROSCO-v2.5.0
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

FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSolve:SD_CalcOutput:
Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large UR_bar input angles.
The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans()
will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans():

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

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 46, blade
1):UA_UpdateStates:UA_UpdateDiscOtherState:ComputeKelvinChain:Mach number exceeds 1.0. Equations
cannot be evaluated.

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

Aborting OpenFAST.

Inexplicably, when I set the marine growth thickness to 50mm,75mm and 100mm, the calculation continued smoothly and work well.

The all simulation files can be found in https://drive.google.com/drive/folders/105IE4ZbeYYAFDrFt3sMfHQMgYAKCZg_A?usp=sharing, hoping you could give me some suggestion.

Best regard,

Yiqi

Dear @Han.Yiqi,

I just requested access to your Google drive.

Regardless, my guess is the model you are using is numerically unstable for some reason. I see that the publicly available OpenFAST model of the IEA Wind 15-MW reference wind turbine atop the monopile (IEA-15-240-RWT/OpenFAST/IEA-15-240-RWT-Monopile at master · IEAWindTask37/IEA-15-240-RWT · GitHub) does not include a correction step, NumCrctn = 1 in the OpenFAST primary input file, despite that generally being recommend for OpenFAST models with SubDyn enabled. Does adding this correction step resolve the issue?

Best regards,

Dear jason,

Based on your suggestion, I have set NumCrctn = 1. However, it doesn’t work yet, still giving the error as shown below.

Running ROSCO-v2.5.0
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**
------------------------------------------------------------------------------

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.

FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSolve:SD_CalcOutput:
Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large UR_bar input angles.
The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans()
will be suppressed.
** Additional debugging message from SUBROUTINE SmllRotTrans():**

The BEM solution is being turned off due to low TSR. (TSR = -2.8106). 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 22, blade
3):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx = 2.461,
Vy = -309.29, rlocal = 54.04, theta = 4.79724E-02, geometric phi = 3.1336. This warning will not
be repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption
violated in SUBROUTINE SmllRotTrans() due to a large platform displacement (ElastoDyn
SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from
SmllRotTrans() will be suppressed.
** Additional debugging message from SUBROUTINE SmllRotTrans(): 1.176 s**
FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 11, blade
1):UA_UpdateStates:UA_UpdateDiscOtherState:ComputeKelvinChain:Mach number exceeds 1.0. Equations
cannot be evaluated.

** OpenFAST encountered an error at simulation time 1.175 of 300 seconds.**
** Simulation error level: FATAL ERROR**

** Aborting OpenFAST.**

Besides, I also set DT_UJac=1.5 as you suggested in https://forums.nrel.gov/t/modelling-marine-growth-on-5mw-oc3-hywind-spar-errors/2515/5, and it also doesn’t work.

Due to the adjustments of the simulation files, I repost the new link to share the files:https://drive.google.com/drive/folders/1mWF-Qjl2tnByCGWhRjwkatCLAgwot5Vq?usp=sharing. hoping you could give me some suggestion.

Best regards,

Dear @Han.Yiqi,

I was looking at the OpenFAST model and it seems that once the yaw degree of freedom is enabled, the system becomes numerically unstable.

Although not ideal, one workaround is to increase the platform yaw inertia (PtfmYIner) two orders of magnitude (from 13548889.3 kg-m^2 to 13548889.3E2 kg-m^2).

I also included a Rayleigh stiffness proportional-only damping in SubDyn of 0.01 s. So, the RayleighDamp parameter is set up to: 0.0, 0.01.

With these modifications and a DT in OpenFAST of 0.001 s, the system seems to be numerically stable.

Below, in the first plot, you can see the rotation experienced by the yaw spring (YawPzn). In the middle plot, you can see the tower top Mz (YawBrMzp). In the lower plot, you can see the rotation at the tower base (PtfmYaw). For reference, the total rotation at the tower top would be YawPzn+PtfmYaw.

I hope that helps!

Roger

2 Likes

Dear Roger,

Firstly, thank you for your efforts to solve my problem. It works well after changing the values mentioned above.

Moreover, i would like another question:
for this numerical instability problem, why did you choose increase the platform Yaw inertia and adjust the Rayleigh Damp parameters to deal with this problem? In other words, why do you choose these two ways to eliminate the instability?

Best regards

Yiqi

Dear @Han.Yiqi,

I am happy to hear that the OpenFAST model is running.

When I was testing your model, I observed that the instability was related to the yaw degree of freedom. In the yaw direction, there is the NacelleYInertia and the YawSpr at the upper side (tower top) and the PlatformYInertia and the monopile at the lower side. I guess there is a torsional mode (that it doesn’t have to be necessarily the 1st torsional mode) or a coupling between modes that makes the system numerically unstable. By increasing the PlatformYInertia, this issue seemed to disappear. To better understand this behavior, it would be necessary to perform an eigenanalysis of the system.

By looking at the files, I also observed that the monopile (defined in SubDyn) did not have any damping applied. There was only a damping applied to the internal modes, but no internal modes were retained (Guyan approach was adopted). Since the system was experiencing numerical instabilities, having a damping (and specially a stiffness proportional damping that increases linearly with the frequency) would help to damp out any possible high frequency that challenged the solver.

I hope that helps!

Roger

2 Likes