Difference between revisions of "FSL"
Jump to navigation
Jump to search
Line 68: | Line 68: | ||
Sequence for running bedpostx: | Sequence for running bedpostx: | ||
− | * log into | + | * log into one of the development servers, dev1 or dev2, via ssh |
* cd into the directory that contains your bedpostx data directory | * cd into the directory that contains your bedpostx data directory | ||
* run screen and turn the log on (ctl-a shift-h) | * run screen and turn the log on (ctl-a shift-h) | ||
Line 75: | Line 75: | ||
* you may detach the screen at any time and then use screen -r to reattach at a later time | * you may detach the screen at any time and then use screen -r to reattach at a later time | ||
* once the script has finished running you may turn the log off | * once the script has finished running you may turn the log off | ||
− | * | + | * check the script display output and emails for warnings or error notifications |
− | |||
− | |||
− | |||
+ | Notes: | ||
+ | * If you can make sure that the terminal is not disconnected at any time while running the bedpostx script then you don't need to use screen. | ||
+ | * If you need to cancel bedpostx, once it's running, you can execute the cancel command from the created output data directory by typing ./cancel or by using the full path to the command. You must execute cancel from the same server where you originally started bedpostx. The cancel command will display the bedpostx PID in case you want to run ps aux | grep yourusername and make sure that the PID matches your bedpostx process. It may take up to 30 seconds for bedpostx to handle the request. If you run bedpostx after previously cancelling it, you may either leave the existing output data directory in place or manually delete it to start from scratch. If you do not delete the directory and there are some slices that were previously processed, they will not be processed again. The cancel command will delete itself once it's executed. | ||
+ | <br/><br/> | ||
What you should know about running bedpostx: | What you should know about running bedpostx: | ||
Revision as of 15:51, 2 January 2014
Description
FSL is a comprehensive library of analysis tools for FMRI, MRI and DTI brain imaging data.
Required Modules
Serial
- fsl
System Variables
- HPC_{{#uppercase:fsl}}_DIR
Additional Information
Running bedpostx
The bedpostx script has been modified to work with Moab/Torque for job submissions. In addition to the standard bedpostx command line options, the following Moab/Torque options have been added:
Option | Default Value | Description |
---|---|---|
-m | abe | see qsub. Note: slice job mail options are set to 'a' to avoid email overload |
-M | see qsub. Note: you must provide an email address (REQUIRED) | |
-N | pbx | job name prefix. Note: this is followed by _pre, _slice, and _post |
-ws | 4:00:00 | see qsub -l walltime. Applies to all slice processing jobs |
-wp | 1:00:00 | see qsub -l walltime. Applies to pre and post processing jobs |
-ms | 1gb | see qsub -l pmem. Applies to all slice processing jobs |
-mp | 1gb | see qsub -l pmem. Applies to all pre and post processing jobs |
-v | turns on verbose option, i.e. displays additional information |
Sequence for running bedpostx:
- log into one of the development servers, dev1 or dev2, via ssh
- cd into the directory that contains your bedpostx data directory
- run screen and turn the log on (ctl-a shift-h)
- run module load fsl
- run bedpostx, a typical command should look like: bedpostx datadir -M emailaddr
- you may detach the screen at any time and then use screen -r to reattach at a later time
- once the script has finished running you may turn the log off
- check the script display output and emails for warnings or error notifications
Notes:
- If you can make sure that the terminal is not disconnected at any time while running the bedpostx script then you don't need to use screen.
- If you need to cancel bedpostx, once it's running, you can execute the cancel command from the created output data directory by typing ./cancel or by using the full path to the command. You must execute cancel from the same server where you originally started bedpostx. The cancel command will display the bedpostx PID in case you want to run ps aux | grep yourusername and make sure that the PID matches your bedpostx process. It may take up to 30 seconds for bedpostx to handle the request. If you run bedpostx after previously cancelling it, you may either leave the existing output data directory in place or manually delete it to start from scratch. If you do not delete the directory and there are some slices that were previously processed, they will not be processed again. The cancel command will delete itself once it's executed.
What you should know about running bedpostx:
- a directory will be created for the output data. It will be named using the original data folder name followed by .bedpostX
- only one bedpostx script at a time can be run for a given data directory otherwise the output data will be unreliable.
- if you run bedpostx and the output directory already exists, it will look to see if any slices need to be processed. It will then run jobs for all the unprocessed slices and post process all the slice data.
- there are 3 stages in the execution of bedpostx:
1. pre-processing - to view job status use: qstat -u yourusername 2. slice processing - a job is posted for each individual slice as part of a job array, to view individual job status use: qstat -t -u yourusername 3. post-processing - to view job status use: qstat -u yourusername
Notes:
- Because of issues with job arrays and qstat, the job array is not considered completed until all the individual jobs stop showing up in qstat - about 5 minutes after completion.
- You can not allow the terminal from which you run bedpostx to get disconnected while the script is running. If the terminal is disconnected, it will cause the job array completion detection to fail and the post processing will run before the slice processing is finished. This is why using screen is recommended.
- Be aware that the job array numbers do not match the sub-directory numbers in the diff_slices directory. The jobs are always numbered 1-n and the directory numbers 0-(n-1) the first time you run bedpostx. If you were to rerun bedpostx again with some slices already processed in a prior run, then the only way to match job numbers with sub-directory numbers is via the job control file commands.txt.
- using qstat -u yourusername for a job array is not reliable. It will sometimes consider the job array done and gone, i.e. it will not display an entry for it, even though one or more of the individual jobs are still running.
Citation
If you publish research that uses fsl you have to cite it as follows:
- M. Jenkinson, C.F. Beckmann, T.E. Behrens, M.W. Woolrich, S.M. Smith. FSL. NeuroImage, 62:782-90, 2012
- M.W. Woolrich, S. Jbabdi, B. Patenaude, M. Chappell, S. Makni, T. Behrens, C. Beckmann, M. Jenkinson, S.M. Smith. Bayesian analysis of neuroimaging data in FSL. NeuroImage, 45:S173-86, 2009
- S.M. Smith, M. Jenkinson, M.W. Woolrich, C.F. Beckmann, T.E.J. Behrens, H. Johansen-Berg, P.R. Bannister, M. De Luca, I. Drobnjak, D.E. Flitney, R. Niazy, J. Saunders, J. Vickers, Y. Zhang, N. De Stefano, J.M. Brady, and P.M. Matthews. Advances in functional and structural MR image analysis and implementation as FSL. NeuroImage, 23(S1):208-19, 2004