Add prestep to calculate_wake() call to set turbine operation

[misi9170]

In v3, wind conditions are passed to the FlorisInterface object with the reinitialize() method, whereas turbine operating setpoints (in particular, yaw_angles) are set with the calculate_wake() method.

I proposed that we add a middle step set_operation() to the usual procedure to set the turbine operation, and have calculate_wake() take no arguments. That is, rather than the existing paradigm

fi = FlorisInterface('inputs/gch.yaml')
fi.reinitialize(wind_speeds=[8, 9, 10], wind_directions=[270, 270, 270], layout_x=[0, 1000], layout_y=[0, 0])
fi.calculate_wake(yaw_angles=[[20, 0], [10, 0], [0, 0]], power_setpoints=None)

we switch to

fi = FlorisInterface('inputs/gch.yaml')
fi.reinitialize(wind_speeds=[8, 9, 10], wind_directions=[270, 270, 270], layout_x=[0, 1000], layout_y=[0, 0])
fi.set_operation(yaw_angles=[[20, 0], [10, 0], [0, 0]], power_setpoints=None)
fi.calculate_wake()

To me, this is more explicit, and would also (in my opinion) more cleanly address the issue raised in #449, that turbine operating setpoints (yaw_angles) are "forgotten" before visualization calls (in the proposed paradigm, set_operation() would be called once and any setpoints would be saved on the FlorisInterface object).

We've added various new "setpoint"-type arguments to Floris with v4 (adding power_setpoints #783, disable_turbines in #799, and will be adding more for the Helix wake mixing model #796). Many of these need to be checked for adequacy and handled before setting on fi, and that handling currently takes place in calculate_wake(). This suggestion would also simplify calculate_wake() and move the handling of these setpoints to the proposed set_operation() method.

@paulf81 pointed out that this is a paradigm change that will break many users' scripts for running Floris. To maintain back-compatibility in v4, we could consider allowing calculate_wake() to take only yaw_angles as an optional argument (the only one available in v3); if the user specifies yaw_angles in calculate_wake(), a deprecation warning would be raised and the new set_operation() method would be called with yaw_angles passed through to it before executing the wake calculation. More generally, calculate_wake() could raise a deprecation warning if any argument is passed to it, and all arguments passed could be passed through to set_operation() (this would allow users to specify all setpoints in with calculate_wake() call until deprecation).

On the other hand, various other changes at the user interface level (time series enforcement, in particular, along with possible renaming of the FlorisInterface) will mean that many scripts will need to be updated regardless.

[paulf81]

@misi9170 I think this is really well-thought-through proposal and agree with all of it. I'm in favor! @rafmudaf , @bayc @ejsimley thoughts?

[Bartdoekemeijer]

I like this! My only thought is: what happens if you reinitialize to a new set of wind conditions after setting your turbine operation?

fi = FlorisInterface('inputs/gch.yaml')
fi.reinitialize(wind_speeds=[8, 9, 10], wind_directions=[270, 270, 270], layout_x=[0, 1000], layout_y=[0, 0])
fi.set_operation(yaw_angles=[[20, 0], [10, 0], [0, 0]], power_setpoints=None)
fi.reinitialize(wind_speeds=[9.5], wind_directions=[270])

[paulf81]

@misi9170 to your question, this would be my only doubt. On the one hand, I really like having just the .set function, and .calculate_wake (maybe now .run?) The doubt I have is I thought an operation like yaw_opt was taking advantage of keeping wind conditions/layout fixed while only making changing calls to controls. But perhaps the .set function could be smart enough to not make the reinstatiate call if it's not necessary?

[misi9170]

I agree; it shouldn't be too difficult to just handle whether or not reinstantiation is needed depending on the inputs passed. .set() -> .run() does have a nice ring to it.

[rafmudaf]

The .set() function could go something like this:

def set(...):

    # Do the things to export the Floris object to a dictionary

    # Change any of the inputs
    needs_reinit = False
    if wind_directions:
        new_dictionary["wind_directions"] = wind_directions
        needs_reinit = True
    if etc:
        ...

    if needs_reinit:
        f = Floris.from_dict(new_dictionary)

    # Change any of the operation settings
    if yaw_angles:
        f.farm.yaw_angles = yaw_angles  # might require a setter method on Farm
    if etc:
        ...

[rafmudaf]

@misi9170 I agree, I also like the idea of

f = Floris.from_dict(...)
f.set(
    wind_directions=...,
    wind_speeds=...,
    any_other_input=...
)
f.run()

[paulf81]

This sounds great to me!

[misi9170]

As I'm now looking into bring the ParallelComputingInterface() over to v4, this makes even more sense---in v3, there is special handling for all of the top-level calls get_turbine_powers(), get_farm_power(), get_farm_AEP() to deal with splitting the yaw_angles between the workers. This will get more complicated with the additional operation keyword arguments (power_setpoints etc). If there is a separate set_operation() call, that needn't be parallelized; those setpoints would then be split over the workers internally (in the _preprocessing() method, which would now take no arguments) much more cleanly.

[misi9170]

The workflow discussed here (set() -> run()) was implemented in #823