Repeated calls to calculate wake can result in wrong wake calculations

[bayc]

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.

[rafmudaf]

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.

[rafmudaf]

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?

[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.

[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.

[rafmudaf]

Thanks for the additional context @bayc.

How would the _unsorted variables be used directly? Do we need to maintain these for some post processing?

[bayc]

Yea, the _unsorted variables are what floris_interface interacts with, and what the user would see, for post-processing.

[rafmudaf]

The remaining task here is to include the description of the _sorted and _unsorted variables in the docs such as in Background and Concepts.