Parallelising bedpost

Bedpost runs Markov Chain Monte Carlo sampling to build up distributions on diffusion parameters at each voxel. This is a very slow process, so bedpost is very processor hungry ( a typical bedpost run might take around 20hrs for 60 direction 2.5mm isotropic data)! However, fortunately bedpost processes every voxel independently, so it is very easy to parallelise.

In order to parallelise bedpost you need multiple processors which can see the same data directory, and which you can log onto using a remote call which does not require a password (for an example of how to do this with ssh see here).

When you have this, you need to set the following environment variables:

FSLMACHINELIST: a list of machines on which bedpost should be run. Each machine can be included more than once to make use of multiple processor machines.
FSLREMOTECALL:The program you want to use to make the remote calls, e.g. ssh or rsh

e.g. for a bash user:
FSLMACHINELIST="machine1 machine1 machine2 machine3 machine5"
FSLREMOTECALL=ssh
export FSLMACHINELIST FSLREMOTECALL

This will enable bedpost to use ssh to send jobs to two processors on machine1, and one each on machine2 machine3 machine5.

You also need to make a file called fsl.sh in one of the following places.
/usr/local/etc/fslconf/fsl.sh
/etc/fslconf/fsl.sh
/${HOME}/.fslconf/fsl.sh

in this file you need to set your FSLDIR in sh language. e.g.:
FSLDIR=/usr/local/fsl
export FSLDIR

NB(1): you may already have this file, and it may set other config variables (e.g. FSLMACHINELIST and FSLREMOTECALL). This is absolutely fine, as long as it also sets FSLDIR

NB(2): If you are a csh or tcsh user you may already have an equivalent fsl.csh in one of the above directories. Note that you still need to specify the fsl.sh file as above. Parallel bedpost uses sh not csh.

NB(3): If you have this file in more than one of the above locations, bedpost will read them in the order specified above, hence the the last setting of FSLDIR will be the one that stands in the case of conflicts.

Locking bedpost

You may want to set up a system whereby only one person can use bedpost at any one time (thus keeping the system load down). In order to do this, set the FSLLOCKDIR environment variable to a directory which is writeable by the users. Every time a bedpost starts, it will write ${FSLLOCKDIR}/.bedpost.lock which will be removed when bedpost completes. If this file is present, new bedpost processes will not start.

Cleaning up bedpost

Bedpost should be relatively well behaved in most circumstances. e.g. If bedpost is cancelled from the keyboard, then it first logs onto all machines in the list and kills its child processes, leaving no trace. However, there are some circumstances where bedpost might not behave so well - e.g. if the master machine (from where bedpost is called) crashes, I don't think the processes on the other machines will crash. If this situation occurs, there is a program called bedpost_cleanup, which will kill all bedpost related processes owned by the user on all machines in $FSLMACHINELIST.