Contents
Availability of FSL
FSL is available ready to run for macOS and Linux (Centos or Debian/Ubuntu) - with Windows computers being supported via the Windows Subsystem for Linux (WSL). We also provide source code if you run an OS not directly supported by us.
Installing FSL
We strongly recommend that the FSL software is downloaded and installed using the fslinstaller.py script available from the link below:
Once you have downloaded the installer, fslinstaller.py, you can use it to install FSL on your computer by following these instructions (click on the appropriate link now, as the next steps for installing are described in the linked pages, not in the sections immediately below here):
Patching FSL
After you have installed FSL for the first time, you can update your version to keep up with new releases by following these instructions to apply upgrades/patches (e.g. from version 6.0.1 to 6.0.2):
Troubleshooting: commands missing after installation
If, after installing FSL, FSLeyes is missing, or you encounter errors such as imcp: No such file or directory (or similar errors referring to imglob or immv), then this means that the installation did not complete successfully. To fix this, follow these steps (you may be able to omit sudo if you installed FSL into a location other than /usr/local/fsl/):
Check to see if a directory called $FSLDIR/fslpython exists. If it does, delete it by running sudo rm -r $FSLDIR/fslpython.
Run sudo $FSLDIR/etc/fslconf/fslpython_install.sh -f $FSLDIR to re-install the missing components.
Note that this will cause a large amount of data to be downloaded - a fast and reliable internet connection is necessary in order for the installation to complete successfully.
Running FSL
Shell setup
The FSL Install script will setup your computer such that you can run the FSL tools from a terminal. See our shell setup guide for details on what this script does. On Linux computers it can also be used to configure FSL for all users on the computer.
Starting the programs
Once your account is configured for FSL use, you can run the FSL tools from the command line; the tools are stored in $FSLDIR/bin and this location will have been added to your terminal's search locations for ease of use.
In general, command-line programs are lower case (e.g. bet), with the GUI version capitalised (e.g. Bet), except on macOS, where you need to append _gui because it can't tell the difference between upper and lower case filenames (e.g. Bet_gui).
To bring up a simple GUI which is just a menu of the main individual FSL GUI tools, just type fsl.
Using FSL with a GridEngine (or similar) computing cluster
Several of the more compute-intensive tools can take advantage of cluster computing, via Son of Grid Engine or http://gridscheduler.sourceforge.net/| Open Grid Scheduler]] (both forks of Sun Grid Engine). We would largely recommend using Son of Grid Engine if you are building a cluster from scratch on a Centos system as they provide RPMs to ease installation. Debian/Ubuntu users should look to install the gridengine package.
Cluster aware tools
FEAT will run multiple first-level analyses in parallel if they are setup all together in one GUI setup. At second level, if full FLAME (stages 1+2) is selected then all the slices are processed in parallel.
MELODIC will run multiple single-session analyses (or single-session preprocessing if a multi-session/subject analysis is being done) in parallel if they are setup all together in one GUI setup.
TBSS will run all registrations in parallel.
BEDPOSTX (FDT) low-level diffusion processing will run all slices in parallel.
FSLVBM will run all registrations in parallel, both at the template-creation stage and at the final registrations stage.
POSSUM will process all slices in parallel.
All the above tools interact with a compute cluster via a single central script fsl_sub; if no cluster is available then this script silently runs all the requested jobs in series. To customise FSL for your local compute cluster and clustering software, simply edit ${FSLDIR}/bin/fsl_sub - hopefully the comments in this file are sufficient to make this fairly painless, particularly for labs using a GE variant. For clustering software other than GE, note that fsl_sub makes use of a GE feature allowing the submission of a text file containing a list of commands (one per line) to be run in parallel.
Running bedpostX on a GPU or GPU cluster
We now have a CUDA implementation of bedpostX which gives 100x speedup on a single GPU compared to a single CPU core. Running the CUDA version of bedpostX requires some special settings as explained below.
- Requirements:
- Linux CentOS 6 or CentOS 6.5
- NVIDIA GPU with compute capability 2.0 or superior
- (FSL version 5.0.6 and CUDA Toolkit 5.0) or (FSL version 5.0.7/5.0.8 and CUDA Toolkit 5.5) or (FSL version 5.0.9 and CUDA Toolkit 6.5)
- SGE for multi-GPU (or optionally SGE for single-GPU)
- Running:
Without SGE (single GPU): Simply run bedpostx_gpu <dataDirectory> [options]
- With SGE:
The environment variable SGE_ROOT must be set
In addition, the variable FSLGECUDAQ must be set with the name of your GPUs queue (which may have 1 or several GPUs)
Simply run bedpostx using the usual call: bedpostx <dataDirectory> [options]
By default, bedpostx will divide the dataset into 4 parts submitted as 4 different jobs. Therefore, if there are 4 GPUs (4 slots in the CUDA queue), they can be processed in parallel. In order to use a different number of parts, use the -NJOBS option. For instance, for using 8 GPUs, run as follows: bedpostx <dataDirectory> -NJOBS 8 [options]
- Please reference the following paper when using the GPU version of bedpostx:
[Hernandez 2013] Hernandez M, Guerrero GD, Cecilia JM, Garcia JM, Inuggi A, Jbabdi S, Behrens TEJ, Sotiropoulos SN, (2013) Accelerating Fibre Orientation Estimation from Diffusion Weighted Magnetic Resonance Imaging Using GPUs. PLoS ONE 8(4):e61892