You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
, we see that _interpolate_turbidity uses time_utc.dayofyear which is 1-indexed. When the middle of the month is calculated, this uses 0-indexing.
Usually in other parts of the code, this is corrected by an offset of 1, but in this case, it is not.
Reproduction
For instance, this year, February 15th 12:00 PM was the midpoint of February. This is the 46th day of the year, so the index is 45.5 which is correctly calculated by _calendar_month_middles.
Expected Behavior
This can be seen for some midpoints which you would expect to be exactly what's in the HDF5 file, but are not. For example, we would expect $\frac{57}{20} = 2.85$ for these coordinates at this time:
I imagine this is of very low priority, since these calculations only have the resolution of a single day, but I noticed it and thought I should make an issue.
pvlib.__version__ == '0.11.1'
pandas.__version__ == '2.2.3'
Python 3.13.0
The text was updated successfully, but these errors were encountered:
Maybe the issue is a lack of clarity in what to expect. What value should be used to represent the entire month in these cases?
February 2024: the middle of the month day is noon of Feb 15 (14.5 days before, 14.5 days remaining). The returned index is 45.5, which is what I would expect (31 + 14.5). But starting from day of year (46 for Feb 15, 2024) I can understand why seeing 45.5 appears to be off.
February 2023: the middle of the month is midnight on Feb 14. The returned index is 45. The day of year for that datetime is 46, but 1 second earlier would be 45.
I don't really have too much stake in this; I just thought it was weird. My own suggestion would be to use actual times instead of dayofyear calculations, so the interpolated value is a continuous function of datetime. You still need to get the middle of the month in epoch time or something like that.
I haven't tested the sensitivity of a final PV power output with respect to turbidity, so I'm not sure how much this matters, especially given how the input data is in uint8.
Description
On line 260 at
pvlib-python/pvlib/clearsky.py
Line 260 in 0781787
_interpolate_turbidity
usestime_utc.dayofyear
which is 1-indexed. When the middle of the month is calculated, this uses 0-indexing.Usually in other parts of the code, this is corrected by an offset of 1, but in this case, it is not.
Reproduction
For instance, this year, February 15th 12:00 PM was the midpoint of February. This is the 46th day of the year, so the index is 45.5 which is correctly calculated by
_calendar_month_middles
.Expected Behavior
This can be seen for some midpoints which you would expect to be exactly what's in the HDF5 file, but are not. For example, we would expect$\frac{57}{20} = 2.85$ for these coordinates at this time:
I imagine this is of very low priority, since these calculations only have the resolution of a single day, but I noticed it and thought I should make an issue.
pvlib.__version__ == '0.11.1'
pandas.__version__ == '2.2.3'
The text was updated successfully, but these errors were encountered: