Dear Jonkman,
I fixed the issue by rolling back the Fast.farm version to 3.4.1.
Thank you!
Sincerely,
Dong Zhiyan
Dear Dr. Jonkman,
As you advised, I tried to output wake slices of wind turbines by enabling OutAllPlanes.
In spite of activating yaw control of upstream wind turbine, the curled shape of velocity fields were not observed.
However, in low-resolution box visualization, the deflected wake of WT1 is observed.
Is it helpful for the issue of high-resolution box visualization?
For the detail, I attached wake slices of two turbines where the WT1 is yawed 30 degrees and low-resolution box.
Sincerely,
Wonsuk Han.
Dear @Wonsuk.Han,
Which wake plane are you showing for T1–is it the one closest to the rotor? I would suggest setting k_VortexDecay to 0.0 to see if that helps.
FYI: I still see signs of a numerical instability in the wake calculation of T2.
Best regards,
Dear all,
Can anyone share the N3 inflow wind generated by sowfa carried by FAST.Farm at the beginning?
Best Regards，
Dear @Jundong.Wang,
I believe you are referring to the FAST.Farm model with SOWFA-generated inflow available through my Google Drive: Neutral_8mps_3WT_Short.zip - Google Drive.
Best regards,
Dear Dr. Jonkman and members,
I am using FAST.Farm with version of 3.4.1 to calculate the load of a wind farm. The wind speed is 5 m/s and the turbulence intensity is 15%. However, I encountered the following problem in my calculation.
`Time: 171 of 800 seconds. Estimated final completion at 15:12:16.
T6:FARM_UpdateStates:WD_UpdateStates:ThomasAlgorithm:Tridiagonal matrix is not diagonally
dominant, i.e., abs(b(i)) <= ( abs(a(i))+abs(c(i)) ). Try reducing the FAST.Farm timestep.
Aborting FAST.Farm.`
The Turbsim .inp file and .fstf file are shown in the following figure.
I am looking forward to your reply.
Thank you.
Best regards,
Dear @Yuxuan.Chen,
Are you seeing anything unexpected in the wind turbine or wake response up until this error is generated?
I suggest trying a few things:
- Upgrading from FAST.Farm within OpenFAST 3.4.1 to the newest version of the software, currently within OpenFAST v3.5.3.
- Reducing the time step (
DT_Low) as suggested in the error. - Reducing the cutoff (corner) frequency of the low pass filter (
f_c) in FAST.Farm.
Best regards,
Dear @Jason.Jonkman,
I reduced the cutoff (corner) frequency of the low pass filter (f_c) in Fast.Farm. This time Fast.Farm terminated normally. Thank you for sparing your valuable time to answer my confusion.
Best regards,
1 Like
Dear Dr. Jonkman,
I could see curled shape velocity field in wake slice setting k_VortexDecay to 0.0.
It was set to 0.1 to follow your work’ A time-varying formulation of the curled wake model within the FAST.Farm framework’ in Wind Energy. I still do not know why curled wake is not shown in the 0.1 setting.
And I have one more question. Now I am working on dynamic yaw control by using UserYawCont with sinusoidal move. In low-resolution vtk, the wake meandering looks unstable to me. Is it derived from the numerical instability in wake calculation? (Still no wake generation in high-resolution vtk files.)
Best regards,
Wonsuk Han.
Dear @Wonsuk.Han,
Regarding k_VortexDecay, the cross-flow velocities used in the curled wake model will dissipate with downstream distance when k_VortexDecay > 0, and the higher the value, the faster the curled wake shape will dissipate.
Regarding the odd visualization of your wake, I would guess this is related to the relationship between the cut-off frequency (f_c) you selected and the frequency at which your yaw angle is varying sinusoidally; f_c could filter out the sinusoidal motion if it is set too low. Also, the low-resolution time step (DT_Low) impacts how resolved or coarse the wake is computed.
Best regards,
1 Like
Dear@Jason.Jonkman,
I am using fast.farm to perform a load calculation for two 10MW wind turbine string, in order to verify the accuracy of the wake model, I set the inflow wind turbulence to 0, but the calculation results are very strange, it seems that the wake of the first turbine completely covers the wake of the second turbine instead of superimposing it, I don’t know exactly what causes such a result
Here is the input file.
------- FAST.Farm for OpenFAST INPUT FILE -------------------------------------------------
FAST.Farm input - file, using two turbines separated by 3D downstream and an offset of 30m, with a turbulent inflow given by one turbsim box
— SIMULATION CONTROL —
False Echo - Echo input data to .ech? (flag)
FATAL AbortLevel - Error level when simulation should abort (string) {“WARNING”, “SEVERE”, “FATAL”}
630 TMax - Total run time (s) [>=0.0]
False UseSC - Use a super controller? (flag)
2 Mod_AmbWind - Ambient wind model (-) (switch) {1: high-fidelity precursor in VTK format, 2: one InflowWind module, 3: multiple instances of InflowWind module}
2 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]
2 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]
2 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]
201 NX_Low - Number of low -resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
93 NY_Low - Number of low -resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
24 NZ_Low - Number of low -resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
-121.0 X0_Low - Origin of low -resolution spatial nodes in X direction for wind data interpolation (m)
-600.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)
13.945 dX_Low - Spacing of low -resolution spatial nodes in X direction for wind data interpolation (m) [>0.0]
12.903 dY_Low - Spacing of low -resolution spatial nodes in Y direction for wind data interpolation (m) [>0.0]
12.083 dZ_Low - Spacing of low -resolution spatial nodes in Z direction for wind data interpolation (m) [>0.0]
16 NX_High - Number of high-resolution spatial nodes in X direction for wind data interpolation (-) [>=2]
17 NY_High - Number of high-resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
19 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 (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 0 “FFTest_WT1.fst” -1.07054700e+02 -1.10677400e+02 5 1.39453000e+01 1.29032000e+01 1.20833000e+01
1246 0 0 “FFTest_WT2.fst” 1.13407390e+03 -1.10677400e+02 5 1.39453000e+01 1.29032000e+01 1.20833000e+01
— WAKE DYNAMICS —
2 Mod_Wake - Switch between wake formulations {1:Polar, 2:Curl, 3:Cartesian} (-) (switch)
8 dr - Radial increment of radial finite-difference grid (m) [>0.0]
40 NumRadii - Number of radii in the radial finite-difference grid (-) [>=2]
762 NumPlanes - Number of wake planes (-) [>=2]
Sincerely,
Dong Zhiyan
Dear @Zhiyan.Dong,
I’m not sure I understand what your question is. Also, what is different between the two visualizations you shared? What you are seeing that you do not expect to see or what you are not seeing that you expect to see?
Best regards,
Dear Jonkman
I’m sorry I didn’t express it clearly, the spacing between these two turbines is fixed 7D, the biggest problem is that I can’t see the wake effect of the second turbine on the XY plane velocity contour, the wake effect of the two turbine is normal at 100s, and at 200s, the wake of the second turbine under the influence of the wake of the first turbine looks not superimposed but be covered, you can see that the velocity defict of the second turbine is reduced, and by 300s, the wake effect of the second unit is completely invisible
T=100s
T=200s
T=300s
Thanks for the quick reply!
Hi @Zhiyan.Dong , asking for curiosity:
Did you check the power & thrust of the 2nd turbine at t=300s and onwards ?
If the wake of the 1st turbine is very strong , 2nd turbine will receive a very low wind speed, hence very low thrust & power… Therefore, it may even fall below cut-in speed, I’m just speculating here, but may help you solve the issue 
Dear @Zhiyan.Dong,
I agree with @Salur.Basbug’s observation. It appears that at 300 s, the near wake of the 2nd turbine appears to be very weak, leaving only the far wake of the 2nd turbine visible, which is a residual from earlier in the simulation when the 2nd turbine had higher thrust.
Best regards,
