On the use of FFTs for remapping points

Ok,. This is, I hope, the start of a great conversation on how we can work more in the spectral space for a whole heap of features across packages. This is motivated by a conversation I had with @aladinor and @swnesbitt and then further with @ghiggi and @kmuehlbauer . I have used AI, Claude, to put together code at radar-palette/src/radar_palette/gridding at main · DIGR-Legacy/radar-palette · GitHub

I need to completely evaluate and understand how this works. The idea is to encode information into the spectral space then do an inverse FFT onto a grid. My initial experiments show the cost is almost exclusively in the mapping to the FFT. Also, the best technique is to do the mapping swep by sweep and do a final, vertical, linear interpolation. The results are compelling. Too good. I almost feel Claude wants me to be right.

For ARM’s BNF C-SAPR2. 15 tilt VCP.

And here is a notebook playing notebooks/01_radar_processing_qc/advection_interpolation/Spectral_FFT_Gridding_Performance.ipynb at master · scollis/notebooks · GitHub

Beautiful Scott! Would be interesting to show the power spectra of the original versus the two results (and stratify by ranges too).

Great idea Steve. We were discussing the use of FFTs for filtering as well.

I improved the ROI for Barnes to give a more fair comparison. This ended up with each ROI with more points in it and increasing cost for Barnes

https://www.sciencedirect.com/science/article/abs/pii/S1090780707002054

Ive been digging in and understand the methods a lot better now. Its really cool. Will give a HUMAN summary later this week.

Another update. It looks like Claude rolled its own Kaiser Bessel NUFFT. There may be good opportunity to speed this code up. eg TorchKbNufft Documentation — torchkbnufft v1.5.2 documentation

ok.. testing is very very promising. Non-GPU test show a major speed up. I also added some parallelization

trying GPUs now