Skip to content

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 :

  1. Right ascension and declination
  2. 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 with sla_e2h
  • sla_rdplan, based on the eponymous function in SLA. Conversion to local coordinates is done with sla_e2h
  • astropy, based on get_moon function, conversion done by defining an ORCA frame.
  • km3astro, using moon_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)

image

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.

Jupyter-notebook

benchmark_moon_coords.ipynb

Edited by Valentin Pestel