Input array formats

[rafmudaf]

FLORIS has a pattern of allowing an input array of size 1 be expanded to the full problem size with all elements equal to the single value give. For example, the following input where wind direction and wind speed are length 2 and turbulence intensity is length 1 is allowed:

wind_direction:
- 270
- 270
wind_speed:
- 8
- 9
turbulence_intensity:
- 0.1

Internally, FLORIS expands turbulence intensity to the same length as wind direction and wind speed and applies 0.1 to all elements. In #793, the question is asked whether this pattern should apply to any array-type inputs.

In earlier versions of FLORIS, the wind directions and wind speeds were central to the problem statement of a FLORIS calculation. However, in FLORIS v4, more aspects of the problem statement are as important, and the central property is now findex. Previously, I would have said that explicitly defining all wind directions and wind speeds is a requirements, but with the new structure I don't think this holds.

UI Evaluation

So how would the input data look if we allow for any array inputs to be either 1 or n_findex?
Here are some examples:

# n_findex = 2
wind_direction:
- 270
wind_speed:
- 8
- 9
turbulence_intensity:
- 0.1

# n_findex = 1
wind_direction:
- 270
wind_speed:
- 8
turbulence_intensity:
- 0.1

# n_findex = 2
wind_direction:
- 270
wind_speed:
- 8
turbulence_intensity:
- 0.1
- 0.2

[misi9170]

To me, broadcasting up would make more sense if the variable to be broadcasted was actually a scalar, rather than a length 1 list/array. As I see it, the broadcasting is clearer with fi.reinitialize(wind_directions=270.0, wind_speeds=[6.0, 8.0, 10.0]) than fi.reinitialize(wind_directions=[270.0], wind_speeds=[6.0, 8.0, 10.0]). This would require an extra step in the handling to check if the arguments passed have attribute len.

[misi9170]

It makes it more uniform across wind_speed, wind_direction, and turbulence_intensity (rather than turbulence_intensity being a special case that is allowed to be length 1 while the others are not).

My feeling is that anything of this form should be handled on FlorisInterface---I think that the FlowField should have everything at length n_findex

[paulf81]

the only issue there would be the yaml, won't get checked at FlorisInterface level,

[misi9170]

True---might have to also have it on Floris's methods. Could just make a small function that checks the three inputs and converts them as needed; then you can call that function in the various places.

[rafmudaf]

@misi9170 On one hand, I agree that any of these preprocessing steps should happen outside floris.simulation. On the other hand, all of the inputs currently map directly to the data structures they create. At least for the develop branch, I made sure of this in #750 and #751. The changed proposed would break that relationship. Maybe it's the right move, but we should think through it. One consequence is that testing the individual classes would not cover the full suite of use cases.

d) Allow floats to mean broadcast up

Before making this change, it would be helpful to sketch out how it impacts the rest of the API including any upcoming array-inputs.

[paulf81]

Updating that #793 has been de-scoped to not address this discussion and instead closes the loop that the current understanding (len(ws) == len(wd)) and ws, wd, ti each have 1-dimension are enforced