Some signals can be lost by find_doppler.py hitsearch() due to the presence of a false positive signal

[Richard Elkins]

The maximum drift rate testing works fine and is performed in the main loop of find_doppler.py search_coarse_channel.

In find_doppler.py hitsearch and its GPU-code equivalent (find_doppler/kernels/_hitsearch/kernels.cu), before we store something in maxsnr[i] and maxdrift[i], the code is correctly checking that spectrum[i] > maxsnr[i]. However, there is no preceding check that the drift rate >= the minimum drift rate parameter value. The code is simply selecting the spectrum[i] value as the new "max" based on an SNR comparison. In fact, hitsearch and the GPU-code equivalent do not entertain a minimum drift rate parameter.

Risks:

• We might store a false positive (E.g. huge SNR, drift rate = 0). Admittedly, this will be caught later by find_doppler.py tophitsearch at the end of the coarse channel processing.
• But, in the process, we might lose a smaller SNR-valued signal that is in-bounds in terms of drift rate and might be of interest.

There is a check on min_drift in tophitsearch that weeds out the false positive I mentioned before but the presence of the in-bounds smaller SNR signal was already lost.

Did I miss anything?

@telegraphic ? @luigifcruz ? Anyone else?

[Richard Elkins]

One solution would be the following:

• Don't call hitsearch if the drift_rate is below minimum in both places where hitsearch is called.
• Yank the min_drift test from tophitsearch.

[Danny Price]

@texadactyl as you've noted, the algorithm will indeed only pick up one maximum hit, regardless of its drift rate.

This is related to why I've been looking into new hit search algorithms for turboseti (e.g. very expensive 'iterative blanking' UCBerkeleySETI/hyperseti#38), which are better able to pickup hits hiding behind really bright sources of interference.

It might be difficult to get the min_drift parameter working in the loop across drift rates (turboseti needs this to get to higher drift rates), but it would be reasonable to do if possible

[Richard Elkins]

It wasn't bad to move the min_drift check to the main search_coarse_channel loop. Essentially, its in the same area as the max_drift check. Will merge 2.1.19 in a bit.

Of course, hyperseti will do better.