FEATURE: multishank capabilities

[marius10p]

Feature you'd like to see:

Right now we are telling users to stack the shanks of probes vertically on top of each other, which seems to work pretty well (and it should). However, it would be better to explicitly treat the shanks as separate sets of data, to avoid any edge effects at the boundaries. There are multiple places where channels from different shanks could currently "interact" and we need the shanks to be treated separately in all those cases.

Additional Context

No response

[jacobpennington]

Version 4.0.4 should handle this now, I'll close this after getting feedback from people using it on their data.

[paolahydra]

Version 4.0.4 should handle this now, I'll close this after getting feedback from people using it on their data.

Hi @jacobpennington,
I used version 4.0.6 and sorted a recording from two active shanks of NPX2.
Everything worked fine. However, in trying to understand the channel order and naming, I noticed that KS only partially reordered channels within each shank.
The first 192 channels all have the x coordinates of the first used shank, which is fine. However, channels 0-96 have depths 720 through 1425, and channels 97-192 have depths 0 through 705. The second shank has the same chunking.

Is it my impression, or does the sorting algorithm not generalize properly? Is KS treating the two groups per shank separately?

If it helps, I've attached the "channel_positions.npy" output file (converted to .csv) and the original probe information obtained through probeinterface.

probe_table_ProbeA.csv

channel_positions.csv

[jacobpennington]

@paolahydra Sorry, I don't understand the problem. Kilosort does not re-order channels, they're indexed in the order provided in the probe file. The probe_table_ProbeA.csv you linked shows the same ordering. What is it you think is problematic about this?

[paolahydra]

@jacobpennington The problem is two-fold.

1. No, the order in the probe file is not the same as in the kilosort output. For example, the 49th row is [x: 750, y:720] in the probe file and [x:500, y: 1080] in channel_positions. I will dig deeper into what is happening and when because I need to know where my channels are. I will report on my findings if they are relevant to this topic.
2. This is more strictly related to the point of this issue. In channel_positions.npy of my two-shank recording, I found a discontinuity in the y-coordinates of each shank. As a result, two adjacent channels are far away from each other, and two non-adjacent channels are contiguous. Question: is this acceptable for the KS algorithm?
   Here is an extract of channel_positions.npy that illustrates the discontinuity for the first shank:
   index, x, y:
   0, 500, 720
   1, 532, 720
   2, 500, 735
   3, 532, 735
   ...
   94, 500, 1425
   95, 532, 1425
   96, 500, 0
   97, 532, 0
   98, 500, 15
   99, 532, 15
   ...
   191, 532, 705

Thanks.

[paolahydra]

re point 1: my bad, I found my problem. The actual probe file and the channel-position file do indeed show the same ordering. I am just left with q2... thanks!

[jacobpennington]

Re: q2, the ordering of the contacts does not matter, so that is not a problem. The x,y positions are treated the same whether the contacts are listed next to each other or far apart.

…

On Tue, May 14, 2024, 1:36 AM Paola Patella ***@***.***> wrote: re point 1: my bad, I found my problem. The actual probe file and the channel-position file do indeed show the same ordering. I am just left with q2... thanks! — Reply to this email directly, view it on GitHub <#641 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIQ6WYDMHZEICL7GMTA5OXLZCHEJZAVCNFSM6AAAAABFJ4E7HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGYYDENBSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jacobpennington]

I've heard back from several people that multi-shank sorting is working fine, so I'm going to close this one now. If anyone encounters more issues related to multi-shank recordings, please open a new issue.