Architectural considerations for next gen FLORIS

[rafmudaf]

Dimension consolidation:

• Collapse the two grid dimensions to just 1

Optimize CPU cache in array operations

[misi9170]

Control setpoints handling #769
Operation rose #964
Reconsider UncertainFlorisModel as a subclass of FlorisModel
Make use of floris_float_type ubiquitous

Deprecated code to remove:

• ParallelFlorisModel

Less clear ideas:

• Possible Grid classes consolidation once two grid dimensions are reduced
• Solver refactor/unification
• Solver with "standard" n_turbines x n_turbines structures (second turbine dimension replaces grid dimension in some cases)
• Generalize wake combination models

[misi9170]

• Require that all inputs to set are either arrays/array-like of the correct dimension (n_findex or n_findex x n_turbines) or they are "scalar" (e.g. a single string for turbine_type, or a single float), which will then be broadcast. Some inputs will continue to require only "scalar" inputs
• Create a dimension checker utility that broadcasts scalars to the correct dimensions.
• Create a "singleton" wind data type, that accepts a scalar wind_direction, wind_speed, and turbulence_intensity, for ease of use in visualizations etc.

[misi9170]

Good suggestion from @RRiva to provide a more flexible way of defining and assigning custom solvers in FLORIS here #1131

[misi9170]

If we can reduce the number of grid types, we may also be able to simplify the types of "solve" operation on Core, so that solve_for_points, solve_for_velocity_deficit_profile, solve_for_viz could be unified. This may also help to simplify ParFlorisModel.

[Bartdoekemeijer]

Not sure if this is architectural, so please delete/move if needed.

• Separating between neighboring wind farm turbines and internal wind turbines. This is not really important for a single simulation, but is very useful for layout and wake steering optimizations. For example, wakes of external turbines do not change with the optimization variable and thus only need to be calculated once. This would require some sort of "memory" and/or allowing the solver to recalculate the wake losses and power productions of only a subset of turbines.

[misi9170]

Interesting idea, thanks @Bartdoekemeijer ! I think we can just generally collect ideas here, they don't need to be strictly architectural :)

To your point, the way we have done this in the past is to run the external turbines only first and sample velocity points in the vicinity of the internal turbines, then use those velocities as a heterogeneous background flow when performing layout/wake steering optimizations. It's not a perfect correspondence though, and your suggestion would certainly streamline things at the user end!