FAST v8 "Mach number exceeds 1.0" for some wind cases

Jason.Jonkman · June 10, 2021, 4:39pm

Dear Raúl,

Well, it looks like your model has gone unstable in the platform. The exact error that aborts the simulation (whether it be high Mach number or a node passing the boundaries of the TurbSim grid) is determined by which features you’ve enabled in the model, but is probably irrelevant. It is the instability in the platform that needs to be fixed.

It appears that you are running a simulation of an offshore wind turbine. Is it fixed or floating? Are you running a model NREL has provided or one you made yourself? Does the model run stably in the absence of wind or wave excitation?

Best regards,

Gustavo.Hylander · October 15, 2021, 7:27am

Dear Dr Jonkman,
Thank for activating my account, and please allow me to continue the thread initiated by my colleague Raúl.

yes indeed, we are simulating custom floating wind platforms.

We are using a custom OpenFAST implementation

For the controller we are currently using ROSCO, developed by (I presume) your colleagues Nikhar Abbas, Daniel Zalkind, Alan Wright, Paul Fleming, and Rafael Mudafort.

I’m unsure if this is caused by the model itself, openFAST or the controller, I’ve opened an issue in the ROSCO repo too, to try and locate why this error arises.

The models exhibit stable and coherent responses under steady state, as well as the decay tests we performed

Jason.Jonkman · October 15, 2021, 12:17pm

Dear Gustavo,

Well, I would suggest simplifying the model to debug.

If the problem is controller related, I would expect the model to run well if you disable the generator degree of freedom in ElastoDyn (GenDOF = False). Does it, or does setting GenDOF = False still result in large floater / platform motions?

Best regards,

Gustavo.Hylander · October 18, 2021, 10:10am

Dear Dr. Jonkman,
I ran a simulation with GenDOF = False, but there were no changes (I would say the Mach > 0,3 and = 1.0 errors happened even sooner than with it set to True).

I suppose this means it’s not a controller problem. This is already helpful because it mean I can focus work on the model itself rather than trying to fix multiple things at the same time.

Thanks and regards

Jason.Jonkman · October 18, 2021, 12:37pm

Dear Gustavo,

Indeed, it is always going to isolate the issue. Perhaps you can further isolate the issue to a single or few DOFs?

Best regards,

Shubham.Baisthakur · November 2, 2021, 4:17pm

Hello Jason,
I am trying to simulate the Design Load Cases (DLC) for the IEA-15MW reference wind turbine. I have generated the wind files (.wnd) to simulate the required inflow conditions using the IECWind module. I am passing these files to the turbine model as a uniform wind file, WindType = 2 in Inflowfile. I initially got the “Mach number exceeds 1.0. The theory is invalid.” error, following which I have changed the parameters AFAeroMod and SkewMod to 1. Now I am getting the following error:

Is this the right approach to analyse various DLCs? What do you think might be causing this error?

Thanking you,
Shubham

Jason.Jonkman · November 2, 2021, 5:51pm

Dear Shubham,

Well, it looks like your model has gone unstable quite quickly, resulting in unrealistically high blade motion. Can you clarify what changes you made to the OpenFAST input file other than AFAeroMod, SkewMod, and WindType?

Best regards,

Shubham.Baisthakur · November 3, 2021, 6:23pm

Hello Jason,
Thanks for your reply. In the earlier case, I made quite a few changes that I couldn’t track, so I started the analysis again with original input files without any modifications. With these files, the following is the error I am receiving for Extreme Operating Gust (EOGO) case generated using IECWind.

Note: All the cases with direction change (ECD) are executed successfully.

Thanks,
Shubham

Jason.Jonkman · November 3, 2021, 7:01pm

Dear Shubham,

What time in the simulation are applying the EOG? Your model is experiencing large blade deflection within the first second of simulation; normally I’d expect that you’d apply the EOG after all simulation start-up transients have ended. Does the model work as expected if you apply the EOG at 60-s in such that steady wind is used beforehand?

Best regards,

Shubham.Baisthakur · November 4, 2021, 12:20pm

Hello Jason,
The Gust is applied after 60 seconds, and the maximum wind speed occurs at 65.25 seconds. I am attaching the .wnd file for your reference.

Thanks,
Shubham
EOGI_IECWind.txt (9.37 KB)

Jason.Jonkman · November 4, 2021, 12:29pm

Dear Shubham,

OK, then the issue you are facing has nothing to do with the EOG at all because your model goes unstable while using steady wind before the EOG. Have you changed the simulation time step (DT)? Are the initial conditions you’ve set for blade-pitch and rotor speed consistent with the mean wind speed (3 m/s) you are simulating?

Best regards,

Shubham.Baisthakur · November 4, 2021, 6:58pm

Hello Jason,
I overlooked the rotor speed; setting the rotor speed corresponding to 3m/s wind speed solved the error.

Thanks for your help,
Shubham

Jian.Zhang · November 18, 2022, 7:27pm

Dear Dr. Jonkman,

I encountered the same problem with the OC3 Spar platform under wave characteristics of Hs=3.75m and Tp=6.50s and turbulent wind with a reference wind speed of 12.0m/s and TI=8%. Different from the simulations here, I employed the FAST.Farm to finish the calculation, including the wake-meandering effect. The blade pitch and torque speed are set below:

          0   BlPitch(1)  - Blade 1 initial pitch (degrees)
          0   BlPitch(2)  - Blade 2 initial pitch (degrees)
          0   BlPitch(3)  - Blade 3 initial pitch (degrees) [unused for 2 blades]
          0   TeetDefl    - Initial or fixed teeter angle (degrees) [unused for 3 blades]
          0   Azimuth     - Initial azimuth angle for blade 1 (degrees)
       12.1   RotSpeed    - Initial or fixed rotor speed (rpm)

When AFAeroMod=2 and SkewMod=2, the warning information is:

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:Rot
CalcOutput:BEMT_CalcOutput(node 15, blade 1):UA_CalcOutput:Mach number exceeds 0.3. Theory is
invalid. This warning will not be repeated though the condition may persist.
 Time: 95 of 4000 seconds.  Estimated final completion at 01:18:03.

T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateS
tates:UpdatePhi(node 16, blade 3):BEMT_UnCoupledSolve:There is no valid value of phi for these
operating conditions: Vx = 0.39827, Vy = -35.182, rlocal = 56.124, theta = -1.5349, geometric phi
= 3.1303. This warning will not be repeated though the condition may persist. (See GeomPhi output
channel.)
 Time: 97 of 4000 seconds.  Estimated final completion at 01:43:59.
The BEM solution is being turned off due to low TSR.  (TSR = 1.8361). This warning will not be
 Time: 98 of 4000 seconds.  Estimated final completion at 01:43:59.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateS
tates:UpdatePhi(node 5, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these
operating conditions: Vx = 15.39, Vy = -1.2619, rlocal = 11.73, theta = 0.7657, geometric phi =
1.6526. This warning will not be repeated though the condition may persist. (See GeomPhi output
channel.)
 Time: 115 of 4000 seconds.  Estimated final completion at 03:04:38.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:Rot
CalcOutput:BEMT_CalcOutput(node 16, blade 3):**UA_CalcOutput:Mach number exceeds 1.0**. Equations
cannot be evaluated.

When AFAeroMod=2 and SkewMod=1

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateS
tates:UpdatePhi(node 5, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these
operating conditions: Vx = 12.782, Vy = -1.169, rlocal = 11.724, theta = 0.98488, geometric phi =
1.662. This warning will not be repeated though the condition may persist. (See GeomPhi output
channel.)
T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateS
tates:UpdatePhi(node 18, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these
operating conditions: Vx = 1.9063, Vy = -27.249, rlocal = 61.546, theta = 0.75118, geometric phi
= 3.0717. This warning will not be repeated though the condition may persist. (See GeomPhi output
channel.)
 Time: 123 of 4000 seconds.  Estimated final completion at 17:14:21.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeri
v: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(): 123.18 s
FWrap_Increment:FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:RotCalcOutput:BEMT_CalcO
utput(node 17, blade 1):UA_CalcOutput:**Mach number exceeds 1.0**. Equations cannot be evaluated.

When AFAeroMod=1 and SkewMod=1

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateS
tates:UpdatePhi(node 16, blade 2):BEMT_UnCoupledSolve:There is no valid value of phi for these
operating conditions: Vx = 7.4405, Vy = -83.447, rlocal = 56.134, theta = 0.5481, geometric phi =
3.0527. This warning will not be repeated though the condition may persist. (See GeomPhi output
channel.)
 Time: 102 of 4000 seconds.  Estimated final completion at 05:21:26.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeri
v: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(): 102.24 s
 Time: 104 of 4000 seconds.  Estimated final completion at 05:52:54.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:SetDisturbed
Inflow:TwrInfl:getLocalTowerProps:Tower strike.

The cases worked well under the reference wind tubine of 4m/s, but something wrong happened under the 12.0m, mainly for WT1.
Could you give more suggestions? Many thanks

Best regards,

Jason.Jonkman · November 18, 2022, 8:01pm

Dear @Jian.Zhang,

If the problem happens with T1, which presumably is the most upwind turbine in the wind farm, you should be able to mimic the issue in standalone OpenFAST, uncoupled from FAST.Farm. I would start there to debug. Is the wind turbine response physically correct before the error is triggered?

Best regards,

Jian.Zhang · November 19, 2022, 12:22am

Dear @Jason.Jonkman

Thank you for your response. I checked the .fstf file and found the same “WT_FASTInFile” for WT1 and WT2 triggered this error; now it works well. Many thanks.

Best regards,

PoChuan.Mao · August 11, 2023, 6:09pm

Dear @Jason.Jonkman
Recently, I’ve encountered the same issue while simulating the 15MW floating turbine using OpenFAST v3.3.0. I’ve tested AFAeroMod = 1, SkewMod = 1, and configured the initial rotor speed to match the wind speed, but the error persists. The model I utilized was extracted from the IEA 15MW Git-hub repository, with modifications made to the inflow condition, wave condition, and mooring settings. The inflow condition was generated by Turbsim with a mean speed of 16.9m/s and propagated from -140 degree. The following is the error message. Could you please assist me with resolving this problem?

Best regards,

Jason.Jonkman · August 11, 2023, 6:43pm

Dear @PoChuan.Mao,

It looks like you are receiving this error 200-s into the simulation. Is the simulation proceeding as expected until this time? Given the large negative wind direction, are you counteracting this with a large positive nacelle-yaw angle to minimize the nacelle-yaw error? It sounds like you initialized the rotor speed, but did you also initialize the blade-pitch angle appropriate for a mean hub-height wind speed of 16.9 m/s?

Best regards,

PoChuan.Mao · August 13, 2023, 6:16am

Dear @Jason.Jonkman

Thank you for your help. After adjusting the initial nacelle-yaw angle, the error has been resolved.

Best regards,