Make parallelization possible on the dimensions other than trials (e.g. over channels)

[nazgulfg92]

Is your feature request related to a problem? Please elaborate.
Parallelization appears to only run over trials. If there's not trial structure in the data (e.g. spontaneous activity), there doesn't seem to be a way to tell Syncopy to use channels as the dimension to parallelize.

Do you have a solution in mind? Please elaborate
Would be nice to add the possibility to use the channel dimension (or any other dimension that is not trials) on the data for parallelization. Perhaps let things run in parallel, if no trials, over the first non-singleton dimension of the data structure hierarchy (e.g. if no trials, then channels, etc.).

Not really a problem per se, more like a missing feature? Please elaborate
Please provide a description of what kind of functionality you want to see in Syncopy. If possible/applicable, please consider writing a few lines of (pseudo-)code to illustrate your thoughts.

Thanks!

[tensionhead]

Thanks for bringing the deficits of our documentation to our attention @nazgulfg92! There is actually a "meta-parameter" available for all meta-functions (spy.freqanalysis, spy.preprocessing, spy.resampledata, ...) called chan_per_worker which allows exactly what you asked for: parallelization over channels. So to use it, you would for example give

fft_spec = spy.freqanalysis(data, chan_per_worker=50)

and so if you have say 200 channels but only 1 trial, this would spawn 4 parallel processes.
There are of course methods, like bascially everything offered by spy.connectivityanalysis, where this is not trivially possible, as for those measures cross-channel entities have to be calculated. For these cases, manually cutting the initial data into smaller channel portions (via spy.selectdata(data, channel=[..]) might help.

Please let me know if chan_per_worker works for you as expected 🙂

PS: Parallelization over different axis does not seem to have a real use case by now, but I acknowledge that this could be a cool feature some time in the future.

[nazgulfg92]

Thanks! I tried yesterday to give it a try, since I got some inside knowledge talking to @pantaray... but it couldn't figure out how the parameter actually worked. I kept getting some errors trying to use it with chan_per_worker = 1, assuming it'd get me one worker per channel (a little bit backwards from the parameter name, I admit haha).
What you say helps a lot making things clearer in my head. I'll try it out and let you know :)

[tensionhead]

Hey @nazgulfg92 , did you had any luck with the chan_per_worker parameter? Thx for letting us know!

[nazgulfg92]

Hi @tensionhead, I tried but for some reason I don't remember it didn't work out for me. Might have been something with the implementation itself, or perhaps that it suddenly didn't fit my workflow (I managed to get ACME working on our Slurm from my computer). I'll try and take a look to see if there are some traces why chan_per_worker didn't make the cut. Will keep you updated :)

[tensionhead]

In any case we should add a unit test to veryify this functionality for the supported computations!