Improvements to wind rose (and maybe a new similar tool) in v4

[paulf81]

HI @rafmudaf @ejsimley @misi9170 @christiannvaughn @bayc @Bartdoekemeijer , @genevievestarke thought I would open a discussion here collecting some discussions I had with each of you.

One point is on the wind rose tool. @ejsimley and I think were discussing this could be a good place to address for example Issue #713 in v4. V4, inside simulation, can have a fixed assumption that there are N_condition wd, ws and TI, which have either the same TI across all conditions (default), or assigned like wind_speed and wind_direction at reinitialize. However WindRose could have some capabilities to have built-in methods to generate series of TI according to some IEC standard, or custom function. This could make having TI a function of wind-speed a fairly simple / built-in assumption to take on.

Building on this, @ejsimley and I were thinking users may want to define market price directly, as TI, or may similarly want to assume some relationship between market price and wind speed. This could be another feature of WindRose (or like PriceRose).

Abstracting out, these tools can provide a convenient way to go from distributions/relationships, to series ready to be inserted in v4, and can keep the internals of simulation/ simple because it will always expect either a scalar or a single vector of data.

[misi9170]

I like this idea. If I'm understanding what you are saying, other "input"-type parameters could then be scheduled as a function of wind speed and wind direction (for example, TI = TI(ws, wd), or price = price(ws, wd)), which are then mapped into the condition tuple if the user wants.

An extension on this that I would like to see (perhaps not in v4.0, but maybe in a later version) could be to have similar control functions, that is, yaw_angles = yaw_angles(ws, wd), or further, yaw_angles = yaw_angles(condition) where condition is the tuple. Then, users wouldn't have to actually specify the yaw angles for each input condition---the yaw_angles would be looked up based on the condition. Of course, similar things could be done for helix etc, and maybe even curtailment if, say, the price signal is negative or something.

The user would need to supply the lookup function (e.g. price(wd,wd), yaw_angles(condition), etc) and instantiate a "rose" for the FLORIS object to use.

[misi9170]

Also, @rafmudaf and I talked briefly about where this would live---I think it makes sense to have this functionality live in FLORIS, but have it imported and tightly integrated into FLASC too

[paulf81]

these are good suggestions @misi9170 , like , a set of tools that map things from a ws/wd table to FLORIS conditions / samples, where WindRose is one case, I think it's a good idea

[ejsimley]

I like the idea of extending the scheduling of inputs as a function of wind speed/direction to control settings like yaw offset too. As far as TI and electricity prices, I think it would be useful to allow custom lookup tables but also include some built in functions based on empirical relationships that people can use, like TI(ws) using the IEC definition and price(ws, wind penetration %) based on findings from LBNL for example.

[paulf81]

this is sounding good to me, I think a way to think about this is that the simulation/ files will always expect simple lists of things, and then WindRose, or similar tools, can be used to go from distributions and relationships to those expected lists

[misi9170]

@rafmudaf @paulf81 spoke a bit more about this early today, summarizing that discussion

• No disagreement with existing discussion above
• This module might be moved up a level in the code, so that rather than being in floris/tools/wind_rose.py, it might be in a new upper level module floris/wind_rose/ (name TBD).
• structurally, we could consider having various "roses" (again, name TBD), that describe a certain parameter as a function of the three core atmospheric variables (wind direction, wind speed, turbulence intensity). The WindRose object would be a case where the parameter is the probability of occurrence, i.e. P(wd, ws, TI), possibly with the third dimension collapsed if no information is availability on variation with TI.
• As @ejsimley mentioned, we may want the capability of generating a rose based on a functional relationship.
• The TI dimension is TBD, since TI is not always (perhaps not often) given, and we may want the output parameter of a certain rose to be TI (again, as @ejsimley mentions above)
• Some roses will be more tightly integrated with the main simulation process. For now, WindRose is mostly used in postprocessing (e.g. to compute AEP), but others (e.g., a rose specifying TI or one specifying yaw angles) may need to be evaluated before running calculate_wake(). This is likely something that would take place within reinitialize().
• According to the above, we may need to have the user specify (in the reinitialize() call) whether to use a rose to "fill out" some elements of the condition tuple