Move FlorisInterface .reinitialize() / .calculate_wake() to .set() / .run()

[rafmudaf]

Adopt .set() / .run() flow for FlorisInterface workflows

Currently, the typical flow for using FlorisInterface is to build a workflow around the .reinitialize() and .calculate_wake() functions. #801 suggests to add an additional step between these two for setting turbine operating conditions. In the subsequent discussion (see #801 (reply in thread)), the idea to refactor this workflow resulted in the following suggestion:

fi = FlorisInterface.from_dict(...)
fi.set(
    wind_directions=...,
    wind_speeds=...,
    any_other_input=...
)
fi.run()

This pull request implements the suggested workflow by adding FlorisInterface.set() and FlorisInterface.run() and removing FlorisInterface.reinitialize() and FlorisInterface.calculate_wake().

The FlorisInterface.set() function allows for setting any of the supported inputs or operation settings individually or in batch:

# These two are equivalent
fi.set(
    wind_directions=...,
    wind_speeds=...,
    any_other_input=...
)

fi.set(wind_directions=...)
fi.set(wind_speeds=...)
fi.set(any_other_input=...)

For any parameter that is part of the input (defined in the input file or input dictionary to FlorisInterface and Floris), the .set() function creates a new Floris object with the setting changed. This matches the functionality of .reinitialize(). Therefore, changes should be batched into one .set() when possible to save the overhead of creating the new objects. In either case, the parameters that aren't provided as arguments to the function are not changed in Floris including the operation settings.

If either FlorisInterface.calculate_wake() or FlorisInterface.reinitialize() are used from v3, an error is raised pointing the user to the upgrade guide.

RIP calculate_wake() 💀

Related issue

Related to #801

Impacted areas of the software

FlorisInterface and any script or function that uses it.

[rafmudaf]

Consider this flow for multiple calculations as implemented in #823:

f = Floris.from_dict(...)

# Get power with non-zero yaw
f.set(wind_directions=..., wind_speeds=..., yaw_angles=...)
f.run()
yawed_power = f.get_farm_AEP()

# Get power with no yaw
f.reset_operation()    # Sets all operating set-points to their default
f.run()
baseline_power = f.get_farm_AEP()

This start to look like Floris is retaining memory, and this is the same paradigm we intended to remove in the shift from v2 to v3. In fact, f.reset_operation() resets the operating set-points and creates a new Floris object, so the memory is not retained. However, the user-facing API still implies that we're operating on a single instance.

@bayc I'm wondering whether you read this the same way, and if you have any feedback on this given our experience with v2 and the shift to v3. For my part, this flow feels like a backward step, but I think I'm stuck too much on the previous API's to give this a fair evaluation.

[paulf81]

@rafmudaf I noticed a test failing and traced it to a small issue in test_disabled_turbines and pushed up a fix

[paulf81]

These seems ready to merge from my point of view, only outstanding comment I see is a question on "TODO" item in the parellel_computing_interface, but that is really minor so I will approve

[rafmudaf]

@misi9170 It would be good to get your eyes here again when you have a chance. I think I've addressed the tests that we had discussed last week.

[misi9170]

@misi9170 It would be good to get your eyes here again when you have a chance. I think I've addressed the tests that we had discussed last week.

Thanks for setting those tests up @rafmudaf --- they look good to me.

[misi9170]

These seems ready to merge from my point of view, only outstanding comment I see is a question on "TODO" item in the parellel_computing_interface, but that is really minor so I will approve

I've now cleaned that up