Consolidate control setpoints for better future-proofing

[misi9170]

In Floris v3 and earlier, the only control setpoints available to the user were yaw_angles. As of Floris v4 and the introduction of operation models, we now allow various new control setpoints to be passed in at the top level (currently, power_setpoints #783 and the various controls needed for the Helix wake mixing model #842 ).

Each time a new control setpoint is added, it has to be piped through various levels of the FLORIS code. This often gets overlooked, as was the case in #1022 .

I'd like to consider whether we can create a data structure that stores all control setpoints in a unified object that can be passed through the code more readily. I'm imagining that this could be a dictionary control_setpoints={"yaw_angles": ... , "power_setpoints": ...}, where each key specifies a (valid) control setpoint and each value is a numpy array of shape n_findex x n_turbines. These would then be validated and mapped to a similar control_setpoints_sorted dictionary.

As well as making new setpoints simpler to include, I think this will also help with reducing the findices in certain cases, e.g. #963 .

Of course, we'll need to maintain support for the keyword arguments (yaw_angles, power_setpoints, etc) already in place in FlorisModel.set(). However, we'd be able to take those and add them to the dictionary/control setpoints data structure, and can add a deprecation warning at some point in the future.

Relevant issues/PRs (I'll add to this list as I find things):
#963
#1027
#783
#842
#964
#1080
#1090
#1107
#454

[paulf81]

Fully agree, I think this will help guard against future errors, and I like the approach you propose

[misi9170]

Another option would be to create a special data class to handle them. Users would still pass them in the dictionary as described above, but maybe in the set() procedure, they'd get used to instantiate a new ControlSetpoints class that had validators on the type, shape, etc, a bit like the way that the turbine dictionaries get transferred into Turbine objects. Then, control_setpoints_sorted could be another instantiation of ControlSetpoints.

[paulf81]

A class gives a lot of ability to manage this all neatly, add tests and checks, and facilitate back compatibility,

[misi9170]

Perhaps it would work to make ControlSetpoints a user-level class that stores the control setpoints in n_findex x n_turbines format, and then have a possible future the op rose #964 be a subclass of ControlSetpoints.

[paulf81]

good idea