TUDelft-DataDrivenControl / OFF

Working repo for a dynamic parametric wake toolbox which combines OnWaRDS, FLORIDyn and FLORIS
BSD 3-Clause "New" or "Revised" License
7 stars 2 forks source link

Controller needed #7

Closed MarcusBecker-GitHub closed 6 days ago

MarcusBecker-GitHub commented 1 year ago

Need at least a basic controller to apply LUT settings to the turbines. Yaw motion is the main control input, as the FLORIS interface does not support setting the axial induction yet (right?)

rafmudaf commented 1 year ago

right?

Yep that's right, but it's on our radar. If this is a priority for OFF, we can work together to address it.

MarcusBecker-GitHub commented 1 year ago

Hey, I am not in need of it at the moment, but I know someone who might want to use it for power tracking soon-ish. My plan would be to take it into account while designing the interfaces and then close the connection once the time is right. Would it be safe to assume that the axial induction would then be set similarly to the yaw angles? fi.calculate_wake(yaw_angles= my_yaw_angles) becomes fi.calculate_wake(yaw_angles=my_yaw_angles, axial_induction=my_axial_induction) where fi is the FLORIS interface

rafmudaf commented 1 year ago

Yes I think that's right. On the back end, FLORIS will have to calculate thrust from axial induction and rather than the current formulation which is the other way around. It will take some thought to integrate it nicely, but it's definitely doable.

MarcusBecker-GitHub commented 1 year ago

Here are some solutions with varying complexity that come to mind:

  1. Let the user set the axial induction and calculate Ct / Cp based on ADM theory (or similar) - would probably be easy to implement but diverges from the level of detail the current Ct(u) tables offer + FLORIS might need an extension to decide what formulation of Ct(a) & Cp(a) is being used.
  2. Exchange/extend the Cp(u) & Ct(u) tables to take the blade-pitch-angle & tip-speed-ratio into account -> Have additional Cp(bpa, tsr) & Ct(bpa, tsr) tables. Then let the user set bpa & rotor speed, FLORIS calculates u_eff and determines tsr, looks up Cp & Ct for further calculations. The downside is the increased complexity - on the input side, and especially on the turbine info side. The upside would be that we get a quite versatile and complex turbine model in FLORIS for advanced control tasks.
  3. Let the user manipulate Ct(u) (and Cp(u)) for each turbine - this shifts all the complexity to the user side, who needs to figure out how the Ct(u) table would look like for the derated turbine - which should be possible with the Ct(bpa,tsr) and Cp(bpa,tsr) tables. Alternatively, if the users don’t have access to those tables, they could still calculate Ct/Cp based on the axial induction and just set a constant for all wind speeds. I guess this could entail the least changes to the FLORIS code, as you could treat the derated turbine as a new turbine type that inherits the rest from the old turbine. Might need input checks to ensure that the wind speed range and CtCp value range is within reasonable bounds / covers enough.
  4. Let the user set Ct and Cp directly - let them apply the derivation they would like to use. The downside is that there is no “this is ueff, what is Ct” feedback loop. But this also would not be the case if the user sets the axial induction factor directly.
tianz1990 commented 1 year ago

Are we still planning to add controllers soon?

MarcusBecker-GitHub commented 1 year ago

@tianz1990 Not axial induction control, there are also no plans for tilt yet. However, a collection of yaw steering controllers will be released soon. What type of control are you interested in?

tianz1990 commented 1 year ago

@MarcusBecker-GitHub Thank you for replying this! This is exactly what I want. I am looking for any interfaces for yaw steering controllers. Basically, I am working on a kind of MPC-based steering control.