Repeated calls to calculate wake can result in wrong wake calculations

Bug description When placed in a for loop with certain turbine layouts, calculate_wake does not return the expected values. Note: this can currently be avoided by calling fi.reinitialize() before each repeated calculate wake call, but that adds unnecessary computation.

To Reproduce Steps to reproduce the behavior:

1. Run the below code in the examples folder of FLORIS.
2. See the error in the displayed plot, where the total farm power varies with each calculate wake call.

import matplotlib.pyplot as plt
from floris.tools import FlorisInterface
import numpy as np


fi = FlorisInterface("inputs/gch.yaml")

D = fi.floris.farm.rotor_diameters[0][0][0]
layout_x = np.array([0.0, 5.0*D, 10.0*D, 0.0, 5.0*D, 10.0*D])
layout_y = np.array([0.0, 0.0, 0.0, 5.0*D, 5.0*D, 5.0*D])
fi.reinitialize(layout=(layout_x,layout_y))

n = 10
wf_pow = np.zeros(n)
for k in range(n):
    fi.calculate_wake()
    wf_pow[k] = fi.get_farm_power()

plt.figure(1)
plt.plot(wf_pow)
plt.xlabel("calculate wake call #")
plt.ylabel("farm power")
plt.show()

Expected behavior Expected behavior would be that calculate wake would return the same power with repeated calls where no inputs have changed (example shown below).

Floris Version Release v3.0.1

System Information (please complete the following information):

• OS: Ubuntu 20.04
• Library versions
  • matplotlib - 3.5.1
  • numpy - 1.22.1
  • pytest - 6.2.5
  • scipy - 1.7.3
  • pandas - 1.4.0

Additional details This is do to the current inclusion of the finalize call within the solve wrapper, which unsorts the turbines. The turbines are then not re-sorted from upstream to downstream (which occurs in the initialization step) before the next calculate wake call, which results in incorrect wake calculations.

[bayc]

One design intent of the v3 architecture was to consider each calculation a unique process that begins and ends. This was the idea with creating a new Floris object in FlorisInterface.reinitialize() instead of making changes to the Floris data directly. However, this change in functionality violates that idea since now we are expecting that each calculation will retain data from a previous calculation. Without considering performance, this would be resolved by doing the sort / unsort every time we execute FlorisInterface.calculate_wake(), like @bayc mentioned in the original post. Practically, though, do we have a guess at the performance impact of that in a realistic use case?

I don’t have an idea of performance, but that is an interesting thought, and would be like how we did the calculations in v2, sorting each time.

[bayc]

Just so I understand the problem a bit more, what’s the scenario for repeatedly calling FlorisInterface.calculate_wake() without changing anything (i.e. without FlorisInterface.reinitialize())? One might be to compare with and without yaw control.

This is an issue in yaw optimizations that don’t need to call FlorisInterface.reinitialize() where they are just updating yaw angles and not turbine positions or wind conditions.