Use SOWFA to generate an inflow and give it to FAST.Farm?

[pingha]

Dear Jason Jonkman, I now want to use SOWFA to generate an inflow and give it to FAST.Farm. May I know how to proceed? I see an example called LESinflow in FAST.Farm

[jjonkman]

Dear @pingha,

Please see the FAST.Farm modeling guidance for inflow wind generation from high-fidelity precursor simulations: https://openfast.readthedocs.io/en/main/source/user/fast.farm/ModelGuidance.html#inflow-wind-generation. That said, these days, we more frequently use AMR-Wind than SOWFA for high-fidelity precursor simulations for FAST.Farm: https://github.com/Exawind/amr-wind.

If you are not already aware, there have been quite a few improvements recently to the python scrips that support FAST.Farm, see: https://github.com/OpenFAST/python-toolbox.

Best regards

[pingha]

Hi, Dear @jjonkman
I have another question to ask you. I have read your article titled "A model to calculate fatigue damage caused by partial washing during wind farm optimization". Therefore, I used FAST.Farm to study the bending moment at the root of a fan blade under different wind speeds. I used Turbosim to generate inflow, and generated wind speeds of 3m/s-25m/s to see the bending moment in the flapwise and edgewise directions at the root, But every time my wind speed reaches a certain level, the obtained bending moment will undergo a sudden change, and the trend of the bending moment change in the edgewise direction is also different from the trend in your paper graph. Do you know why? In addition, I saw that the azimuth written above the graph in your paper is 90 °. Does 90 ° here refer to the direction of the wind? Or does it refer to the angle of the turbine blades? If it is the angle of the turbine blade, I have a question. The angle of the turbine blade should constantly change during turbine operation. Why can you fix the angle of the turbine blade here? Regarding Figure 4 in your paper, I do not understand these. I have placed the relevant images below and look forward to your reply.

[jjonkman]

Dear @pingha,

I was not a couthor of the paper you reference, but here are my responses:

• I'm not sure what is causing your flapwise and edgewise loads to change at 19, 20, and 22 m/s. Can you clarify how you are generating these figures? (Are you plotting the time-series mean load from time-series simulations?) Do other responses such as rotor speed and blade pitch look correct?
• Figure 4 shows the effect of the rotor blade azimuth angle.

Best regards,

[pingha]

Hi, Dear @jjonkman
I'm very sorry to overlook that you are not the author of this paper. I have read many NREL papers before, and the authors in them all include you. This has caused me to think of you as soon as I saw NREL. I apologize again.
In addition, for my two images, I used turbosim to generate different wind speeds. I changed the URef in "90m_08mps. inp" in the TSinflow example under FAST.Farm, and changed RefHt to the actual hub height of 90m. Then, I simulated the wind speed from 3m/s to 25m/s. After obtaining the turbine response, I simulated for 660s and selected the maximum value from the last 100s for plotting.
Through your reminder, I found that under the three sudden changes in wind speed, the rotor speed and blade pitch angle also became abnormal. At present, I have not found the reason. I am using an NREL-5MW turbine.
You said that Figure 4 shows the influence of blade azimuth angle. I would like to know the approximate process of this simulation? I feel that I don't quite understand Figure 4. During the simulation process, the blade azimuth angle of the fan does not always change, but from Figure 4, it can be seen that the blade azimuth angle is always a fixed value. It is simulated under different wind speeds, and then the load response at a blade azimuth angle of 90 degrees is selected each time? I have tried this before, but after outputting the results, I found that the same blade may have experienced more than one blade azimuth angle of 90 ° during the simulation process. Finally, what do you mean by "blade pitch" is the pitch angle of the blade? Is this the meaning of Figure 3 in the paper? I also placed Figure 3 in the paper below.
Below are some of my graphs. There is no problem at 18m/s wind speed, but there will be problems at 19m/s. At first, I thought it was caused by excessive wind speed, but looking at the trend of the graph, the wind speed later was higher, and some did not have problems. Looking forward to your reply.

[jjonkman]

Dear @pingha,

Just a few comments:

• When you change the mean wind speed, are you also changing the initial conditions of rotor speed and blade pitch in ElastoDyn? If not, the controller may not respond as expected. I suspect this is the reason why your results are not correct at 19, 20, and 22 m/s. (It is generally recommend to initialize the rotor speed and blade-pitch angles to their expected (mean) values based on the mean hub-height wind speed being simulated.)
• The paper you reference only discusses mean (steady-state) loads, and for the blade, azimuthal dependence of these loads. From an OpenFAST simulation, you can calculate the equivalent by running a time-domain simulation, plotting the blade loads as a function of azimuth angle (rather than as a function of time), and then averaging the values at a given azimuth angle. This post-processing approach is called "azimuth averaging".
• Blade pitch is the rigid-body rotation of the blade about the pitch axis, as regulated by the controller.

Best regards,

[pingha]

Dear @jjonkman

Thank you for your answer. As you mentioned, I set the initial blade pitch angle and speed for the fan before each operation. After simulating again, there were no previous problems. Here, I would like to ask that in previous simulations, I did not set the corresponding initial speed and blade pitch angle, but this problem did not occur in subsequent simulations. I believe that the controller is working, So in the 19,20 and 22m/s simulations, the initial values were not set, and it was an error that made me realize this. Do you mean that regardless of the wind speed, I should set the relevant initial values before each simulation?

In addition, I currently want to conduct some research on wind turbine fatigue, and for this reason, I need to conduct a lot of simulations. I am currently using FAST.Farm for simulation, which is very fast in calculating the response of the wind turbine. However, every time I use turbosim to generate the wind field, this process takes me several hours. I think doing so and conducting a large number of simulations is too time-consuming, May I ask if you have any other methods for quickly generating inflow wind farms? This way, I can shorten the time spent on simulation.

[jjonkman]

Dear @pingha,

Do you mean that regardless of the wind speed, I should set the relevant initial values before each simulation?

Yes, this is a generally recommended practice as has been discussed many times on this issues page and on our forum. Using incorrect initial conditions may result in the controller not being able to recover and producing unphysical results.

Generating farm-wide turbulent inflow for FAST.Farm can be time consuming. For small wind farms, TurbSim likely suffices, but for large wind farms, a high-fidelity precursor simulation (from AMR-Wind or SOWFA) is likely required. When using TurbSim to generate wind inflow for FAST.Farm, the Mod_AmbWind = 3 approach of FAST.Farm is generally more efficient because it always you to tailor separate TurbSim wind data files for the low-resolution (coarse discretization) and high-resolution (fine discretization) domains. When generating wind inflow for use in FAST.Farm, I would recommend following the modeling guidance (https://openfast.readthedocs.io/en/main/source/user/fast.farm/ModelGuidance.html) and using the python toolbox, including recent updates that make the process much easier (OpenFAST/python-toolbox#56).

Best regards,

[pingha]

Dear @jjonkman

Thank you for your suggestion. Currently, I plan to use FAST.Farm to study the fatigue load of two wind turbines. This should belong to the category of small wind farms, and I apologize for not being specific enough before. I would like to ask for your advice. If I only study two wind turbines, which parameters do I need to change to design different simulation scenarios regarding fatigue? Do you have any suggestions in this regard? Because I currently think the spacing between turbines is also a variable, I did not design the wind farm size too small in the. fstf main file of FAST.Farm, which also caused me to generate inflow slowly using the. inp file.

In addition, I would like to ask you another question. If I were to use an. inp file to generate an inflow and need to change the wind direction, which specific parameters should be changed? I saw two parameters in the. inp file and the inflowWind.dat file, and I am not very sure if the two parameters that are very similar in these two files mean the same thing. After reading the turbsim manual, I still don't quite understand. I tried the following situation:
case1. After changing the VFlowAng in the. inp file to 0 and HFlowAng to 10, I found that the wind direction did indeed change;
case2. The VFlowAng and HFlowAng in the .inp file are set to 0. If the PropagationDir in the inflowWind.dat file is changed to 10, an error will occur during operation. I have placed the relevant figures below and look forward to your reply.

[jjonkman]

Dear @pingha,

Fatigue loads during normal operation are typically found by running a series of simulations from cut-in to cut-out wind speed, e.g., using 2-m/s bins from 3 to 25 m/s and 6 turbulence seeds per bin, would be 66 simulations for a given turbulence level.

It is generally not recommend to set HFlowAng nonzero in in TurbSim when using TurbSim wind data within InflowWind due to the use of Taylor's frozen turbulence assumption in InflowWind.

In standalone OpenFAST (uncoupled from FAST.Farm), we generally recommend setting PropagationDir in InflowWind to change the wind direction.

However, the FAST.Farm modeling guidance recommends keeping PropagationDir in InflowWind set to zero, which is why the FAST.Farm modeling guidance recommends rotating the wind farm (by moving the wind turbine positions) rather than changing the wind direction when using TurbSim-based inflow in FAST.Farm.

Best regards,

[pingha]

Dear @jjonkman

At present, I want to use FAST. Farm to study the fatigue load of two turbines. I want to change some parameters to set up multiple simulation situations, such as turbulence intensity and wind speed. I want to get a turbine response database, and then use neural network and other methods to train a surrogate model. I want to ask you what other parameters I need to consider in terms of parameter selection besides turbulence intensity and wind speed, Currently, due to limitations in time and computing resources, I cannot consider it comprehensively because there are too many parameters that have changed and too many simulations have been conducted, which I am unable to achieve on my end. Looking forward to your reply.

[pingha]

Dear @jjonkman

Thank you for your previous reply. I have another question to ask you. I conducted a comparison of two calculation examples, one using SWOFA and the other using FAST. Farm. The inflow wind speed at the hub height is 8m/s and the turbulence intensity is 5.6%. Three turbines were calculated, including the first one. I turned off its yaw freedom and set the initial yaw angle to 15 degrees. After comparison, I found that:, The power calculated by FAST. Farm is always slightly lower than that calculated by SOWFA. May I ask if there are any issues with FAST. Farm in considering turbine yaw calculations? I will put the relevant pictures and some settings in the calculation examples below, and look forward to your reply.

[jjonkman]

Dear @pingha,

Regarding your first question, the following NREL publications are likely of interest to you--related to the use of FAST.Farm to generate surrogate models for the loading of downstream wind turbines:
https://www.nrel.gov/docs/fy22osti/78861.pdf
https://www.nrel.gov/docs/fy22osti/82524.pdf

(Please note that I'm not a coauthor on these papers, so, can't speak to their details.)

Regarding your second question, I think we've recently realized that the original polar wake model of FAST.Farm can overpredict wake deflection in skewed flow. Collaboration of the wake-related parameters, such as the wake deflection correction parameters can help. We've also recently released the new curled wake model into FAST.Farm that is aimed at improving the prediction of wakes under skewed flow: https://www.nrel.gov/docs/fy23osti/82963.pdf. Comparisons between FAST.Farm and SOWFA for wake steering applications have also been discussed on our forum: https://forums.nrel.gov/t/fast-farm/1887. Otherwise, I'm not fully sure I understand the results you are sharing regarding power.

I also notice that your turbulence intensity is low, where FAST.Farm is known to underpredict wake-induced turbulence. NREL is working to resolve that by introducing a new wake-added turbulence model into FAST.Farm.

Best regards,

[pingha]

Dear @jjonkman

I have two questions to ask you. One is in FAST.Farm, where I use TurboSim to generate an inflow wind farm and I use the TSinflow case. I would like to ask

1. If I just want to change the position of the turbine without changing the characteristics of the inflow wind farm, can I use TurboSim to generate a wind farm and then directly change the position of the turbine and dX _ High，dY_ High，dZ_ High in the TSinflow.fstf file?
2. Or even if the inflow characteristics of the wind farm remain unchanged and only the position of the turbine is changed, I still need to make some modifications in the TSinflow. fstf file before using TurboSim to generate inflow wind. I don't know if the first approach is correct.

The second issue is that I have seen some recommendations in the manual regarding the determination of parameters such as "dX_High, dY_High, dZ_High". However, in the initial TSinflow. fstf file setting, "dX_High, dY_High, dZ_High" does not seem to be set strictly as recommended in the manual. May I ask why this is? For example, DS_ High should be smaller than the maximum chord length of the blade, and the maximum chord length of NREL-5MW should be around 4.6m, but here dx_ High chose 10.17m.
I put the relevant pictures and some settings in the calculation examples below, and look forward to your reply.