Hello,
I am using FAST v8.15, compiled using gfortran for Unix, to simulate the NREL 5MW wind turbine under a variety of wind conditions generated using IECWind. I am using “FAST Certification Test #18” (5MW onshore setup) as a reference and the only parameters I am changing, aside from some output parameters, are the parameters used to specify different .wnd files. Of the 32 cases I am simulating, all seem to work fine except for two: “ECD-R-2.0” and “ECD+R-2.0”. In those cases, this is the output I am getting from FAST:
Timestep: 5 of 60 seconds. Estimated final completion at 08:57:49.
Timestep: 10 of 60 seconds. Estimated final completion at 08:57:48.
Timestep: 15 of 60 seconds. Estimated final completion at 08:57:48.
Timestep: 20 of 60 seconds. Estimated final completion at 08:57:48.
Timestep: 25 of 60 seconds. Estimated final completion at 08:57:50.
Timestep: 30 of 60 seconds. Estimated final completion at 08:57:49.
Timestep: 35 of 60 seconds. Estimated final completion at 08:57:48.
Timestep: 40 of 60 seconds. Estimated final completion at 08:57:49. Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 5, Blade = 3
Timestep: 45 of 60 seconds. Estimated final completion at 08:57:49. Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 5, Blade = 2
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 6, Blade = 2
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 5, Blade = 1
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 6, Blade = 1
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 6, Blade = 3
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 7, Blade = 3
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 18, Blade = 1
Warning: Turning off Unsteady Aerodynamics due to high angle-of-attack. BladeNode = 17, Blade = 1
Timestep: 50 of 60 seconds. Estimated final completion at 08:57:49.
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:AD_CalcOutput:BEMT_CalcOutput(node 19,
blade 1):Compute_UA_AirfoilCoefs:UA_CalcOutput:Mach number exceeds 1.0. Equations cannot be
evaluated.
FAST encountered an error at simulation time 50.019 of 60 seconds.
Simulation error level: FATAL ERROR
Aborting FAST.
Because it states that the “mach number exceeds 1.0”, which sounded much like the “supersonic” issues I’ve read about elsewhere on the forum, I assumed the issue could be simple numerical instability. I’ve tried time steps as low as DT = 0.006s, however, and I get the same error (at approximately the same time–50s or so). What seems odd to me–though I could obviously be missing something–is that I have no trouble with the cases “ECD-R+2.0” and “ECD+R+2.0”.
Can anybody provide guidance about which parameters I should look into adjusting to avoid this error? I assume that the “Turning off Unsteady Aerodynamics” warning is not a problem since it occurs with the inflow transient and a high angle-of-attack is to be expected, but I guess I could see that being a related factor here.
Thanks in advance for any help that anybody can provide.
Best,
Austin Herrema
Dear Austin,
The error “Mach number exceeds 1.0. Equations cannot be evaluated” is an error triggered by the unsteady airfoil aerodynamics (UA) routines of AeroDyn v15. Because the ECD cases involves large inflow skew, I’m curious if the problem with your simulation is more related to problems with the BEMT solution rather than the UA solution e.g. see: AeroDyn v15 convergence issues - #7 by Jason.Jonkman. I suggest that you first see if the solution is reasonable for these cases when UA is disabled (AFAeroMod = 1).
Best regards,
Dear Dr. Jonkman,
Thank you for your response and suggestions. I plan on doing a bit more experimentation along the lines of what is done in the related topic that you linked. That said, I thought it would already be worth sharing that it seems that you were correct about the problem being related to the BEMT solution. Here is the output using AFAeroMod = 1:
[code] Timestep: 5 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 10 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 15 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 20 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 25 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 30 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 35 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 40 of 60 seconds. Estimated final completion at 16:38:12.
Timestep: 45 of 60 seconds. Estimated final completion at 16:38:12.
FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 7, blade
1):BEMT_UnCoupledSolve:DeterminePhiBounds:There is no valid value of phi for these operating
conditions! Vx = -0.88453, Vy = 45.258, rlocal = 19.937, theta = 0.19465
FAST encountered an error at simulation time 49.456 of 60 seconds.
Simulation error level: FATAL ERROR
Aborting FAST.[/code]
So it appears the issue is similar to the linked topic, a negative relative wind speed, Vx. I will explore if anything strange is going on in the structural simulation to cause this issue and will post again if I discover anything of use.
Best,
Austin
Dear Dr. Jonkman,
I’ve spent some more time experimenting with this problem. From what I can tell (mostly looking at out-of-plane tip deflection), the structural simulation seems to be behaving reasonably for the majority of the simulation, regardless of time step size. That said, comparing the disturbed wind speed, BαNβVDisx, and the structural speed, BαNβSTVx, as suggested in [url]AeroDyn v15 convergence issues - #7 by Jason.Jonkman] (since Vx = BαNβVDisx - BαNβSTVx) reveals some interesting behavior around the time of simulation failure. Here, I plot those two values at the 7th node (the problematic node) on blade 1 for both the problematic wind case (ECD-R-2.0, in green) and a non-problematic–but somewhat similar–case (ECD-R+2.0, in orange).
Clearly, the structural speed undergoes a sudden and significant change just before the failure. If that slope were to to stay the same (or increase), I can definitely imagine that Vx would equal zero for the next time step. This still seems a bit like numerical instability to me, but decreasing time step size doesn’t solve the problem.
Let me know if you have any additional thoughts or suggestions of what to try. I’m tempted to use AeroDyn v14 at this point since it apparently experiences this problem less for whatever reason, but I’d really like really prefer to use the most recent version if at all possible!
Thank you,
Austin
Dear Austin,
I would expect that the time step set for Test18 should be sufficient. My guess is the problem is not the result of too large a time step, but a problem in the aerodynamic BEMT solution at large inflow-skew angles. Are the results you’re showing without UA (AFAeroMod = 1)? How large is the inflow-skew angle (AeroDyn v15 output RtSkew) at the time of simulation failure? Do you get more reasonable solution when the Pitt/Peters skewed-wake correction model is disabled (SkewMod = 1)?
Best regards,
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: FAST v8 AeroDyn v15 convergence problems for low-speed, high-turbulence - #2 by Jason.Jonkman, 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
