Hi everyone,
I am trying to use standalone AeroDyn to simulate multi-rotor HAWT. The simulations teminated normally with wakeMod as BEM type but some error occured when I tried to model it with OLAF model. The errors are displayed below.
“ADI_ADIW_Solve:ADI_CalcOutput_IW:InflowWind_CalcOutput:CalculateOutput:IfW_FlowField_GetVelAcc:Grid3DField_GetCell: G3D wind array boundaries violated. Grid too small in Z direction (Z=165.07 m is above grid.)”
The inflow is set as a FF turbulence wind and the same file for OLAF model as that for BEM model. The highest grid in inflow is set as 85+160/2=165m according to my set-up. Thus, the 165.07m is indeed outside my wind field, but my question is why this happen? In BEM model, this wind inflow is feasible.
My wake pannels and regularization parameters are set accoring to the recommendations in online documentation of OpenFAST.
Dear @TianCheng.Yao,
In BEM, the aerodynamic analysis nodes where inflow wind data is needed all lie on the rotor and tower. In OLAF, there are also aerodynamic analysis nodes in the wake where inflow wind data is needed, so, the grids may need to be larger when running OLAF versus BEM.
Best regards,
Dear @Jason.Jonkman ,
Thanks for your reply! But the GridHeight in the current .inp file (160m) is close to the maximum restricted by the HubHt (85m), where GridHeight must be set smaller than twice of HubHt to make al points of the grid above ground level. Besides, the rotor radius is 65m in my research, which is much smaller than the half of the current GridHeight.
I will increase the GridHeight to a value close to the thresold like 168m and try it again.
Btw, I want to confirm if I can keep the RefHt as the real hub height as 85m and increase the parameter HubHt to a lager value like 100m so that GridHeight can be increased to like 190m to generate the wind field I required?
Best regards,
Dear @TianCheng.Yao,
I would first try keeping HubHt physically correct and increasing GridHeight to its maximum possible value (limited by HubHt).
If that is not large enough, you could set HubHt higher than is physically correct; we often do this when using TurbSim to generate inflow for use in FAST.Farm. But this approach is subject to the limitations discussed in the following OpenFAST issue that has not been resolved yet: Decouple Hub Height from Grid in TurbSim · Issue #199 · OpenFAST/openfast · GitHub.
Best regards,
Dear @Jason.Jonkman ,
I want to simulate two NREL 5 MW wind turbine models using FAST.Farm. I set up the FAST.Farm model with a computational domain of X_low = 16.7D, Y_low = 16.5D, and Z_low = 2.7D. For the two-turbine model, I allocated high-resolution dimensions of 1.5D (x), 1.5D (y), and 1.3D (z). In order to maintain undisturbed wind speed upstream, I used X0_low = -1260, Y0_low = -1040, and Z0_low = 5.
This model works with the AeroDyn BEM model. However, it shows the following error when running the OLAF model. As this issue has been discussed in the forum, I tried changing HubHt and GridHeight multiple times but could not solve the problem. How can I solve this issue?
Thank you!
Best regards,
The error
FARM_InitialCO:AWAE_CalcOutput:LowResGridCalcOutput:The rotor plane for turbine 1 has left the
low-resolution domain (i.e., there are no points in the polar grid that lie within the
low-resolution domain).
Aborting FAST.Farm.
35 NumGrid_Z - Vertical grid-point matrix dimension
209 NumGrid_Y - Horizontal grid-point matrix dimension
0.1 TimeStep - Time step [seconds]
200 AnalysisTime - Length of analysis time series [seconds] (program will add time if necessary: AnalysisTime = MAX(AnalysisTime, UsableTime+GridWidth/MeanHHWS) )
“ALL” UsableTime - Usable length of output time series [seconds] (program will add GridWidth/MeanHHWS seconds unless UsableTime is “ALL”)
175 HubHt - Hub height [m] (should be > 0.5GridHeight)
345 GridHeight - Grid height [m]
2080 GridWidth - Grid width [m] (should be >= 2(RotorRadius+ShaftLength))
— AMBIENT WIND: INFLOWWIND MODULE — [used only for Mod_AmbWind=2 or 3]
3.0 DT_Low - Time step for low -resolution wind data interpolation; will be used as the global FAST.Farm time step (s) [>0.0]
0.1 DT_High - Time step for high-resolution wind data interpolation (s) [>0.0]
213 NX_Low - Number of low -resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
209 NY_Low - Number of low -resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
30 NZ_Low - Number of low -resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
-1260 X0_Low - Origin of low -resolution spatial nodes in X direction for wind data interpolation (m)
-1040 Y0_Low - Origin of low -resolution spatial nodes in Y direction for wind data interpolation (m)
5.0 Z0_Low - Origin of low -resolution spatial nodes in Z direction for wind data interpolation (m)
10.0 dX_Low - Spacing of low -resolution spatial nodes in X direction for wind data interpolation (m) [>0.0]
10.0 dY_Low - Spacing of low -resolution spatial nodes in Y direction for wind data interpolation (m) [>0.0]
10.0 dZ_Low - Spacing of low -resolution spatial nodes in Z direction for wind data interpolation (m) [>0.0]
39 NX_High - Number of high-resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
39 NY_High - Number of high-resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
33 NZ_High - Number of high-resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
“IW.dat” InflowFile - Name of file containing InflowWind module input parameters
— WIND TURBINES —
2 NumTurbines - Number of wind turbines (-) [>=1] [last 6 columns below used only for Mod_AmbWind=2 or 3]
WT_X WT_Y WT_Z WT_FASTInFile X0_High Y0_High Z0_High dX_High dY_High dZ_High
(m) (m) (m) (string) (m) (m) (m) (m) (m) (m)
0.0 0.0 0.0 “FFTest_WT1.fst” -94.5 -94.5 10.0 5 5 5
378.0 0.0 0.0 “FFTest_WT2.fst” 283.5 -94.5 10.0 5 5 5
Dear @Dereje.Haile,
I’m not exactly sure why enabling OLAF is triggering this specific error, but I would say that FAST.Farm has not yet been developed to effectively couple the OLAF free-vortex near-wake model with the far-wake model of FAST.Farm. This is an improvement we are planning to make in the future to improve the near-to-far wake transition (an improvement currently in the planning stages), but is not a feature that is available yet. For now, I would stick with BEM/DBEMT in AeroDyn for OpenFAST models within FAST.Farm.
Best regards,
Dear @Jason.Jonkman ,
Thank you very much. That helps a lot.
In OpenFAST and FAST.Farm v5.0.0, the AeroDyn input wake model does not include the DBEMT model. How can I add the DBEMT model to AeroDyn , or make the BEMT model perform as good as DBEMT so that DBEMT is no longer required in the OpenFAST or FAST.Farm model?
When I use the BEMT model, the model run only for 123 seconds and abort. How I can solve avoid issues causing the model to abort?
Best regards,
Running ElastoDyn.
Running InflowWind.
Running AeroDyn.
AeroDyn: projMod: 1
Projection: legacy (NoSweepPitchTwist), BEM: legacy (2D)
Running ServoDyn.
Running ServoDyn Interface for Bladed Controllers (using Intel Visual Fortran for Windows).
Using legacy Bladed DLL interface.
Time: 93 of 630 seconds. Estimated final completion at 15:42:10 (in 0.002 days).
The BEM solution is being turned off due to low TSR. (TSR = 1.9998). This warning will not be
Time: 123 of 630 seconds. Estimated final completion at 15:42:17 (in 0.002 days).
T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_UpdateStates:Solver_Step:FAST_UpdateStates
:AD_UpdateStates:BEMT_UpdateStates:UpdatePhi(node 10, blade 2):BEMT_UnCoupledSolve:There is no
valid value of phi for these operating conditions: Vx = 4.5997, Vy = -38.456, rlocal = 32.233,
theta = 0.11416, geometric phi = 3.0226. This warning will not be repeated though the condition
may persist. (See GeomPhi output channel.)
Time: 159 of 630 seconds. Estimated final completion at 15:42:25 (in 0.002 days).
T2:FARM_UpdateStates:WD_UpdateStates:NearWakeCorrection:Wake model is not valid in the
propeller-brake region, i.e., Ct > 2.0.
Aborting FAST.Farm.
Dear @Dereje.Haile,
DBEMT is available within AeroDyn in OpenFAST and FAST.Farm v5.0 by selecting DBEMT_Mod > 0 (line 42 in the AeroDyn input file).
Regarding your FAST.Farm error, I’m guessing the AeroDyn warning about “BEM [being] turned off due to low TSR” is eventually leading to the FAST.Farm error about “Ct > 2.0”. This warning and error suggest something is not physically correct in your OpenFAST model. I would guess the turbine you are simulating is not responding properly for some reason, e.g., due to an improper controller setting or initial condition, a model instability, or the like.
Best regards,