Description
I tried to sort a MaxWell chip recording (10min, ~9gb) that I had previously sorted with an older spykingcircus version, using the spikeinterface-based sorters (spykingcircus 2 and tridesclous 2, v0.96.1) with default parameters - other than sorter_params['job_kwargs']['n_jobs'] = 8. However, while there are clear spikes in the recording, both sorters did not find any peaks and gave an error afterwards. I went line by line through the spykingcircus2 code, and right before the detect_peaks call, there are still clear spikes in the data (example of one channel):
Interestingly, when I used method=by_channel, a few peaks were found, but they all belonged to the same channel. When I lowered the detection threshold to sorter_params['detection']['detect_threshold'] = 4, the number of peaks increased quite a bit, but still all peaks belonged to the same channel and the amplitudes also were very odd:
When running tridesclous2, I additionally get the following warnings and also detect 0 peaks:
E:\envs\si\lib\site-packages\spikeinterface\preprocessing\normalize_scale.py:230: RuntimeWarning: divide by zero encountered in true_divide
gain = 1 / mads
E:\envs\si\lib\site-packages\spikeinterface\preprocessing\normalize_scale.py:231: RuntimeWarning: invalid value encountered in true_divide
offset = -medians / mads
Since the sorting worked with the old spykingcircus, and the preprocessing does not seem to distort the data (clear spikes visible), I am not sure where to go from here on. Might there be a bug in the detect_peaks function?