Input parameter "local_contact_locations" for "make_initial_guess_and_bounds" does not accept 3D locations

[chiyu1203]

Dear Spikeinterface community,
This question extends my previous post #3790 to analyse spike data with 3D probes.
Thanks to the latest merge #3829, I managed to start post-processing with the sorting_analyser!!
However, when calculating "unit_locations": {"method": "monopolar_triangulation"}, I bumped into the following error

Exception has occurred: ValueError
could not broadcast input array from shape (3,) into shape (2,)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\postprocessing\localization_tools.py", line 343, in make_initial_guess_and_bounds
x0[:2] = com
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\postprocessing\localization_tools.py", line 360, in solve_monopolar_triangulation
x0, bounds = make_initial_guess_and_bounds(wf_data, local_contact_locations, max_distance_um)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\postprocessing\localization_tools.py", line 123, in compute_monopolar_triangulation
unit_location[i] = solve_monopolar_triangulation(wf_data, local_contact_locations, max_distance_um, optimizer)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\postprocessing\unit_locations.py", line 100, in _run
self.data["unit_locations"] = func(self.sorting_analyzer, **method_kwargs)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\core\sortinganalyzer.py", line 2293, in run
self._run(**kwargs)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\core\sortinganalyzer.py", line 1527, in compute_one_extension
extension_instance.run(save=save, verbose=verbose)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\core\sortinganalyzer.py", line 1588, in compute_several_extensions
self.compute_one_extension(extension_name, save=save, verbose=verbose, **extension_params)
File "C:\Users\neuroPC\Documents\GitHub\spikeinterface\src\spikeinterface\core\sortinganalyzer.py", line 1450, in compute
self.compute_several_extensions(extensions=input, save=save, verbose=verbose, **job_kwargs)
File "C:\Users\neuroPC\Documents\GitHub\ephys\spike_curation.py", line 199, in calculate_analyzer_extension
sorting_analyzer.compute(compute_dict)
File "C:\Users\neuroPC\Documents\GitHub\ephys\spike_curation.py", line 306, in si2phy
calculate_analyzer_extension(sorting_analyzer)
File "C:\Users\neuroPC\Documents\GitHub\ephys\spike_curation.py", line 356, in
si2phy(thisDir, json_file)
ValueError: could not broadcast input array from shape (3,) into shape (2,)

It looks like this error is due to the "local_contact_locations", coming from the "contact_positions" of my customised 3D probe profile, includes the 3rd axis. Should I create fake 2D contact positions to avoid this issue or dig into the code already? Below is the probe profile. Please feel free to let me know if you have any thought! Thank you very much in advance.

H10_stacked_probes.json

[zm711]

What I do for this type of case is artificially make a 2d probe group for now where I squash the 3d into a 2d plane with the 3 dimension distance being the x translation of the two different probes. One of the long term goals will be to allow everything to be 3d, but most spike sorting can't handle 3d data anyway so until that point I don't know how high up that is on the priority list. I tend to find the 3D->2D works fine especially if you're isolating probe groups into their individual probes, then the position doesn't matter in 3D so you can post-hoc correct the values based on which probe is which. Does that make sense? Happy to hear if any other devs would recommend a different strategy.

[alejoe91]

Well said Zach. I agree that this would be the best approach as the 3d location is ignored by the sorters. So what you really need is only the information about shanks!

[chiyu1203]

That's a good idea! Thanks for the suggestion! I was hoping that the squared-shape probes can be useful to estimate 3D motion but yeah I was too naive about that problem....

[zm711]

I think everyone would love for something like that to happen in the future. But groups are still actively working on 2D motion so maybe someday. As always feel free to open new issues if anything else comes up!