Add support to shut off turbines

[ElieKadoche]

Added the possibility to shut off some turbines (related issue #687).
The new turbines_off argument is similar to the yaw_angles argument.
The feature does not alter FLORIS computations and can be used in a vectorized way for different wind directions and speeds.

Added a turbines_off argument to the following functions:

• Ct();
• axial_induction();
• calculate_wake();
• calculate_no_wake().

The thrust coefficient is equal to 0.001 for turbines off.
In the get_turbine_powers() function, the power outputs of turbines off are set to 0.0 MW.
I modified all the Ct() and axial_induction() functions in the ./floris/simulation/solver.py file accordingly.
I modified the visualization functions to integrate the turbines_off argument.
I integrated the feature in the 02_visualizations.py example.
I created a new example demonstrating the turbines_off feature.

Files modified:

• floris/simulation/farm.py;
• floris/simulation/floris.py;
• floris/simulation/solver.py;
• floris/simulation/turbine.py;
• floris/tools/floris_interface.py;
• floris/tools/visualization.py;
• floris/turbine_library/turbine_previewer.py.

[rafmudaf]

Hi @ElieKadoche thank you for submitting this pull request! I also very much appreciate you adding documentation via an example to demonstrate this code - well done.

Conceptually, this design is a bit intrusive to the low level code as the Turbine.Ct/axial_induction functions now include high-level user settings that change their functionality and scope. As a general principle, floris.simulation is the "core" simulation code and floris.tools use floris.simulation in various ways. For this sort of feature, it would be better scoped to design a method for making the modifications to the turbine from outside of the core code. This way, the core doesn't need to have any of the information about whether a turbine is on / off or anything else, it just does the math and lets the calling code make the other decisions. As a check, the docstring would have to change to something like below and we can get an idea of the scope-creep.

Thrust coefficient of a turbine incorporating the yaw angle.
The value is interpolated from the coefficient of thrust vs
wind speed table using the rotor swept area average velocity.
--> Additionally, set some turbine Ct's to a negligible value if given in user inputs.

FWIW the yaw settings should follow a similar design as described above. I let the scope creep already on these Turbine functions, and I'll make note to improve this design in future work.

[Bartdoekemeijer]

Just wanted to highlight that this would be a very useful functionality to have! Thanks @ElieKadoche for taking the initiative!!

[ElieKadoche]

Thank you for your feedbacks, I understand that the proposed design is a bit intrusive.
What I struggle to understand, is that having some turbines off alters the propagation of the wind flow.
Therefore, as it is the case for the yaw angles, it affects the whole simulation, i.e., the functions of the solver.py file.

Considering yaw angles and turbines off outside of the core code would require important refactoring?
I understand that future development will tend to such architecture.
In the meantime, would you accept such approach to shut off some turbines?
If not, would there be a different workaround I could try?

[rafmudaf]

Thanks for the added context @ElieKadoche. My initial thought was to modify the turbine Ct curves from FlorisInterface for the specific turbines to disable. After prototyping this, I see that one fundamental problem is that in turbine.Ct we get the thrust coefficient from wind speed based on the turbine-type not that turbine index.

    for turb_type in turb_types:
        # Using a masked array, apply the thrust coefficient for all turbines of the current
        # type to the main thrust coefficient array
        thrust_coefficient += (
            fCt[turb_type](average_velocities)                 <-- Here's the problem
            * np.array(turbine_type_map == turb_type)
        )

This means that changing a turbine's thrust curve would change all the thrust for that type of turbine. To continue along this path means to make an entirely new turbine type that would be in the "off" configuration, and I don't think that's a reasonable workaround.

If you want to see the changes I've made to get to here, its on a branch on my fork.

In any case, I agree that this is a great idea, and I'd like to think through the architecture of this a bit more over the next few days. Thanks for your patience while we find the right way to integrate it into the full system.

[ElieKadoche]

Thank you @rafmudaf for your branch, I can see where you want to go with the FarmController.
The core simulation should be independent from what we do regarding shutting down the turbines of yawing them.

As proposed by @Bartdoekemeijer , modifying the Ct curves was my first approach.
But as you pointed out, it would change the thrust for all the corresponding turbines.
Also, from my understanding, even a new turbine type would have some issues regarding vectorization.
For a single simulation on different wind conditions (see my example here) to work, turbines_off needs to be defined as a matrix, as it is the case for the yaw angles.

In any case, as you said, there are a lot of refactoring to do in order to reach an acceptable architecture.
Do not hesitate if I can help you in your thoughts or if you think of a different workaround on which I could contribute.
In the mean time, I integrated the turbines off feature to the tests in order to pass the different workflows.

[paulf81]

@ElieKadoche @Bartdoekemeijer @misi9170 @rafmudaf , we've created a new pull request where we've adapted the proposed changes of this pull request into the new v4 framework where we believe this fits really nicely. I adapted the provided example and interface changes and it should function the same way. Hope that this works for you!

[paulf81]

Going to close this now following the merge of #799