On Wed, Jul 13, 2011 at 04:46:33PM +0100, David Flitney wrote:
> It's only an estimate and your job is really dispatched via the queue
> matching function (map_qname) at the start of fsl_sub. As long as you
> have a queue capable of taking a very short job (on ours it goes to
> veryshort.q) then all should be fine.
The problem is that this logic relies on a particular set of queues with
particular names being available. Unless you have full control over the
SGE setup those are unlikely to be available. As a consequence I have
disabled map_qname in the Debian package, as SGE is capable of
automatically selecting an appropriate queue based on the wall_time
guess. That worked well over the past years -- I never got a single report
regarding this.
I would assume that something in your particular SGE setup causes this
problem (I never tested "-T 0").
On a more general level: not only the runtime guessing is causing some
headache in the way FSL talks to clusters. I was trying to work on
abstracting the whole cluster interface to something more flexible, but
I haven't had the time to make significant progress yet.
The actual issue is that knowledge of job-dependencies is hidden inside
FSL. There is currently no way to dump a full specification of a
directed acyclic graph (DAG) of all jobs at any given point. That makes
it very hard to employ more clever job-dispatchers. See this page for a
possible way to describe a job DAG
http://www.cs.wisc.edu/condor/manual/v7.0/2_10DAGMan_Applications.html
If we would have that whole pipelines could be submitted at once, instead
of each job sequentially, waiting for the SGE id, and using that to
indicate dependencies between jobs. It would also make it trivial to
indicate data dependencies and make it possible to run FSL jobs on
grids without a shared file system. There is software like:
http://nd.edu/~ccl/software/makeflow/
that would automatically translate that into the APIs of a number of
batch systems (including SGE and Condor).
If anyone is willing to work on this with me, I'd be very happy!
Michael
--
Michael Hanke
http://mih.voxindeserto.de
|