New default solar position algorithm

[kurt-rhee]

Is your feature request related to a problem? Please describe.

[Solar Position Documentation](https://pvlib-python.readthedocs.io/en/stable/reference/solarposition.html
https://pvlib-python.readthedocs.io/en/stable/reference/generated/) recommends using the default solar position algorithm. Should we update to a faster algorithm given @AdamRJensen's poster at this year's PVPMC which shows that most algorithms have minimal impact on energy regardless of run-time?

With permission I can edit this comment and add a photo of the poster.

Describe the solution you'd like
A fast implementation of the SG2, USNO or NOAA solar position algorithms set as the default model for the get_solarposition wrapper.

Describe alternatives you've considered
We could leave the default as nrel_numpy

Additional context

• Increased run-time speed of pvlib reduces carbon output of running models (no matter how small or large that might be)
• I am happy to re-implement one of the above models in Rust with python bindings and open source the rust backend. I know that this comment will open up a can of worms. I think one way to go about this is to implement the model twice, once in python as a reference for the community and once in rust/julia/c++ etc. for use in practice. Users would be able to select which model to use at their prerogative.

[williamhobbs]

I like the idea. A picture of the poster (with permission) would definitely be nice.

[mikofski]

Solpos is a great algorithm as fast as usno but as accurate as spa and it already has a c implementation. Try pip install solarutils or see https://sunpower.github.io/SolarUtils/

[kurt-rhee]

@mikofski that is awesome, would it be feasible to add the algorithm to pvlib to make it easier for newcomers to use? I wouldn't mind doing the work.

[mikofski]

I would appreciate a Python version of SOLPOS. Or pvlib can also import optional dependent, for example perhaps consider sg2

Past concerns were

• license
• cython/binary maintenance

SPECTRL2 addition by Kevin resolved these concerns by reimplementing natively.

Related / past:

• Add a new and faster way to calculate the solarposition #730
• [WIP] Implement Michalsky's solar position algorithm #2167
• Add pvsyst solar position algorithm #2169
• [WIP] Implement the Plataforma Solar de Almerı́a (PSA) solar position algorithm #2152
• Cython Implementation of the NREL SPA #1906
• add more Solar Position calculations like US Naval Observatory and Michalsky #1308
• New Method to Solarposition #1714
• Improved benchmark in solarposition.py #1443

Purpose of listing these just for reference

[adriesse]

Are there issues here?

1. Changing the default algorithm
2. Adding another algorithm

I admit SPA sometimes takes longer than I would like, but I can cache the results if needed. Consistency is most important to me.

Here's a slide from software comparisons I did (what!? it's already) 6 years ago.

[kandersolar]

Should we update to a faster algorithm given @AdamRJensen's poster at this year's PVPMC which shows that most algorithms have minimal impact on energy regardless of run-time?

A paper is in the works with more detail on this topic. Note that we already have a faster alternative to SPA (pvlib.solarposition.ephemeris), but quoting #2323 (comment):

A bit of context: @AdamRJensen, @IoannisSifnaios, and I have a project underway comparing solar position algorithms. We plan to contribute implementations of one or more algorithms to pvlib-python, depending on the results of the comparison. We expect some of them to be better than ephemeris in all respects (speed, accuracy, period of validity, clear reference).

#2152 and #2167 are candidates, but those PRs are on hold for now while we work towards clear recommendations for choice of algorithm.

Solpos is a great algorithm as fast as usno but as accurate as spa

I do not think this is true, unless "accurate as spa" means "produces practically equivalent solar energy simulations", which is also the case for half a dozen other algorithms :)

[kurt-rhee]

Nice! @kandersolar can do this way better so I'll leave this up, but I won't do any work on the topic.

[adriesse]

A paper is in the works with more detail on this topic. Note that we already have a faster alternative to SPA

Looking forward to both of these! The poster made some claims but lacked justification. :(