Add forecast module

[wholmgren]

@MoonRaker and I created a forecast module for pvlib. The initial discussion of this was in issue #86.

Here's a link to the documentation and our PVSC abstract:

http://wholmgren-pvlib-python-new.readthedocs.org/en/fx-master/forecasts.html
https://forecasting.uaren.org/media/pvlib_fx_pvsc_43.pdf

Basically, we use Unidata's Siphon library to pull data from Unidata's THREDDS server, standardize the variable names, and calculate irradiance components from cloud cover forecasts.

I think this PR fairly complete already, but there are plenty of opportunities for refinements and refactoring before or after merging.

The module was developed based on pvlib 0.2.1, so we'd need to make some minor changes to accommodate the work done in #93.

Let me know if you think that this idea and implementation would be a valuable addition to pvlib. I would consider packaging it separately, too, either under the pvlib organization or my own account. I'd probably squash some/all of the git history before merging.

To do:

• Add notes about geographic extent of models
• Add note about who is making the models (NCEP and NWS, both part of NOAA)
• Figure out how to allow model tests to fail due to random down time.
• Add kwargs for irradiance data processing.
• Update for version 0.3

[wholmgren]

Thanks.

What is the geographical coverage of the Unidata forecasts? If it is limited for North America, then maybe a separate package for each region would be a possibility.

GFS is global, the rest range from US (NDFD) to most of North America (NAM). I'll make a couple of notes about this in the documentation. I'll also clarify who is actually making the forecasts (not Unidata).

Maybe the same approach works with ECMWF data. There is a python api for their data as well.

I know of their API but I don't think that it provides access to their forecast data, only related products like reanalysis.

[dacoex]

Ok.

Maybe also state what frequency is used and what cell dimension in the weather model used as input. This is often a difference criteria.

[jforbess]

This looks great. I do agree with DaCoEx about not understanding the
current and future state of validation of these forecasts. Is that the next
stage of your grant?

Random note on abstract, isn't the second sentence reversed from the intent
of the first sentence? "On standard meteorology metrics, the ECMWF is
superior to the GFS by about a day. In other words, the accuracy of the GFS
at 6 days out is comparable to the ECMWF at 5 days out."

Tangentially related, I just was reminded about the MERRA historical
dataset, and even tracked down a PVSC paper comparing its accuracy to Solar
Prospector, only to discover that the work had been done by our own
@calama-consulting. It looks like the MERRA radiation flux dataset
(tavg1_2d_rad_Nx) is not yet available through the MERRA API, but that
would be a good addition to data sources when it is.
https://cds.nccs.nasa.gov/wp-content/test/MASOverview.html#Order

I am ambivalent as to whether the forecast module should be in a separate
package. I definitely think it would be good to keep it associated with
pvlib, but if it has some esoteric dependencies, maybe a second package is
a good idea.

On Thu, Feb 18, 2016 at 11:38 PM, DaCoEx notifications@github.com wrote:

Ok.

Maybe also state what frequency is used and what cell dimension in the
weather model used as input. This is often a difference criteria.

—
Reply to this email directly or view it on GitHub
#124 (comment).

[wholmgren]

@dacoex good/bad is subjective, but I'd say that the state of solar power forecasting is bad. Of course, people trying to sell forecasts say that their model is the best and people trying to get grant funding say that their model is great but would be so much better if you'd just give them a little bit of money, please, please, please. The problem is that weather is so complicated and varies so much across the world that it becomes very difficult to make objective comparisons without quickly getting lost in the details. This is perhaps even more true for clouds and thus irradiance. Finally, if you add a weather-to-irradiance-to-power black box to your analysis then it becomes harder still to tease out the real differences between forecasts.

My proposal is that the new code can make the objective comparisons a little more rigorous and a little bit easier. First, it makes it trivial to access the data related to PV generation from many U.S. weather models. Then you can use the preexisting pvlib functions on that data, or you can do whatever you want with it. If you choose the latter, hopefully you'll now be in an open source mindset and publish (in some form) your analysis code in addition to the results. Either way, it establishes a traceable, open benchmark tool for forecast comparisons.

So, like the rest of pvlib, what I'm proposing is a tool. I'm not making any claims as to the accuracy of the weather models, or the Liu Jordan model, or the SAPM, or the combinations of them. The tool certainly does not solve all problems related to objective, reproducible research in the solar power forecasting field, but I think/hope that people will find it useful.

Quick notes regarding a few other points above...

1. All weather models are a mix of approximated physics, plus a lot of parameterizations, so, they're both empirical and physical. pvlib adds another layer of empiricism: the Liu Jordan cloud-cover-to-irradiance model. This is, to me, the least interesting part of the proposal. We just picked an old, standard reference model to get started, but there's an infinite number of ways to improve this.
2. The interesting MERRA discussion perhaps suggests that much of the "forecasting" code actually belongs in a new io module (see add a io module #29), with the forecast data being just another data source along with TMY and other standard datasets. Much of the motivation for the forecasts is similar to the motivation for standard datasets such as TMY, which further suggests that they could be grouped together. I'll have to think about this more.
3. All of this is helpful feedback for how to develop the PVSC abstract into a talk or poster and a paper. I'll be the first to admit that we need to add a lot more references to the literature in the final paper. And yes, @jforbess, that is an embarrassing mix up, thank you for pointing it out.

On to the dependencies and packaging... The main new optional dependency, Siphon, is a bit esoteric at this point, but Unidata has made developing Python tools a priority for the foreseeable future, so I'm not too worried about it. Installing Siphon itself is not a big deal, but it depends on NetCDF, which requires slightly more experience/luck to compile (though not nearly as bad as scipy). The anaconda packages for NetCDF have been reliable, though. The forecast module is not imported in the __init__.py file, so if you don't install the optional dependencies then you can continue to use pvlib as if it never existed. These are not arguments for including the code in pvlib, only that it's not making it any harder to install pvlib.

Thanks again for your feedback.

[jforbess]

Yes, I brought up the MERRA data partly because this forecasting paired
with it does suggest an io module might be useful, despite my lack of
enthusiasm previously.

But let me just say, wow, a solar forecasting tool in open source! Awesome!

On Fri, Feb 19, 2016 at 12:31 PM, Will Holmgren notifications@github.com
wrote:

@dacoex https://github.com/dacoex good/bad is subjective, but I'd say
that the state of solar power forecasting is bad. Of course, people trying
to sell forecasts say that their model is the best and people trying to get
grant funding say that their model is great but would be so much better if
you'd just give them a little bit of money, please, please, please. The
problem is that weather is so complicated and varies so much across the
world that it becomes very difficult to make objective comparisons without
quickly getting lost in the details. This is perhaps even more true for
clouds and thus irradiance. Finally, if you add a
weather-to-irradiance-to-power black box to your analysis then it becomes
harder still to tease out the real differences between forecasts.

My proposal is that the new code can make the objective comparisons a
little more rigorous and a little bit easier. First, it makes it trivial to
access the data related to PV generation from many U.S. weather models.
Then you can use the preexisting pvlib functions on that data, or you can
do whatever you want with it. If you choose the latter, hopefully you'll
now be in an open source mindset and publish (in some form) your analysis
code in addition to the results. Either way, it establishes a traceable,
open benchmark tool for forecast comparisons.

So, like the rest of pvlib, what I'm proposing is a tool. I'm not making
any claims as to the accuracy of the weather models, or the Liu Jordan
model, or the SAPM, or the combinations of them. The tool certainly does
not solve all problems related to objective, reproducible research in the
solar power forecasting field, but I think/hope that people will find it
useful.

Quick notes regarding a few other points above...

1. All weather models are a mix of approximated physics, plus a lot of
   parameterizations, so, they're both empirical and physical. pvlib adds
   another layer of empiricism: the Liu Jordan cloud-cover-to-irradiance
   model. This is, to me, the least interesting part of the proposal. We just
   picked an old, standard reference model to get started, but there's an
   infinite number of ways to improve this.
2. The interesting MERRA discussion perhaps suggests that much of the
   "forecasting" code actually belongs in a new io module (see add a io module #29
   add a io module #29), with the forecast
   data being just another data source along with TMY and other standard
   datasets. Much of the motivation for the forecasts is similar to the
   motivation for standard datasets such as TMY, which further suggests that
   they could be grouped together. I'll have to think about this more.
3. All of this is helpful feedback for how to develop the PVSC
   abstract into a talk or poster and a paper. I'll be the first to admit that
   we need to add a lot more references to the literature in the final paper.
   And yes, @jforbess https://github.com/jforbess, that is an
   embarrassing mix up, thank you for pointing it out.

On to the dependencies and packaging... The main new optional dependency,
Siphon, is a bit esoteric at this point, but Unidata has made developing
Python tools a priority for the foreseeable future, so I'm not too worried
about it. Installing Siphon itself is not a big deal, but it depends on
NetCDF, which requires slightly more experience/luck to compile (though not
nearly as bad as scipy). The anaconda packages for NetCDF have been
reliable, though. The forecast module is not imported in the init.py
file, so if you don't install the optional dependencies then you can
continue to use pvlib as if it never existed. These are not arguments for
including the code in pvlib, only that it's not making it any harder to
install pvlib.

Thanks again for your feedback.

—
Reply to this email directly or view it on GitHub
#124 (comment).

[cwhanse]

Will, I’d like to applaud your efforts here. We started PVLib to improve PV modeling by promoting transparency and rigor. We don’t want to make any particular model into a standard, rather, we want the modeling process to become standardized, and make available a wide variety of models.

Your vision of the forecasting module is precisely in this spirit. The danger is that once a free solar forecasting tool is available, people will use it and stop questioning the tool itself. For this reason, I’d recommend building options which present the user choices. The specific choice (e.g., weather data source, irradiation decomposition and/or transposition models, etc.) may not be as important as having the choice presented.

Cliff

[wholmgren]

Thanks, Jessica and Cliff. Good points regarding the need for people to keep questioning the tools. I will make a few options available for the forecast irradiance data here and keep this in mind elsewhere.

[wholmgren]

closed in favor of #180.