Thanks a lot @Rafael.Mudafort , for the very useful information.
I already had -DBUILD_TYPE=RELEASE (as ccmake shows now) which sounds like the most suitable for me.
I’ve just read about -march and -mtune. I’m running FAST.Farm in a cluster with different nodes (with different types of Intel CPU’s). For now, all nodes are able to run FAST.Farm with similar performance. Therefore, maybe it’s the best to keep the compilation as it is now 
Best regards,
Dear Jason,
I use FAST.Farm with Mod_AmbWind=2 option, and generate the ambient wind using Turbsim (for NREL 5 MW turbines).
As I understand, it is recommanded to use “the high-resolution discretization values” for inflow wind generation (e.g. DS_high=5 m and DT_high=0.3 s) so I set the Turbsim input file accordingly. That means, for my wind farm with 340 m GridHeight & 1000 m GridWidth, Turbsim grid is 69 x 201.
For such a grid, Turbsim generation takes quite long time. It’s been 4 days and still calculating the u-component (certainly enough RAM is available, so that’s no bottleneck; and AnalysisTime = 600 s).
Therefore, I wanted to double-check: Is there anything that I missunderstood regarding the settings ?
Best regards,
Dear @Salur.Basbug,
This is the problem with the Mod_AmbWind = 2 option of FAST.Farm–it takes a long time to generate highly resolved synthetic wind data from TurbSim for large domains. As such, I would recommend to instead use the Mod_AmbWind = 3 option of FAST.Farm, which requires that you run TurbSim separately for the low- and high-resolution domains. With this approach, the synthetic wind data can be generated from TurbSim much more efficiently. See the “Modeling Guidance” section of the online FAST.Farm User’s Guide and Theory Manual for more information: 4.2.15.6. Modeling Guidance — OpenFAST v3.3.0 documentation.
Best regards,
Thanks a lot @Jason.Jonkman. I will check about the Mod_AmbWind = 3.
And maybe in the future, we will have a parallelized Turbsim
Best regards,
Hello everyone, I’d like to share an observation that could be interesting for others as well.
I used FAST.Farm to determine the wake trajectory of a 5 MW NREL turbine with 30 deg. yaw (8 m/s wind & TI= 10 % via Turbsim), as seen in the first figure below (wake deflection vs downstream distance). Since the flow is turbulent, I averaged 1 hour simulation data, which started after a 20 min ramp-up period (for the initial wake development).
To make sure that 20 min is enough (or too much), I prepared the second figure below. In the 2nd figure, every point is an average of 1 h data, starting at different points of time. It seems like 15 min of ramp-up time would be needed, in order to get a fully developed wake, before one starts to evaluate statistics.
As a final note, when I increased the input value of f_c (cutoff frequency of the low-pass time-filter, default = 0.0007) the required ramp-up time decreases drastically. 3 or 4 min ramp-up would be sufficient, with f_c = 0.07 or 0.007, respectively. The time-averaged wake position and its standard deviation are affected very little (probably negligible).
Regards,
Dear @Salur.Basbug,
Thanks for sharing your observation.
In the development of our new curled wake model implementation in FAST.Farm applicable to skewed flow, we found that our previous calibration of f_c was not correct. We now suggest using an f_c that is consistent with the typical time scales used in dynamic inflow models, which is likely 200-300 times higher than the original DEFAULT for the NREL 5-MW baseline turbine. This will be documented in an upcoming publication and updated release of FAST.Farm.
Best regards,
Thanks for info @Jason.Jonkman, I’ll adjust f_c as you said, and looking forward to the new release with the curled wake.
In case you’ll also update the theory guide, it seems like there is a typo (wrong superscript) you may fix. In section “6.2.4 Wake Dynamics”, right after equation 6.5, there is a sentence:
“Equations 6.4 and 6.5 apply directly to the WD module inputs …DiskAvg_Vx_Rel… The associated states are… FiltDiskAvg_Vx_Wind… respectively (each for 0 =< np =< Np -1)”
If I understand correctly, Vx_Rel in the first sentence should have been Vx_wind.
Moreover, I have a question regarding the AWAE module. As equations 6.30 & 6.31 indicate, the parameters DiskAvg_Vx_Wind and TI_amb are calculated using the undisturbed ambient wind. Wouldn’t be more realistic to use the disturbed wind for the calculation (ideally from hi-res domain) ? Especially for a turbine right behind another one, the TI should be quite affected, right ?
Best regards,
Dear @Salur.Basbug,
Thanks for the note regarding the typo in the FAST.Farm User’s Guide and Theory Manual. I agree with your correction; we’ll get this fixed in a future update.
The variables computed by the equations you reference are used in the calculation of the eddy viscosity within the Wake Dynamics (WD) module of FAST.Farm. By DWM convention, the eddy viscosity is calculated based on separate contributions from the ambient turbulence and the wake shear layer, with the aforementioned variables used by the former. The separation of ambient and wake contributions would be lost if the waked inflow was used here, but I see your point as well. The calculation of eddy viscosity is one area where improvements to DWM in general, and FAST.Farm specifically, are warranted.
Best regards,
Thank you for the clarification @Jason.Jonkman. I understand there’s room for improvement to DWM in general regarding the eddy viscosity.
I’ve also seen the item: “Incorporate wake-added turbulence” in the list of “Future Work”, which will provide yet another contribution to the eddy viscosity. I expect that will improve the results significantly for the low ambient turbulence conditions.
But also I guess this and the curled wake model will require a new calibration study, so probably lots of work to do there.
Already the average wake deflection trajectory obtained with FAST.Farm agrees well with other studies. I have plotted FAST.Farm result on the top of the others (the red line) under 30 degrees yaw. The original plot is from the paper “Wake Structure of Wind Turbines in Yaw under Uniform Inflow (2016. Howland et al)”
Best regards,
Dear @Salur.Basbug,
Indeed, those (curled wake and wake added turbulence) are the two FAST.Farm improvements that we are currently working on. The curled wake release is nearly complete (you can track the progress here: Implementation of the curled-wake model in FAST.Farm by ebranlard · Pull Request #931 · OpenFAST/openfast · GitHub) and the wake-added turbulence improvement is forthcoming.
Best regards,
Thanks a lot @Jason.Jonkman, I’ll follow the improvements and excited to use the updated version.
Best regards,
Hi my friends
Does anyone know the specific steps to install and use FAST.Farm under linux (ubuntu)? I installed openfast using conda as instructed at 2. Installing OpenFAST — OpenFAST v3.3.0 documentation and did cmake/make and finally make FAST.Farm. But I still don’t know how to use the software, maybe someone has experience using it under linux? I didn’t find useful information from youtube or other sites. If possible, I hope to get a more detailed tutorial or experience, very grateful.
Best regards,
Dear @Jundong.Wang,
See the online FAST.Farm documentation on readthedocs: 4.2.15.3. Running FAST.Farm — OpenFAST v3.3.0 documentation.
Best regards,
Thanks for your reply @Jason.Jonkman .It seems that i have already compiled FAST.Farm , I’m new to linux, so I don’t know how to define that the compilation is successful, but I found that there is a FAST.Farm (type: application/x-sharedlib) under build/glue-codes/fast-farm, which means I have compiled success right?
Another thing I want to ask is, do I just need to migrate the input files and settings that have been prepared under Windows to Linux, and then I can start running Farm? Hope someone with experience can answer my doubts.
Sorry to ask such a naive question.
Best regards,
I believe your input files from Windows will work all the same in Linux. You can put them in a folder, open a terminal there and type the address of the executable and the name of FAST.Farm input file, and press enter such as:
(full adress)…/build/glue-codes/fast-farm/FAST.Farm my_input.fstf
To copy the full address: You can go to the folder where the executable is and type pwd on the terminal (and press enter) and get the adress, e.g. if I do that I get:
/home/salur/simulation/openfast_3.1_sp/build/glue-codes/fast-farm
I hope that helps.
Thanks for your kindest help @Salur.Basbug
I will try it !
Best regards,
Dear @Jason.Jonkman ，
We know that the governing equations of the dynamic wake model are (6.19) and (6.20), while the continuity equation in the cylindrical coordinate system is (1). Therefore, the dynamic wake model assumes that the third term of equation (1) is 0. This will cause the results in Y and Z directions to be much smaller than the experimental results. Is there any relevant correction formula to make up for the speed loss in this regard?
Hi @YuMing_Yuan,
The third term of equation (1) is zero in FAST.Farm as you said (i.e. no derivatives in azimuthal direction), and it calculates the wake parameters as azimuthally averaged quantities. In other words, the wake is symmetric around the wake centerline (that is perpendicular to the wake plane). Note that wake planes are not parallel to the Y-Z plane when there’s the turbine tilt or yaw but they are always parallel to the rotor disk (assuming rotor yaw angle has not changed since the wake plane is created).
I guess the only way to compare experimental results to FAST.Farm is to average the measurement data also in azimuthal direction within the wake plane (and of course average everything in time to remove the turbulent fluctuations). This is how I understand it but let’s see how Jason would like to comment
Best regards,
Dear @YuMing_Yuan, and @Salur.Basbug,
I agree with @Salur.Basbug’s comments. The third term of (1) is zero for an axisymmetric solution, which FAST.Farm’s polar wake model assumes. There is no loss in accuracy to drop this term if the wake is in fact axisymmetric. If the wake is not axisymmetric, e.g. in the case of inflow skewed relative to the rotor axis, then some inaccuracies are expected.
Please note that we are introducing another wake modeling option in FAST.Farm that does not make use of axisymmetric assumptions–that is, we are introducing the curled wake model applicable to skewed flow conditions. This model is implemented in Cartesian rather than polar coordinates. You can find the curled wake pull request here: Implementation of the curled-wake model in FAST.Farm by ebranlard · Pull Request #931 · OpenFAST/openfast · GitHub, which will be merged once a couple improvements are made and the associated Wind Energy journal publication summarizing the development, implementation, and initial verification/validation of the curled wake model has been accepted for publication.
Best regards,
Hi my friends
I encountered a non-convergence problem when I used the newly generated wind data file for simulation. Compared with the fstf that was not error-free before, I modified the size of N*_High (the previous setting was 2m). Can someone provide Any suggestions?
--- AMBIENT WIND: INFLOWWIND MODULE --- [used only for Mod_AmbWind=2]
2.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.3333333 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]
60 NY_Low Number of low -resolution spatial nodes in Y direction for wind data interpolation (-) [>=2]
17 NZ_Low Number of low -resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
0.0 X0_Low Origin of low -resolution spatial nodes in X direction for wind data interpolation (m)
-450.0 Y0_Low Origin of low -resolution spatial nodes in Y direction for wind data interpolation (m)
0.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]
21 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]
17 NZ_High Number of high-resolution spatial nodes in Z direction for wind data interpolation (-) [>=2]
"AmbWind/14m-006.dat" InflowFile Name of file containing InflowWind module input parameters (quoted string)
--- WIND TURBINES ---
1 NumTurbines Number of wind turbines (-) [>=1] [last 6 columns used only for Mod_AmbWind=2]
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)
1000.0 0.0 0.0 "OpenFAST/5MW_Land_DLL_WTurb_T1.fst" 935.0 -70.5 0.0 10.0 10.0 10.0
the error message is :
Farm_Initialize:Farm_ValidateInput:OutFmt produces a column width of 10 instead of 20 characters.
Time: 0 of 1800 seconds.
T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_AdvanceStates:SrvD_UpdateStates:DLL_contro
ller_call:BladedInterface option was designed for an explicit-loose coupling scheme. Using last
calculated values from DLL on all subsequent calls until time is advanced. Warning will not be
displayed again.
FAST_Solution:FAST_AdvanceStates:B2:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after
the maximum number of iterations