add more Solar Position calculations like US Naval Observatory and Michalsky

[mikofski]

Should we consider adding more published solar position algorithms? Maybe related to #1065 do we already have the Michalsky aglorithm in pvlib? I see it cited frequently, but I don't know the actual algorithm. Also supposedly pvsyst uses the USNO algorithm. How good or bad is it? I have never seen the actual algorithm or what inputs it uses. Also I am a big fan of NREL SOLPOS which is actually an input to SPECTRL2, so did @kanderso-nrel already implement it? Do we have it already and not even know it. There's an excel version and a C version, it's pretty short so I bet we could reimplement it as python with numba if needed.

• USNO
• Michalsky
• SOLPOS
• SG2
• Grena
• PSA (Blanco & Muriel)
• other?

comparison (from Adam's DTU classmate: Nick Riedel, @nicorie)

more info

1. Seidelmann K (ed.) , Explanatory supplement to the Astronomical Almanac, 1992.
2. Michalsky JJ, , “The Astronomical Almanac’s Algorithm for Approximate Solar Position (1950-2050),” Solar Energy, vol. 40, no. 3, pp. pp 227-235, 1988.
3. https://www.nrel.gov/grid/solar-resource/solpos.html
4. https://www.pvsyst.com/help/solar_geometry.htm
5. https://www.usno.navy.mil/USNO/astronomical-applications/astronomical-information-center/
6. https://forum.pvsyst.com/viewtopic.php?t=1774
7. https://forum.pvsyst.com/viewtopic.php?t=1790

[kandersolar]

I do not have a python version of SOLPOS; in the comparison notebook I called out to solar_utils for that part. But I wouldn't be opposed to making one.

I have also been eyeing "Efficient calculation of solar position using rectangular coordinates", which is apparently "SPA but faster":

• paper: https://www.sciencedirect.com/science/article/pii/S0038092X21001213#!
• C implementation (BSD I think?): https://github.com/DavidHoadley/sky

[wholmgren]

I'm not opposed to implementing more algorithms. It's consistent with the pvlib philosophy of providing reference implementations of algorithms commonly used in the solar modeling community. But I think the discussion would still benefit from identifying if there is real world problem we're trying to solve. Match PVSyst more closely? Are we speculating that lots of people would benefit from a faster default algorithm and they're also uncomfortable with the documentation/validation of the existing ephemeris function? Have you personally run into problems with the existing algorithms?

I recently wrote down some related thoughts in Unidata/MetPy#1440 (comment) TLDR: python (or python wrappers) of a fast algorithm that supports arrays of space and time would be useful to a lot of people.

[mikofski]

I do want to be able to duplicate the PVsyst model chain to remove any doubt about differences we see from pvlib/SPA. The Michalsky seems to be cited so frequently that it just seems philosophically aligned for it to be covered by pvlib. Ditto for USNO. It should not be difficult to find the raw implementation details for these models if folks need to duplicate a prior assessment.

Speed of calculation is less of a concern for me, but it may be for others. If algorithms become popular we should find a way to wrap them or make them accessible to analysts.

[AdamRJensen]

@mikofski @wholmgren Earlier today I was talking to @YvesMSaintDrenan from MINES ParisTech who has developed a fast algorithm for calculating solar position for a grid of points and is interested in contributing it to pvlib. I personally would find this very useful, as none of the existing pvlib methods today can handle this.

What is the general opinion on welcoming such a contribution?

[cwhanse]

Is the fast algorithm documented somewhere?

[cwhanse]

@AdamRJensen The home page for the SG2 algorithm has a link to a paper documenting the algorithm. I took at look at the SG2 repository. The source is almost all C++. For this reason I would vote no on porting the code into pvlib-python. If we can figure out the API it might make sense to add a function to iotools to make it easier for users to combine SG2 with pvlib code (primarily, to handle variable name translations).

[AdamRJensen]

I had originally thought that it was written in Python, but as @cwhanse pointed out it is not. @kanderso-nrel suggested including the package as a dependency and adding it as an option in the pvlib.solarposition.get_solarposition function.

The algorithm is available as a python package (wrapping the C++ code). However, the package is hosted on a custom package index and not on PyPI. For it to be included as a dependency, Kevin suggested that they put the package on the PyPI instead to make it a smoother user experience.

[AdamRJensen]

As an update, SG2 is now available on pypi:

pip install sg2

[mikofski]

How does it compare to SOLPOS? We could do some side-by-side benchmarks using the solarutils python extension from SunPower. We don't have an implementation of PSA from Muriel-Blanco. According to one paper, PVsyst doesn't use USNO, it uses an algorithm by Pierre Ineichen! Evidently the USNO algorithms are in the USNO Astronomical Almanac 2020? I could not find any references for the 2000 SOLPOS algorithm, or what it's time range or accuracy is, could it possibly be just another implementation of Michalsky? Anyway, I just found some more random notes here:

• K. B. de Melo, M. Kitayama, L. R. Tavares, H. Andreazza de Freitas and M. G. Villalva, "Accuracy Analysis of Sun Position Calculation Algorithms: Ineichen and SPA," 2019 IEEE PES Innovative Smart Grid Technologies Conference - Latin America (ISGT Latin America), Gramado, Brazil, 2019, pp. 1-5, doi: 10.1109/ISGT-LA.2019.8895282.
• PVCDROM/PVEducation
• difference between SPA and PVsyst from PVsyst forum

[AdamRJensen]

Just as a comment to the original list of software and their usage of solar position algorithms: SAM has since version 2020.11.29 been using SPA - the change was implemented here: NREL/ssc#450.

[mjprilliman]

Thanks to @kanderso-nrel for pointing me to this conversation. Just want to note that SAM has some interest in exploring these different solar position algorithms as well.

[mikofski]

related to #1714

[adriesse]

Precision really isn't the main criterion for me most of the time, it's getting the same angles as whatever I'm comparing with. I'm less interested in new algorithms even if they somehow provide a more attractive balance of accuracy vs. flops because after all running SPA once is usually acceptable.