-
Notifications
You must be signed in to change notification settings - Fork 1.1k
pvlib.irradiance.erbs and .disc to accept kt as optional input parameter #1128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks @StefaE. In don't understand the benefit of this proposal because |
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. |
@wholmgren - I can't really comment on dependency between 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. |
@StefaE can you tell from the forecast documentation if |
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 |
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:
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
The text was updated successfully, but these errors were encountered: