918particle
commented
5 years ago Copy that on the python implementation - it's on the to-do list but I have maybe 4 hours per week to allocate and there are several projects going.
The issue of the phase is actually physical - it's a feature not a bug. The Ralston-Buniy work (as does the work of ARZ, by the way) tells us that the signal should be delayed as you go off-cone. Or, there is an off-cone group delay. It also depends on frequency. You can see this in one of the figures of the paper Amy and I wrote.
The problem, as you point out, is when you take an iFFT and the phase is wrapped onto [0,2pi]. Pulses that don't get wrapped will have the correct time-shift relative to each other, because of the physical group delay. But if they are wrapped, game over. I was thinking of re-writing the iFFT function in AskaryanModule in the C++ version. I don't think there was ever a bug, though.
I think the bug you refer to is the normalization of the iFFT. When you have a function defined in time, FFT, then iFFT, you incur a normalization change that has to be corrected. But here, in this code, we are generating the field in the Fourier domain, and doing one Fourier transform. Thus, the normalization doesn't change. Further, although Ralston and Buniy use a different minus sign in their definition of the Fourier transform, this is irrelevant. Flipping the sign of the Fourier transform in AskaryanModule merely flips the pulse, but doesn't change the amplitude.
cg-laser
I made a few tests with the RalstonBuniy module and it seems to work fine. I couldn't reproduce any problems that Brian saw previously which were probably just related to a bug in original the iFFT implementation. However, while testing the module I found another issue that need to be solved before using it (for timing studies) in NuRadioMC.
As illustrated by the two plots below, the pulse time behaves weirdly and makes this module impossible to use at the moment for timing studies. I think the reason is that the phase is just modified according to the distance from emitter to source. But the phase is 2pi periodic, hence, at certain distances the pulse just moves from the end of the trace to the beginning. It can even happen that part of the pulse is at the beginning and the other part of the pulse is at the end of the trace.
We can't just shift the pulses to always be in the middle of the trace because we want to keep track of the physical time delays that we get when moving off the cherenkov cone. I think the best way would be if the module had the pulse arrival time on the chrerenkov cone at a fixed time. The time delay due to different distances to the receivers are anyway calculated via ray tracing.
This might actually also impact the trigger modules, as we require a time coincidence between antennas.
I added the plotting script in the branch 'askaryan-hanson' where also further improvements of this module should take place.