Bug report: FLORIS 2.5 is not able to handle ngrid=1 correctly

[gogannes]

FLORIS 2.5 is not able to handle ngrid=1 correctly

The ngrid option does not work correctly for ngrid=1.

I know that most people may not use 2.4 anymore, but for those who may have to use it still in some cases, this issue may help if ngrid=1 is chosen.

I believe this isn't an issue with FLORIS 4.x anymore, as the similar issue is mentioned within the comments of grid.py: "If a grid resolution of 1 is selected, create a disc_grid of zeros, as np.linspace would just return the starting value of -1 * disc_area_radius which would place the point below the center of the rotor. (turbine_grid_points)."

How to reproduce

import numpy as np
import floris.tools as wfct

for ngrid in [5, 4, 3, 2, 1]:
    fi = wfct.floris_interface.FlorisInterface("examples/example_input.json")
    fi.reinitialize_flow_field(layout_array=[[0], [0]], wind_speed=6, wind_direction=0)
    fi.change_turbine([0], {"ngrid": ngrid})
    fi.calculate_wake(no_wake=True)
    print(f"turbine power for ngrid={ngrid}: {np.array(fi.get_turbine_power())}")

Relevant output

turbine power for ngrid=5: [702300.90048392]
turbine power for ngrid=4: [701715.73960506]
turbine power for ngrid=3: [700546.00421529]
turbine power for ngrid=2: [697099.02181379]
turbine power for ngrid=1: [602547.23424941] << changing from ngrid=2 to ngrid=1 affects turbine power significantly!

How to fix

in flow_field.py, replace:

yt = np.linspace(
    x2 - pt,
    x2 + pt,
    ngrid,
)
zt = np.linspace(
    x3 - pt,
    x3 + pt,
    ngrid,
)

by

if ngrid == 1:
    yt = [x2]
    zt = [x3]
else:
    yt = np.linspace(
        x2 - pt,
        x2 + pt,
        ngrid,
    )
    zt = np.linspace(
        x3 - pt,
        x3 + pt,
        ngrid,
    )

and the output changes to

turbine power for ngrid=5: [702300.90048392]
turbine power for ngrid=4: [701715.73960506]
turbine power for ngrid=3: [700546.00421529]
turbine power for ngrid=2: [697099.02181379]
turbine power for ngrid=1: [707405.81137472] << now the power value is correct.

Floris version

2.5.1

System Information

• OS: Windows 11 Pro
• Python version: Python 3.9.13

[paulf81]

HI @gogannes, thanks very much for your post. Version 2.5 is unfortunately a bit of a ways back and harder for our team so we don't activity maintain it anymore. That said your solution seems very direct and sensible and I really appreciate you proposing it. If you wouldn't mind to submit it as a small pull request, that will allow us to run the tests and do a short review and we can merge it.

[gogannes]

Great that you plan to include this fix in 2.5. I didn't even expect that you would update it anymore, but that's even better. Due to some specific reasons I sometimes (and maybe others as well) still need to use 2.5.

I just submitted a tiny pull request, but it seems that the all macos tests failed because the python versions were not found.
Please let me know if you need anything else to be able to merge it.

Best,
Johannes

[paulf81]

Thank you for the PR @gogannes ! And then lastly, I wanted to mention, in case a use case keeping you on version 2 is wind direction heterogeneity, I wanted to see if you noticed @misi9170 's #954, which will add this feature back in to Floris v4 via warping.

[misi9170]

Closing as addressed in #1008

[misi9170]

Hi @gogannes ,

Just to close the loop here, we merged your pull request last week and today released a patch release for FLORIS v2 (v2.5.2) that includes your fix. Thank you!

Misha

[gogannes]

@misi9170 and @paulf81 Thank you for merging and even more for your work on FLORIS in general!