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

Dear Dr. Jonkman,

You are correct that the previous results I showed were without UA. Disabling the Pitt/Peters skewed-wake correction model did indeed allow the simulation to compute fully with seemingly reasonable results, so that’s great! I’ve shown the inflow-skew angle as well as Vx at the previously problematic node for both SkewMod = 1 and SkewMod = 2 for reference. These values, at least, seem to be comparable between the two cases before failure. The skew angle goes to a maximum of a bit under 80 degrees.


I’ll have to do a bit of reading to understand the implications of using a different skewed-wake correction model. Feel free to let me know if you think there is anything I should be aware of in that regard! (I’m using these simulations to extract loads for FEM blade design and analysis.) Overall, though, I’m happy to have the simulation running at this point. Thanks for your thorough support!

Best,
Austin

Dear Austin,

The Pitt and Peters skewed-wake model of AeroDyn v15 (SkewMod = 2) works well for small to moderate inflow-skew angles, but is invalid for large skew angles (much greater than 45 degrees). This is mentioned in section 6.4 of the draft AeroDyn v15 User’s Guide and Theory Manual: wind.nrel.gov/nwtc/docs/AeroDyn_Manual.pdf. From your plot, it looks like the inflow-skew angle exceeds 70 degrees; I recommend disabling the Pitt and Peters skewed-wake model at these extreme inflow-skew angles.

Best regards,

Dear Jason,

I’ve noticed the same issue for power production calculations with turbulent wind with high turbulences (e.g. for rated wind speed) without yaw error/direction change. I’ve solved the problem like Austin has done, but isn’t it poor to disable wake and unsteady aerodynamics in AeroDyn v15 under these conditions?
How valid is the model with these restrictions?

Thank you again.

Best regards,
René

Dear René,

I thought Austin was able to solve his problem not by disabling the wake or unsteady airfoil aerodynamics calculations, but by disabling the skewed-wake correction. Does that not solve your problem?

Best regards,

Dear Jason,

No, this wasn’t sufficient because the problem with negative wind-speed Vx occured. I know that I have to use AeroDyn v14 when this error occures, but I tried to avoid this.

Best regards,
René

Dear René,

As first reported here: http://forums.nrel.gov/t/fast-v8-aerodyn-v15-convergence-problems-for-low-speed-high-turbulence/1532/2, working in collaboration with Envision Energy, we have found the algorithmic problem causing the convergence issues in AeroDyn v15.00 - v15.03 when Vx goes negative. While we have not yet publicly released an update to FAST with this version of AeroDyn, you can find AeroDyn v15.04 with this issue resolved here: nwtc.nrel.gov/AeroDyn. With this fix, you don’t need to use AeroDyn v14 when Vx goes negative.

Bets regards,

Dear Jason,

I know that AeroDyn v15.04 is released but how can I use the new version of AeroDyn with FAST v8.16?

Thank you for your support.

Best regards,
René

Dear René,

You must recompile FAST by replacing the AeroDyn source files with the newest ones.

Best regards,

Dear Jason,

Thank you for your answer. This was the way I’ve tried it, but the source code was missing in the windows archive from nwtc.nrel.gov/AeroDyn.

Best regards,
René

Dear René,

Oops! We had meant to add a link to the source code on github, but I don’t see that we did that. Regardless, you can find the newest AeroDyn source code here: github.com/OpenFAST/openfast/tr … erodyn/src.

Best regards,

Dear Jason,

I have had the same problem as Austin with the Mach number, I have change AFAeroMod to 1 and solve that problem. Then, I couldn’t solve the problem with negative wind-speed Vx disabling the wake or unsteady airfoil aerodynamics calculation. So I decide to solve it with AeroDyn V14.

To use AeroDyn V14 I just need to change CompAero to 1 on the .fst file, Am I correct?

When I try to simulate with that change I have this error:

FAST_InitializeAll:ED_Init:ED_ReadInput:ReadBladeInputs:ReadBladeMeshFileAD:Invalid numerical input for file "C:\Users\raul_\code\openfast\reg_tests\r-test\glue-codes\openfast\S_124bis\NRELOffshrBsline5MW_OC 3Hywind_AeroDyn15.dat" occurred while trying to read Blade element line1.

How can I solve it? The main objetive is to simulate with AeroDyn14 to avoid the negative wind-speed Vx. Is it necessary to change anyhing else apart from the CompAero in the .fst?

Best regards,
Raúl.

Dear Raul,

Which version of FAST / OpenFAST are you using? As discussed above, there are two solutions:
(1) If you are using FAST v8.16, upgrade from AeroDyn v15.03 to AeroDyn v15.04 (or newer). If you are using OpenFAST, AeroDyn should already be updated.
(2) Switching to AeroDyn v14. However, the AeroDyn input files are very different between AeroDyn v14 and AeroDyn v15. So, when you change CompAero to 1, you must also switch to the AeroDyn v14 input file format. There are sample AeroDyn v14 input files for the NREL 5-MW baseline turbine in the archives of both FAST v8 and OpenFAST.

Best regards,

Dear Jason,

Thanks for your quick response.

I’m using OpenFAST-v2.4.0. Thast’s why I don’t understand all this errors. I ve reading in this foro the errors have been solutioned in newest version. So I don’t understand why I am having them. This error may ocurr due to the desviation of the wind with the rotor (45 degrees aprox.).

I am simulating with SkewMod = 1 and AFAeroMod=1, as yo recomended in this post.

Best regards,
Raúl.

Dear Raúl,

Can you share a copy of the command window, including error, when you run OpenFAST v2.4 with AeroDyn v15? I need to see the exact error you are receiving.

Best regards,

Dear Jason,

This is the error when I try to simulate with AFAeroMod=2 and SkewMod=2:

[code]FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:AD_CalcOutput:BEMT_CalcOutput(node 16,
blade 2):Compute_UA_AirfoilCoefs:UA_CalcOutput:Mach number exceeds 1.0. Equations cannot be
evaluated.
CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in
GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.

FAST encountered an error at simulation time 123.62 of 300 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.
[/code]

The problem with the GetSmllRotAngs() are larger than 0.4 radians, start before the simulation stop in every step time.

This is the error with AFAeroMod=1 and SkewMod=2 or SkewMod=1, it doesn’t change:

FAST_Solution:FAST_AdvanceStates:SolveOption2c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_Un
iformWind_CalcOutput:GetWindSpeed:Height must not be negative. Error calculating the wind speed
at position (43122, -34986, -61939) in the wind-file coordinates

 FAST encountered an error at simulation time 123.8 of 300 seconds.
 Simulation error level: FATAL ERROR

 Aborting OpenFAST.

The problem with the GetSmllRotAngs() are larger than 0.4 radians, start before the simulation stop in every step time in this simulation too.

Best regards,
Raúl

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,

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

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,

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

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,