Dear Liye,
OK, thanks for confirming. I asked Paul Fleming, the lead author on that paper and he referred me to a couple other papers showing asymmetry in the blade OoP bending moment DEL with yaw error, with the results dependent on shear, which makes sense to me, e.g.:
onlinelibrary.wiley.com/doi/abs/10.1002/we.1612
ieeexplore.ieee.org/document/7524969
I can’t say that I’ve ran equivalent OpenFAST simulations myself recently, but hopefully these references are useful and you can get FAST v8 or OpenFAST to match.
Best regards,
1 Like
Dear Jason,
Regarding the resolution of the domain, I understand the manual such that, for “Mod_AmbWind = 2” with synthetic turbulence, we should strive to have cell side lengths smaller than or equal to the maximum chord length (cmax). Using the Python Toolbox to generate a domain for two baseline 5 MW wind turbines in a row yields a domain with a width and height of 535 m and 420 m, respectively. With cmax = 5, that corresponds to Ny = 108 and Nz = 85. I find that it takes a long time for TurbSim to generate a flow for this discretization (1 second of flow took approximately 40 minutes to calculate). For the tutorial case, “TSinflow”, I noticed that the cell sizes are larger, roughly 10 meters everywhere. With this in mind, I have a couple of questions:
- How coarse can I make the mesh, is there a great difference in accuracy for a 5 m cell sized mesh, versus a 10 m cell sized mesh?
- Since we can use the TurbSim generated flow as periodic inflow, do you have any recommendation for what minimum amount of time such a flow should span?
Best regards,
Viktor
Dear Viktor,
I agree that with Mod_AmbWind = 2, the TurbSim calculation would be very slow using the recommended wind field discretization. Thus, I would recommend using Mod_AmbWind = 3 instead, which allows you to generate distinct TurbSim wind fields for the low- and high-resolutions. In this case, the discretization for each domain can be chosen based on the modeling guidance without the extreme computational expense.
Regarding (1), the answer likely depends on what physics you are trying to capture. Please see our discretization study paper for the kinds of error you would expect at coarser discretizations: https://www.nrel.gov/docs/fy19osti/73657.pdf.
Regarding (2), wake meandering is a fairly low-frequency process, so, we typically run wind farm simulations that are longer than the standard 10-minute simulations common in wind turbine load cases. 30 minutes is a common length of time for us, but again that is something that can be studied to ensure that the simulation results are converged. There is always a tradeoff between running longer simulations and running shorting simulations but more turbulence seeds.
Best regards,
1 Like
Dear Jason,
Thank you for the very useful answer! Mainly I am interesting in wake steering and wind farm power production. The paper answered my questions regarding the discretization.
I still have a doubt about the TurbSim-generated inflow. As I understand it, if the time it spans is shorter than the FAST.Farm simulated time, the flow is repeated. Would you recommend against using a, say, 30 second TurbSim-generated inflow which is repeated 20-60 times (depending on what simulation time is chosen for FAST.Farm)? Is there a recommendation for how long such a repeating TurbSim-generated flow should be?
Best regards,
Viktor
Dear Viktor,
Yes, the TurbSim output will be periodic when you set UsableTime = “ALL”, which means that in FAST.Farm the wind can repeat itself over and over again. But you still want to generate enough unique wind to ensure statistical significance of the FAST.Farm result. The periodic feature of TurbSim is useful (1) if you want to avoid adding extra wind data to cover the start-up transient whose output data is thrown out anyway or (2), for offshore wind simulations, if you know that you’ve reached statistical significance for the wind excitation but still need to run longer simulations to ensure statistical significance of wave excitation. In the later case, for example, it is common in offshore wind simulations to run a simulation with 3 hours of unique wave data with repeated 1 hour of unique wind data.
Best regards,
1 Like
Dear Jason,
Thank you very much for the help.
Best regards,
Viktor
Dear Jason,
I have a doubt regarding how to run the Mod_AmbWind = 3 option. By using the Matlab utilities (readfile_BTS.m), I extract the low resolution flow to create a time series for the high resolution flow. In the FAST.Farm manual, it is stated that the time series should be offset in time based on downstream turbine distance and the freestream velocity. Can I take this freestream velocity as the mean velocity at the point which I choose as “RefPtID” in the time series?
Best regards,
Viktor
Dear Viktor,
No, you should use the velocity that is used to propagate the low-resolution wind data through the FAST.Farm domain by the InflowWind module.
Within the InflowWind module of OpenFAST and FAST.Farm, “Time” in the wind data file is related to “Distance” via:
Time = Distance/Velocity
where Velocity is the the mean wind speed of the turbulence box, which is used to propagate the full field inflow planes downstream within InflowWind. The reference point for this mean wind speed is the based on the HubHt input set in TurbSim. Of course, HubHt is likely set different than the actual hub height, as discussed in the following issue on the OpenFAST github page: Decouple Hub Height from Grid in TurbSim · Issue #199 · OpenFAST/openfast · GitHub.
I hope that helps.
Best regards,
1 Like
Dear Jason,
Thank you very much for your answer. However, I still have a question. As I understand the InflowWind user’s guide, the flow “starts” at x = 0 (when the flow is periodic). Does that mean that the distance used for the time offset is simply WT_X? Or should the offset be made with respect to perhaps an upstream face of the high resolution domain? Also, is there any way I can know for sure that I have correctly offset the time series? Perhaps by somehow comparing the flow in the low and high resolution domains in two adjacent points?
Thank you in advance and best regards,
Viktor
Dear Viktor,
Correct. For periodic wind generated by TurbSim for use with Mod_AmbWind = 3, the wind data of the low-resolution domain “starts” at X=0 in global coordinates and the wind data of each high-resolution domain “starts” at x = 0 in the local coordinate system of the specific turbine, which is offset from global by WT_X in the X direction. Thus, for wind propagating along X, WT_X is the distance that you should use to shift the wind response for each high-resolution wind box from the low-resolution wind box.
You can verify that you’ve implemented this correctly by outputting the wind data from the low- and high-resolution domains at the same location and comparing them. The low-resolution domain can be output through FAST.Farm write outputs WηVAmbδ, e.g., at the location (X,Y,Z) = (WT_X,WT_Y,HubHeight) in global coordinates. The high-resolution wind data can be output through InflowWind output WindηVelδ of each wind turbine OpenFAST model, e.g., at the location (x,y,z) = (0,0,HubHeight), which should match the location of the low-resolution domain. As long as wakes are not considered in the FAST.Farm simulation, the time series from the low- and high-resolution domains will hopefully match closely.
Best regards,
1 Like
Dear Jason,
I am trying to visualize my two-turbine interaction in the XY plane by Paraview.
However, the resolution seems unsatisfied, which was made by .Low.DisXY<n_out>.t.vtk.
Actually, the 3D low- and high-resolution flow fields generated by FAST.farm are turned out to be empty and I don’t know how to solve it. Also, I am wondering if taking a XY plane from high-resolution 3D is a good way to satisfy the picture resolution?
The performance of this picture is very ideal for me, which made by some scientists in NREL in “Simulation comparison of wake mitigation control strategies for a two-turbine case”
Truly appreciate it if you can give me some hints to make pictures like this!
Thanks
Ruiyang He
Dear Ruiyang He,
The figure you extracted from the paper you reference shows both a horizontal XY plane and a vertical XZ plane (assuming the two turbines are aligned with the X axis). You can output both types of visualization planes from FAST.Farm. The resolution will be determined by the resolution of the low-resolution domain and will likely not be as refined as the figure you show because the low-resolution domain of FAST.Farm does not need as fine as resolution as SOWFA, from which that figure was derived.
ParaView should also be able to plot the full 3D domain, but such files contain a lot of data. I’m not sure why the box you are showing is empty; do the files you are trying to plot have data in them? If so, the problem is likely an incorrect setting in ParaView.
Best regards,
Hello,
I started learning FAST.Farm 2 weeks back. I am trying to work with a simple 2 turbine case in FAST.Farm. Everything works fine, I am able to run fast.farm, compile DISCON, and command yaw rate through the supercontroller.
Then, I try to read the individual turbine powers through the avrSWAP(14) variable. I want to get the individual turbine powers of both the T1 and T2 into the supercontroller using the “to_SC” variable.
I use - ‘to_SC(3)=avrSWAP(14)’ in the DISCON file for turbine 1 and ‘to_SC(4) = avrSWAP(14)’ in the DISCON file for turbine 2. If I print these i.e., to_SC(3) and to_SC(4) inside the DISCON file, I get the individual turbine powers in the command prompt. But, when I try to read (print) to_SC(3) and to_SC(4) inside the SC_DLL.f90 (specifically inside the sc_calcOutputs subroutine), I get the correct value for to_SC(3) i.e., power for turbine 1 (upstream) but the value for to_SC(4) (i.e., power for turbine 2 (downstream) comes out to be 0. The NumCtrl2SC is set to 4 inside the sc_init subroutine.
I want to read the two individual turbine powers and implement a yaw controller. If possible, can anyone please suggest what I might be doing wrong?
Any help would be appreciated.
Thanks and Regards,
Devesh
Dear @Devesh.Kumar,
I would guess your not accessing the correct element of the to_SC array in the super controller.
The variable to_SC specified in the DISCON controller of an individual wind turbine should be an array of size NumCtrl2SC. In the DISCON for turbine 1, you can set: to_SC(3)=avrSWAP(14), and you can do the same in the DISCON for turbine 2: to_SC(3)=avrSWAP(14).
The variable to_SC input to the super controller is an array of size NumCtrl2SC*nTurbines, whereby the to_SC arrays defined in each wind turbine controller are collected together into a single array.
I hope that helps.
Best regards,
2 Likes
Thank you so much for the reply, got it!
Regards,
Devesh
1 Like
Dear Ruiyang He
For the empty box that you get from ParaView, it is because you have to change the parameter “Solid Color” and to choose the velocity magnitude as I stated in this post here: https://forums.nlr.gov/t/fast-farm/1887/284?u=younes.oudich
Then you can play with the opacity, colors and other parameters in ParaView to get something interesting. Personnaly, I prefer to have slices like in this post here:
https://forums.nlr.gov/t/fast-farm/1887/286?u=younes.oudich
I hope this will help.
Kindest regards
Younes
Dear Younes,
Thanks for your response, I really appreciate that!
Your suggestions are literally helpful to me and I have made some animations in XY plane.
Thanks
Ruiyang
Dear Jason,
Recently, I used the FAST.Farm to realize the yaw control in a floating wind farm to improve the total power output. But I suddenly remembered that the yaw angle is between the nacell and tower, but for the floating wind turbine,the floater will rotate, so the yaw angle is not equal to the angel between the nacell and wind direction. So I want to know about whether the FAST or FAST.Farm could output the rotated angle of floater to get the real angle between nacell and wind direction? waht’s more, are you had some research on this field about the floater rotate degree?
Thank you in advance,
Jiaping.Cui
Dear @Jiaping.Cui,
FAST.Farm output TIAmbTα provides the total yaw error for turbine Tα, including nacelle-yaw, wind direction, and rotation of the support structure.
OpenFAST and FAST.Farm certainly account the impact of support structure rotation on the total yaw error, but I can’t think of a specific paper that highlights the impacts.
Best regards,
Dear Jason,
Using FAST.Farm, I simulated the following case: Three turbines in a row (NREL 5 MW), 8D spacing, 8 m/s steady wind speed (WindType = 1). A cut plane image at the hub height is attached below.
By chance, I have observed a strong relation between the generator power (of the 2nd and 3rd turbines) and the wake parameter C_meander, while keeping all the other wake parameters as “default”, as plotted in the second image below. Since there is no turbulence, I expected C_meander would not influence the results. I’m wondering:
-
Do you know how C_meander affects the power in that scenario ?
(maybe via affecting the calculation of wake propagation speed or any other parameter ?)
-
What would be the most plausible choice of C_meander for steady wind ?
(I understand that steady wind is not a realistic case and FAST.Farm is calibrated for turbulent conditions)
Best regards,
