Update uncertainty interface to 4d, new API

[paulf81]

Update uncertainty interface to 4d, new API

This pull request updates UncertaintyInterface to the v4 4d structure and the new set/run api currently in the fi_api branch. In doing so it resolves Issue #516 since uncertainty will now work equivalently to time series or wrapped wind rose.

The UncertaintyInterface, unlike previous implementatons, inherits the FlorisInterface and overloads certain functions to implement wind direction uncertainty (in practice this was the only type used). As before it uses gaussian averages of perturbations, but makes greater use of rounding and numpy reshaping and summing methods to achieve this result. It reimplements set (leaving run as is), as well as get_turbine_powers, get_farm_power, get_farm_aep to return this uncertain result. Parameters of uncertainty are passed in at initialization.

Pull request includes unit tests of some of the underlying functions, and an update of example 20_ to show the new usage.

Related issue

#516

Impacted areas of the software

uncertainty_interface.py

[rafmudaf]

Maybe not here, but in general we should pick either "wind_direction" or "wd" for wind direction named arguments.

[rafmudaf]

And same for the other related input arguments

[paulf81]

Yeah, I would be happy either way, with maybe a slight preference toward wd_ for succinctness in this case

[rafmudaf]

Thanks for addressing my comments @paulf81. Overall, this is looking pretty good to me.

[paulf81]

@rafmudaf and @misi9170 , just to close a loop here, @misi9170 added some tests of applying yaw angles to the uncertainty interface that threw some unexpected errors. I tracked down two seperate issues:

1. One is a problem of passing lists, or integers, to yaw_angles in the set function to FlorisInterface. I made a new pull request for handling that one ([Bugfix] Cast yaw angles to np.ndarray on set #828 )

2. I realized that having one saved internal floris_interface was a bug, because in some places I expected it to hold the un_expanded conditions and in others the expanded. This works fine if you call set once, but falls apart after that. However, the solution of holding two seperate fis, with the expanded created every time you run _set_uncertain, I think clears everything up. This change is now in the code.

[paulf81]

Hi @rafmudaf and @misi9170 , we talked today about possibly removing the un-expanded FLORIS interface, I started making the changes tonight (storing the dict instead) but there did seem to be some trade-offs, mainly I think in the set function the operation would be to declare a new FLORIS object, and again only store the dict. I think it clearly could be done, but if you wouldn't mind having a quick look and concurring it should be done (versus the current version's memory usage but clearer syntax), let me know what you think and I'll make the change

[misi9170]

Hi @rafmudaf and @misi9170 , we talked today about possibly removing the un-expanded FLORIS interface, I started making the changes tonight (storing the dict instead) but there did seem to be some trade-offs, mainly I think in the set function the operation would be to declare a new FLORIS object, and again only store the dict. I think it clearly could be done, but if you wouldn't mind having a quick look and concurring it should be done (versus the current version's memory usage but clearer syntax), let me know what you think and I'll make the change

I guess an option would be to create a dict direction rather than instantiating a new FLORIS object and then exporting it to a dict. The code for that (building a floris_dict) is in FlorisInterface._reinitialize(). It doesn't seem great to copy that code into UncertaintyInterface, but we could consider having a standalone function that builds a floris_dict that both FlorisInterface._reinitialize() and UncertaintyInterface.set() call. But, honestly, that might be overdoing it; I'd say that, for now, it's probably fine to just go ahead and instantiate a FLORIS object (and allocate memory to it); and then convert it to a dict with .as_dict() and (presumably) release the memory again. It's not super elegant, but at least it's easy with the methods we already have in place.

[paulf81]

Hi @rafmudaf and @misi9170 , we talked today about possibly removing the un-expanded FLORIS interface, I started making the changes tonight (storing the dict instead) but there did seem to be some trade-offs, mainly I think in the set function the operation would be to declare a new FLORIS object, and again only store the dict. I think it clearly could be done, but if you wouldn't mind having a quick look and concurring it should be done (versus the current version's memory usage but clearer syntax), let me know what you think and I'll make the change

I guess an option would be to create a dict direction rather than instantiating a new FLORIS object and then exporting it to a dict. The code for that (building a floris_dict) is in FlorisInterface._reinitialize(). It doesn't seem great to copy that code into UncertaintyInterface, but we could consider having a standalone function that builds a floris_dict that both FlorisInterface._reinitialize() and UncertaintyInterface.set() call. But, honestly, that might be overdoing it; I'd say that, for now, it's probably fine to just go ahead and instantiate a FLORIS object (and allocate memory to it); and then convert it to a dict with .as_dict() and (presumably) release the memory again. It's not super elegant, but at least it's easy with the methods we already have in place.

Ok @misi9170 , I made the change, now the unexpanded FI is only created as needed and only the dictionary version is saved. One place we might just want to double check ourselves, does the dictionary save the values of yaw_angles/power_setpoints? If not repeated calls to uncertainity_interface.set() might work a little differently in this version than the previous where we hold the entire fi in some cases, but I'm not sure,

[misi9170]

@paulf81 no, the dictionary doesn't hold the yaw_angles and power_setpoints; unless those are saved elsewhere, they'll be lost, so we might need to put in special handling for that since it would be nice if that was consistent between FlorisInterface and UncertaintyInterface. See here, where the setpoints are "replayed" over the newly instantiated FLORIS object. That won't work directly in the UncertaintyInterface, but they could be saved on hidden attributes until they are needed (if they are needed).

[paulf81]

ok @rafmudaf and @misi9170 , tonight it:

1. Reverted this back to using a seperate FlorisInterface (rather than dict, a little wasteful but safer)
2. I merged v4 back in following the merge into v4 of the change to layout_visualization.
3. Made sure I had addressed previous hanging comments

Think it's now ready,

[paulf81]

@rafmudaf good to merge this one?