model Validation

Dear Georgia,

It sounds like there is a formatting problem in your AeroDyn v14 input file. Please note that when using AeroDyn v14, ElastoDyn (ED) reads the AeroDyn v14 input file to obtain the blade discretization. (This is not the case when using AeroDyn v15, whereby ElastoDyn and AeroDyn can have independent blade discretizations.)

Regardless, an AeroDyn v14 input for the NREL 5-MW baseline wind turbine is provided as NRELOffshrBsline5MW_AeroDyn_Equil_noTwr.dat in the CertTest/5MW_Baseline directory of the FAST v8.16 archive.

Best regards,

Dear jason
Hello
I have modeled a 5kw turbine using FAST software and I want to validate the results, and I also do not have experimental data from the turbine to compare the results with.
The outputs that I am looking to validate are also mostly related to turbine blade loads and especially outputs like RootMxb1 and RootMyb1
If possible, guide me how to validate these results

Thankful

Dear @Ali.Rouhbakhsh,

Validation implies comparison of the FAST results to data. If you don’t have data for the wind turbine you are modeling, you can’t really validate your results.

Best regards,

Thank you for your answer
So, is it possible to validate my modeling using other software? If you can think of any way, I would be grateful if you could guide me

Dear @Ali.Rouhbakhsh,

You can verify your FAST results by comparing them to the results from comparable software, e.g., from Bladed, FLEX, or HAWC2.

Sometimes the word validation is used to imply comparisons to results obtained with higher-fidelity software, e.g., comparison of FAST results to those obtained from high-fidelity computational fluid dynamics coupled with a high-fidelity structural solver.

Best regards,

Dear @Jason.Jonkman

I hope to gain a deeper understanding of the parameters related to atmospheric stability and turbulence length scale in the DWM (Dynamic Wake Modeling) within the fast.farm software. My research primarily focuses on optimizing the model to improve simulation accuracy, especially under different stability conditions.

  1. Could you please specify which particular parameter settings in the DWM model are closely related to atmospheric stability? Do different stability conditions necessitate specific parameter adjustments to ensure the accuracy of the simulation results?**
  2. Additionally, what role does the turbulence length scale play in the model? Are there specific methods or recommendations for adjusting parameters related to the turbulence length scale to better suit varying meteorological conditions?**
  3. Finally, would you be able to recommend some best practices or literature resources to further understand the impact of these parameters on model output?**

Thank you for taking the time to consider my questions. I look forward to your response.

Best regards,

Dear @Jundong.Wang,

FAST.Farm does not directly consider atmospheric boundary layer (ABL) stability, but the wind inflow input to FAST.Farm can certainly be generated under different ABL stability conditions, and the wake evolution and meandering calculated by FAST.Farm will be influenced by this inflow. While you could likely define the wind profile (shear, veer), turbulence spectra (including standard deviation and length scale), and spatial coherence functions in the TurbSim synthetic turbulence generator to match different levels of ABL stability, to truly resolve ABL stability in the inflow generation would likely require the use of a high-fidelity precursor simulation, e.g., from the Large-Eddy Simulation (LES) solver AMR-Wind.

Within FAST.Farm, I would think the parameters most sensitive to the wake response to inflows of different atmospheric stability would be parameters of the eddy viscosity model associated with the influence of the ambient turbulence (vAmb for k, FMin, DMin, DMax, and Exp). I would also expect wake-added turbulence to be much more important for stable ABL with low ambient turbulence intensity (TI) than it would be for neutral and unstable ABL with higher TI.

Here are a couple of our papers related to this topic:

https://onlinelibrary.wiley.com/doi/10.1002/we.2543

FYI: We are working now on improvements to FAST.Farm that will improve its predictions under inflow with high shear and veer, which are conditions quite prevalent under stable ABL. We’ll present first results at WESC 2025 in June.

Best regards,

Dear @Jason.Jonkman ,

Thank you very much for sharing a comprehensive paper. I have gained a better understanding of this topic. I am very interested in the comparison mentioned in this article, and I hope to add a comparison of new wake models based on the work in this article ‘Multimodel validation of single wakes in neutral and stratified atmospheric conditions’. However, I need some help:

1.Fast.Farm simulaiton files.

I plan to replicate the findings in FAST.Farm but I do not have access to the “modified Vestas V27” turbine model or any accompanying .fst/fstf/other supported files referenced in her paper. I searched the r-test repository and found a folder for AWT27, but its contents are missing. I don’t know if this is the correct path.Would it be possible for you to share these files, or perhaps direct me to where I might be able to obtain them?

2.Implementing Different Atmospheric Stability Conditions in TurbSim/FAST.Farm

My work also involves investigating the predictive capabilities of wake models under different atmospheric stability conditions. In this paper, author describe how SWiFT measurements were converted into TurbSim .inp files, particularly addressing parameters such as the stability parameter, 2-m kinematic heat flux, and 2-m virtual potential temperature. I am somewhat confused about mapping these parameters to values used in FAST.Farm. If you would be willing, having a look at your TurbSim input files or an example thereof would greatly help clarify this process.

I have read some literature on atmospheric stability, and most scholars use the Monin-Obukhov length scale for characterization, but it seems difficult to reflect stability directly using FAST.Farm without high-fidelity precursor simulation. I would like to know how NREL views this issue? Some scholars at DTU have done relevant work(https://doi.org/10.1002/we.1662), but I don’t understand how they combined the Mohning Obhoff length with the turbulence length scale in the Mann model after introducing it. I want to know how to set turbulence length scales at different stability levels. So as to better simulate the front wind drive using Turbsim.

Best regards,

Dear @Jundong.Wang,

Regarding (1), I don’t have access to the OpenFAST/FAST.Farm/TurbSim input files used in the Wind Energy Science paper I cited to share with you. And I don’t recall if that OpenFAST model of the modified Vestas V27 turbine is available publicly anyway. I would suggest reaching out to other coauthors directly, but unfortunately, Paula Doubrawa and Kelsey Shaler, no longer work at NREL, so, that may be hard to track down now.

Regarding (2), as I said in my prior post, TurbSim does not resolve ABL stability either, but TurbSim does allow you to define your own wind profile (shear, veer), turbulence spectra (including standard deviation and length scale), and spatial coherence functions to match different levels of ABL stability (if you have such data to enter into TurbSim). I would say that we at NREL have had mixed success in using this user-specified TurbSim functionality to represent different ABL stability. So in the end, when our goal to is study the effects of different ABL stability in OpenFAST or FAST.Farm, in most cases we will resort to generating the inflow using high-fidelity precursor LES simulations.

Best regards,

Dear @Jason.Jonkman

Thank you again for your guidance and suggestions. I will try to use LES tools for corresponding research.

Best regards,

1 Like

Dear @Jason.Jonkman

I realized that I had been overlooking some questions. Can the existing 5WM wind turbine model run beyond the cut-out wind speed in OpenFAST? I mean, is the result obtained in this way valid and used for analysis? I did the simulation in the case of the cut-out wind speed, and although there are some caveats, the program can complete the calculation smoothly.

FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:AD_CalcOutput:RotCalcOutput:BEMT_CalcOut
put(node 18, blade 3):UA_CalcOutput:UA_BlendSteady:Temporarily turning off UA due to high angle
of attack or low relative velocity. This warning will not be repeated though the condition may
persist.

Best regards,
Jundong

Dear @Jundong.Wang

Hope you are doing well.

The figure you have posted is a warning and it is not an error.

For me, this is not a problem and your simulation is correct.

Best Regards,

Riad

Dear @Jundong.Wang,

I agree with @Riad.Elhamoud’s response, but I’m also not sure I understand your question. The baseline controller of the NREL 5-MW turbine does not have logic to shut down the turbine in high winds, so, if you run at high speeds higher than cut-out, in reality, the real turbine would shut down, but unless you’ve changed the controller logic to shut down the turbine, the simulation would continue to operate the turbine in a region it was not designed to operate in. At high enough wind speeds, this could cause problems such as excessive fatigue or a tower strike.

Best regards,

1 Like

@Jason.Jonkman @Riad.Elhamoud

Thank you very much for your reply!

Best Regards,
Jundong

Dear @Jason.Jonkman ,

I am currently studying the structural design of wind turbines. In the design process, the partial safety factor for wind load is taken as rw = 1.35 and the partial safety factor for self-weight load is rg = 1.1. I intend to implement the following two approaches in the main input file (*.fst) of OpenFAST v3.5.0. The definition of the partial safety factor is based on Section 7.6.1.2 of IEC 61400-1 (Edition 4.0, 2019). If these settings are not appropriate, please kindly correct them.

  1. Only wind load is considered while gravity is neglected. In this case, rw = 1.35 is applied (i.e., the effect of the wind load is amplified by a factor of 1.35). I set Gravity to 0 instead of the default value of 9.80665, and set AirDens to 1.654 = 1.35 × 1.225.
  2. Only gravity is considered while wind load is neglected. In this case, rg = 1.1 is applied (i.e., the effect of gravity is amplified by a factor of 1.1). I set Gravity to 10.78732 = 1.1 × 9.80665, and set AirDens to 0 (alternatively, AirDens = 0 can also be achieved by setting CompAero = 0, as referenced in your Share Post #54 on this forum).

Best regards,

Dear @Yangyang.Li,

It is not common practice in wind turbine design to perform dynamic analysis based on terms (such as aerodynamic loads or gravity loads) that are scaled up via partial load safety factors (PLSF). Rather, it is common practice to perform dynamic analysis based on actual conditions, and then scale up the resulting load effects based on PLSF. While the standard allows different components of the load to have PLSF (rw, rg in your terminology), to make use of this, would require that specific contributions to the load to be separated out. OpenFAST does not currently output the gravity contribution to reaction loads separately from other components, so, this is not really possible; as such, the larger of PLSF (rw) is applied overall:

Design load effect = rw * Characteristic load effect (OpenFAST output)

But if OpenFAST were modified so that the gravity contribution could be separated out, you could instead compute the design load effect as follows:

Design load effect = rw * Characteristic load effect without gravity term + rg * Gravity term contribution to the characteristic load effect

Best regards,

Dear @Jason.Jonkman ,

Thank you for your prompt responses. Based on the final expression for the design load effect that you provided, I still have the following questions.

Taking the calculation of the tower gravity load Fr|GravT on page 9 of the “FASTKinetics.doc” file as an example: when g = 0.001 ≈ 0 m/s^2, this corresponds to neglecting the gravity load (Characteristic load effect without gravity term, Swk), because in this case Fr|GravT ≈ 0. When g = 9.80665 m/s^2, this corresponds to the characteristic value of the gravity load effect (Gravity term contribution to the characteristic load effect, Sgk). This reasoning is analogous to setting AirDens = 0 kg/m^3 to neglect wind loads and AirDens = 1.225 kg/m^3 to include wind loads. The link to the document is as follows:https://openfast.readthedocs.io/en/main/source/user/elastodyn/index.html

Taking TwrBsMyt as an example, two cases shown in the table below were simulated to calculate Swk and Sgk, respectively, based on Test #18: NREL 5.0 MW Baseline Wind Turbine (Onshore). Except for the parameter modifications listed in the table, no other parameters were changed. TwrBsMyt is obtained from the OpenFAST output, and the reported values correspond to t = 200 s with the total simulation time Tmax = 200 s. The details are summarized in the table below. If the parameter settings used in the two cases for Swk and Sgk are not correct, please kindly correct them.


Best regards,

Dear @Yangyang.Li,

I don’t really agree with your approach because it doesn’t take into consideration the dynamics and coupling in the system, for example, the reaction loads (TwrBsMyt, etc.) depend both on the applied loads and inertial effects, and the inertial effects are affected both by the applied aerodynamic and gravity terms. It would be better to compute the reaction loads with both the aerodynamic and gravity loads enabled, and then subtract out the known static gravity component (-m*g) from this reaction load in order to isolate the two terms. But again, OpenFAST does not output the known static gravity component separately. Doing so would require a change to the OpenFAST source code.

Best regards,

Dear @Jason.Jonkman ,

Thank you for your prompt responses. If the influence of wind loads on gravity, as well as the influence of gravity loads on wind loads, are neglected—that is, if the coupling effects between these two loads in the system are ignored—and the response results are intended to be obtained under the action of wind load only, would the calculation of Swk in Case 2 in the table of the previous question be acceptable?

Best regards,

Dear @Yangyang.Li,

I would not say that it is generally acceptable to ignore the coupling between the aerodynamic and gravity loads. You could do as you say if you are OK with neglecting the coupling, but I would suggest trying to quantify how much error this neglection is introducing.

Best regards,