
On Tue, Nov 27, 2012 at 2:20 PM, Oleksandr Moskalenko <om@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). Regards, Peter