Moon position performance enhancement using SLALIB
Retrieve Moon position: benchmark between astropy and SLALIB
I was looking at an efficient way to compute the moon and sun position inside the detector, and I quickly ran into performance issue with astropy/km3astro. I realized a small comparison between km3astro
, astropy
and SLALIB
(pyslalib, python wrapper around the Fortran library). The jupyter-notebook used for that can be found in attachment.
I have generated 10000 random time in seconds, along ~ 1 month (1 lunar period). Then, in 2 steps I convert these times in :
- Right ascension and declination
- In local detector coordinates (i.e. azimuth and zenith)
The 4 studied cases are :
-
sla_dmoon
, based on the eponymous function in SLA. Conversion to local coordinates is done withsla_e2h
-
sla_rdplan
, based on the eponymous function in SLA. Conversion to local coordinates is done withsla_e2h
-
astropy
, based onget_moon
function, conversion done by defining an ORCA frame. -
km3astro
, usingmoon_local
which return directly the moon position into local coordinates.
Moon position
The results can be seen in this plot (top to bottom: Right ascension, declination, azimuth & zenith)
sla_rdplan
is the one appearing the most distant to the other functions. I suspect it comes from some parallax correction due to the fact that the distance ORCA-center of earth is not entirely negligible compare to the earth-moon distance (but that's a wild guess).
Except that, all 4 methods give similar results.
Processing time
Now, let's take a look at the processing time. For each function, 2 times are displayed. The first is the function that gets the [RA,DEC] of the moon. The second is the conversion to the local coordinates. As km3astro
does both at once, only 1 time is displayed:
sla_dmoon
41.5 ms ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
3.45 ms ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
sla_rdplan
97.8 ms ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
4.24 ms ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
astropy
2.72 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
1.1 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
km3astro
4.21 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)
The results are ordered from the faster to the slower. We can see that sla_dmoon
does the task almost 100 times faster than km3asto. The sla_rdplan
solution, which embed (maybe not needed) corrections is 2 times slower. We can also note that the km3astro implementation appear already slower than a bare astropy
implementation.
I don't know if we want to include other solutions like SLALIB in km3astro, but I think that if you look for performances, you should give it a try. To be totally fair, SLALIB is much more difficult to use than astropy/km3astro, mainly because of the old style doc write inside the Fortran code.