SpikeInterface / spikeinterface

A Python-based module for creating flexible and robust spike sorting pipelines.
https://spikeinterface.readthedocs.io
MIT License
521 stars 186 forks source link

Only one cluster survives final clustering with KS4 #3006

Closed EricKenjiLee closed 4 months ago

EricKenjiLee commented 4 months ago

@alejoe91 opening the issue here as per your instructions. SI version 0.100.6; KS4 version 4.0.

I've just started using SpikeInterface to try to compare DREDge to KS4 drift correction for NHP Neuropixels (4.5 cm version) but I keep running into this bug in which all clusters but one are discarded during final clustering and then zero clusters make it through refractory period thresholding. This image is from after conducting drift correction and running Kilosort4 for spike detection and clustering using default parameters except 'do_correction' = False. I've confirmed this error also occurs when using Kilosort's drift correction instead of DREDge and also that it happens on other recordings; when running sorting via KS4 GUI, I end up with hundreds of clusters to examine in Phy. See other screenshot showing it's a "typical" recording. I'm following the tutorial in the docs.

Will upgrade KS4 to 4.0.11 and see if this resolves things.

image (3) image (4)

JoeZiminski commented 4 months ago

Hi @EricKenjiLee thanks for this, just to confirm the workflow that leads to the bug is:

1) preprocessing in SI 2) drift correction in SI (kilosort-like or DREDGE) 3) passing to KS4 through spikeinterface (do_correction is off)

However you do not see the bug when: 1) passing directly to KS4, doing all preprocessing in KS4.

and that in SI you are pointing to the same version of KS4 you have installed locally?

I wonder if this is a problem with the preprocessing steps or the KS4 wrapper. Could you please try running the sorting through SI, but with no SI preprocessing, and full KS4 preprocessing (i.e. I think replicating running KS4 through the GUI, but in spikeinterface, though let me know if I have overlooked something that means this is not the case). This should indicate if it is a problem with the wrapper vs. preprocessing steps.

As a potential quick fix, bumping to SI 0.100.7 and KS4 v4.0.6 (currently the latest KS4 version supported by SI) might help, although it would still be good to track down the cause of the problem in 4.0.

JoeZiminski commented 4 months ago

Oh I just saw you already did upgrade in #3007 😄 did it help?

EricKenjiLee commented 4 months ago

Yes bumping to SI 0.100.7 and downgrading to kilosort4 version 4.0.6 worked! The only bug that remains is that this workflow takes approximately 5-7 times longer to get from raw data to spike clusters than using the KS GUI directly (5-7 times the recording length as well) but I think your team is already aware of that issue. I'm working with a 8-core Intel i9 CPU, 64 GB of RAM, and a 4070 GPU. I'm also I/O bottlenecked as data is on an HDD but this is also the case for KS GUI. Will try to process again once my new NVMe SSD comes in.

EricKenjiLee commented 3 weeks ago

Just commenting that I/O bottlenecking doesn't seem to have been the issue as speeds are still dreadfully slow even after loading data onto an NVMe SSD. GPU is being fully-utilized as well.