On Tue, Nov 27, 2012 at 2:20 PM, Oleksandr Moskalenko <o...@hpc.ufl.edu> wrote:
> The "Right Way (TM)" I believe would be to have a universal resource request
> selector that could be plugged into any wrapper simply by including an
> appropriate element like say <resources proc=x pmem=y walltime=z />.
> Those variables could be exported, so the corresponding DRMAA call
> could be made in the dynamic runner and the data could be used in the
> wrapper to run the underlying tool as needed.

I am not convinced about that. For a simple non-dynamic setup I
think the resources like the number of threads should be dictated
by the local configuration (e.g. universe_wsgi.ini) and customised
to the local compute resources, rather than in the tool wrappers
which must be sufficiently general to run on any Galaxy install.

In general we need dynamic negotiation between the tool (e.g. this
tool can use as many threads as you like, suggest 8) and the local
configuration (we want to limit this tool to just 4 threads to make
maximum use of our cluster), and ideally the input data (e.g. this
job will need lots of RAM and must go on the big memory queue).
Right now the dynamic runner  which John Chilton and others
are working on seems capable of this (although quite complex).


Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to