search

NREL / rdtools

PV Analysis Tools in Python
https://rdtools.readthedocs.io/
MIT License
146 stars 61 forks source link

clearsky_temperature : move to pvlib-python? #118

Open cwhanse opened 5 years ago

cwhanse commented 5 years ago

From rdtools perspective would it make sense to host clearsky_temperature in pvlib-python? IMO that nice function has broad uses outside of degradation analyses, e.g., power forecasting. I'm willing to help port it if we agree that would improve both packages. @wholmgren

wholmgren commented 5 years ago

I think it would make sense to add to pvlib python.

It looks like this data set is for land-surface (skin) temperature rather than 2 m temperature. I can't think of any pvlib functions that use skin temperature, so we'd want to find a different data set.

cwhanse commented 5 years ago

Maybe there's a model to map surface to air temperature?

wholmgren commented 5 years ago

I don't think there is a model that is accurate for diverse locations, across seasons, and is simple to implement. It's not clear to me what spatial/temporal resolution and coverage we'd need, but a few things to consider include PRISM and NCEP Reanalysis.

mdeceglie commented 5 years ago

I support moving that function over to pvlib-python.

It's useful to keep the ecosystem organized with pvlib providing a home for PV modeling functionality and RdTools providing a home for PV data analysis. Clear sky temperature is clearly in the former.

Looping in @GregoryKimball who developed that method.

GregoryKimball commented 5 years ago

Thanks Cliff for raising this issue, and thank you guys for your comments. I support moving clearsky_temperature to pvlib-python. We use clearsky_temperature for filtering and back-filling temperature data from field sensors and we also feed the data into pvlib.pvsystem.sapm_celltemp as "temp_air".

In reference [1], we conducted a review of 480 ambient temperature sensors against the clearsky_temperature model which uses monthly day/night MODIS data processed by NEO against ECMWF "2 metre temperature" and "skt" (skin temperature) values as 3hr and as monthly day/night values. We found the monthly day/night MODIS data currently used by clearsky_temperature to show similar or lower median square error values than the much-larger ECMWF datasets. Each sensor had about 2-6 years of data and errors were evaluated at a 15-min interval.

References [1] and [2] used the clearsky_temperature as implemented in rdtools. I recommend that we transfer the current implementation pvlib with this method. If we would like to evaluate a new temperature dataset we should probably publish another reference.

[1] Kimball, Gregory., et al. "Clear Sky Irradiance and Temperature Models for Mitigating Sensor Drift in PV System Degradation Analysis" 8th PVPMC 2017 [2] Jordan, Dirk., et al. "Robust PV Degradation Methodology and Application" JPV 2017. 10.1109/JPHOTOV.2017.2779779v

wholmgren commented 5 years ago

Hm, maybe there is enough averaging that the differences wash out on the time scales considered. The examples below show typical differences in skin vs. 2 m temp from weather models (in this case the HRRR). For most locations on these maps, putting skin temp into a PV power model that expects 2 m temp is going to lead to a noticeable difference in output power.

temp_sfc_f04 temp_2m_f04

GregoryKimball commented 4 years ago

@wholmgren Thank you for sharing this example. I don't think anyone on this thread would argue that skin temperature and 2m temperature are identical. The results in reference [1] above showed that the difference between skin temperature and 2m temperature in satellite models was not a significant driver of the error between satellite models and ground sensors. I understand that you have reservations about introducing the rdtools clearsky_temperature model to pvlib. What additional studies or research might change your mind?

wholmgren commented 4 years ago

I looked at the reference but I'm still confused about exactly what each data source is and how each data source is processed into the time series of temperature that's used for PV modeling.

I'm not saying that we can't put the model in pvlib. I just want to make sure that we understand how it's supposed to be applied and what if any warnings we should add to the documentation.

cwhanse commented 4 years ago

Proposed way ahead: let's separate the data acquisition parts of rdtools.get_clearsky_tamb from the clear-sky temperature model which is this private function. If @wholmgren agrees the data acquisition could be added to pvlib.iotools. The clear-sky irradiance function (Eq. 3 in [2]) would be a nice addition to pvlib.clearsky. The equation takes monthly average daytime and nighttime temperature, and hour of day, as input.

[2] Jordan, Dirk., et al. "Robust PV Degradation Methodology and Application" JPV 2017. 10.1109/JPHOTOV.2017.2779779v

wholmgren commented 4 years ago

I agree.

mdeceglie commented 3 years ago

@cwhanse @wholmgren Wanted to check in and see if this had been implemented in pvlib yet. If so we could consider pulling or deprecating this function in the upcoming RdTools 2.0.0 release. If not, no worries, we can keep it on the longer term road map.

I didn't see it in pvlib, but just confirming I haven't missed something.

wholmgren commented 3 years ago

@mdeceglie it has not been implemented in pvlib