Simulation of 15MW FOWT failing due to spike in Rotor RPM


I am running a floating wind turbine model in OpenFast v3.4.1 on a Windows 10 x64 machine. The floating hull is our own design and the turbine and all associated files are for the IEA 15-240-RWT (downloaded from here: IEA-15-240-RWT/OpenFAST at master · IEAWindTask37/IEA-15-240-RWT · GitHub). Only the formatting of the turbine files has been modified as necessary to work in the newest version of OpenFast.

The rotor speed has a sharp change and increases very rapidly at ~11.5seconds (I have uploaded a plot of the rotor RPM). This obviously results in the simulation aborting as the values are non-physical. It is not clear to me why this would happen when reviewing all output parameters.

I have tried changing various parameters to test their influence, for example:

  1. Changing from a constant wind to a full field wind with turbulence from Turbsim.
  2. Turning off all wave induced motions (WaveMod = 0).
  3. Setting AFAeroMod=1 and WakeMod=1.

I have also downloaded and run all the files on v3.1.0 of OpenFast (making all necessary formatting changes to the files to get them to run). No matter what is changed it still shows the same behavior with the rotor RPM between 11 and 12 seconds of the simulation. The specific error messages are typically along the following:

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(): 11.125 s

The BEM solution is being turned off due to low TSR. (TSR = 1.6773). 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 30, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx =5.4802, Vy = -401.83, rlocal = 73.077, theta = 9.10045E-02, geometric phi = 3.128. This warning will not be repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Solution:FAST_AdvanceStates:SolveOption2c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_FF Wind_CalcOutput [position=(612.25, -1181.3, 462.38) in wind-file coordinates]: Error: FF wind array was exhausted at 11.25 seconds (trying to access data at -34.975 seconds).

OpenFAST encountered an error at simulation time 11.238 of 20 seconds.

Simulation error level: FATAL ERROR

Dear @Bart.Grasso,

You mention changing several things like OpenFAST version, wind, waves, and aero settings. Presumably these changes are having sizeable effects on the system response. But in all cases, the rotor still overspeeds after 11 s? That sounds a bit odd.

It sounds like your model is numerically or physically unstable after 11 s, resulting in the rotor overspeed and unrealistically large blade deflection. Does dropping the time step influence the behavior, which would imply that the instability is numerically related?

I would also recommend simplifying the model to debug. The rotor likely can’t overspeed if you disable the influence of the controller by setting GenDOF = False in ElastoDyn. I would also assess if other the instability is tied to other structural DOFs (such as the rigid-body DOFs of the floater (platform) in ElastoDyn. Is the instability tied to a specific ElastoDyn DOF?

Best regards,


Thanks for the quick reply. I have run the simulation with GenDOF = False. The rotor speed remains constant as you note. However, the rotor loads torque/thrust still continue to spike. See the below graph.

Looking at all other parameters, I don’t see any other odd behavior. The mooring loads are reasonable, and the changes to vessel DOFs are gradual per the below.

Previous analyses were run with a time step of 0.0125 seconds. Running the simulation with a time step of 0.001 seconds continues to give the same behavior.

I am still at a loss as to why this behavior is occurring. Any other suggestions would be greatly appreciated.

Best Regards,

Dear @Bart.Grasso,

With the GenDOF disabled and the rotor thrust still spiking, is there a particularly large deflection in some component such as blade flapwise or edgewise, tower fore-aft or side-side, or platform surge, sway, roll, or yaw? (I don’t see a large response in heave or pitch.)? Can you isolate the problem to a specific structural DOF?

What aerodynamic settings are you using?

Best regards,