Merging SpikeForest with SpikeTookit

Today we took some important steps in merging SpikeForest with SpikeToolkit. It was great to have all 5 of us around the same table!

We managed to get the MountainSort4 MountainTools processor to now call SpikeToolkit’s version of MountainSort4 (we first eyeballed the code to ensure that the wrappers were both doing the same thing). Then we did the same for the Klusta wrapper.

A key step was separating out spikesorters from SpikeToolkit as a new package. There are mild cyclic dependencies, but not too bad. This separation makes it possible to modify / improve the spike sorters without affecting the (more stable) spike toolkit. Great idea Samuel!

For now, the Docker files for mountainsort and klusta point to the git repo for installation, but they should point to a version of spikesorters package in the future.

We also made a crucial step of utilizing the comparison with ground truth from SpikeToolkit. We then used a unit test to verify that the accuracy numbers still matched. The numbers were very close, and I’m not worried about the very slight deviation since the spiketoolkit version was checked very carefully by Samuel, and we have unit tests in SpikeToolkit!

Progress!

3 Likes

The new SF wrappers for ms4 and klusta have run successfully and the results are now up on the website (I confirmed they are consistent with previous results). Next I will work on spyking circus (including the update to latest version).

https://spikeforest.flatironinstitute.org

@alejoe91 @colehurwitz @samuelgarcia

2 Likes

Made more progress today on the integration, working with @alejoe91 and @samuelgarcia. Now we have cleaner wrappers for kilosort and kilosort2, and spikeforest is pointing to them. We also have a new spikeinterface wrapper for ironclust which seems to be working.

I am now rerunning the entire spikeforest analysis (only the updates actually run) and we’ll be able to see tomorrow whether today’s work led to any problematic deviations.

2 Likes