extending SFA to wind power analysis

[wholmgren]

I'm frequently asked what we'd need to do to support wind power forecast analyses in the Arbiter. Technically it works now if you ignore the solar specific items and hack your way around the solar plant metadata. So for this issue I'll interpret the question to mean: what do we need to do to support wind power as robustly as we support solar power?

I'll update the list below with potential new requirements as they're discussed in this issue or elsewhere.

• [ ] replace documentation and report text references to "solar" with "solar and wind" or "wind" where appropriate
• [ ] create a datamodel.WindModelingParameters similar to datamodel.PVModelingParameters
• [ ] create a datamodel.WindPowerPlant similar to datamodel.SolarPowerPlant. The SolarPowerPlant doesn't have anything particular to solar aside from the modeling parameters type hint, so it could easily be generalized to PowerPlant. A WindPowerPlant might need richer metadata for specifying individual turbine locations and specs. There are probably enough forecasters interested in turbine by turbine forecasts vs. plant forecasts that we need to think hard about these metadata issues as well as aggregation.
• [ ] create new wind variables like wind_80m through wind_120m or maybe just wind_hub_height. maybe users would want us to track direction or shear too.
• [ ] might need to track other weather variables for things like icing
• [ ] data validation toolkit needs new limit checks (limits exceeded and clipped are currently nighttime-aware), maybe other more sophisticated checks. icing and high speed cutouts come to mind.
• [ ] reference wind power data
• [ ] reference wind speed data at hub height
• [ ] implement a reference forecast based on NWP data using simple turbine metadata
• [ ] track aggregates of wind and solar, potentially with another level of aggregation

[williamhobbs]

You could also consider adding load forecasts (e.g., building electric load, distribution feeder load, or ISO/RTO etc. balancing area load) and/or net load forecasts (e.g., net after solar). We recently completed a building-level load forecasting trial with EPRI. EPRI also created a reference forecast model which might be easy to implement.

[wholmgren]

@williamhobbs thanks, it's definitely a good idea to keep those applications in mind as we think about refactoring to support wind.

We put a little bit of thought into load forecasts earlier this year when SETO announced their FY20 funding that included a subtopic on AI/ML for net load forecasts. That subtopic actually specified that awardees are supposed to use Solar Forecast Arbiter to assess their forecasts. SETO has not yet announced the winner(s) of those awards, but I expect we'll need to rethink the "sites", "observations", and "aggregates" model for really robust support of their forecasts. A datamodel that allows for building --> feeder --> substation --> load pocket --> BA/ISO could also allow for more granularity in wind and solar. I'd also like to see a broader stakeholder engagement effort to better understand the requirements.

For the record, we do already support basic analyses of "net load" in that you're allowed to specify that as the variable type for an observation or forecast. Also the reference data set includes observations and reference forecasts for the US ISOs. For example, here's a link to the CAISO "site": https://dashboard.solarforecastarbiter.org/sites/c52b4b26-bfd7-11ea-adc8-0a580a800344/ The reference forecasts are just based on persistence, so there's a lot of room for a more sophisticated (but still understandable and transparent) reference forecast.