Software progress/bug/solutions of the past, present and future
Dedispersion algorithms w/ EPFL
FDD version of dedisp
(Piyush Panchal)
… Here are the errors I found:
cufft calls (both real to complex and complex to real in FDDGPUPlan.cpp) were silently failing as there was no error checking in the code. I would strongly advise you to check the return values for cufftExecR2C and cufftExecC2R functions.
Wrong spin frequencies are computed when nsamp_fft != nsamp (FDDGPUPlan::execute_gpu()). This could be fixed by setting use_zero_padding to false in the same function which is set to true by default.
Phase values multiplied with the fourier coefficients in fdd_kernel.cuh are are incorrectly computed. To shift a discrete time signal a_j (j = 0 .. N-1) by complex multiplication of some phasors to its fourier coefficients A_j (j = 0 .. N-1) and doing an inverse FFT, the complex phasor multiplied to A_j has to be of the form exp(-i * 2 * pi * j/N * delta) where delta is an integer denoting the shift.
Testing repo:
(Piyush Panchal)
I was thinking about the fourier domain dedispersion and there seems to be a fundamental problem in this approach which has not been addressed.When shifting a time series (a)_j by multiplying its fourier coefficients (A)_j with exp(-i 2pi j/N delta), the time series is shifted periodically. That is, if the shift is to the right, some elements at the end of the time series will be moved to the beginning. So, for a particular DM value, the fourier coefficients obtained by complex multiplication and summing across channels correspond to a time signal for which delays for frequency channels have been applied in a periodic sense. This means that at the ends of the time signal, we have some garbage values that we would ideally like to discard, as is done in the time domain version. However, discarding end values of a certain discrete time signal in the fourier domain is a non trivial task. Actually I can't think of a way to do it without doing an inverse transform which is something we want to avoid, otherwise the advantage of FDD in terms of the number of operations is gone. An alternative is to just use the fourier coefficients of this contaminated signal but it is important to be aware of this contamination and maybe even quantify its effect. What are your thoughts?
(Christopher Lee)
I see what you mean, this may be something to consider if you want to take advantage of staying in the Fourier domain. It’s interesting that the authors didn’t mention this in the FDD paper.FDD does have the computational benefit of GPU acceleration though. So even including the inverse FFT, it’s still faster than time domain dedispersion. This is why I’ve been using it in my search pipeline even though dedisp performs the inverse FFT by default. However, my use case isn’t as data intensive as the SMART blind search, since I’m searching far less beams. So the added inverse FFT isn’t as much of a problem for me.
(Piyush Panchal)
Yes it is an important consideration and it seems to be overlooked in the FDD paper! Unfortunately there is no straightforward solution to this. I am thinking of conducting some numerical experiments where I observe the effect of a contaminated time series in the fourier domain for different contamination levels. A low DM means lower delays and lower contamination and vice versa.
VDIF smearing bug (solved)
See Issue 45 and PR 69 for GitHub related content. Sam McSweeney ultimately found the error and corrected it. We should turn these notes essentially into a unit test that can be run on both Legacy and MWAX VCS data in future now that we know the answers. The test data and associated scripts will live in Acacia in the mwavcs:tests bucket.
(Sammy’s notes on diagnosing and correcting the problem, with demonstrations)
