Open markveillette opened 1 month ago
I'm inclined to consider this a feature request rather than a bug report since spa_python
's docstring specifies that latitude and longitude are of type float (not array). Arrays being allowed with how='numpy'
is coincidental :)
It seems possible to modify the numba code to allow arrays for lat/lon, although the code might be a little ugly.
@markveillette do you need specifically the SPA for your application, or would a faster (but somewhat less accurate) solar position algorithm be acceptable?
fair enough! That makes total sense, appreciate you looking at this so quickly.
For my use case, yes, I am okay with fast-but-not-perfectly-accurate. e.g. <1 degree error.
I've found a some repos online that offer this, e.g. https://github.com/david-salac/Fast-SZA-and-SAA-computation/tree/master or @leaver2000 's https://github.com/leaver2000/fast_spa. If you have other alternatives that handle array inputs I can definitely look into them.
SG2 was developed for a mesh of latitudes and longitudes: https://github.com/gschwind/sg2
Works for python < 3.12
Another option in pvlib is pvlib.solarposition.ephemeris
. I'd expect it to work with array input for lat/lon, although also coincidentally.
A future version of pvlib may have even better alternatives.
Describe the bug I'm trying to call
pvlib.solarposition.spa_python
with arrays for time, latitudes and longitudes. It works fine by default, but I get an error if I usehow='numba'
with the same inputs.To Reproduce The following reproduces my error:
The error I get is
Expected behavior Both calls to
spa_python
should give same result, given the inputs are identical.Versions:
pvlib.__version__
: 0.11.0pandas.__version__
: 2.2.2