Thinking about lookup_table_toolbox and wfc_framework

[paulf81]

Hi @Bartdoekemeijer @ejsimley and @misi9170 , I had an action with myself to move the hysteresis code out of lookup_table_toolbox and into flasc (so that it would be public), but before started, was thinking actually since the hysteresis design is not related to SCADA comparison, maybe it better belongs in wfc_framework, in that that contains more things related to practical design (and I think some things now redundant to flasc and flasc_cookiecutter_template). Plus I think wfc_framework is still maybe private?

What do you think we should do here, considering all the other moves we've got in progress? Would a sequence like:

• Move hysteresis and other design codes over to wfc_framework
• Clean out the parts of wfc_framework with are redundant to flasc and fct
• Make wfc_framework public?

[ejsimley]

I generally agree with the steps you propose. wfc_framework currently doesn't have features for designing lookup tables (except in the examples), hysteresis directions, etc. It focuses more on the dynamic implementation of wind farm control. But I think it makes sense to add modules to help with the design of these lookup tables. As far as making wfc_framework public I think we first need to consider if/how to handle the optional use of consensus. After we resolve that it would be great to make it a public repo.

[Bartdoekemeijer]

maybe it [hysteresis] better belongs in wfc_framework, in that that contains more things related to practical design

Agreed!

• Move hysteresis and other design codes over to wfc_framework
• Clean out the parts of wfc_framework with are redundant to flasc and fct
• Make wfc_framework public?

Also agreed! It would be great to have wfc_framework public-facing. We just have to make sure nothing confidential still resides in those Git histories. For example, I'm not sure if any of the turbine yaw controller algorithm is confidential.

[paulf81]

These are great points, and I think I have an idea on consensus, we could link to some open source approximation line "cluster averaging" but then have some links for proper consensus, with a note to reach out to us for a license. This would be akin to how we do optimization now, slsqp is for free, but you need a license for SNOPT. What do you think of this @jrannoni ?

[Bartdoekemeijer]

I like this idea!

[paulf81]

ok! I can now put in to get a public facing github.com/nrel site for wfc_framework but thought before I do I should make a quick check, do we love that name? Right now on the front page the code is described as:

A code skeleton demonstrating the communication between a wind farm controller and wind turbine controller. This package can be used to simulate wind farm controllers and interactions over a period of time."

If we add hysteresis we're broadening a little from what seems like a way to analyze wfc with respect to dynamics to including help to design of the realized in-place control system, so the focus of the package is something like:

FLORIS: Goes all the way up to the design of the steady offset values
wfc_framework [or new name]: Design of "balance of station" of the wind farm controller (filters, hysteresis, tuning to turbine dynamics?)
FLASC: Analysis of results

So wanted to add just a little more discussion @ejsimley @dzalkind @Bartdoekemeijer @misi9170 @rafmudaf @jrannoni @bayc should we keep the same name or a new name?

[Bartdoekemeijer]

I guess the name depends on what objectives we assign to wfc_framework. The way it is now, FLASC is focused on SCADA analysis but also includes some wake steering design functionality like lookup_table_tools.py. With the going public of wfc_framework, perhaps the right hierarchy is:

• FLORIS: Focused on yield models, simulation, layout & wind farm control optimization functionality
• FLASC: Focused on SCADA analysis (both nominal operation and in field experiments/toggle tests) and comparison between SCADA and yield models (mainly FLORIS).
• wfc_framework: Focused on wind farm controller design. Includes functions for creating wake steering lookup tables in specific formats, simplifying/approximating them with linear splines, different ways to visualize the offsets. Also, includes timeseries simulations and simplified yaw controller logic to assess the change in cumulative yaw travel and number of yaw events. Simplified timeseries simulation to test logic for practical implementation.

These packages all come together in flasc_cookiecutter_template.

____ windfarm_example
  |____ setup_floris_model (FLORIS)
  |____ raw_data_processing (FLASC & FLORIS)
  |____ model_validation (FLASC & FLORIS)
  |____ visualize_energy_ratios (FLASC & FLORIS)
  |____ windfarm_controller_design (FLORIS & wfc_framework, possibly also consensus-based methods)

Then, perhaps we should also rename flasc_cookiecutter_template to be more inclusive of different repositories, perhaps windfarm_cookiecutter_template or wf_cookiecutter_template.

[misi9170]

I think wfc_framework could go two ways:

1. We could keep it as a `framework' that control developers are expected to plug their controllers into. I do think it should ship with some basic options for wake steering and consensus (spatial averaging), but those would be kept simple (although good enough to provide some exposition of the benefits). Then, developers could define their own packages that plug in (possibly inheriting from our base classes). We could demonstrate this "plugging in" with a hysteresis package (for instance) and consensus (behind paywall/agreement). In this case, the name wfc_framework is still good I think. Pros: simple, serves the public nicely as well as being useful for academics looking to try out other controllers. Cons: plug-in packages would be their own repos, which could make maintenance more difficult (or easier? I'm not sure).
2. We use wfc_framework as the main repository for all of the wind farm controllers we develop. wfc_framework would then be in constant development, with new options being added as we develop them (e.g. hysteresis). In this case, the name should probably change to something like wind_farm_controller or similar. Pros: all tools would be readily available if someone just want to try it out. Cons: not sure whether constant development of a repo is good or bad?

[paulf81]

I think in reading these we're all pretty close in our feeling. Putting my two cents back in, I think in my mind another way we could think about this is if we keep FLORIS and FLASC essentially unchanged, then wfc_framework is a good place to house what doesn't belong in either. This I think gets us back to Bart's breakdown another way. Basically with FLORIS you can get a steady set of yaw angles (even with uncertainty) but wfc_framework provides all the methods we use for practical implementation including consideration of turbine yaw control dynamics. This I think then produces the table you have Bart, just wanted to work it out in text.

Maybe then, just spitballing, if there is FLORIS, and then FLORIS +SCADA = FLASC, then this new one could be FLORIS + Controller Design = FLOCO

[Bartdoekemeijer]

@misi9170 I would definitely be in favor of option 2! It'll be a more active repository but thereby also easier to find and grab attention. Separate modules might just not get enough attention, and perhaps not worth the additional overhead in tests/documentation/automated GitHub actions. I think your breakdown makes a lot of sense Paul. Also, FLOCO sounds great!