|Deletions are marked like this.||Additions are marked like this.|
|Line 40:||Line 40:|
|=== Handling custom templates||=== Handling custom templates ===|
|Line 42:||Line 42:|
|TO DO||(thanks Joff Jones)
fMRIPrep supports custom templates, but getting them into your container can be challenging! Here is a pattern that Joff has found to work. First you need templateflow on your path, so try something like activating [[Neuroconda]].
templateflow.api.TF_S3_ROOT = 'http://templateflow.s3.amazonaws.com'
fMRIPrep at MRC CBU
For details about what fMRIPrep is and why you'd want to use it, see their website. This page is about how you use it at CBU with Singularity.
Singularity is a container image runner, like the more famous Docker. The preferred route for using fMRIPrep is as a Docker container image, which we run in Singularity rather than Docker. Easy right? There is a good explanation on this CBU Intranet page.
Wait, what's a container image?
You can think of it like a little virtual machine that bundles a version of Linux, all the dependencies fMRIPrep needs, and the fMRIPrep application itself into a neat little package that can run independently of the rest of the imaging system.
Using fMRIPrep at CBU
We keep containers for each release at these imaging system paths:
/imaging/local/software/singularity_images/fmriprep/fmriprep-1.1.4.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.1.7.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.1.8.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.2.0.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.4.0.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.4.1rc4.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.4.1.simg /imaging/local/software/singularity_images/fmriprep/fmriprep-1.5.0.simg
To use it, you would do something like this frankly intimidating command, substituting the version that you want to use:
singularity run -C -B /imaging/jc01/kamitani:/kamitani /imaging/local/software/singularity_images/fmriprep/fmriprep-1.1.8.simg /kamitani/bids /kamitani/fmriprepnew participant --participant-label sub-03 -w /kamitani/fmriprepwork --nthreads 16 --omp-nthreads 16 --fs-license-file /kamitani/license.txt --output-space T1w
Again, computing has a nice explanation of what it all means on this CBU Intranet page. The key things to notice are
- You call the container image like any binary, by plugging in its full absolute path (this is different from what you may be used to coming from Docker)
- All the -B flags are for bind-mounts - like a virtual machine, the container can't see any paths on the wider imaging system unless you make them available inside the container as mounts. So for instance -B /imaging/jc01/kamitani:/kamitani makes the former imaging system path accessible inside the container as the latter path.
- It is very irritating, but you must bind-mount a path to the Freesurfer license file.
Handling custom templates
(thanks Joff Jones)
fMRIPrep supports custom templates, but getting them into your container can be challenging! Here is a pattern that Joff has found to work. First you need templateflow on your path, so try something like activating Neuroconda.
import templateflow.api templateflow.api.TF_S3_ROOT = 'http://templateflow.s3.amazonaws.com' get('MNI152NLin6Asym')