Python port of KiloSort2

This is a Python port of the original MATLAB version of Kilosort 2.5, written by Marius Pachitariu, with Neuropixel specific improvements and software engineering enhancements.

Scope

Why an IBL port of pykilosort? (draft)

Preprocessing functions and standardization of outputs (white paper coming last week of 2021). Kush Banga, Mayo Faulkner, Cyrille Rossant, Olivier Winter

Installation

System Requirements

The code makes extensive use of the GPU via the CUDA framework. A high-end NVIDIA GPU with at least 8GB of memory is required.

A good CPU and a large amount of RAM (minimum 32GB or 64GB) is also required.

See the Wiki on the Matlab version for more information.

You will need NVIDIA drivers and cuda-toolkit installed on your computer too. This can be the hardest part of the installation. To test if your is working OK you should be able to run the following:

nvidia-smi # Should show how much your GPU is being used right now
nvcc # This is the CUDA compiler

Doing the install using Anaconda

On Linux install

sudo apt-get install -y libfftw3-dev

Create a conda environment

cd ~/Documents/PYTHON/SPIKE_SORTING/pykilosort
conda env create -f ./pyks2.yml
conda activate pyks2

Clone the repository:

git clone -b ibl_prod https://github.com/int-brain-lab/pykilosort.git
cd pykilosort
pip install -e .
pip install cython
pip install pyfftw
pip install git+https://github.com/int-brain-lab/ibllib.git
pip install -U phylib

Usage

Example

The programming interface is subject to change. The following code example should be saved in a directory, along with the following files:

• imec_385_100s.bin

This is how to run for NP1.0 probe

import shutil
from pathlib import Path
import numpy as np

import pykilosort
from pykilosort.ibl import run_spike_sorting_ibl, ibl_pykilosort_params

INTEGRATION_DATA_PATH = Path("/datadisk/Data/spike_sorting/pykilosort_tests")
SCRATCH_DIR = Path.home().joinpath("scratch", 'pykilosort')
shutil.rmtree(SCRATCH_DIR, ignore_errors=True)
SCRATCH_DIR.mkdir(exist_ok=True)
DELETE = True  # delete the intermediate run products, if False they'll be copied over
bin_file = INTEGRATION_DATA_PATH.joinpath("imec_385_100s.ap.bin")
# this is the output of the pykilosort data, unprocessed after the spike sorter
ks_output_dir = INTEGRATION_DATA_PATH.joinpath("results")
ks_output_dir.mkdir(parents=True, exist_ok=True)
# this is the output standardized as per IBL standards (SI units, ALF convention)
alf_path = ks_output_dir.joinpath('alf')


params = ibl_pykilosort_params()
run_spike_sorting_ibl(bin_file, delete=DELETE, scratch_dir=SCRATCH_DIR, neuropixel_version=1,
                      ks_output_dir=ks_output_dir, alf_path=alf_path, log_level='DEBUG', params=params)

Disk cache (serialized results & parameter objects)

The MATLAB version used a big rez structured object containing the input data, the parameters, intermediate and final results.

The Python version makes the distinction between:

• raw_data: a NumPy-like object of shape (n_channels_total, n_samples)
• probe: a Bunch instance (dictionary) with the channel coordinates, the indices of the "good channels"
• params: a Bunch instance (dictionary) with optional user-defined parameters. It can be empty. Any missing parameter is transparently replaced by the default as found in default_params.py file in the repository.
• intermediate: a Bunch instance (dictionary) with intermediate arrays.

These objects are accessible via the context (ctx) which replaces the MATLAB rez object: ctx.raw_data, etc.

This context also stores a special object called ctx.intermediate which stores intermediate arrays. This object derives from Bunch and implements special methods to save and load arrays in a temporary folder. By default, an intermediate result called ctx.intermediate.myarray is stored in ./.kilosort/context/myarray.npy.

The main run() function checks the existence of some of these intermediate arrays to skip some steps that might have run already, for a given dataset.

The suffixes _m (merge), _s (split), _c (cutoff) are used to disambiguate between multiple processing steps for the same arrays (they would be overwritten otherwise).

Technical notes about the port

The following differences between MATLAB and Python required special care during the port:

• Discrepancy between 0-based and 1-based indexing.
• MATLAB uses Fortran ordering for arrays, whereas NumPy uses C ordering by default. The Python code therefore uses Fortran ordering exclusively so that the custom CUDA kernels can be used with no modification.
• In MATLAB, arrays can be extended transparently with indexing, whereas NumPy/CuPy requires explicit concatenation.
• The MATLAB code used mex C files to launch CUDA kernels, whereas the Python code uses CuPy directly.
• A few workarounds around limitations of CuPy compared to MATLAB: no cp.median(), no GPU version of the lfilter() LTI filter in CuPy (a custom CUDA kernel had to be written), etc.