Wind estimator problem: incorrect evaluation of WE_op

[R-Quancard]

Desired use case

I am using ROSCO 2.10.1 for normal power production in OrcaFlex, with WE_Mode = 2 and with small pitch offsets on each blade (thanks to PF_Offsets). I run various wind speeds, but here I am specifically talking about below rated conditions.

Description

Out of a large selection of load cases, it appeared that some cases below rated showed erratic rotor speed behaviour which was not present with ROSCO 2.9. Also, this behaviour could be eliminated by reducing slightly the time step (in this case, 0.04s vs. 0.05s). After investigating what differences between v2.9 and v2.10 could explain this, I realised that WE_Op was zero in a lot of time steps, and that this was probably due to BlPitchCMeas being just slightly below PC_MinPit. In the present case, the small (negative / zero / positive) pitch offsets on each blade cancel out when the average is calculated to obtain BlPitchCMeas, but I think a tiny rounding error causes the result to be just below PC_MinPit (I'm talking less than 1e-6 rad).

Solution

The solution I have found is to change the lower bound that delimits the "operating" pitch range.

ROSCO/rosco/controller/src/ControllerBlocks.f90

Line 332 in fc11f43

WE_Inp_Pitch = saturate(LocalVar%BlPitchCMeas, CntrPar%PC_MinPit,Max_Op_Pitch)

In my case, the pitch lower bound from the rotor performance file is a good lower bound for that "operating" pitch range because it's lower than PC_MinPit. I made this change in the controller code and it solved the problem (no more zero-WE_op situations, and no more erratic rotor speed variations). It might not be the right solution for other cases though. Maybe consider saturating with PC_MinPit minus an epsilon, to avoid getting zero-WE_Op just because of tiny rounding problems?

An important note: at the moment it's unclear to me why the WE_Op = 0 situations (and the use of "measured" wind speed instead of the estimation) lead to bad rotor speed behaviour. And it is even less clear why this problem arose with time step 0.05s and not with 0.04s...

Anyway, thanks for all the great work on this very useful tool!

[dzalkind]

Thanks for finding this! I admit that we haven't accounted for this case.

I'm also not sure yet what the proper solution should be for all cases. PC_MinPit is supposed to be a hardware limit, but PF_Offsets is meant to simulate potential hardware offsets. However, the controller doesn't "know" there are offsets, so perhaps they should not be accounted for in internal signals. Either way, I think an epsilon offset on that saturation limit makes sense.

Does WE_Op toggle for both time steps?

I can only speak to my experience with OpenFAST, but I rarely simulate with time steps greater than 0.02s. The issue could be related to the aeroelastic solver, the sampling of wind, or the changing of the rotor speed reference. Ideally, the estimated wind speed and the measured wind speed should be similar, so the reference shouldn't change too much. If you're able to share/quantify the erratic variations (figures, amplitudes, frequencies), that would help.

[R-Quancard]

Hi Dan,

And thanks for your quick reply. I haven't had much time to dig deeper into this issue, but here are a few additional elements.

Regarding your question about WE_Op, it does toggle in both cases (time step = 0.04 and 0.05s). Initially it toggles pretty much at the same instants, and then the behaviour for each case start to diverge from each other: in the case with 0.04s, WE_Op remains 1 most of the time; and with 0.05s, it constantly toggles between 0 and 1.

I wish I had time to show you this in more detail, but below are 2 graphs showing the rotor speed (in rad/s) for each case mentioned above (first with 0.04s, then 0.05s). Note that I included the initialisation phase, which allows to see the moment when the divergence happens.

Edit: note also that the estimated wind speed is quite good compared to the rotor-averaged measured wind speed - however the low-pass-filtered hub-height measurement is slightly less good. The latter being used when WE_Op = 0, this could explain some erratic behaviour (the difference really isn't huge though, thanks to the low-pass filtering).

Romain