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
