Dear Jason,
We’re currently looking at using the ROSCO toolbox to develop controllers for various different turbine models. The models have all come out of a piece of software called ATOM, which optimises the geometry and structure of the blade to minimise LCOE. One of the things it does to achieve this is make extensive use of bend-twist coupling to alleviate loads, meaning that if we just use the rigid properties of the blade to obtain a Cp/Ct/Cq surface then it’s going to be pretty wrong (a recent design twists around 7 deg at the tip at rated power!).
We have a few thoughts about how to get around this – initially I thought about creating our own Cp_Ct_Cq.txt file, but on reflection this won’t work as the blade won’t twist nearly as much at low speeds as it does at higher speeds, even if the tip speed ratio is the same. I was wondering if there is any way we could enforce a pitch and rotor speed schedule in the code (perhaps by hardcoding whatever Cp_Ct_Cq.txt is used for?). If so, could you point me in the direction of the correct file/variable names to edit etc?
Any help on this will be much appreciated!
Regards
Salem
Hi Salem,
I believe I just responded to one of your collegues who emailed me directly with this question. The following was my response:
This is a very good question that hasn’t yet been directly addressed in ROSCO. I think, ideally, the Cp_Ct_Cq.txt file could be expanded to have a third, rotor-speed dependent, dimension that different Cp surfaces could be interpolated upon. This would obviously take a bit of time and care from the software engineering side.
Within the controller itself, the primary use of the Cp surface is for the calculation of the current aerodynamic torque in the wind speed estimator. This happens here in the code:
github.com/NREL/ROSCO/blob/7e10 … s.f90#L534
Depending on how your Cp surface changes, you may be able to implement some sort of scaling factor on the Cp term calculated, based the current rotor speed.
This can get a little bit more tricky from the controller tuning side of things. Any changes to this would primarily have to happen in the tuning function here:
github.com/NREL/ROSCO_toolbox/b … er.py#L156
Below rated:
Technically, the below-rated TSR tracking controller should be scheduled based on wind speed. We have found that the gains can generally be simplified to a single value thus far, though. How much does the ideal Cp change in below rated operation for your turbine? The tuning process does assume that the turbine is operating at it’s nominal state, so if the Cp and TSR values don’t change, I suspect that no major changes are needed. If they do change, some scheduling may be in order.
Above rated:
This may be a bit more involved, as your Cp-surface presumably changes as the wind speed increases and the blades pitch. You could add a third-dimension to your Cp surfaces to interpolate across based on wind speed (and this would be much easier in python than fortran). Doing so would involve changes to the interpolation function here:
github.com/NREL/ROSCO_toolbox/b … er.py#L191
so that that the expected above-rated Cp is correct. You would also need to appropriately interpolate the gradients here:
github.com/NREL/ROSCO_toolbox/b … er.py#L221
I think these areas would be the main places to start. You would need to go through similar steps for the pitch saturation routines as well, but I would recommend just getting the “regular” controller working first before addressing the optional features.
I hope this helps. Definitely let me know if you have any clarifying questions. Also, if you do plan to go down this route, it would be really great to have this all integrated into the main source code for ROSCO. I would be happy to get on a telecon to talk about the best way to go about things and to make sure you understand what might be needed.
Cheers,
Nikhar
Hi Nikhar,
Many thanks for your response, indeed very insightful. We would get in touch and hopefully arrange a discussion.
Regards
Salem