pvlib / pvlib-python

A set of documented functions for simulating the performance of photovoltaic energy systems.
https://pvlib-python.readthedocs.io
BSD 3-Clause "New" or "Revised" License
1.17k stars 993 forks source link

pvlib.irradiance.erbs and .disc to accept kt as optional input parameter #1128

Open StefaE opened 3 years ago

StefaE commented 3 years ago

Some weather forecasts (eg. Deutscher Wetterdienst, MOSMIX) provide GHI (in MOSMIX 'conveniently' dubbed 'Rad1h' and in units of kJ :-( ) and kt (dubbed 'RRad1)).

Proposal pvlib.irradiance.erbs could easily be enhanced to optionally accept kt as a parameter:

def erbs(ghi, zenith, datetime_or_doy, min_cos_zenith=0.065, max_zenith=87, kt = None):

   if kt is None:
        kt = clearness_index(ghi, zenith, dni_extra, min_cos_zenith=min_cos_zenith,
                             max_clearness_index=1)

This change should be transparent to current users but allow the use of two input parameters from the forecast, in the hope that they combined describe actual weather conditions more accurately than just one.

A symmetrical change could be proposed for disc, which also first calculates kt. However, due to the usage of I0 for calculating both kt and later dni, this would end up in a considerably less clean situation and should not be lightly done.

Thx. for consideration

wholmgren commented 3 years ago

Thanks @StefaE. In don't understand the benefit of this proposal because kt and ghi are completely dependent on each other and there is essentially no uncertainty in converting between them. If the forecast has meaningful differences between them (i.e. kt derived from forecast ghi is meaningfully different from forecast kt) then I'd question the solar position algorithm within the weather model.

cwhanse commented 3 years ago

From the perspective of distributing reference implementations of published algorithms, the proposal could be of use for a small number of users. The Erbs paper doesn't specify which method is to be used to determine extraterrestrial irradiance. There isn't much difference among extraterrestrial irradiance models (or the solar position algorithms) and the defaults in pvlib are reasonable choices. But if someone needs to reproduce work done with a different combination of models and cares about very small differences, it could be useful to supply dni_extra or k_t to .erbs rather than have erbs compute these quantities.

StefaE commented 3 years ago

@wholmgren - I can't really comment on dependency between kt and ghi - for that I'm way too new to the subject (off-topic: If there are great resources to learn about such things ... :-) ); I just noticed that the forecasts I'm getting have two radiation related parameters. At the very minimal - that makes one wonder how they'd influence a performance forecast.

dni(erbs) vs. dni(erbs with kt as input) doesn't give me a great correlation. This is in the European winter with very little sun. I'm in no position to judge whether this is a deficiency of the weather model. Running this all through a model of my rooftop installation results in meaningful differences in a regime where the installation runs at about 3 - 6% of it's peak power.

cwhanse commented 3 years ago

@StefaE can you tell from the forecast documentation if kt is clearness index (global horizontal irradiance / extraterrestrial irradiance) or is it clearsky index (global horizontal irradiance / clearsky global horizontal irradiance)?

StefaE commented 3 years ago

LOL - what do you mean with "documentation"? It says only global irradiance within the last hour. When I asked them through eMail for details, they came back that it was a "relative global irradiation" - that was hard to guess from the unit [%].

When I plot kt_erbs as calculated by erbs internally vs. their forecast element kt_fc, both numbers are in range [0 .. 0.5] and R2 = 0.91 (kt_erbs = kt_fc*1.05) over a set of 6000 data points in cloudy winter weather. When I calculate ghi_clearsky with pvlib and then calculate clearsky index against their ghi_fc I get a number in the range [0 .. 1]. Plotted vs. kt_fc, R2 = 0.93 (clearsky_index = kt_fc*1.8) So - empirically, it should be clearness index.