-
Notifications
You must be signed in to change notification settings - Fork 997
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
Accept float in PVSystem.get_irradiance #2227
base: main
Are you sure you want to change the base?
Conversation
Working on this bug fix uncovers a related bug: the
raises So tuple of float of length N only works with a PVSystem with N Arrays. I would like to edit the docstring to remove the promise that a tuple of floats will work. If more than one irradiance value is to be processed, they can be supplied in a Series. A tuple of Series, one Series for each Array, should still be accepted. |
Isn't that the intended behavior? Tuples for these inputs are supposed to index over Arrays. That example: irrads = {'dni': (900., 0.), 'ghi': (600., 0.), 'dhi': (100., 0.)}
irradiance = system.get_irradiance(..., irrads['dni'], irrads['ghi'], irrads['dhi']) is simulating a single timestamp for system with two Arrays, where for some reason it is daytime for one Array and night for the other. The specific values are not realistic, but the use case is still valid (IMHO). I wouldn't call it a bug. |
It would be simpler to describe behavior if we could state "tuples are distributed over Arrays". But that's not what happens when the system has only one Array: the tuple is treated the same as a Series of timestamped values. If we want to keep the case of "tuple of float" I can put that back in the docstring as:
|
Can you provide an example? I'm not seeing that behavior: from pvlib.pvsystem import PVSystem
import pandas as pd
system = PVSystem(surface_tilt=32, surface_azimuth=135)
for converter in [pd.Series, tuple]:
irradiance = system.get_irradiance(
solar_zenith=converter([45, 45]),
solar_azimuth=converter([180, 180]),
dni=converter([900, 900]),
ghi=converter([600, 600]),
dhi=converter([100, 100])
)
print(irradiance) |
Neither am I. I must have been imagining what was originally intended by including "tuple of float" in the docstring. To be sure we're seeing the same thing, that code produces And this is the case we want to accomodate? |
Correct.
On the contrary, I think pvlib already behaves correctly. Tuples should get distributed over Arrays, so tuples of anything (float or Series) should only work when the length of the tuple equals the number of Arrays. The case above shows that a single-Array PVSystem raises an error when given tuples of length 2. That seems correct to me. So what I am saying is that I think the "related bug" described in #2227 (comment) is actually the intended behavior. |
We are in agreement now. Thanks. |
[ ] Updates entries indocs/sphinx/source/reference
for API changes.docs/sphinx/source/whatsnew
for all changes. Includes link to the GitHub Issue with:issue:`num`
or this Pull Request with:pull:`num`
. Includes contributor name and/or GitHub username (link with:ghuser:`user`
).remote-data
) and Milestone are assigned to the Pull Request and linked Issue.If
solar_zenith
is not a Series with a DatetimeIndex, then the solar constant is used.