MouseLand
help adjusting parameters to control split/merge decisions
Describe the issue:
Hi,
This issue is not concerning a bug, just a request for advice. Kilosort 4 is generally working beautifully on my data. The most common error mode I encounter seems to be an overmerge (or failure to split) for certain units, but the combined multiunit nonetheless has a clean refractory period. I think this might be an unusual scenario that arises if, say, two neurons have highly selective activity for different task features. (for example, in my case, two highly selective place neurons with fields in different parts of an arena). If on a coarse time-scale two neurons are rarely co-active, they might not have the opportunity to accumulate enough spikes in the ccg window to detect violations?
In any case, I was curious if there were any parameters which could be tweaked to effect this scenario. In the example below, I am showing a single 'good' unit with excellent acg, yet shows two distinct clusters of waveforms, amplitudes, and spike positions:
I then used the SpikePositionsView to split this cluster, and it's clear that this position split aligns closely with the different waveforms and amplitudes, and that there are just very few spikes occurring in the CCG window (potentially underlying the failure to detect ccg violations)
I could imagine manually or writing code to semi-automatically look for over-merges like this. But I was curious if there are parameters to adjust that would affect this behavior. Thanks for your help!
(p.s. since I've separately commented on drift, just wanted to emphasize that this is from highly stable sessions with essentially no drift)
hi @Selmaan, I think this is similar to what happened for the torus paper and Richard had a modification to the merging and splitting steps that deals with it, at least for grid cells. It is described in the methods here.
The good news is that these were probably found as separate cells, and then merged in the pairwise comparison step which is the last thing that happens in the pipeline. So if you tweak that step the right way, you may be able to get the behavior you want without affecting anything else (maybe use the strategy from the torus paper). The bad news is that we do not have a lot of bandwidth to address this right now, but we could put into a queue and hopefully get to it eventually. If you think it's of paramount importance for you/your lab, I could be persuaded to take a look at some data.
Thanks @marius10p , can you point me to the code where this step is happening? I was wondering if there was an easy fix, but if not it's fine to go into the queue. I can currently identify the issue by finding units where spike positions have a clear bimodality, and I should look at the tuning of these units after splitting to get a deeper understanding of what's going on.
This is the last merging step here. It calls this function here
I have not made it this far with adding comments, so it might not be very clear yet what's happening in there but let us know if you have questions.
Great, I'll follow up if and when I have some insight into what's going on.
Closing this for now, please feel free to re-open it at a later date if you need more assistance.
