Serial-Refine Optimization not compatible with heterogenous inflows

[paulf81]

Bug description SR currently does not work with heterogenous inflows. Partly this is because the het_map isn't copied (resolved by pull request #456 ) but then also because SR automatically expands wd to the number of yaw angles to test in order to capitalize on vectorization. However, FLORIS assumes the het_map must match the dimensions of num_wd/num_ws. And throws an error. I believe the way to resolve will be to have SR automatically check for and make a matching expansion to the het_map.

An alternative perhaps could be to allow for het_map to function as a dict, so repeated wd don't require extra directions?

A still additional alternative, assume that if a het_map is defined with 1 wind direction, it automatically applies to all?

@Bartdoekemeijer in case you check these, do you have a preference?

To Reproduce If not yet merged, need to be on the branch feature/copy_het_map for error to be thrown

Then in the example 08_opt_yaw_single_ws.py, make the following change in code:

# # Load the default example floris object
# fi = FlorisInterface("inputs/gch.yaml") # GCH model matched to the default "legacy_gauss" of V2
# # fi = FlorisInterface("inputs/cc.yaml") # New CumulativeCurl model
from floris.tools.floris_interface import generate_heterogeneous_wind_map
speed_ups = [[2.0, 2.0, 1.0, 1.0]]
x_locs = [-300.0, -300.0, 2600.0, 2600.0]
y_locs = [ -300.0, 300.0, -300.0, 300.0]
het_map_2d = generate_heterogeneous_wind_map(speed_ups, x_locs, y_locs)
fi = FlorisInterface("inputs/gch.yaml", het_map=het_map_2d)

This produces the error:

ValueError: cannot reshape array of size 27 into shape (60,1,3,3,3)

Since we are only initialized to 1 wind direction and 1 wind speed, shape is assumed 3 turbines x3x3 grid. However SR has expanded the wind directions with tiling up to 60 (line 117 of yaw_optimizer_sr.py)

[Bartdoekemeijer]

I think what you suggest, I believe the way to resolve will be to have SR automatically check for and make a matching expansion to the het_map, makes sense. Though I've wondered before how het_map lives inside the FLORIS object. What happens if you initialize FLORIS with a certain het_map and then reinitialize and change the wind directions/speeds? Is het_map maintained inside the FLORIS object? Perhaps, then, it's something that shouldn't just be implemented on the Serial-Refine level, but rather on the FlorisInterface level.

[paulf81]

That is a good point, @bayc what do you think was your idea for het map? Should it be adjusted when reinitialize is called? That does seem to be most general approach? (Also nice to hear from you!! Hope you're doing well!)

[misi9170]

678 addresses this.

[misi9170]

Closing as addressed by #678