On Nov 27, 2012, at 9:37 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
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
The dynamic wrapper is capable of building a DRMAA call based on the external data and is what I am using for our local production instance. I cannot praise it highly enough. John Chilton has made a wonderful addition to the Galaxy. However, not being able to give users some manual control over the resource requests places the burden of figuring them out on the administrator and the dataset-based heuristics are often much worse then the knowledge of the person running the analysis. In addition, different tools use different options for setting thread numbers and cannot communicate realistic or even reasonable limits as those are based on the data from actually running the tool in different conditions and finding how well it scales. Dynamic negotiation is unfeasible at this time I think. The "simple non-dynamic setup" does not really work for any real-world multi-user instance anymore. Regards, Alex