Thanks for your reply. The yaw angle convention is the same between the paper I referenced and the FAST.Farm results, where a negative yaw for the front turbine (T1) is the clockwise direction and a positive yaw is in the counterclockwise direction. The wake centerline was not mentioned in the paper I referenced, but we will try extracting it by repeating the same simulation case in SOWFA as you suggested.
I look forward to the new version of FAST.Farm with the new curled wake model. It would be a great pleasure to improve the results of FAST.Farm together or test the new version if I could. Thank you very much again!
I am also a PhD student in ULB, Brussels. I am also working on wake steering methods for wind farm power maximization. Your post interested me a lot as I got similar plots with the same simulations done on FAST.Farm. But in my case, I took a constant wind speed of 8m/s (without turbulence as in your fig.1), and a simulation time of 1500s to be sure that we are in the permanent part. Plotting the wind turbines power and the wind farm power, I actually have a power surplus for C_Meander=1.9 (DEFAULT) (at yaws =+/-30°), as you can see in the plot below.
Maybe the difference comes from turbulent wind? Did you take an average of the power in this case?
The super controller in FAST.Farm provides a way for the user to develop a master farm-level controller that can interact with the individual turbine-level controllers. The super controller can receive signals from, and send signals to, the individual turbine-level controllers. The super controller example provided in my post dated Mar 18, 2021 above sends simple nacelle-yaw commands to the individual turbine-level controllers, but this is just an example to explain how the super controller functions. The super controller is really a placeholder for users to implement there own wind farm control logic.
For more information on the super controller example and links to its online documentation, see my post dated Sep 20, 2021 above.
FYI: While you can specify steady, uniform wind in FAST.Farm, the main strength of FAST.Farm is its dynamics modeling capability for the calculation of structural loads, including the modeling of turbulent inflow, wake meandering and merging. In steady, uniform wind, the wakes will not meander and the FAST.Farm response will naturally lead to a steady-state solution after all start-up transients die out. If you are seeking the steady-state response, simpler steady-state tools like FLORIS would be easier and less computationally to use. The main advantage of running FAST.Farm is to impose turbulent inflow and calculate more than just steady-state behavior.
In my turbulent case, I took an average of the power during last 400-s in the 600-s simulation. For the case without turbulence, it seems to need more time for downstream wake to be relatively steady. I guess the difference might be brought from turbulence.
I am trying to simulate wind farm with 16 wind turbines. But I can not simulate it due to the next error.
Heading of the FAST.Farm input file:
Sample FAST.Farm input file
Farm_Initialize:Farm_ReadPrimaryFile:Invalid numerical input for file
"C:\Users\....\TSinflow.fstf" occurred while trying to read C_HWkDfl_xY.
Aborting FAST.Farm.
I don’t undertand it beacuse it’s values is DEFAULT. How can I solve it?
Thanks
I would guess a line was accidentally added or removed from your FAST.Farm input file. As with any input file processing error, I suggest enabling the Echo option to debug.
Dear Jason:
when DT_low was set to 3s and DT_high was set to 0.1s in FAST.farm, DT_low was set to 0.00625s in FAST, I ran FAST.farm without any trouble. Now, I modified these values to 0.05s, 0.01s and 0.00625s, the following problem occurred at 128 seconds in several wind speeds. Inputfile is TSinflow.fstf, I might have overlooked something, how can I solve it? Thanks.
Can you clarify which version of FAST.Farm you are using? Are you using the precompiled Windows version of FAST.Farm from the main branch of OpenFAST v3.0 or something else?
Also, I’m not sure why you’d want to change the DT_Low and DT_High time steps as you propose, which are much smaller than recommended. Guidance for choosing these time steps is provided in the FAST.Farm documentation: openfast.readthedocs.io/en/main … retization.
I would call it a mid-fidelity engineering model. The wake of each individual wind turbine is solved in a CFD-type way (based on simplified continuity and momentum equations, i.e., the thin shear-layer approximation of Navier-Stokes equations with an eddy viscosity model), but the meandering and farm-level effects are solved based on simple engineering models (passive tracer for meandering and superposition for wake merging).
I have learned from this post and the FAST . Farm User ’ s Guide and Theory Manual that the inflow file of fast.farm is independent of the inflow file used by openfast and some parameters of which is overwritten by inflow file used in fast.farm. But there are still some questions that confused me a lot:
From my perspective, the inflow profiles of downstream WTs are determined by the wake of upstream WTs or the mixture of wake flow and ambient flow. So why still need an independent inflow file for openfast?
If it is necessary, how should I set the Meteorological Boundary Conditions to generate inflow file for individual openfast? Is it ok just to set them the same as in the counterpart for fast.farm? or there is a guideline for generating inflow file for openfast when running fast.farm.
To generate the inflow file for fast.farm, it is hard to keep the HubHt in Turbine/Model Specifications as realistic (for example, 90m for 5MW Baseline) since the GridHeight is expected to be higher than twice of hubht in fast.farm. I notice that the HubHt in TestCase.inp is 141 and GridHeight is 280, does it mean the HubHt can actually be larger than the real hub height?
Are you referring to the InflowWind input file that is referenced within the OpenFAST model of each individual wind turbine in the FAST.Farm model (OpenFAST input parameter InflowFile), or the InflowWind input file referenced directly in FAST.Farm (FAST.Farm input parameter InflowFile) with Mod_AmbWind = 2 or 3? These InflowWind files function quite differently. The InflowWind input file that is referenced within the OpenFAST model of each individual wind turbine in the FAST.Farm model is not used to specify inflow because WindType is ignored; the actual inflow used is passed to the OpenFAST model through FAST.Farm and includes ambient wind plus wakes. Instead, this file can be used to identify wind outputs that are tracked by that OpenFAST model. The InflowWind input file referenced directly in FAST.Farm with Mod_AmbWind = 2 or 3 is used to specify the ambient wind used by FAST.Farm for both the low- and high-resolution domains.
For guidance on generating ambient wind inflow for FAST.Farm, please see the Modeling Guidance chapter of the FAST.Farm User’s Guide and Theory Manual: openfast.readthedocs.io/en/main … dance.html. The issue you mention regarding the HubHt specified in TurbSim is discussed in the TurbSim subsection of this document.
Only one thing I am not quite sure that Wwat is the mean of “this file can be used to identify wind outputs that are tracked by that OpenFAST model.”? Does it mean that the inflowWind input file used in openfast can output wind velocity at point WindList(1)? If it is true, are the coordinates in the inertial X,Y,Z direction the local coordinate or global one?
Another question is the FAST. Farm User ’ s Guide and Theory Manual recommend that full-field wind data files be generated periodically. But may I ask how can I periodically generate the wind data file? which parameter should I set to which value?
Yes, by that I meant that you can use the InflowWind write outputs (specified at locations in the WindList) via the settings in the InflowWind input file that is referenced within the OpenFAST model of each individual wind turbine in the FAST.Farm model. All inputs in the OpenFAST models are in the coordinate system local to that wind turbine. This coordinate system is aligned with the FAST.Farm coordinate system, but offset by the wind turbine location specified in the FAST.Farm input file (via inputs WT_X,WT_Y,WT_Z). So, the global coordinates of a WindList location specified in the InflowWind input file of an OpenFAST model would be:
WT_X+WindVxiList
WT_Y+WindVyiList
WT_Z+WindVziList
In TurbSim, periodic wind data can be generated by setting UsableTime = “ALL”. See the TurbSim documentation for more information: nrel.gov/wind/nwtc/assets/d … _v2.00.pdf.
I am using Python notebooks provided in github.com/OpenFAST/python-tool … T/fastfarm to set up my new inflow and fast.farm cases. But I find that the GridHeight and GridWidth in .inp file is not consistent with Z_dist and Y_dist in .fsts file.
Also, the obtained GridHeight is 420.000 m when I use 5MW Baseline (D=126 m and HubHt=90 m).
May I ask whether the above situations are abnormal? And how to solve them?
I have another question now. I think I have set the NumPlanes to a reasonable value (pls see in attachment) but the executable shows the fatal error below:
Heading of the FAST.Farm input file:
Sample FAST.Farm input file
Farm_Initialize:Farm_ReadPrimaryFile:Invalid numerical input for file “TestCase_mod.fstf”
occurred while trying to read NumPlanes.
Aborting FAST.Farm.
I tried to set the value of NumPlane to 200 but it still didn’t work. Did I make something wrong in other places?
I’ve asked Kelsey Shaler to respond regarding your issue with the Python notebooks.
Regarding your input file processing error, as with any such error, I recommend enabling the Echo option to debug. But from my quick look, it appears that the header line between the wind turbines table and the wake dynamics inputs is missing.
I have set WrDisWind = True but got some trouble when using Paraview to show both the full 3D low-and high-resolution disturbed wind data. As you can see there is only an empty box.
The XY planes for output of disturbed wind data can be successfully shown.
Am I missing something or just my GPU is not good enough?
