FSL

### 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.
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`, on each machine listed, 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 all 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, the processes on the other machines will probably not be stopped. 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`.