Pydra SPM

[ghisvail]

This thread discusses the elements of design for a Pydra SPM task package.

Pieces of information listed in this thread may be imprecise of incomplete. They will be refined over time as collective understanding improves through brainstorming and experimentation.

Initial brainstorming session happened during the last Pydra hackathon on May 3rd with @effigies, @djarecka and myself.

Challenges

1. Multiple SPM versions: SPM12 (the default today), SPM8, SPM5 and SPM2.

2. Multiple runtimes: MATLAB (version 7.4 to 9.14), standalone (with separate MCR) and Octave (with SPM patches)

3. Different environment setup: for MATLAB, for SPM standalone, for Docker

4. Primarily designed as a GUI tool

5. Support for compressed NIfTI is unclear

Focus

1. Focus on SPM12, since it's been the default version for a while.

2. Give priority to the standalone version. Feature parity with MATLAB is no longer a concern, and it's also used for the official Docker container. It's also simpler to deploy and does not require a MATLAB license to operate.

3. Focus on the standalone model, which uses run_spm12.sh /path/to/MCR /path/to/SPM12/script. This might need adaptation for running in Docker.

4. This is what makes SPM12 particularly tricky to run as a task. A script needs to be generated based on the task specifications prior to being passed to the SPM12 run script.

5. This needs to be investigated further, either by asking upstream first, or fallback to experimenting by trials as the port to Pydra progresses. We might want to consider providing compression / decompression utils too, just in case.

Pydra task design

SPM tasks will basically perform two sequential operations: prepare the MATLAB script and run its execution through the SPM12 wrapper. Unlike a regular ShellCommandTask whereby the generated commandline varies based on the field values, a SPMCommandTask will generate a MATLAB script whose content will vary based on the desired processing and field values.