FAST.Farm

Dear @Jason.Jonkman

Thanks for your help!
I have thought about using wake visualization to obtain information about the position and diameter of the wake, but I am confused about the method of calculating the position and diameter of the wake center in FAST. Farm. I could use some assistance.

Best Regards,

Dear @Jundong.Wang,

To identify the time-varying wake meandering position of the wake center based on visualization output from FAST.Farm (or CFD), NREL developed the python-based SAMWHICH toolboxā€“see: SAMWICH Box: Simulated And Measured Wake Identification and CHaracterization Toolbox ā€” waketracking documentation.

Best regards,

Dear @Jason.Jonkman

Thanks for your help!

Best regards,

Dear everyone,

I wanted to try out Fast.farm and used it to simulate two NREL 5MW wind turbines. I found that the simulation result is only the .out file of Fast.farm, which does not contain the output of the OpenFAST sub-module (e.g. the aerodynamic power of the wind turbine from AeroDyn), and there was no separate .out file for OpenFAST. I wonder if the outputs requested in the individual submodules are invalidated when using Fast.farm simulation?

Thanks for any replies!

The model Iā€™m simulating is:

Dear @Yao.Tian,

When you run FAST.Farm, the OpenFAST model of each wind turbine will generate its own output file. In the example you share, it appears that each OpenFAST model has set OutFileFmt = 2, so, each OpenFAST model will generate a .outb (binary output) file.

Best regards,

Dear @Jason.Jonkman

Thanks for your help, and my question has been answered!

Best regards,

Dear Jason
I am modifying the TSinflow case based on the fastfarm example, and I want to replace the wind turbines inside with the OC4 semi-submersible wind turbines. After replacing them with the OC4 from the new version of r-test-main, I encounter an error and the calculation stops at 210 seconds. The error I encountered is shown in the following

T2:FARM_UpdateStates:NearWakeCorrection:Wake model is not valid in the propeller-brake region,
i.e., Ct > 2.0.

I noticed that you have previously answered similar questions.This error could be caused with the old near-wake correction model of FAST.Farm when running a wind turbine in a high thrust condition. In the most recent version of FAST.Farm available in the pull request (https://github.com/OpenFAST/openfast/pull/584), weā€™ve introduced an improved near-wake correction model that is valid for both low- and high thrust conditions.
But thereā€™s so much in the site I couldnā€™t find where to download the new version of fastfarm.

Best regards,
Tianhui.Liu

Dear @Tianhui.Liu,

Can you confirm which version of FAST.Farm are you running? The newest release of OpenFAST and FAST.Farm is v3.5.1 available here: Releases Ā· OpenFAST/openfast Ā· GitHub.

Regardless, the older version of the near-wake correction was only valid up to about Ct = 24/25. The newer near-wake correction model is valid up to Ct = 2.0. I would generally not expect Ct to exceed 2 in standard wind turbine applications. I would guess something else is not functioning properly in your FAST.Farm model that is resulting in such high Ct values that would trigger this error. But it is difficult to guess what that could be without more information.

Best regards,

Dear Jason
Thank you for your prompt response. I am quite certain that I am currently using version 3.5.1 of FAST.farm. The wind turbines I am using are the OC4 semi-submersible platform turbines, and all parameters are kept at their default values. However, I am using the default IW.dat file from FAST.farmā€™s TSinflow for the InflowFile, and for simplicity, I have set WindType to 1 and wind speed to 6 m/s.
Regarding the input files for FAST.farm, they are as follows:

--- SIMULATION CONTROL ---
False              Echo               - Echo input data to <RootName>.ech? (flag)
FATAL              AbortLevel         - Error level when simulation should abort (string) {"WARNING", "SEVERE", "FATAL"}
3000.0               TMax               - Total run time (s) [>=0.0]
False              UseSC              - Use a super controller? (flag)
3                  Mod_AmbWind        - Ambient wind model (-) (switch) {1: high-fidelity precursor in VTK format, 2: one InflowWind module, 3: multiple instances of InflowWind module}
1                  Mod_WaveField      - Wave field handling (-) (switch) {1: use individual HydroDyn inputs without adjustment, 2: adjust wave phases based on turbine offsets from farm origin}
0                  Mod_SharedMooring  - Shared mooring system model (switch) {0: None, 3=MoorDyn}}
--- SUPER CONTROLLER --- [used only for UseSC=True]
"unused"           SC_FileName        - Name/location of the dynamic library {.dll [Windows] or .so [Linux]} containing the Super Controller algorithms (quoated string)
--- SHARED MOORING SYSTEM --- [used only for Mod_SharedMoor>0]
""                 SharedMoorFile     - Name of file containing shared mooring system input parameters (quoted string) [used only when Mod_SharedMooring > 0]
0.04	           DT_Mooring         - Time step for farm-level mooring coupling with each turbine (s) [used only when Mod_SharedMooring > 0]
--- AMBIENT WIND: PRECURSOR IN VTK FORMAT --- [used only for Mod_AmbWind=1]
3.0                DT_Low-VTK         - Time step for low -resolution wind data input files; will be used as the global FAST.Farm time step (s) [>0.0]
0.1                DT_High-VTK        - Time step for high-resolution wind data input files (s) [>0.0]
"unused"           WindFilePath       - Path name to VTK wind data files from precursor (string)
False              ChkWndFiles        - Check all the ambient wind files for data consistency? (flag)
--- 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]
300                NX_Low             - Number  of low -resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
81                 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]
-100               X0_Low             - Origin  of low -resolution spatial nodes in X direction for wind data interpolation (m)
-400.0             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.17              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]
32                 NX_High            - Number  of high-resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
16                 NY_High            - Number  of high-resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
16                 NZ_High            - Number  of high-resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
"turbines/IW.dat"           InflowFile         - Name of file containing InflowWind module input parameters (quoted string)
--- 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  30.0    0.0    "turbines/5MW_OC4Semi_WSt_WavesWN1.fst"   -69.49   -50.0   5.0      10.17    10.0     10.0
1008   0.0    0.0    "turbines/5MW_OC4Semi_WSt_WavesWN2.fst"   938.00   -80.0   5.0      10.17    10.0     10.0

After I modified the spacing of the two semi-submersible fans, the current example can be successfully calculated after 3000s, but the following error occurs

T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:AD_CalcOutput:RotCalcOutput:BEMT_CalcOutput(node 5, blade
1):UA_CalcOutput:UA_BlendSteady:Temporarily turning off UA due to high angle of attack or low
relative velocity. This warning will not be repeated though the condition may persist.

The BEM solution is being turned off due to low TSR. (TSR = 1.9989). This warning will not be repeated.

FARM_CalcOutput:AWAE_CalcOutput:LowResGridCalcOutput:The center of wake plane #131 for turbine #2 has passed the upper-most X boundary of the low-resolution domain.ļ¼ˆIn fact several wake planes have experienced this problemļ¼‰

I would like to ask another question, which is related to calculating the wake of wind turbines. Typically, in high-fidelity simulations, there should be more high-resolution grid points downstream of the wind turbine compared to upstream. However, in the default cases provided by the official documentation, for the first wind turbine, the starting point of the high-resolution grid (in the x-direction) is -70m, the grid length is 5m, and the default number of grid points is 16. This means that the high-resolution grid spans from -70m to 10m. Since the wind turbine is located at 0m, does it mean that this high-resolution grid only captures the wake of the turbine from 0m to 10m downstream? Thi

Dear @Tianhui.Liu,

Regarding the results when you change the wind conditions and switch to floating, did you change initial conditions of each wind turbine to match? (We generally recommend that the initial rotor speed and initial blade-pitch angles be set based on their expected (mean) values for the mean hub-height wind speed you are simulating.) Also, because you have switched to a floating wind turbine, you may need to lower the value of FAST.Farm input f_c to ensure wake planes emanating from a turbine donā€™t overpass each other as a result of the floater motion, resulting in unphysical wake behavior. Weā€™ve also found that using the curled wake model provides better vertical wake deflection resulting from floater pitch than the default polar wake model. We are working on a paper that explains these and other topics relative to wake effects of floating offshore wind turbines that we expect to submit to the Wind Energy Science journal in January.

Regarding your second question, the high-resolution domains used by FAST.Farm are there to provide sufficient resolution of the disturbed inflow (ambient + wakes) around each wind turbine to ensure that the aero-elastic calculation in OpenFAST is accurate. The high-resolution domain does not directly impact the accuracy of the wake evolution. Instead, the wake evolution relies on the spatial-temporal resolution defined by FAST.Farm inputs DT_Low and dr.

Best regards,

Dear Jason,

When I used FAST.Farm for simulation I noticed that InflowFile has been set on both FAST.Farm main input file and FAST main input file. What will happen if inflow file of different types is taken? Which shall prevail?

Best regrads,

Yao Tian

Dear @Jundong.Wang,

How OpenFAST interprets the InflowWind input file when coupled within FAST.Farm is documented within the FAST.Farm documentation on readthedocs here: 4.2.15.4. Input Files ā€” OpenFAST v3.5.1 documentation.

Best regards,

Dear @Jason.Jonkman

Thanks for your help!

Best regards,

Dear everyone,

I wanted to examine the effect of yaw angle on wind turbine power output, so I simulated two turbines in FAST.Farm. I set a fixed nacelle-yaw angle only for the upstream turbineļ¼ˆ0Ā°ļ¼Œ10Ā°ļ¼Œ20Ā°ļ¼Œ30Ā°ļ¼‰, with a wind speed of 9m/s. The simulation results showed that the power output of the upstream turbine decreased when the yaw angle was set, while the power output of the downstream turbine increased. However, the total power output of the wind farm decreased as the yaw angle increased. Contrary to some literature, which suggests that the total power output of the wind farm increases with an increase in yaw angle. Is this phenomenon normal?

Best regards,
Yuxuan.Chen

Yes, Iā€™d say your results are normal.

whether the total power output of the wind farm decreases or increases depends on many factors, for example the turbulence intensity or the distance between turbines. Also, if you add a 3rd or 4th turbine in your setup (in a row), that may change the overall conclusion.

BR
Salur

Dear @Yuxuan.Chen,

I generally agree with @Salur.Basbugā€™s response.

You havenā€™t stated which wake model in FAST.Farm you are using (polar or curl). Iā€™ll just add that from our experience, the curled wake model of FAST.Farm (Mod_Wake = 2) predicts more realistic responses for cases with skewed flow between the wind and rotor, e.g., for situations with intentional wake steering.

In case you were not already aware, we recently submitted a paper to the Wind Energy Science journal were we systematically look at the influence of positive/negative wake steering and wind direction on the power output and structural loads of a five-turbine wind farm using FAST.Farm: https://wes.copernicus.org/preprints/wes-2024-6/ (currently undergoing peer review).

Best regards,

Dear @Salur.Basbug

Thanks for your prompt response! I agree with your opinion.

Best regards,

Dear @Jason.Jonkman

Thanks for your help! Much sorry for not stating it clearly. The wake model I am using is polar (Mod_Wake = 1). I will attempt to use the curled wake model of FAST.Farm (Mod_Wake = 2) for the calculations.

By the way, I also have a question about the wind load at the rotor. In fast.farm, two wind turbines are set up (with a fixed yaw angle for the upstream turbine). To consider the wind load at the rotor for the upstream turbine, the rotor thrust(RotThrust) is decomposed into forces in the x and y directions(RotThrustcosĪ³, RotThrustsinĪ³ -Ī³ is the nacelle-yaw angle). For the downstream turbine which is affected by the skewed flow, the original rotor thrust(since the yaw angle of the downstream turbine is 0Ā°, the rotor thrust is along the x-axis) is considered. Is there something wrong with this approach? Does the downstream turbine experience wind load in the y-axis direction?

Best regards,

Dear Jason,

I conducted a simulation using two aligned turbines (NREL 5MW) separated by 7D. The curled wake model (Mod_Wake= 2) is used in FAST.Farm. The version of FAST.Farm is 3.5.2. However, I have encountered the following issues.

errorļ¼š
Time: 156 of 630 seconds. Estimated final completion at 10:41:41.
Warning: SkewedWakeCorrection encountered a large value of chi (179.64 deg), so the yaw
correction will be limited. This warning will not be repeated though the condition may persist.
See the AD15 chi output channels, and consider turning off the Pitt/Peters skew model (set
SkewMod=1) if this condition persists.

The BEM solution is being turned off due to low TSR. (TSR = -1.90915E-04). This warning will not
be repeated though the condition may persist. (See GeomPhi output channel.)

T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:SolveOption2c_Inp2AD_SrvD:In
flowWind_CalcOutput:CalculateOutput:IfW_FlowField_GetVelAcc:Grid4DField_GetVel:Outside the grid
bounds.
FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 5, blade
1):UA_UpdateStates:UA_UpdateDiscOtherState:ComputeKelvinChain:Mach number exceeds 1.0. Equations
cannot be evaluated.

Aborting FAST.Farm.

Here is the link to my folder. https://drive.google.com/drive/folders/1PHi844OPw__N9Rlej-4UMliA9eVBbO6x?usp=sharing Could you help me take a look and identify any issues?

Best regards,

Dear @Yuxuan.Chen,

I would say that aerodynamic loads on the rotor can include transverse forces and bending moments regardless of whether the rotor is skewed or not, but that thrust along the shaft and torque about the shaft are typically the dominant of the 6 load components (3 forces, 3 moments).

Regarding your error, Iā€™m not sure. When looking at your OpenFAST time series, the big problem I see is that the wind input to both wind turbines is the same until the wake of T1 impinges on T2, resulting in differences in the response of T2. This suggests something incorrect in the inflow set up. Regardless, the error you are reporting seems to indicate that the model has gone numerically unstable, but I donā€™t see that in the time series you have shared. To solve that, I would suggest disabling features of OpenFAST, such as structural degrees of freedom, to better isolate the problem.

Best regards,