HI Shenwiyn,


The definition of regularjobs etc. is there to allow each job to be run
under different environment on the cluster.

I am actually not using most of those definitions, except for the BWA tool,
which I want to run using 4 slots on our cluster so I use the destination


The nativeSpecification are the options that you can give as if you were to
use the QSUB command directly to submit jobs to the cluster.


-V -q short.q -pe smp 1

Is what I normally use for the qsub command for a job that is fast, for


You don't need to specify the destination for each job, since the tool
section has a default, which is "regularJobs" in my case.

So only if you want to do something other than submit a regular job (which
only takes one slot) do you need to define something else, like I did for


Hope that helps






Thon deBoer Ph.D., Bioinformatics Guru 
California, USA |p: +1 (650) 799-6839  |m:   <mailto:thondeb...@me.com>


From: shenwiyn [mailto:shenw...@gmail.com] 
Sent: Tuesday, July 30, 2013 11:52 PM
To: Thon Deboer
Cc: galaxy-dev@lists.bx.psu.edu
Subject: shall us specify which tool run in cluster?


Hi Thon Deboer ,

I am a newer in Galaxy.I installed my Galaxy with Torque2.5.0 ,and Galaxy
uses the pbs_modoule to interface with TORQUE.But I have some question of
the  job_conf.xml :

1.)In your  job_conf.xml ,you use regularjobs,longjobs,shortjobs...to run
different jobs ,how our Galaxy know which tool belongs to regularjobs or
longjobs.And what is the meaning of "nativeSpecification"?

2.)Shall us use <tools>collection of <tool id="bwa_wrapper"
destination="multicorejobs4"/>to specify bwa ?Does it mean the bwa belong to
multicorejobs4,and run in cluster?

3.)Does every tool need us to specify which job it belong to?

 I saw http://wiki.galaxyproject.org/Admin/Config/Jobs about this,but I am
not sure above.Could you help me please?





From: Thon Deboer <mailto:thondeb...@me.com> 

Date: 2013-07-18 14:31

To: galaxy-dev <mailto:galaxy-dev@lists.bx.psu.edu> 

Subject: [galaxy-dev] Jobs remain in queue until restart



I have noticed that from time to time, the job queue seems to be "stuck" and
can only be unstuck by restarting galaxy.

The jobs seem to be in the queue state and the python job handler processes
are hardly ticking over and the cluster is empty.


When I restart, the startup procedure realizes all jobs are in the a "new
state" and it then assigns a jobhandler after which the jobs start fine..


Any ideas?





P.S I am using the june version of galaxy and I DO set limits on my users in
job_conf.xml as so: (Maybe it is related? Before it went into dormant mode,
this user had started lots of jobs and may have hit the limit, but I assumed
this limit was the number of running jobs at one time, right?)


<?xml version="1.0"?>


    <plugins workers="4">

        <!-- "workers" is the number of threads for the runner's work queue.

             The default from <plugins> is used if not defined for a


        <plugin id="local" type="runner"
load="galaxy.jobs.runners.local:LocalJobRunner" workers="2"/>

        <plugin id="drmaa" type="runner"
load="galaxy.jobs.runners.drmaa:DRMAAJobRunner" workers="8"/>

        <plugin id="cli" type="runner"
load="galaxy.jobs.runners.cli:ShellJobRunner" workers="2"/>


    <handlers default="handlers">

        <!-- Additional job handlers - the id should match the name of a

             [server:<id>] in universe_wsgi.ini.


        <handler id="handler0" tags="handlers"/>

        <handler id="handler1" tags="handlers"/>

        <handler id="handler2" tags="handlers"/>

        <handler id="handler3" tags="handlers"/>

        <!-- <handler id="handler10" tags="handlers"/>

        <handler id="handler11" tags="handlers"/>

        <handler id="handler12" tags="handlers"/>

        <handler id="handler13" tags="handlers"/>



    <destinations default="regularjobs">

        <!-- Destinations define details about remote resources and how jobs

             should be executed on those remote resources.


        <destination id="local" runner="local"/>

        <destination id="regularjobs" runner="drmaa" tags="cluster">

            <!-- These are the parameters for qsub, such as queue etc. -->

            <param id="nativeSpecification">-V -q long.q -pe smp 1</param>


        <destination id="longjobs" runner="drmaa" tags="cluster,long_jobs">

            <!-- These are the parameters for qsub, such as queue etc. -->

            <param id="nativeSpecification">-V -q long.q -pe smp 1</param>


        <destination id="shortjobs" runner="drmaa"

            <!-- These are the parameters for qsub, such as queue etc. -->

            <param id="nativeSpecification">-V -q short.q -pe smp 1</param>


        <destination id="multicorejobs4" runner="drmaa"

            <!-- These are the parameters for qsub, such as queue etc. -->

            <param id="nativeSpecification">-V -q long.q -pe smp 4</param>



        <!-- <destination id="real_user_cluster" runner="drmaa">




        </destination> -->


        <destination id="dynamic" runner="dynamic">

            <!-- A destination that represents a method in the dynamic
runner. -->

            <param id="type">python</param>

            <param id="function">interactiveOrCluster</param>




        <!-- Tools can be configured to use specific destinations or

             identified by either the "id" or "tags" attribute.  If assigned

             a tag, a handler or destination that matches that tag will be

             chosen at random.


        <tool id="bwa_wrapper" destination="multicorejobs4"/>



        <!-- Certain limits can be defined.

        <limit type="registered_user_concurrent_jobs">500</limit>

        <limit type="unregistered_user_concurrent_jobs">1</limit>

        <limit type="concurrent_jobs" id="local">1</limit>

        <limit type="concurrent_jobs" tag="cluster">200</limit>

       <limit type="concurrent_jobs" tag="long_jobs">200</limit>

        <limit type="concurrent_jobs" tag="short_jobs">200</limit>

        <limit type="concurrent_jobs" tag="multicore_jobs">100</limit>




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:

To search Galaxy mailing lists use the unified search at:

Reply via email to