In case this fell through the cracks with the recent listserv
problems, this is a repost of our question regarding a FEAT error
using our cluster. Thanks in advance!
Ted
On Mar 24, 2010, at 4:32 PM, Lokke Highstein wrote:
> just to add some more info about this:
>
> if we edit the design.fsf file to remove references to
> /private/var/automount/nfs/ and instead put just /nfs/path/to/files in
> both the input and outpur directory fields, the job still won't run,
> *however* if those changes are made and the job is run with fsl_sub
> (i.e. "fsl_sub feat design.fsf" as opposed to "feat design.fsf" the
> jobs
> run fine.
>
> however that isn't the way that it's supposed to work, unless i am
> wrong, feat has fsl_sub built in, and should work anyway.
>
> so far the biggest clue that we have is that feat doesn't like
> automount. is anyone else using automount successfully?
>
> thanks for any help,
>
> lokke
> On Tue, 2010-03-23 at 16:34, Ted Yanagihara wrote:
>> Dear all,
>>
>> We recently updated our storage which changed the paths to our data.
>> Everything is up and working perfectly fine, except a problem that is
>> specific to submitting FEAT jobs. To be clear, we are running FSL
>> 4.1.5, on a cluster of PPC Apple Xserves, using SGE. The work is
>> done on
>> NFS mounted volumes using automount located at /nfs/research/
>> data. We
>> added a line to the sge_aliases file to link /private/var/
>> automount/nfs
>> to /nfs. None of that has helped.
>>
>> In the command line, typing "feat design.fsf" will properly set up
>> the "pre" "reg" "post" and "stop" jobs in the queue. However, once
>> these jobs go into on of the cluster processors, each job is
>> terminated prematurely. No errors are found in the report_log file,
>> but in the preproc.feat/logs directory the following error is
>> reported in the feat2_pre.e file:
>>
>> grep: /private/var/automount/nfs/research/data/tyanagihara/hedrat/
>> x_am84/group/1int-2val_hedonic_tor28.gfeat/design.fsf: No such file
>> or directory
>> while executing
>> "exec sh -c "grep 'fmri(inmelodic)' $filename | tail -n 1 | awk
>> '{ print \$3 }'" "
>> (procedure "feat5:load" line 5)
>> invoked from within
>> "feat5:load -1 1 ${fsfroot}.fsf"
>> (file "/common/fsl4.1.5/bin/feat" line 132)
>>
>> I've made sure, and the design.fsf file that it is looking for does,
>> in fact, exist.
>>
>> Another potentially useful note is that, after running a job that
>> errors, if we log into the node that it tried to run in and check the
>> logs we get a different error. Here, it says that the node cannot
>> find a file, but it is looking in the wrong place because it is using
>> the *old* path that existed before the storage upgrade. This is very
>> strange, because nowhere in the setup of the design file (I've tried
>> doing this manually and with the GUI) do we input the old paths. SGE
>> has been updated and all other FSL jobs have been running without
>> problem.
>>
>> Any help with troubleshooting would be greatly appreciated. Thank
>> you,
>>
>> Ted
> --
> Lokke Highstein
> Systems Manager
> PICS, Columbia University
> 710 W.168th st.
> New York, NY 10032
> 212-342-0293
>
|