I downloaded fsl 5.0.9 again, to make sure I had the latest fsl_sub version. But the version that came with it is still missing the -R flag. I don't know why this is the case, since at this point I've done both a manual download and the automatic. Dr. Orr, I wonder if you would mind sending me the code for the fsl_sub you have? Not completely sure that will work embedded in the other commands, but it seems like it's worth a shot.
Sarah On Fri, May 6, 2016 at 1:18 PM, Joseph Orr <[email protected]> wrote: > That's from the code package with fsl 5.0.9 (on a CentOS system at least). > Perhaps your sysadmin copied fsl_sub from an old version to carry over > modifications, e.g., modification for a non-SGE job manager. My fsl_sub is > heavily modified for slurm, but the section that contains the fsl_sub > options is from the original. > > -- > Joseph M. Orr, Ph.D. > Assistant Professor > Department of Psychology > Texas A&M University > College Station, TX > > On Fri, May 6, 2016 at 12:08 PM, Sarah Heilbronner < > [email protected]> wrote: > >> Sounds right, since my fsl_sub is missing that part! I have fsl version >> 5.0.9 running, with the fsl_sub that came with it. Where is your version of >> fsl_sub from? >> >> On Fri, May 6, 2016 at 1:01 PM, Joseph Orr <[email protected]> wrote: >> >>> Sounds like you might be using an old version of fsl_sub. You should >>> have a section in fsl_sub that starts with "$command V1.0beta" that has the >>> following options for fsl-sub: >>> >>> -T <minutes> Estimated job length in minutes, used to >>> auto-set queue name >>> This is helpful if you don't set a FSL default queue. >>> -q <queuename> Name of FSL defualt queue possible values for >>> <queuename> >>> are "verylong.q", "long.q" and "short.q". See below for >>> details. >>> -Q <queuename> Name of Wash U Queue to use, one of (dque, dque_HT, >>> dque_smp) >>> -a <arch-name> Architecture [e.g., darwin or lx24-amd64] >>> -p <job-priority> Lower priority [0:-1024] default = >>> 0 >>> -M <email-address> Who to email, default = none >>> -j <jid> Place a hold on this task until job jid has >>> completed >>> -t <filename> Specify a task file of commands to execute in >>> parallel >>> -N <jobname> Specify jobname as it will appear on queue >>> -n <nCPUs> Number of CPUs per node that job will use >>> (default = 1) >>> -R <RAM> Max total RAM to use for job (integer in MB) >>> -l <logdirname> Where to output logfiles >>> -m <mailoptions> Change the notification mail options, see qsub >>> for details >>> -F Use flags embedded in scripts to set SGE queuing >>> options >>> -v Verbose mode. >>> >>> -R is the MB of RAM you are allocating for the job. You may run in to >>> problems with other FSL tools with large HCP datasets, basically for >>> fslmerge and fslmaths commands you'll need to modify to allocate more RAM. >>> >>> -- >>> Joseph M. Orr, Ph.D. >>> Assistant Professor >>> Department of Psychology >>> Texas A&M University >>> College Station, TX >>> >>> On Fri, May 6, 2016 at 9:45 AM, Sarah Heilbronner < >>> [email protected]> wrote: >>> >>>> Hi Stam, >>>> >>>> Thanks for thinking this through with me! I added what you suggested, >>>> but I'm getting an error saying that -R is in invalid option. And when I >>>> look inside fsl_sub, I don't see any -R flags. Any ideas? >>>> >>>> for reference, that line is now: >>>> preprocid=`${FSLDIR}/bin/fsl_sub -T 60 -R 10000 -m as -N bpx_preproc -l >>>> ${subjdir}.bedpostX/logs ${FSLDIR}/bin/bedpostx_preproc.sh ${subjdir} >>>> ${gflag}` >>>> >>>> Thanks, >>>> Sarah >>>> >>>> >>>> On Fri, May 6, 2016 at 10:53 AM, Stamatios Sotiropoulos < >>>> [email protected]> wrote: >>>> >>>>> Hi >>>>> >>>>> If the problem is in fslslice, this is likely a memory problem. >>>>> Depending on how strict your queueing software is and what are the memory >>>>> limits for each queue, it may kill or not the preproc job if it thinks it >>>>> asks too much memory. Notice that the HCP data are an order of magnitude >>>>> larger than conventional data and this may cause such problems. All you >>>>> need to do is change the amount of memory requested when queuing >>>>> bpx_preproc. >>>>> >>>>> In the $FSLDIR/bin/bedpostx script, the line to modify (e.g. by adding >>>>> fsl_sub -T 60 -R 10000…) would be the following: >>>>> >>>>> preprocid=`${FSLDIR}/bin/fsl_sub -T 60 -m as -N bpx_preproc -l >>>>> ${subjdir}.bedpostX/logs ${FSLDIR}/bin/bedpostx_preproc.sh ${subjdir} >>>>> ${gflag}` >>>>> >>>>> >>>>> By the way the “ -rician “ flag should be “ --rician" >>>>> >>>>> Hope this helps >>>>> Stam >>>>> >>>>> >>>>> On 6 May 2016, at 14:56, Sarah Heilbronner < >>>>> [email protected]> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I've been trying to run bedpostx on a single subject's HCP >>>>> preprocessed diffusion data (I haven't made any changes from the initial >>>>> download) on our cluster. I've run it a number of different ways, and >>>>> always seem to get the same error: >>>>> /software/fsl/5.0.7/fsl/bin/bedpostx_preproc.sh: line 77: 97699 >>>>> Killed >>>>> ${FSLDIR}/bin/fslslice ${subjdir}/data >>>>> >>>>> Seems to be encountering a problem with the fslslice line inside >>>>> bedpostx_preproc. >>>>> >>>>> For reference, I'm using the latest version of FSL. I'm entering this >>>>> command: >>>>> bedpostx subject#/T1w/Diffusion -n 3 -model 2 -g -rician >>>>> >>>>> I've also tested some variations, like without grad_dev/g, etc, always >>>>> getting the same error message. Any help? >>>>> >>>>> Thanks, >>>>> Sarah Heilbronner >>>>> University of Rochester >>>>> >>>>> _______________________________________________ >>>>> HCP-Users mailing list >>>>> [email protected] >>>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> HCP-Users mailing list >>>> [email protected] >>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>>> >>> >>> >> > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
