If NWP-based reference forecasts are going to be in future feature additions, it might be helpful to go ahead and add relevant NWP data to solarforecastarbiter/io/fetch/nwp.py. That way, anyone that is already fetching and archiving NWP data will have a useful historical dataset.
For example, 0.25 degree GFS has temperature, pressure, and u- and v- components of wind at 80 meters above ground (https://www.nco.ncep.noaa.gov/pmb/products/gfs/gfs.t00z.pgrb2.0p25.f003.shtml). It also includes u- and v- wind at other levels. I would recommend at least grabbing 100 meter (the highest), maybe 50 meter as well (next one below 80 m).
I would be willing to work on this for a pull request, but I'd be interesting in a few bits of feedback first:
Is adding NWP-based wind reference forecasts in current scope/plans?
If adding wind-related data to the fetch process is worthwhile, should it be enabled by default, or added as some form of option for the fetchnwp CLI function? In the case of GFS, I think it would add 4-8 new values in addition to the existing 9 (?), so 50-100% increase in resulting data volume (I'm assuming it increases final netCDF file size by about that much as well). [edit: We could also create new model maps that are called from solararbiter fetchnwp, e.g., gfs_0p25_wind as an alternative to gfs_0p25]
Related, how do we decide which parameters/levels to add?
For reference (no pun intended), I think all the changes would be in the code linked below. For GFS_0P25_1HR, as an example, I think we would only need to add the following lines [edit: plus modify NC_TBL and maybe other minor changes]:
If NWP-based reference forecasts are going to be in future feature additions, it might be helpful to go ahead and add relevant NWP data to solarforecastarbiter/io/fetch/nwp.py. That way, anyone that is already fetching and archiving NWP data will have a useful historical dataset.
For example, 0.25 degree GFS has temperature, pressure, and u- and v- components of wind at 80 meters above ground (https://www.nco.ncep.noaa.gov/pmb/products/gfs/gfs.t00z.pgrb2.0p25.f003.shtml). It also includes u- and v- wind at other levels. I would recommend at least grabbing 100 meter (the highest), maybe 50 meter as well (next one below 80 m).
Anecdotally, I've heard of GFS being used for wind forecasts, and if only one NWP is added, it might be the best "catch-all". HRRR is reportedly relevant in wind as well (https://research.noaa.gov/article/ArtMID/587/ArticleID/2876/NOAA-wind-forecasts-result-in-150-million-in-energy-savings-every-year) so it would be #2 on my (subjective) list.
I would be willing to work on this for a pull request, but I'd be interesting in a few bits of feedback first:
solararbiter fetchnwp, e.g., gfs_0p25_wind as an alternative to gfs_0p25]For reference (no pun intended), I think all the changes would be in the code linked below. For
GFS_0P25_1HR, as an example, I think we wouldonlyneed to add the following lines [edit: plus modify NC_TBL and maybe other minor changes]:https://github.com/SolarArbiter/solarforecastarbiter-core/blob/d4d85a344ef38024eb47c7daaa557d4fe17730ff/solarforecastarbiter/io/fetch/nwp.py#L61-L194