Thanks again for the great work on FASTv812, we are already looking forward to the next release!
Myself and a student of mine are having issues with the convergence in AeroDyn v15.
We have run a number of simulations with both ElastoDyn and BeamDyn, but the simulations with turbulent windfields (TurbSim), which produce the following error:
“FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UnCoupledSolve:DeterminePhiBounds:There is
no valid value of phi for these operating conditions! psi = -1.8325, Vx = -4.0579, Vy = 37.139,
rlocal = 28.136, theta = 0.13636”
(The values psi, vx,vy etc are different every time the crash occurs)
There is of course a number of issues which could be occuring here, but we have done our best to eliminate sources of error.
The problem appears to occur whenever we use the Pitt-Peters wake model (BEMT=1, SkewMod /=1), particularly at small time steps or low wind velocities.
We have inspected the source code (particularly BEMT:TestRegion), but have thus far not found where exactly the problem could be coming from. Is there perhaps
a condition hard-coded into the BEMT module somewhere for low wind speeds which is causing the issues?
There is nothing in AeroDyn hard-coded for low wind speeds.
A negative Vx is a bit odd. Does the structural solution look satisfactory up until the point of failure, or is there perhaps a numerical instability whereby the structural motions become very large?
Occasionally the structural appears to fail (small rotation assumption invalid error), but this is generally the exception.
The structural (along with aerodynamic) outputs appear to be quite stable (albeit even if the simulation only runs for a few seconds).
We have inspected the IP, OOP tip deflections, generator power, rot speed, pitch angles, and have trialled deactivating a number of DOF’s.
Switching back to Aerodyn14 completely eliminates the error and the simulation runs without problem to the end. We also focussed first on the -ve Vx, but found no reason for it…
If we find any other error sources, we will update.
I was wondering whether there was any update related to the post of Joseph above ?
I am running into a similar problem when simulating a 660 kW wind turbine using FAST 8.15 with Aerodyn v15. In some very specific cases (Class A turbulent wind with 5 m/s average), I often get an error of the type:
The values quoted in the error message can change, but Vx is always somewhere between say -0.15 and -0.0001 m/s. I tried deactivating structural vibrations of the blades and tower with no success. Could you please tell me which variables to track in order to find why Vx < 0 m/s ? I looked at variables such as B3N11Vundx, B3N11VDisx, B3N11VRel, but could not identify which one leads to the error message.
I hadn’t heard from Joe and Arved since their last post on Mar 24, 2016, so, I had assumed there problem was related to numerical instability that they managed to solve.
Do you run into this problem when the blades are modeled with ElastoDyn, BeamDyn, or both?
The Vx in the error message is the relative wind speed (wind speed minus structural speed) at the AeroDyn blade analysis node, not including the influence of induction. While this speed is not directly an output of AeroDyn, it can be calculated with existing outputs i.e.
Vx = BαNβVDisx - BαNβSTVx
for node β of blade α. Note that the disturbed wind speed, BαNβVDisx, is used here in place of the undisturbed wind speed, BαNβVUndx (the former includes the influence of the tower disturbance on the wind, if enabled).
I am modelling the blades with ElastoDyn only - I have no experience of BeamDyn.
I have been tracking the variables that you suggested for the blade node that issued an error. It seems that the x-disturbed wind speed at the blade node of interest is getting too close to zero, and so the difference between the disturbed speed and the structural speed is negative (see figure below).
Is there a way to prevent this from happening ? My wind input is a full-field file generated with TurbSim, class A turbulence with 5m/s average.
So, are you saying that you get the “no valid value of phi” error when Vx goes negative e.g. at time = 140 s for the case you’ve plotted? Does this happen often? My guess is this would happen less frequently at higher mean wind speeds or lower turbulence levels–is this what you’ve seen?
Yes exactly, this is when I get the error. I run a large set of tests at different wind speeds in the context of a fatigue analysis. The error occurred in most of the cases with a 5m/s average and class A turbulence, and some cases with a 7m/s average and class A turbulence.
It rarely happened for higher wind speeds, or lower turbulence, as you guessed.
OK, it is good to know what is triggering the error. But I doubt this issue will be easy to solve. The AeroDyn source code already has logic to prevent the code from throwing an error for the case where Vx equals zero; perhaps the tolerance around zero needs to be expanded? I’ll report this as a known issue, but I can’t promise an immediate solution.
I have a problem when using AD15.ipt instead of AD.ipt as the AeroDyn inputs.
I ran the FAST Test04 example after changing the inputs “AeroFile” and “CompAero” in the Test04.fst file into “AWT27/Test04_AD15.ipt” and “2” {2=AeroDyn v15}, I got the following errors:
It appears that we forgot to update the AeroDyn v15 input file for Test04, when converting from AeroDyn v15.02 to v15.03 in FAST v8.16. To resolve this error, simply add the following line after line for input TwrAero:
I tried to enlarge the grid size to even GridHeight=80.0 and GridWidth=100.0 in the file of 42m_12mps.inp, and then run by using Turbsim v1.06.00. However, the resulting new 42m_12mps.wnd file still cannot resolve the above error. Do you know the possible reason?
Looking at the AWT27/Test04_AD15.ipt file, I see that the downwind tower shadow model is enabled (TwrShadow = True), with tower analysis nodes starting at ground level (TwrElev = 0). To run this model, you must use wind with data starting at the ground level.
I agree that you won’t receive an error regarding “no valid value of phi” if you switch from CompAero = 2 (AeroDyn v15) to CompAero = 1 (AeroDyn v14). To avoid the issue with CompAero = 2 will require you to recompile with the newer version of AeroDyn v15, as discussed in my previous post above.
I don’t know why your Linux compilation does not allow CompAero = 2.
The error you are receiving from ElastoDyn is caused because you’ve changed to CompAero = 1, but you didn’t change the format of the AeroDyn primary input file to that compatible with AeroDyn v14.
I am facing the AeroDyn v.15 convergence issue for Vx value <0. I understand it has been corrected in AeroDyn v15.04. How do I get the FAST version I am using (v8.16.00a) to run with AeroDyn v15.04, instead of v15?
I don’t have a compiled Windows executable of FAST v8 linked with AeroDyn v15.04. However, I suggest that you simply upgrade to OpenFAST v1.0.0, which includes the AeroDyn v15.04 changes, as well as a few other more minor improvements to the FAST source code relative to v8.16. You can read about the changes and download a 64-bit Windows executable of OpenFAST v1.0.0 here: nwtc.nrel.gov/OpenFAST.
