ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi,

I’m having some problems getting the extended Kalman filter (WE_Mode=2) to work reliably when I enable the blade degrees of freedom. I find that reliable estimates are obtained with rigid blades and that the divergence between reliable and unreliable esimates (obtained with flexible blades) is well correlated with a drift tip deflection around 20s. Please have a look at the plots below.

Perhaps it’s due to a poor initialisation of the tip-deflection (initially set to 0 at t=0) on my part and the nature of the Kalman filter.

Any advice would be much appreciated.

Edit. I would have thought the equivalent mean speed would be 9 m/s as that is the mean wind speed during the simulation. The rotor diameter is approximately 200m.

Best,
Sam
equivalent-windspeed-estimate-hh.png
out-of-plane-tip-deflections.png
equivalent-windspeed-estimate.png

It was my openfast naivety which was the problem, nothing to do with the ROSCO_toolbox or the ROSCO controller. Updating the LinearRamp setting to true in ServoDyn and adding a corrector iteration in the driver stabilised things.

I noticed in the source code for the wind-speed estimator that there is a variable denoted ti, I guess turbulence intensity? Is it a fixed parameter or can it evolve throughout a simulation?

Sam

Hi Sam,
Just to clarify, was the instability due to the WSE, or elsewhere in the setup?

Nikhar

Hi Nikhar,

I edited my original reply for clarity. I added a question relating to turbulence intensity in the WSE.

Thanks,
Sam

Hi Sam,
Good to hear!

Yes, you are correct - ti corresponds to the turbulence intensity.

The way it is now, it is a hard coded value. It could certainly be made a time-dependent (or wind-dependent) value that evolves over time if wanted/needed. The selection of ti, as well as the other parameters/values that affect the Q matrix in the WSE can certainly be a bit touchy, however. Some recent work has been done to clean up and improve the WSE response and will be merged once it is more extensively tested.

Nikhar

Hi Nikhar,

Thanks for the assistance!

If I was to make ti a user input variable, do you think it would actually improve the quality of my results?

Also, will VS_ControlMode = 2 strictly try and enforce that the tip-speed ratio is constant up to rated speed, or rated-speed and beyond? From what I can see, the main difference between this approach and the implementation of the traditional region 2 approach is that the user is in effect setting the value of VS_Rgn2K(\lambda, \beta, R) which is fixed using optimal values of \lambda in VS_ControlMode = 1. However, with VS_ControlMode=2, above rated the generator torque appears to saturate at VS_MaxTq (LocalVar%GenTq = MIN(LocalVar%GenTq, CntrPar%VS_MaxTq)) and not LocalVar%GenTq = (CntrPar%VS_RtPwr/(CntrPar%VS_GenEff/100.0))/LocalVar%GenSpeedF (=constant Power), like using VS_ControlMode=1.

Sam

Hi Sam,

It certainly could improve results, but it is hard to say specifically. There is so much coupling going on between everything that it would certainly take some time spent modifying and tuning the specifics of the controller and WSE to find the best ways to improve performance. Modifying the Q(1,1) and L parameters also tend to a have somewhat large influence on the WSE performance - the values currently used were based on “standard” values that provide reasonable performance in a number of test cases for different turbine configurations.

As far as the TSR tracking logic itself, with VS_ControlMode=2, the torque controller will always try to enforce that the tip-speed ratio is constant. The torque PI controller itself takes a TSR-tracking generator speed reference based on the estimated wind speed. When the wind speeds are above rated, the torque will simply saturate at the rated torque value. This does differ from the constant-power in above rated logic seen in the legacy controller, and when VS_ControlMode=1. It would be good to have a constant power and constant torque regime in above rated for TSR tracking control, but we haven’t had the need (or bandwidth) to implement this internally yet. That said, from my understanding, constant torque is generally standard for floating turbines, and the performance differences can be negligible as compared to constant power for fixed-bottom turbines.

As an additional note on this: the overall AEP differences of using VS_ControlMode=2 vs. VS_ControlMode=0/1 are minimal. Especially in the simulation case, the Komega^2 law works very well to maximize power output. Implementation of a TSR tracking controller is mostly motivated by industry feedback suggesting that this would be a good feature to have implemented in a reference controller. You can feel free to implement the komega^2 law by changing VS_ControlMode=0/1 and ensuring that VS_Rgn2K is correct (it should be if you used the ROSCO toolbox to write DISCON.IN).

Finally, I have opened a pull request with my updates to the WSE parameters and some related values to improve performance and stability here: [url]https://github.com/NREL/ROSCO/pull/10[/url]. No promises that they improve the performance for your turbine, but might be worth taking a look at.

Cheers,
Nikhar

Hi Nikhar,

Sounds good. I was thinking of running constant TSR under rated and constant power above, seems like that’s an easy change to the source code I can make if it is worth while. My main motivation had been that power curves tend to be flat after rated conditions. But perhaps controllers based on constant torque/constant power don’t vary too much as you suggested.

I’ll use your pull request and see how it changes things.

Best,
Sam