Print

Print


Hi all


have spent a merry day chasing this one down (thanks to my colleague Wilson
for moral and mental support at the end of the day!).    A user triggered this  
with a higher-level analysis.

The feat script submits a number of jobs to the queue with job dependencies.

In particular, there is a section of feat thus:

	set ID [ fsl:exec "${FSLDIR}/bin/feat ${fsfroot}.fsf -D $FD -I $session -flame1" -b 60 -N feat3a_flame -h $preID -l logs ]
	set ID [ fsl:exec "./.flame" -b 60 -N feat3b_flame -h $ID -l logs -f ]



at around line 650.    The second line  submits the file .flame.  However, the contents of  .flame is actually generated
by the previous job.    There is a fudge in feat to generate a dummy .flame file (with the line "dummy")
at the beginning so that when these jobs are all submitted to the queue, there is a .flame file (albeit the wrong one).

Subsequently, the first line replaces .flame with the correct contents.  

When SGE then runs the .flame command, it appears that it goes and fetches the contents of .flame afresh,
Our PBS-based system does not do this. It actually runs the initial (apparently cached) .flame file.

This

1) generates an error about a missing command 'dummy'
2) of course does not run the correct command with subsequent errors.

The solution is to replace the second line with

	set ID [ fsl:exec "source  ./.flame" -b 60 -N feat3b_flame -h $ID -l logs ]


that is,   when the job runs, it executes (source) the .flame file rather than submitting it to the batch system.  This forces
it to re-read the now correct .flame file and all is well.


regards
Neil