Dear community
I’m attempting to reproduce the steady-state rotor aerodynamic performance values reported on page 23 of “Definition of the IEA Wind 22-Megawatt Offshore Reference Wind Turbine.” The goal is to confirm my model before using it in my master’s thesis by matching the reported values once steady state is reached.
Modeling setup
-
Inflow: Steady wind; PLexp = 0 (no vertical shear).
-
Main .fst: Gravity disabled (Gravity = 0 m/s^2). Simulation time long enough to reach steady state.
-
ElastoDyn: Platform and tower DoFs disabled; ShftTilt = 0.
-
Post-processing: For each wind speed, I discard transients (identified by plotting the time series of the target variables) and take the median of the steady-state segment.
-
Software versions: OpenFAST 4.1.2; ROSCO 2.9.0.
What I observe
When I plot my results against the values on page 23, they do not match exactly—especially near rated wind speed.
-
Below rated: I did not specify ElastoDyn initial states for blade pitch or rotor speed. ROSCO still converges rotor speed and pitch pretty close to the tabulated values.
-
At/above ~10 m/s: I initially encountered tower strike in either 0 initial values or using tabulated initial values (table 7), so I set the initial pitch to 21.86473° and kept the rotor speed from Table 7. ROSCO reduces pitch and reaches a steady state, but the final steady-state pitch angle is consistently higher than the documentation value.
-
I verified that DrTrDOF is deactivated for all cases.
Question
Should I expect exact agreement with the page-23 steady-state values under this setup? If not, what factors typically explain the remaining differences around rated wind speed (e.g., controller assumptions, initial conditions, gravity removal, tower/platform DoF choices, or post-processing choices like using the median)?
Any insight on aligning my setup with the assumptions used to produce the page-23 results would be much appreciated.
Dear @Zuhir.Jamaleh,
I was not the one to generate Figure 23, but I would expect OpenFAST to match close with, but not exactly with the results of Figure 23, which where generated by DTU using a solver that has some differences relative to OpenFAST. Based on the text surrounding Figure 23, I agree with your settings except that you should enable all structural degrees of freedom in ElastoDyn and BeamDyn.
Best regards,
Dear @Jason.Jonkman ,
Thanks for the quick reply. According to the documentation on the official GitHub page, the rotor-performance values from HAWC2 and OpenFAST are reported as identical (i.e., 100% agreement) for the IEA-22-280-RWT_tabular.xlsx dataset. I had expected small deviations between the two codes, but the file suggests there are none. Based on that, I assumed it should be possible to reproduce those results as a validation step before using the model for my master’s thesis. Did I misunderstand the intent of that dataset or the comparison?
I also wanted to confirm the setup: should all ElastoDyn DoFs—including drivetrain/tower DoFs and platform DoFs—be enabled during the steady-state simulations used to produce the performance curves? Below are the settings I used.
Thank you in advance for your help.
Dear @Zuhir.Jamaleh,
I’m not familiar with the spreadsheet you are referring to, but I would generally expect small differences between HAWC2 and OpenFAST.
I agree that the results in section 2.2.7 of the DTU report you are referencing implies that the rotor is flexible while the support structure is rigid, but this section also refers to blade torsion, so, when running the equivalent in OpenFAST, you’d have to enable BeamDyn and not model the blades in ElastoDyn.
Best regards,
Dear @Jason.Jonkman
Thank you for your suggestion. I tried to enable BeamDyn + ElastoDyn but I am getting this error
What I tried to fix it in BeamDyn:
1- increase the rhoinf to add a numerical damping (used 0.85 instead of 0)
2- reduce the time step size DTBeam from default to 0.001
3- Increase the number of iterations NRMax from 10 to 75
I also tried to change the damping coefficients in IEA-22-280-RWT-BeamDyn_Blade.dat to have the same order of magnitude by increasing mu4 and mu6 but did not help. Here are the original values
My module switches are as follows
The DoFs in ElastoDyn are :
Dear @Jason.Jonkman,
Thank you for responding. Regarding your comments:
- agreed, I have removed SeaState, HydroDyn and MoorDyn and no change observed. However, when I disable the DoFs of the tower, I am getting tower strike (While using the initial conditions stated in table 7 of the report)
- The original model comes with CompElast = 1 (working with no fatal error but higher pitch angle and RPM than the values stated in table 7), the error occurs when I change that to CompElast = 2 to include both ElastoDyn and BeamDyn
I think the higher values for thrust, TSR and Ct are properly due to the difference in RPM and blade pitch in my results compared to these obtained in table 7. For example when I test uniform wind of 11 m/s, Rosco settles at RPM of 7.1 and pitch degree of 4.9. While table 7 states that these values should be 6.77094 and 2.42859, respectively. I think my issue must be in Discon.IN file. But I could not manage to fix it so far.
Addition: I have now compared my results to these calculated in IEA-22-280-RWT/Documentation/IEA-22-280-RWT_tabular.xlsx at main · IEAWindSystems/IEA-22-280-RWT · GitHub using WISDEM. As you can see, my results are much closer to WISDEM than OPENFAST (Except for Cp)
Best regards.
Dear @Zuhir.Jamaleh,
The OpenFAST model for the monopile comes with CompElast = 2. Does that one run for you? If so, what is different from what you are running? (I would not think the use of the monopile versus the semi model would matter if the support structure is treated rigidly anyway).
I would guess the differences in speed, pitch, etc. that you are describing are the result of the lack of blade torsion when the blade is modeled in ElastoDyn (which I would not recommend for the IEA Wind 22-MW RWT).
Best regards,
Dear @Jason.Jonkman
Thank you for your help. Know i am getting much closer values to that provided in the rapport. It was the time step interval that caused BeamDyn to not converge. Since I was using the Semi-version, the time step was 0.01 by default. I had to change that to 0.002. Also for some reason the model did not work with OpenFAST 4.1.2 so I had to use the 3.5.3 which is the one suggested by the comparison study. Apologize for late response but re-running the simulations took a while.
