Yes - in fact this was a bug - the call to "batch" in fdt.tcl should
have been to fsl_sub and using the -T option not the explicit queue
name - we'll make a patch shortly (though the direct fix mentioned to
call qsub is fine too).
Cheers.
On 10 Oct 2007, at 21:53, Lokke Highstein wrote:
> thanks merry,
>
> that was it, we are able to submit the probtrack jobs fine now.
>
> just a few more types of jobs to test.
>
> -lokke
> On Oct 10, 2007, at 2:57 PM, Merry Mani wrote:
>
>> Hi,
>>
>> I had the same problem on OS X too. I showed it to my system
>> administrator and he modified the fdt.tcl by changing the "exec
>> batch -q all.q ${filebase}_script.sh" to "exec qsub -q all.q $
>> {filebase}_script.sh". Now it works fine for me.
>>
>> -Merry
>>
>>
>> On Oct 10, 2007, at 2:36 PM, Lokke Highstein wrote:
>>
>>> hi matthew,
>>>
>>> we don't have a long.q (or a short.q, veryshort.q, or verylong.q)
>>> we only are currently using the all.q
>>>
>>> so i went and changed all the references to "long.q" in the
>>> fdt.tcl file and edited them to all.q instead. i think that is
>>> what you are getting at. if you were suggesting that i remove
>>> any references to long.q by commenting out the whole line, i can
>>> do that but it seems like it would guarantee that the job
>>> wouldn't get submitted to the cluster then.
>>>
>>> unfortunately changing that didn't help with the GUI error, and
>>> even under command line use, the job still just ran on the head
>>> node (didn't get submitted to the SGE)
>>>
>>> here's the error output from the GUI:
>>>
>>> usage: at [-q x] [-f file] [-m] time
>>> at -c job [job ...]
>>> at [-f file] -t [[CC]YY]MMDDhhmm[.SS]
>>> at -r job [job ...]
>>> at -l -q queuename
>>> at -l [job ...]
>>> atq [-q x] [-v]
>>> atrm job [job ...]
>>> batch [-f file] [-m]
>>> usage: at [-q x] [-f file] [-m] time
>>> at -c job [job ...]
>>> at [-f file] -t [[CC]YY]MMDDhhmm[.SS]
>>> at -r job [job ...]
>>> at -l -q queuename
>>> at -l [job ...]
>>> atq [-q x] [-v]
>>> atrm job [job ...]
>>> batch [-f file] [-m]
>>> while executing
>>> "exec batch -q all.q ${filebase}_script.sh"
>>> ("probtrackx" arm line 144)
>>> invoked from within
>>> "switch -- $probtrack(tool) {
>>> eddy_current {
>>> global eddy
>>>
>>> set errorStr ""
>>> if { $eddy(input) == "" } { set errorStr "You need to
>>> specify..."
>>> (procedure "fdt:apply" line 5)
>>> invoked from within
>>> "fdt:apply .fdt keep"
>>> invoked from within
>>> ".fdt.apply invoke"
>>> ("uplevel" body line 1)
>>> invoked from within
>>> "uplevel #0 [list $w invoke]"
>>> (procedure "tk::ButtonUp" line 22)
>>> invoked from within
>>> "tk::ButtonUp .fdt.apply"
>>> (command bound to event)
>>>
>>> On Oct 10, 2007, at 6:42 AM, Matthew Webster wrote:
>>>
>>>> Hi,
>>>> It looks like the problem is with the batch call - the "-q"
>>>> option doesn't seem to be available for the osx batch command.
>>>> If you remove "-q long.q" from the batch command in fdt.tcl, I
>>>> think it should batch correctly.
>>>>
>>>> Matthew
>>>>> hello list,
>>>>>
>>>>> sorry to keep bugging you all, but we are making a lot of
>>>>> progress with our cluster, thanks to this list, and we are
>>>>> almost fully functional which is very exciting, as we are
>>>>> seeing some very impressive speeds on the larger jobs
>>>>> (especially bedpost!)
>>>>>
>>>>> i implemented the symbolic links which were suggested to me in
>>>>> earlier posts, and now we can run bedpostx jobs and FEAT jobs
>>>>> fine from the gui, however we seem to have hit a snag with
>>>>> probtrackx. here is the information i got from the user in
>>>>> question, please advise what the problem could be, as it works
>>>>> fine from the command line (although for some reason this job
>>>>> gets run on the head node only and never gets submitted through
>>>>> the qsub process to the cluster.)
>>>>>
>>>>> Running probtrackx from the GUI creates the appropriate output
>>>>> directory, but only contains fdt_log.tcl and fdt_script.sh
>>>>>
>>>>> If I open fdt_script.sh and paste only the probtrackx command
>>>>> into the terminal command line, the job runs perfectly. This is
>>>>> the command that I paste:
>>>>>
>>>>> /common/fsl/bin/probtrackx --mode=seedmask -x /Volumes/Clinical/
>>>>> homes/tyanagihara/sweat/DTI/mask-dump/seed-internalCapsule-
>>>>> mask.hdr -l -c 0.2 -S 2000 --steplength=0.5 -P 5000 --stop=/
>>>>> Volumes/Clinical/homes/tyanagihara/sweat/DTI/mask-dump/target1-
>>>>> mask.hdr --forcedir --opd -s
>>>>>
>>>>> This is the error I get when running from the GUI:
>>>>> usage: at [-q x] [-f file] [-m] time
>>>>> at -c job [job ...]
>>>>> at [-f file] -t [[CC]YY]MMDDhhmm[.SS]
>>>>> at -r job [job ...]
>>>>> at -l -q queuename
>>>>> at -l [job ...]
>>>>> atq [-q x] [-v]
>>>>> atrm job [job ...]
>>>>> batch [-f file] [-m]
>>>>> usage: at [-q x] [-f file] [-m] time
>>>>> at -c job [job ...]
>>>>> at [-f file] -t [[CC]YY]MMDDhhmm[.SS]
>>>>> at -r job [job ...]
>>>>> at -l -q queuename
>>>>> at -l [job ...]
>>>>> atq [-q x] [-v]
>>>>> atrm job [job ...]
>>>>> batch [-f file] [-m]
>>>>> while executing
>>>>> "exec batch -q long.q ${filebase}_script.sh"
>>>>> ("probtrackx" arm line 144)
>>>>> invoked from within
>>>>> "switch -- $probtrack(tool) {
>>>>> eddy_current {
>>>>> global eddy
>>>>>
>>>>> set errorStr ""
>>>>> if { $eddy(input) == "" } { set errorStr "You need to
>>>>> specify..."
>>>>> (procedure "fdt:apply" line 5)
>>>>> invoked from within
>>>>> "fdt:apply .fdt keep"
>>>>> invoked from within
>>>>> ".fdt.apply invoke"
>>>>> ("uplevel" body line 1)
>>>>> invoked from within
>>>>> "uplevel #0 [list $w invoke]"
>>>>> (procedure "tk::ButtonUp" line 22)
>>>>> invoked from within
>>>>> "tk::ButtonUp .fdt.apply"
>>>>> (command bound to event)
>>>
------------------------------------------------------------------------
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
---
