SpikeInterface / SpikeInterface/probeinterface

`ProbeGroup` should enforce contact position uniqueness across probes

Open
#422 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
85
Forks
49
Avg merge
13h 47m
Merged PRs (30d)
3

Description

We should not have a ProbeGroup with overlapping contact positions.
I think ProbeGroup.add_probe should raise an error if the incoming probe has contact positions that collide in space with contacts already in the group. A ProbeGroup represents a physical experimental setup, and two distinct contacts cannot occupy the same spatial position. We should enforce that invariant at Probe construction and when adding an extra Probe with ProbeGroup.add_probe.

Currently we enforce checks with _check_compatible within ProbeGroup.add_probe that raises an error when trying to mix 2D and 3D probes. We should extend it for contact position uniqueness across the probe group. We are already doing this at the Probe level (see Probe.set_contacts) and I think we should use the same criteria when forming a ProbeGroup, where two contacts might be in the same position in the experimental setup.

In practice, we are already checking this on the SpikeInterface side: ChannelsAggregationRecording asserts unique contact positions before building a combined ProbeGroup. I think the responsibility and logic for this should be here.

The complication of a probe having a side (or whatever comes in the future) does not really change the logic here. If the criterion is position, we should validate position across the probe group; if the criterion for uniqueness is position plus side, we should validate that; we can extend the criterion to whatever might come, but we should check it.

Note that this is separate from the contact_ids uniqueness discussed in #402 (unique at probe level, compound key (probe_index, contact_id) unique at group level). Positions are stricter, because they correspond to physical space rather than a labelling choice.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/probeinterface/probegroup.py with ProbeGroup.add_probe and _check_compatible, then compare the existing position validation in src/probeinterface/probe.py at Probe.set_contacts. Trace how probes are constructed and grouped, and identify the existing tests covering these entry points. Done means colliding contact positions are rejected consistently when contacts are set and when probes are added to a group, without confusing this with contact_ids uniqueness.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
56/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.