Feature request: Allowing complex topology

[Bartdoekemeijer]

Is your feature request related to a problem? Please describe. Whenever a turbine has a different relative rotor position (vertically) due to a complex topology, it feels like I am hacking the FLORIS object. Namely, what I end up doing is incrementing each turbine's hub height with the ground height w.r.t. sea level or other reference value. Something along these lines:

# Define complex topology
layout_z = np.array(...)

# Define a zero point, e.g., min. of all turbines (z0)
if normalize_terrain:
    z0 = np.min(layout_z)
else:
    z0 = 0.

# Shift all the turbine hub heights accordingly
for ti in range(len(fi.layout_x)):
    hub_height_z0 = fi.floris.farm.turbines[ti].hub_height
    hub_height_z = layout_z[ti] - z0 + hub_height_z0
    fi.change_turbine([ti], {'hub_height': hub_height_z})

The problem is that this is a somewhat roundabout process, that we lose track of what specified_wind_height corresponds to if its value was set to -1, and that layout_z is not included in the .json file and therefore needs to be defined somewhere externally.

Describe the solution you'd like Similar to in #223, I would like layout_z to be defined in the .json file. If there is a single turbine type and layout_z is an array with all the same value, then the definition of specified_wind_height is not ambiguous. In any other situation, it must force the user to specify its value manually.

Describe alternatives you've considered I now have a practice where I create a class for these types of wind farms, wherein I contain all these operations. That way, I can still simply call a wind farm using a single command and get a floris object in return.

Additional context This issue is somewhat related to Issue #223.

[bayc]

I believe we can address this in v3.1, and want to add a comment here to note that. Thanks Bart!

[rafmudaf]

@bayc I've created a v3.1 milestone and added this to it