Cp coefficient in Imposed motion simulation

[C-Giorgio]

Dear all,
I ran a simulation with the IEA-15-240-RWT under imposed surge motion. The surge imposed motion was set at the base of the wind turbine using the seismic module (in this case amplitude 2m and frequency 0.3 Hz). The surge motion is visible in the figure below. All of the other 'platform DOFs' are off. The wind speed is set constant in space and time to 9 m/s. I am using the VolturnUS DISCON as controller. I am interested in the power produced under this condition. Checking the generator power, it seems reasonable. However, when I compute the Cp (RtAeroCp), it reaches also values of 1, as reported in the graph below. I understood that this Cp is computed using the aerodynamic power (RtAeroPwr), but I don't understand how it can reach suck high value. The other variables (Blade pitch, trhust force, generator torque,...) have reasonable values, always following a sinusoidal trend. I have also tried this simulation, without the control, imposing a fixed rotor speed and collective blade pitch. The Cp trend is similar, but this time also the Rotor Torque (RotTorq) reaches negative values. I don't understand why this occurrs.

Any help is welcomed. Thanks in advance for a kind response.
Best,
Giorgio

[jjonkman]

Dear @C-Giorgio,

AeroDyn output RtAeroCp may temporarily exceed the Betz limit if the solution is undergoing a transient. If this is troubling to you, I would only use RtAeroCp under steady conditions or in a time-averaged sense, which in both cases I would exceed to be below the Betz limit.

I’d have to understand more about what your simulation set up (e.g., aerodynamic settings) to comment more.

Best regards,

[C-Giorgio]

Dear @jjonkman ,

Thanks for your kind reply. I also tried to use the mean value of RtAeroCp. For the majority of the cases, it sounds reasonable, except for a few exceptions. For instance, the average for the case above is 0.531, although below the Betz limit, I believe not to be correct. Also, in another case, with the surge motion imposed to an amplitude of 2.5 m, the mean value of RtAeroCp is 0.609. I don't really understand why this is occurring.
I am using Aerodyn v15. I am attaching the file in case the general settings are needed.
IEA-15-240-RWT_AeroDyn15.txt

Thanks in advance for a reply.
Best regards,

Giorgio

[C-Giorgio]

Dear @jjonkman,

I checked the rotor-average wind speed and it matches what I would expect.
Disabling the unsteady airfoil aerodynamics, I get 0.464 as mean value of the RtAeroCp, which is in the expected range (I would expect a value around 0.46-0.47). SO, the problem could be the unsteady airfoil aerodynamics ?

Best regards,
Giorgio

[jjonkman]

Dear @C-Giorgio ,

Perhaps you are experiencing the same issue discussed in the following OpenFAST r-test issue: OpenFAST/r-test#20 and the associated forum topic: https://forums.nrel.gov/t/unsteady-aerodynamics/2254. If so, these posts point to a potential solution as well.

Best regards,

[C-Giorgio]

Dear @jjonkman ,

Thanks for your kind response. I will dive deeper into the problem.

Best regards,
Giorgio

[C-Giorgio]

I believe that is not the cause. I have tried to plot the lift versus the angle of attack of a few sections and unsteady aerodynamics values matches the static one. Here a few nodes:

If anyone will have any further hypothesis on the reason why I get that strange values of Cp, please don't hesitate to reach out.

Thanks in advance. Best,
Giorgio

[jjonkman]

Dear @C-Giorgio,

I'm curious if you see the same issue with high Cp if you switch from UAMod = 3 to UAMod = 4 or 5?

Best regards,

[C-Giorgio]

Dear @jjonkman ,

Here the outcome:

The simulations are done by imposing a surge motion at the tower base increasing the amplitude, from 0.5 to 3 m (frequency of the surge motion has been kept the same at 0.3 Hz). On y-axis the mean value of the RtAeroCp is plotted, with the transient removed. I also tried disabling unsteady airfoil aerodynamics. The Cp-values are lower. Same occur to the mean generator power. However, with UAMod 4, at surge amplitude of 3 m, the Cp drops to 0.28, which is unrealistic.

Thanks for any help. Best regards,

Giorgio

[ebranlard]

Hi Giorgio,
I don't have much input to help. I'm guessing we are reaching some of the limits of the UA models, and we are definitely lacking verification/validation/robustness studies, and without them, it's all a bit of a guess for now. Here's some potential paths forward:

• I would recommend using UAMod=6, which is a simple dynamic stall model, at the expense of likely lacking some physics. I think it's the most robust model.
• UAMod=4 & 5 leads to somehow stiff systems, and sometimes significantly smaller time steps are required.
• If smaller time steps dont improve the results for the 3m amplitude, we would need to dive into why UAMod 4 seems to fail at high amplitudes. We should look at the values of the unsteady parameters used for UA4, which are in particular the Cl slope, and the separation function, and see if they are valid. I don't have a systematic way of doing that at the moment. There are ways to recompile OpenFAST with -DCMAKE_Fortran_FLAGS="-DUA_OUTS=ON" to include a debug output file for the UA module (these can be quite big and slow down the simulation). Maybe that can give us hints as to what is happening with this UAMod 4.
• Maybe the dynamic inflow model has an impact as well here (other studies have found little impact though). You can experiment with or without DBEMT, and also adjust the time constant, making sure it matches your freestream U0 (based on the equation for tau_1 here). It might be that "U0" needs to be adjusted based on the relative velocity of the rotor in your surge motion. It could also be that a different kind of DBEMT model is needed for such kind of oscillations, which are different from what original dynamic inflow models were derived for.
• I would recommend using the AeroDyn driver to simplify and speed up the simulations.

Most likely, you are reaching some limits of the UA models and it could require a lot of debugging to figure out what's happening.

[C-Giorgio]

Dear @ebranlard ,

Thank you for your help.

Best,
Giorgio