speed up regridding beams and compute beam

[Joshuaalbert]

The problem here is that the beam is generally a function of time, geodesic, frequency, and polarisation. In order to evaluate it quickly we must have either a parametric function or a quick interpolation function. Search sorted and brute force are slow due to repeated search operations, so we initially regrid the beam onto a regular grid so that we can use O(1) lookup and interpolation. This regridding takes considerable time, however it's a single overhead cost. We'd like to speed it up.

Secondly, the interpolation is still slow even with the regridded data. It's unclear what is causing it, though likely a data access pattern problem. We must speed this up too.

Alternative approaches explored:

• [ ] #102

The problem is that I can't get robust fits without spending more time exploring this option. This could be a nice followup improvement however.

[Joshuaalbert]

Firstly, I attack the speed of interpolation. It turns out that the ordering of interpolation drastically impacts performance. For a interpolant of shape [num_time, num_l, num_m, num_freq, 2, 2] switching order of interpolation from time -> l -> m -> freq to time -> freq -> l -> m brought interpolation of DSA2k beam for single time/freq slice from 6 seconds to 0.003 seconds!

[Joshuaalbert]

Secondly, using the newly implemented approximate tree NN we are able to speed up regridding from on a single slice of time/freq for DSA2k from 11s to 3.7s. Furthermore, the memory usage scaling is much better so that we can increase resolution from 128x128 pixel beam to 256x256 which was before prohibitive for DSA during regridding.

[Joshuaalbert]

Used kdtree to get fast exact