I have migrated a wind turbine model that previously worked with a ROSCO controller to the new OpenFast v5.0 version . However, when I run a stedy simulation in this new version using the old .dll and DISCON.in files, the controller does not behave as expected and the turbine response is not correct:

As far as I understand, the latest ROSCO release is compatible with OpenFAST 4.2 (as indicated in the environment.yml file), so I am currently unable to generate a new DISCON.IN file specifically for OpenFAST v5.0.

Is there any way to continue using the ROSCO controller with OpenFAST v5.0?

If not, what would be the best way to obtain an equivalent controller for OpenFAST v5.0 that reproduces the behavior of the previous one as closely as possible?

Thank you very much for your help.

Maddi

3 posts - 2 participants

Read full topic

We’ve coupled AeroDyn and ServoDyn to our own structural solver, effectively taking the place of ElastoDyn/BeamDyn in terms of the overall solution. It’s working fine for the most part, but there are some minor issues which ideally we like to get working better. One of these is supplying initial conditions to ServoDyn.

For example, I have a simple test case…

• IEA 15MW RWT
• Wind speed = 20 m/s steady/constant
• Based on turbine characteristics, this is safely into the rated range, where rotor speed is 7.55 rpm
• Running the turbine from a standing start (zero initial rotor speed), indeed produces a rotor speed of 7.55 rpm, and a blade pitch angle is 17.55 deg. But it takes a while to reach steady-state naturally.
• Now if I want to run the turbine starting from a realistic rotor speed, to fast-track away the initial transience, I supply initial conditions via the AeroDyn driver file, and the structural code also passes some initial conditions to ServoDyn.
• The initial rotor speed from AeroDyn looks good at 7.55rpm. But then it changes, most likely due to changes in pitch angle, see next point
• The initial blade pitch angle returned from ServoDyn looks good, momentarily, at the very first solution step, then seems to reset to zero degrees, before slowly recovering to the correct angle as the controller gets to grips with the applied loads and turbine response.
• Probably goes without saying, but we are supplying AeroDyn with instantaneous blade positions etc. as discussed in… How to import hub motions to AeroDyn?
• See plots below for illustration.

In the structural code, we are initialising blade pitch and rotor speed.

• InitInData_SrvD%BlPitchInit
• InitInData_SrvD%RotSpeedRef

In the OpenFAST code (SUBROUTINE SrvD_Init), I noticed that ServoDyn is accepting our suggested pitch angle during initialisation. But I also noticed that it is setting an initial rotor speed of zero.

SUBROUTINE SrvD_Init

p%BlPitchInit = InitInp%BlPitchInit

u%BlPitch = p%BlPitchInit(1:p%NumBl)

u%RotSpeed = 0.0

I am just wondering if the structural solver could/should be setting more information for ServoDyn’s initial conditions, in addition to InitInp%BlPitchInit and InitInp%RotSpeedRef?

Hope the above makes sense.

Kind regards,

Aengus.

Driver File

----- Combined-Case Analysis [used only when AnalysisType=3, numTurbines=1 -------------

      1    NumCases        - Number of cases to run

WndSpeed ShearExp RotSpd Pitch Yaw dT Tmax DOF Amplitude Frequency

(m/s) (-) (rpm) (deg) (deg) (s) (s) (-) (-) (Hz)

0.2000000E+02 0.0000000E+00 0.7550000E+01 0.1755000E+02 0.0000000E+00 0.5000000E-01 0.2000000E+03 0 0 0

Blade Pitch

Rotor Speed

2 posts - 2 participants

Read full topic

Does WEIS include RBDO (Reliability Based Design Optimization)?

Best Regards,

Riad

4 posts - 2 participants

Read full topic

We are seeing what it looks like a yaw dependent instability in OpenFAST that appears mainly around yaw = +30 deg / -30 deg, and we were wondering whether others have run into something similar.

For the parked cases, we are using:

• Blade pitch = 87 deg

• GenDOF = False

• CompServo = 0 so the controller is disabled

• UA_Mod = 0

So these are intended to be fully parked cases with no active control action.

What we see is that most yaw angles look reasonable, but +/-30 deg tends to produce a much stronger oscillatory response, in some channels almost looking like the onset of an instability:

What is interesting is that we sometimes see something similar in idling cases too. In those cases, however, we are not disabling GenDOF or CompServo, so the rotor, generator and controller dynamics are still present. Even there, the +/-30 deg yaw cases tend to stand out:

This makes us wonder whether yaw around +/-30 deg is a known sensitive condition for parked/idling simulations, especially with blades feathered to 87 deg. So our questions are the following ones:

• Have you ever seen this kind of behavior before?

• Is +/-30 deg yaw known to be especially problematic or sensitive in parked/idling OpenFAST simulations?

• What would you recommend testing for this specific cases?

Any suggestions would be very helpful.

Kind regards,

Kepa

2 posts - 2 participants

Read full topic

I am working on the IEA 3.4 MW onshore wind turbine.

I decided to compare between CCblade and OpenFAST.

The steady-state rotor performance from CCblade could be found here.

Regarding OpenFAST:

• i have disabled all DoFs

• I have set the Wake induction model in AeroDyn to steady BEM

• The inputs used for the OpenFAST model are the wind speed, the rotor speed and the blade pitch. All three parameters were obtained from here. I have automated the computations using MATLAB.

• Regarding the outputs from OpenFAST, i take the mean value of the time series after ignoring the first 30 seconds. However, i found discrepancies which seems to me odd.

Did anyone perform the comparison and obtain good agreement ?

Thank you in advance,

Best Regards,

Riad

6 posts - 3 participants

Read full topic

We are trying to model a 22MW idling turbine at 50m/s steady wind with fixed base in OpenFAST.

The Aerodyn and Servodyn files are attached.

We have not set GenDOF to False because we want to model idling turbine and not a braked one.

1. However when looking at the results of the Rotor Thrust (RtAeroFxh) we see a very large moment (in the order of 45 MN-m) in the initial step. We have set the initial blade pitch to 90 in Elastodyn.

What could be leading to such high initial values ?

2. We observe a initial highly transient response in the tower base shears and moments, even though Aero forces responses are as expected for an Idling case.

Rotor Force is as expected

Aerodyn_parked file
```

------- AERODYN v15.03.* INPUT FILE ------------------------------------------------
Generated with AeroElasticSE FAST driver
======  General Options  ============================================================================
False                  Echo        - Echo the input to "<rootname>.AD.ech"?  (flag)
Default                DTAero      - Time interval for aerodynamic calculations {or "default"} (s)
0                      Wake_Mod    - Wake/induction model (switch) {0=none, 1=BEMT, 3=OLAF} [Wake_Mod cannot be 2 or 3 when linearizing]
1                      TwrPotent   - Type tower influence on wind based on potential flow around the tower (switch) {0=none, 1=baseline potential flow, 2=potential flow with Bak correction}
1                      TwrShadow   - Calculate tower influence on wind based on downstream tower shadow (switch) {0=none, 1=Powles model, 2=Eames model}
True                   TwrAero     - Calculate tower aerodynamic loads? (flag)
False                  CavitCheck  - Perform cavitation check? (flag) [UA_Mod must be 0 when CavitCheck=true]
False                  Buoyancy    - Include buoyancy effects? (flag)
False                  NacelleDrag - Include Nacelle Drag effects? (flag)
False                  CompAA      - Flag to compute AeroAcoustics calculation [used only when Wake_Mod = 1 or 2]
AeroAcousticsInput.dat AA_InputFile - AeroAcoustics input file [used only when CompAA=true]
======  Environmental Conditions  ===================================================================
1.225                  AirDens     - Air density (kg/m^3)
1.4775510204081632e-05 KinVisc     - Kinematic viscosity of working fluid (m^2/s)
340.0                  SpdSound    - Speed of sound in working fluid (m/s)
103500.0               Patm        - Atmospheric pressure (Pa) [used only when CavitCheck=True]
1700.0                 Pvap        - Vapour pressure of working fluid (Pa) [used only when CavitCheck=True]
======  Blade-Element/Momentum Theory Options  ====================================================== [unused when Wake_Mod=0 or 3, except for BEM_Mod]
2                      BEM_Mod     - BEM model {1=legacy NoSweepPitchTwist, 2=polar} (switch) [used for all Wake_Mod to determine output coordinate system]
--- Skew correction
0                      Skew_Mod    - Skew model {0=No skew model, -1=Remove non-normal component for linearization, 1=skew model active}
False                  SkewMomCorr - Turn the skew momentum correction on or off [used only when Skew_Mod=1]
default                SkewRedistr_Mod - Type of skewed-wake correction model (switch) {0=no redistribution, 1=Glauert/Pitt/Peters, default=1} [used only when Skew_Mod=1]
1.4726215563702154     SkewRedistrFactor - Constant used in Pitt/Peters skewed wake model {or "default" is 15/32*pi} (-) [used only when Skew_Mod=1 and SkewRedistr_Mod=1]
--- BEM algorithm 
True                   TipLoss     - Use the Prandtl tip-loss model? (flag) [unused when Wake_Mod=0 or 3]
True                   HubLoss     - Use the Prandtl hub-loss model? (flag) [unused when Wake_Mod=0 or 3]
True                   TanInd      - Include tangential induction in BEMT calculations? (flag) [unused when Wake_Mod=0 or 3]
True                   AIDrag      - Include the drag term in the axial-induction calculation? (flag) [unused when Wake_Mod=0 or 3]
True                   TIDrag      - Include the drag term in the tangential-induction calculation? (flag) [unused when Wake_Mod=0,3 or TanInd=FALSE]
Default                IndToler    - Convergence tolerance for BEMT nonlinear solve residual equation {or "default"} (-) [unused when Wake_Mod=0 or 3]
500                    MaxIter     - Maximum number of iteration steps (-) [unused when Wake_Mod=0]
--- Shear correction
False                  SectAvg     - Use sector averaging (flag)
1                      SectAvgWeighting - Weighting function for sector average {1=Uniform, default=1} within a sector centered on the blade (switch) [used only when SectAvg=True]
default                SectAvgNPoints - Number of points per sectors (-) {default=5} [used only when SectAvg=True]
default                SectAvgPsiBwd - Backward azimuth relative to blade where the sector starts (<=0) {default=-60} (deg) [used only when SectAvg=True]
default                SectAvgPsiFwd - Forward azimuth relative to blade where the sector ends (>=0) {default=60} (deg) [used only when SectAvg=True]
--- Dynamic wake/inflow
0                      DBEMT_Mod   - Type of dynamic BEMT (DBEMT) model {0=No Dynamic Wake, -1=Frozen Wake for linearization, 1:constant tau1, 2=time-dependent tau1, 3=constant tau1 with continuous formulation} (-)
34.079999999999984     tau1_const  - Time constant for DBEMT (s) [used only when Wake_Mod=2 and DBEMT_Mod=1]
======  OLAF -- cOnvecting LAgrangian Filaments (Free Vortex Wake) Theory Options  ================== [used only when Wake_Mod=3]
IEA-22-280-RWT_OLAF.dat OLAFInputFileName - Input file for OLAF [used only when Wake_Mod=3]
======  Unsteady Airfoil Aerodynamics Options  ====================================================
True                   AoA34       - Sample the angle of attack (AoA) at the 3/4 chord or the AC point {default=True} [always used]
0                      UA_Mod      - Unsteady Aero Model Switch (switch) {0=Quasi-steady (no UA), 2=B-L Gonzalez, 3=B-L Minnema/Pierce, 4=B-L HGM 4-states, 5=B-L HGM+vortex 5 states, 6=Oye, 7=Boeing-Vertol}
True                   FLookup     - Flag to indicate whether a lookup for f' will be calculated (TRUE) or whether best-fit exponential equations will be used (FALSE); if FALSE S1-S4 must be provided in airfoil input files (flag) [used only when UA_Mod>0]
3               IntegrationMethod  - Switch to indicate which integration method UA uses (1=RK4, 2=AB4, 3=ABM4, 4=BDF2)
0.05                   UAStartRad  - Starting radius for dynamic stall (fraction of rotor radius [0.0,1.0]) [used only when UA_Mod>0; if line is missing UAStartRad=0]
1                      UAEndRad    - Ending radius for dynamic stall (fraction of rotor radius [0.0,1.0]) [used only when UA_Mod>0; if line is missing UAEndRad=1]

ServoDyn Parked file

------- SERVODYN v1.05.* INPUT FILE --------------------------------------------
Generated with AeroElasticSE FAST driver
---------------------- SIMULATION CONTROL --------------------------------------
False                  Echo        - Echo input data to <RootName>.ech (flag)
default                DT          - Communication interval for controllers (s) (or "default")
---------------------- PITCH CONTROL -------------------------------------------
5                      PCMode      - Pitch control mode {0: none, 3: user-defined from routine PitchCntrl, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
0.0                    TPCOn       - Time to enable active pitch control (s) [unused when PCMode=0]
0.0                TPitManS(1) - Time to start override pitch maneuver for blade 1 and end standard pitch control (s)
0.0                TPitManS(2) - Time to start override pitch maneuver for blade 2 and end standard pitch control (s)
0.0                TPitManS(3) - Time to start override pitch maneuver for blade 3 and end standard pitch control (s) [unused for 2 blades]
1800.0               PitManRat(1) - Pitch rate at which override pitch maneuver heads toward final pitch angle for blade 1 (deg/s)
1800.0               PitManRat(2) - Pitch rate at which override pitch maneuver heads toward final pitch angle for blade 2 (deg/s)
1800.0               PitManRat(3) - Pitch rate at which override pitch maneuver heads toward final pitch angle for blade 3 (deg/s) [unused for 2 blades]
90.0                   BlPitchF(1) - Blade 1 final pitch for pitch maneuvers (degrees)
90.0                   BlPitchF(2) - Blade 2 final pitch for pitch maneuvers (degrees)
90.0                   BlPitchF(3) - Blade 3 final pitch for pitch maneuvers (degrees) [unused for 2 blades]
---------------------- GENERATOR AND TORQUE CONTROL ----------------------------
5                      VSContrl    - Variable-speed control mode {0: none, 1: simple VS, 3: user-defined from routine UserVSCont, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
1                      GenModel    - Generator model {1: simple, 2: Thevenin, 3: user-defined from routine UserGen} (switch) [used only when VSContrl=0]
95.4                   GenEff      - Generator efficiency [ignored by the Thevenin and user-defined generator models] (%)
True                   GenTiStr    - Method to start the generator {T: timed using TimGenOn, F: generator speed using SpdGenOn} (flag)
True                   GenTiStp    - Method to stop the generator {T: timed using TimGenOf, F: when generator power = 0} (flag)
99999.0                SpdGenOn    - Generator speed to turn on the generator for a startup (HSS speed) (rpm) [used only when GenTiStr=False]
0.0                    TimGenOn    - Time to turn on the generator for a startup (s) [used only when GenTiStr=True]
99999.0                TimGenOf    - Time to turn off the generator (s) [used only when GenTiStp=True]
---------------------- SIMPLE VARIABLE-SPEED TORQUE CONTROL --------------------
7.061131867192265      VS_RtGnSp   - Rated generator speed for simple variable-speed generator control (HSS side) (rpm) [used only when VSContrl=1]
31219733.35544         VS_RtTq     - Rated generator torque/constant generator torque in Region 3 for simple variable-speed generator control (HSS side) (N-m) [used only when VSContrl=1]
626153.114868262       VS_Rgn2K    - Generator torque constant in Region 2 for simple variable-speed generator control (HSS side) (N-m/rpm^2) [used only when VSContrl=1]
2.0                    VS_SlPc     - Rated generator slip percentage in Region 2 1/2 for simple variable-speed generator control (%) [used only when VSContrl=1]
---------------------- SIMPLE INDUCTION GENERATOR ------------------------------
99999.0                SIG_SlPc    - Rated generator slip percentage (%) [used only when VSContrl=0 and GenModel=1]
99999.0                SIG_SySp    - Synchronous (zero-torque) generator speed (rpm) [used only when VSContrl=0 and GenModel=1]
99999.0                SIG_RtTq    - Rated torque (N-m) [used only when VSContrl=0 and GenModel=1]
99999.0                SIG_PORt    - Pull-out ratio (Tpullout/Trated) (-) [used only when VSContrl=0 and GenModel=1]
---------------------- THEVENIN-EQUIVALENT INDUCTION GENERATOR -----------------
99999.0                TEC_Freq    - Line frequency [50 or 60] (Hz) [used only when VSContrl=0 and GenModel=2]
0                      TEC_NPol    - Number of poles [even integer > 0] (-) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_SRes    - Stator resistance (ohms) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_RRes    - Rotor resistance (ohms) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_VLL     - Line-to-line RMS voltage (volts) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_SLR     - Stator leakage reactance (ohms) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_RLR     - Rotor leakage reactance (ohms) [used only when VSContrl=0 and GenModel=2]
99999.0                TEC_MR      - Magnetizing reactance (ohms) [used only when VSContrl=0 and GenModel=2]
---------------------- HIGH-SPEED SHAFT BRAKE ----------------------------------
0                      HSSBrMode   - HSS brake model {0: none, 1: simple, 3: user-defined from routine UserHSSBr, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
99999.0                THSSBrDp    - Time to initiate deployment of the HSS brake (s)
99999.0                HSSBrDT     - Time for HSS-brake to reach full deployment once initiated (sec) [used only when HSSBrMode=1]
99999.0                HSSBrTqF    - Fully deployed HSS-brake torque (N-m)
---------------------- NACELLE-YAW CONTROL -------------------------------------
0                      YCMode      - Yaw control mode {0: none, 3: user-defined from routine UserYawCont, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
99999.0                TYCOn       - Time to enable active yaw control (s) [unused when YCMode=0]
0.0                    YawNeut     - Neutral yaw position--yaw spring force is zero at this yaw (degrees)
9093012484.130638      YawSpr      - Nacelle-yaw spring constant (N-m/rad)
6410654.157064741      YawDamp     - Nacelle-yaw damping constant (N-m/(rad/s))
99999.0                TYawManS    - Time to start override yaw maneuver and end standard yaw control (s)
0.25                   YawManRat   - Yaw maneuver rate (in absolute value) (deg/s)
0.0                    NacYawF     - Final yaw angle for override yaw maneuvers (degrees)
---------------------- AERODYNAMIC FLOW CONTROL --------------------------------
0                      AfCmode     - Airfoil control mode {0: none, 1: cosine wave cycle, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
0.0                    AfC_Mean    - Mean level for cosine cycling or steady value (-) [used only with AfCmode==1]
0.0                    AfC_Amp     - Amplitude for for cosine cycling of flap signal (-) [used only with AfCmode==1]
0.0                    AfC_phase   - Phase relative to the blade azimuth (0 is vertical) for for cosine cycling of flap signal (deg) [used only with AfCmode==1]
---------------------- STRUCTURAL CONTROL --------------------------------------
 0                     NumBStC     - Number of blade structural controllers (integer)
"unused"               BStCfiles   - Name of the files for blade structural controllers (quoted strings) [unused when NumBStC==0]
0                      NumNStC     - Number of nacelle structural controllers (integer)
"unused"               NStCfiles   - Name of the files for nacelle structural controllers (quoted strings) [unused when NumNStC==0]
0                      NumTStC     - Number of tower structural controllers (integer)
"unused"               TStCfiles   - Name of the files for tower structural controllers (quoted strings) [unused when NumTStC==0]
0                      NumSStC     - Number of substructure structural controllers (integer)
"unused"               SStCfiles   - Name of the files for substructure structural controllers (quoted strings) [unused when NumSStC==0]
---------------------- CABLE CONTROL -------------------------------------------
0                      CCmode      - Cable control mode {0: none, 4: user-defined from Simulink/Labview, 5: user-defined from Bladed-style DLL} (switch)
---------------------- BLADED INTERFACE ---------------------------------------- [used only with Bladed Interface]
"../IEA-22-280-RWT/libdiscon.dll" DLL_FileName - Name/location of the dynamic library {.dll [Windows] or .so [Linux]} in the Bladed-DLL format (-) [used only with Bladed Interface]
"IEA-22-280-RWT_DISCON.IN" DLL_InFile  - Name of input file sent to the DLL (-) [used only with Bladed Interface]
"DISCON"               DLL_ProcName - Name of procedure in DLL to be called (-) [case sensitive; used only with DLL Interface]
default                DLL_DT      - Communication interval for dynamic library (s) (or "default") [used only with Bladed Interface]
False                  DLL_Ramp    - Whether a linear ramp should be used between DLL_DT time steps [introduces time shift when true] (flag) [used only with Bladed Interface]
99999.0                BPCutoff    - Cuttoff frequency for low-pass filter on blade pitch from DLL (Hz) [used only with Bladed Interface]
0.0                    NacYaw_North - Reference yaw angle of the nacelle when the upwind end points due North (deg) [used only with Bladed Interface]
0                      Ptch_Cntrl  - Record 28: Use individual pitch control {0: collective pitch; 1: individual pitch control} (switch) [used only with Bladed Interface]
0.0                    Ptch_SetPnt - Record  5: Below-rated pitch angle set-point (deg) [used only with Bladed Interface]
0.0                    Ptch_Min    - Record  6: Minimum pitch angle (deg) [used only with Bladed Interface]
0.0                    Ptch_Max    - Record  7: Maximum pitch angle (deg) [used only with Bladed Interface]
0.0                    PtchRate_Min - Record  8: Minimum pitch rate (most negative value allowed) (deg/s) [used only with Bladed Interface]
0.0                    PtchRate_Max - Record  9: Maximum pitch rate  (deg/s) [used only with Bladed Interface]
0.0                    Gain_OM     - Record 16: Optimal mode gain (Nm/(rad/s)^2) [used only with Bladed Interface]
0.0                    GenSpd_MinOM - Record 17: Minimum generator speed (rpm) [used only with Bladed Interface]
0.0                    GenSpd_MaxOM - Record 18: Optimal mode maximum speed (rpm) [used only with Bladed Interface]
0.0                    GenSpd_Dem  - Record 19: Demanded generator speed above rated (rpm) [used only with Bladed Interface]
0.0                    GenTrq_Dem  - Record 22: Demanded generator torque above rated (Nm) [used only with Bladed Interface]
0.0                    GenPwr_Dem  - Record 13: Demanded power (W) [used only with Bladed Interface]
---------------------- BLADED INTERFACE TORQUE-SPEED LOOK-UP TABLE -------------
0                      DLL_NumTrq  - Record 26: No. of points in torque-speed look-up table {0 = none and use the optimal mode parameters; nonzero = ignore the optimal mode PARAMETERs by setting Record 16 to 0.0} (-) [used only with Bladed Interface]
GenSpd_TLU            	GenTrq_TLU            
(rpm)                 	(Nm)                  
---------------------- OUTPUT --------------------------------------------------
False                  SumPrint    - Print summary data to <RootName>.sum (flag) (currently unused)
1                      OutFile     - Switch to determine where output will be placed: {1: in module output file only; 2: in glue code output file only; 3: both} (currently unused)
True                   TabDelim    - Use tab delimiters in text tabular output file? (flag) (currently unused)
"ES10.3E2"             OutFmt      - Format used for text tabular output (except time).  Resulting field should be 10 characters. (quoted string) (currently unused)
0.0                    TStart      - Time to begin tabular output (s) (currently unused)
              OutList      - The next line(s) contains a list of output parameters.  See OutListParameters.xlsx for a listing of available output channels, (-)
"GenPwr"
"GenTq"
END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
---------------------------------------------------------------------------------------

Thank you,

Ashok

21 posts - 3 participants

Read full topic

I am looking to model the IEA 22MW reference turbine with a stiff-stiff tower configuration. In most references I find online, there is a clear soft-soft, soft-stiff and stiff-stiff design region for the tower design (see left side of the figure below). However, the IEA 22MW reference turbine large rpm range (1.81-7.06 rpm <~> 0.03-0.12 Hz) means that the 1P, 3P, and 6P regions overlap (see right side of the figure below). In other words, no such “safe” soft-stiff and stiff-stiff designs are possible.

Would it be possible to tell me why such a large rpm range was chosen and suggest how to define the soft-stiff and stiff-stiff regions? I assume the next best thing is to use the rated rpm as boundaries for the 1P, 3P and 6P regions, but then there will always be resonance somewhere between the cut-in and rated wind speed.

Kind regards,

Victor Rappe

11 posts - 3 participants

Read full topic

I hope this mail finds you well. I am recently calculating the Campbell diagram of the IEA 22MW project (using the file from GitHub - IEAWindSystems/IEA-22-280-RWT: Repository for the IEA 22-MW offshore reference wind turbine developed by the IEA Wind Task 55 REFWIND · GitHub).

And everything goes well when I set the UA_mod = 0, which means Quasi-steady. However, when I switched this value to 4, which means B-L HGM 4-states, the Campbell diagram results came like this below.

I think it might because of noisy, as some excepted pattern could still be found. So I then checked the excel file after linearization, and found that the eigenvalue should be plurals, but many positive integers have appeared there.

Do I just need to delete those integers manually? And could you please tell me why this happened?

Thank you so much!

All best wishes,

Xingyu

UPDATED: I just delete those integers manually, but it doesn’t work because of the wrong column number

9 posts - 3 participants

Read full topic

I have a question regarding the mode shapes of the blade used in ElastoDyn.

Indeed, the mode shapes are polynomials that are used to fit points given by B_modes. In the input file of B_modes, one should specify the rotor speed. This means that the mode shape depends on the rotor speed which seems reasonable for me since the more the rotor speed is, the more the stiffening effect is pronounced and therefore, the mode shapes are affected.

However, in OpenFAST, ElastoDyn does not have the capability to change the mode shape automatically according to rotor speed.

Is it a limitation of ElastoDyn and one should use BeamDyn instead ?

What do you think ? If there is any NLR publications about this, i will be glad whether you can share them.

Thanks in advance,

Best Regards,

Riad

2 posts - 2 participants

Read full topic

I am currently creating a model for a real onshore wind turbine that is equipped with strain gauges on certain sections of the tower. Now I am unsure how to define the parameters in ElastoDyn so that the simulation results are output at the height of the strain gauges in order to be able to later compare the measurement data with the simulation results.

I have the following tower proportions :

TowerBsHt = 0.87 [m]
TowerHt = 71.4 [m] (sum of the individual tower section lengths plus the tower base height)

The strain gauges are attached at the following heights (with regard to the base of the tower):

3.215m, 25.505m, 50.115m and 69.72m

In the documentation I found this formula for the definition of the parameter TwrGagNd in ElastoDyn:

Elev. of node J = TwrRBHt + ( J – 1⁄2 ) • [ ( TowerHt + TwrDraft – TwrRBHt ) / TwrNodes ]

Translated into the current parameter names and assuming TwrDraft = 0 the formula simplifies to

Elev. of node J = TowerBsHt + ( J – 1⁄2 ) • [ ( TowerHt – TowerBsHt ) / TwrNodes ]

If I understand correctly, I can now use the TwrNodes parameter (also defined in ElastoDyn) to control at which tower heights results can be calculated.

For TwrNodes = 45 I get the following elevations:

J = 2 → 3.22

J = 16 → 25.16

J = 32 → 50.24

J = 44 → 69.05

These elevations are close to the locations of the strain gauges. So, my input for ElastoDyn would be:

NTwGages = 4

TwrGagNd = 2,16,32,44

Are these assumptions correct, or have I misunderstood something?

Thank you in advance.

Best regards,
Sarah

2 posts - 2 participants

Read full topic

I would like to ask about the use of different time steps in OpenFAST and TurbSim.

Suppose I use a time step of 0.0125 seconds in the .fst file, while the time step in the .bts file is 0.05 seconds. In this case, does ElastoDyn interpolate the wind speed field internally?

More generally, could you clarify how the wind field is handled when the time steps differ between TurbSim and OpenFAST?

Thank you for your time and guidance.

Best regards

Riad

2 posts - 2 participants

Read full topic

We are currently looking for reasons to stabilize Tower Mx loads and found the shear correction option in AeroDyn v15 and would like to understand whether it is ready for practical use.

Our understanding is that this feature is still described as a beta option intended to improve BEM behavior in the presence of wind shear by averaging inflow velocity over a limited azimuthal sector. In our preliminary simulations, activating it leads to a noticeable reduction in load oscillations, as could be seen below:

Could you please clarify:

• What is the current stage of development status of this feature?

  • Is it recommended for Design Load Cases at this stage?

• Why does it produce such a significant difference in loads?

We would appreciate any guidance on whether this option can already be used confidently, or whether it should still be treated only as a trade off study for the moment.

Thank you once again for your time.

Kind regards,

Kepa

4 posts - 2 participants

Read full topic

I’m looking for the blade pitch controller for the IEA 3.4 MW onshore wind turbine, compiled as a .so library for Linux.
If anyone has a precompiled version available, or can share a link to download it, I would greatly appreciate it.

Thanks in advance.

Best Regards,

Riad

3 posts - 2 participants

Read full topic

I am currently setting up TurbSim for a series of aeroelastic simulations using OpenFAST for a research project on offshore wind turbine power prediction under varying atmospheric conditions. I am modelling a 15 MW offshore turbine (IEA 15 MW reference turbine) and want to explicitly represent atmospheric stability as a simulation input rather than relying on TI and wind shear alone.

Based on my reading of the TurbSim documentation and some forum threads, I believe the SMOOTH spectral model is the appropriate choice for this, as it accepts the gradient Richardson number (RICH_NO) as a direct input unlike the IEC Kaimal model. I have a few questions I’d like to confirm before proceeding:

1. Richardson number as primary stability input

My plan is to sample RICH_NO across a range from approximately −2.038 (very unstable, following Mohan 1998) to 0.1667 (which appears to be the TurbSim upper limit for stable conditions based on previous forum posts). Is this range correct for the SMOOTH model? Are there known numerical stability issues at the extremes of this range I should be aware of?

2. Role of TI when using SMOOTH

My understanding is that when using the SMOOTH spectral model, IECturbc is ignored and turbulence intensity is instead determined internally by TurbSim from the input RICH_NO and URef, with Ustar left as default. If this is correct, TI would effectively be an output of the simulation rather than an independent input — meaning I should extract TI from the simulated wind field after the fact rather than specifying it directly. Is this understanding correct?

3. Wind shear with SMOOTH

I plan to keep PLExp as an explicit input controlling the mean wind speed profile, with WindProfileType set to PL. Is there any interaction between PLExp and RICH_NO in the SMOOTH model that I should be aware of — for example, does the model internally derive a wind profile from Ri that would conflict with the specified PLExp?

4. Design of Experiments

My current DoE is 23 wind speeds × 50 LHS combinations of RICH_NO and PLExp per wind speed = 1150 simulations total. Does this seem reasonable for covering the offshore atmospheric parameter space adequately, or would you recommend a different sampling strategy?

Any guidance or pointers to relevant documentation would be greatly appreciated.

Thanks, Naomi

3 posts - 2 participants

Read full topic

I’ve recently updated my openFAST version from v3.5.2 to v4.1.0 and I’ve noticed a big drop in computational speed. On two different machines the time ratio went down with more than a factor 3 from v3.5.2 to v4.1.0:

• Machine one: Sim/CPU = 4.80 → 1.48
• Machine two: Sim/CPU = 2.11 → 0.48

For both machines and both versions similar simulations were performed (same time step and interpolation order, same/similar modules, IEA 15MW vs IEA 22MW turbine).

I tried both with the precompiled binaries and self-compiled (speed-optimised) binaries, but this gave almost no difference.

Is this expected behaviour or is there something that I can fix/improve?

Kind regards,

Victor Rappe

5 posts - 2 participants

Read full topic

I am honored to participate in the discussions on the forum. Currently, I am researching the blade icing and its adverse effects on floating wind turbines operating in cold regions. After a period of self-study, I have gained a general understanding of the working principle of OpenFast. But due to my limited knowledge, there are still some issues with running OpenFast. These questions do not involve specific techniques, only requesting some inspiration.
As mentioned earlier, I calculated the ice accumulation of airfoils with different blade lengths under various icing conditions, and obtained the icing mass of the airfoil and the new lift and drag coefficients of the airfoil. I was inspired by the relevant discussions on airfoilprep regarding the correction of lift coefficient and other factors. But what I still don’t know is, where should I make corrections to the blade mass to calculate the impact of additional ice mass on the wind turbine structure (blades)? Additionally, what numerical values (such as torque) can I obtain through OpenFast to assist in analyzing significant ice breaking? Perhaps there have been similar discussions on the forum, but unfortunately, I am still a pure novice in the field of structure. Dear experts, please let me know the relevant discussion titles.
In addition, regarding the hydrodynamic part, in my rough opinion, the slight ice buildup on the blades should not be enough to affect the overall movement of the wind turbine, at least relative to wind and waves. Can we directly use the hydrodyn file from the OpenFast case (r-test)?
Please forgive my poor English.

4 posts - 2 participants

Read full topic

For my master thesis, I’m researching multiple floaters for the IEA 15 MW turbine.
To be able to compare the different floaters more easily, I’m converting all my floaters to the latest version of OpenFAST.
When I update the version of the WindCrete floater (Home - COREWIND), I run in to a numerical stability issue of the code.

In the figures below, I have plotted the simulation results of a single input for different version of openfast: 2.1.0, 3.5.4 and 4.2.0.

This simulation shows the output for a windspeed of 8 m/s, Hs = 3.0 m, Tp = 8s, regular waves.

En zoomed in:

However, the simulation behaves as normal before the crash. For example, the nacelle movement is almost identical:

For all simulations, I use the same inputs, such as the controller or hydrodynamic inputs. To rule out any problems in the modules, I ran the simulation without Hydrodyn and Moordyn and the platform DOF turned off. For a windspeed of 8 m/s, the results for the power are as follows:

To rule out the moordyn file, I used the same file in version 3.5.4 (which worked correctly). I now think the problem lies in the Hydrodyn/Seastate file or in the coupling between all modules. The files are attached below.

I was hoping someone could help with solving this issue.
Thanks in advance!

14 posts - 2 participants

Read full topic

① Change input files such as tower.dat and perform linearization analysis.

② Calculate the RNA mass inertia matrix using the parallel axis theorem for the 6x6 mass matrix.

③ Input the obtained data and find the eigenvalues ​​and eigenmodes using BModes.

④ Enter the data into ModeShapePolyFitting.xls to obtain the mode coefficients.

I also have four questions.

• In which output file is the mass matrix (6x6) obtained in ① stored?

• Have any changes been made to the analysis flow for steps ① through ④ between FASTv7 and OpenFASTv4-2-0?

• Could you please tell me how to calculate HubIner and NacIner? (I want to change the weight of the hub and nacelle, so I’d like to recalculate.)

-Is there a way to calculate the mass-inertia matrix of the RNA without using the parallel axis theorem or something like that?

2 posts - 2 participants

Read full topic

I am encountering an error when running a FAST.Farm simulation with turbulent inflow generated by TurbSim. The error messages indicate that FAST.Farm is trying to access wind data at negative time steps, which is outside the range of the generated wind field. Here are the details:

Farm_Initialize:AWAE_Init:AWAE_UpdateStates:InflowWind_CalcOutput:CalculateOutput:IfW_FlowField_GetVelAcc:Grid3DField_GetCell:
Error: GF wind array was exhausted at 0.1 seconds (trying to access data at -0.48498 seconds). IT_Lo=-4, IT_HI=-3

Configuration Details:

TurbSim Input File:

• GridWidth = 240 m

• GridHeight = 204 m

• AnalysisTime = 7800 s

• UsableTime = "ALL"

• TimeStep = 0.1 s

FAST.Farm Input File:

• TMax = 3900 s

• DT_Low = 0.1 s

• DT_High = 0.1 s

• Mod_AmbWind = 3 (multiple instances of InflowWind)

• NY_High = 37, dY_High = 6.4864 m, Y0_High = -120 m (for both turbines)

I’ve tried different configuration :

Grid Alignment:

• Adjusted Y0_High and dY_High to ensure the high-resolution grid is entirely within the TurbSim flow field (GridWidth = 240 m).

• Confirmed that the grid extends from -120 m to ~120 m, which is within the TurbSim limits.

Time Synchronization:

• Verified that DT_Low and DT_High in FAST.Farm match the TimeStep in TurbSim (0.1 s).

• Ensured TMax in FAST.Farm (3900 s) is less than AnalysisTime in TurbSim (7800 s

Simulation Start Time:

• Confirmed that the simulation should start at t = 0 s (no negative start time is specified).

Question :

1. Why is FAST.Farm trying to access wind data at negative time steps (-0.48498 s, -46.211 s)?

2. Are there any hidden parameters or delays in FAST.Farm or TurbSim that could cause this issue?

3. Could the issue be related to the InflowWind module configuration or the way FAST.Farm initializes the wind field?

Any insights or suggestions would be greatly appreciated!

Thank you in advance,

3 posts - 2 participants

Read full topic

We are currently working on a wind turbine control validation setup. In previous work, we successfully ran co-simulations where OpenFAST was executed within Simulink via the FAST S-Function, and a simulated PLC as the controller. Communication between Simulink and the simulated PLC was established through OPC UA, with Simulink acting as an intermediary.

We would now like to remove the dependency on MATLAB/Simulink and run OpenFAST in standalone mode. I understand that achieving real-time synchronization may not be straightforward, but I would like to ask what the recommended approach is for synchronizing an external controller with OpenFAST under these conditions.

The key aspect in our case is that the controller is not compiled as .dll, but instead runs on a simulated or real PLC (e.g., Siemens 1200).

What would be the correct or recommended approach to implement this type of simulation? Any guidance or references to existing work in this direction would be greatly appreciated.

Best regards,

-Mario

4 posts - 2 participants

Read full topic

• I am using the 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti file for simulation in OpenFAST.
• I am trying to comparison of motion RAO (Figure 26-RAO WAMIT 27m) calculated by Denis Matha in “Model Development and Loads Analyis of an Offshore Wind Turbine on a Tension Leg Platform, with a Comparison to other Floating Concepts”.
• The way I do it is calculating motion RAO using white noise spectrum, with reference to the paper("Investigation of Response Amplitude Operators for Floating Offshore Wind Turbines) and forum posts
  [Method]
  I used 8000 seconds out of a 10000second simulation.
  wave time series → Sxx (spectral density ) using Blackman-Tukey
  ouput response(surge, pitch) → Sxy (spectral density) using Blackman-Tukey
  motion RAO = Sxy/Sxx
• For surge motion RAO, I think the peak values match and y(RAO)-values for each frequency appear to be influenced by smoothing.
  However, For pitch motion RAO, the magnitude of the peak values varies significantly.

Is there something I am forgetting or doing wrong?
Please give suggestions on how to analyze.

Thank you for your help in advance.

9 posts - 2 participants

Read full topic

I´m currently simulating DLC 1.3 with Extreme Turbulent wind, and I´m appreciating a transient at low wind speeds (100–200 s): AoA becomes erratic and LSS loads oscillate. DLC 1.2 with the same controller does not show this behavior, as can be seen below:

Some observations:

• With AeroDyn BEM_Mod=2, I get some errors when the simulation is running:

  • “There is no valid value of phi for these operating conditions”

  • “Temporarily turning off UA due to high angle of attack or low relative velocity”

• Disabling UA does not change that transient.

• Switching BEM_Mod from 2 → 1 makes the AoA and LSS loads well behaved and the problem dissapears:

From what I’ve read in the forum, these warnings often occur when relative velocity approaches zero. My case seems consistent with that, but I’m not sure what the recommended mitigation is when using BEM_Mod=2.

So my question is the next one:

• Are there recommended settings to keep BEM_Mod=2 in this Design Load Cases and avoid this numerical error? If not, do you recommend to use BEM_MOD=1 in this specific situation?

Happy to share the OpenFAST (4.1.1) and the Aerodyn (v15) versions in order to provide you more information.

Thanks!

8 posts - 3 participants

Read full topic

I would like to use FAST.Farm with an OpenFAST turbine model which includes a linkage to a controller in Simulink (defined in the ServoDyn file).
Is there a way to run FAST.Farm with theat type of turbine model or is it only possible with another setting in the ServoDyn file?
I am not sure, if this was discussed somewhere before but I have only found discussions about running FAST.Farm direcly in Simulink, like OpenFAST with the S-function. But this is not what I intend to do.

Maybe someone already has experiences with it.
Thanks in advance.

4 posts - 2 participants

Read full topic

I am currently working with linear models generated using OpenFAST, and I’ve been experimenting with the option LinInputs = 2 to include additional inputs in the linearization. While analyzing the newly included inputs in the linearized models, I noticed that some of them related to the blades (particularly those related to AeroDyn) are marked as rotating frame = false in the .lin files.

I would like to understand whether there is a known limitation or incomplete implementation in the development of the linearization inputs when LinInputs = 2 is used, or I am misunderstanding the description and these inputs are in fact expressed in the fixed frame rather than the rotating blade frame.

Could someone clarify how the reference frame of these addtional inputs is defined when using LinInputs = 2?

Thank you very much for your help.

Best regards,

Daniel Lacheta.

2 posts - 2 participants

Read full topic

I am currently using OpenFAST v4.1.2 (installed via Anaconda) and attempting to run the MoorDyn MHK_RM1_Floating example. However, the simulation terminates with the fatal error reported below:

After reviewing previous discussions in this forum (OpenFAST v3.0.0 – MoorDyn.dat execution error), it appears that similar issues may be related to modifications introduced in the HydroDyn and/or SubDyn modules in OpenFAST versions 4.1.0 and later. My understanding is that recent updates require additional input parameters that are not defined in the MHK_RM1_Floating_HydroDyn.dat file available in the current github repository.

Upon inspecting the HydroDyn input file, it seems that the newer OpenFAST versions introduced a more flexible treatment of structural members by distinguishing between cylindrical and rectangular cross-sections. Since my simulations involve exclusively cylindrical members, I would like to know whether it is possible to disable or bypass the requirement for rectangular cross-section parameters within HydroDyn. If the answer is yes, how could I do this?

So far, my attempts to manually modify the MHK_RM1_Floating_HydroDyn.dat file to satisfy the new input requirements have not been successful. I would greatly appreciate any guidance on:

• Whether this example input file is really incompatible with OpenFAST v4.1.2;

• If and how specific additional parameters must be included in the HydroDyn file;

• Or if there is a recommended migration procedure for legacy examples to v4.x.

Thank you in advance for your time and assistance.

Kind regards,
Bryan L. Andrade

2 posts - 2 participants

Read full topic

I was just wondering whether it’s possible to scale the constraints in WEIS the way the objective is scaled? I was looking for something like a scaler/adder (or ref/ref0) from OpenMDAO in the analysis schema, but it doesn’t seem to be an option, @Daniel.Zalkind ?

Thanks,
Kasia

5 posts - 2 participants

Read full topic

I do not the reason that why teeter degree is going under 10 deg in condition of below certain TeetSSSp in openFAST.

---------------------- ROTOR-TEETER --------------------------------------------

1E+7 TeetSSSp - Rotor-teeter soft-stop linear-spring constant (N-m/rad) [used only for 2 blades and when TeetMod=1]
1.0401E+10 TeetHSSp - Rotor-teeter hard-stop linear-spring constant (N-m/rad) [used only for 2 blades and when TeetMod=1]

This is a part of my teeter file. I want to figure out a minimum value of SSSp. Because, firstable, i don’t consider about fatigue now. I just only want to see the decrease of load at the blade root and tower base. I calculated the c and k values by referencing other papers and used a value of about 2E+8. For reference, the model I’m using is the 22 MW turbine model. When I used that SSSp value, the loads in the x-direction at the two previously mentioned locations did not decrease; instead, they actually increased. I expected that enabling the teeter function would reduce the loads, but they did not decrease at all. Therefore, while I was trying to reduce the k value slightly, I found a strange result. When I set k below 1E+7, the OpenFAST simulation showed the teeter angle dropping rapidly to −11deg and failing to recover. Why does this happen?

Thank you for reading.

Best regards,

Jihan Kim

9 posts - 2 participants

Read full topic

Hope you are doing well.

I wanna ask you whether NREL has made a comparsion between steady Blade Element Momentum Theory (BEMT) and the unsteady one focusing on the difference of aerodynamic loads?

In other terms, if i use steady BEMT instead of the unsteady one, am i doing a big mistake ?

Best Regards,

Riad

2 posts - 2 participants

Read full topic

I´m currently using Modes.exe to obtain Blade Mode Shapes for my Blade files. The linear mass of my first section (x=0, blade root) has decreased, so I changed that value and proceeded to obtain the modes again. Then, I realized that modifying the linear mass density at the first blade station (x = 0.0, start of the flexible portion) produces no change in computed mode shapes or natural frequencies, even with unrealistically large values.

This behavior is independent of the Rigid beam length setting: I varied Rigid beam length over a wide range and the result is the same (mass at x=0 does not affect the solution).

In contrast, changing mass density at the second station (x > 0) or changing Flap and Edge Stiffnesses in the first section (x=0) does affect the results as expected. Having seen this, my question is as follows:

• Is the x=0 station treated as a clamped node such that its mass contribution is effectively excluded from the eigenproblem?
  • If one wants to represent root mass change, is the recommended approach to distribute it over a short span with x > 0?

Thank you once again for your time and kind regards,

Kepa

2 posts - 2 participants

Read full topic

From OpenFAST readthedocs (Section 4.2.3.19.2. Blade Data Input File):

“BlTwist specifies the local aerodynamic twist angle (in degrees) of the airfoil; it is the orientation of the local chord about the vector normal to the plane of the airfoil, positive to feather, leading edge upwind; the blade-pitch angle will be added to the local twist;”

Is “vector normal to the plane of the airfoil” referring to the blade’s rotational axis/pitching axis (defined at z_b in AeroDyn driver section)? If so, is this angle referenced from the rotor plane to the local chord line? Additionally, is the blade twist angle defined about the blade root or tip? For example, in Hansen’s Aerodynamics of Wind Turbines and Manwell’s Wind Energy Explained, blade pitch angle and twist angle are defined with respect to the tip chord.

Additionally, at the end of Section 4.2.3.19.2, the documentation references a figure specifically for twist. I’m not sure if it’s a typo, but shouldn’t theta (local pitch) = pitch angle + twist in this figure?

Thank you so much for your help and response,

Megan Andersen

4 posts - 2 participants

Read full topic