Definitions of Quest's job queues.
Quest contains several queues (or as Moab calls them, "classes") to which jobs are assigned. Depending on the duration of your job, number of cores, and type of access to Quest, you can choose the best class for your job when you submit. If a queue is not specified, the scheduler will choose one for you based on the resources requested for the job, but it is highly recommended that you explicitly specify the appropriate queue. Users with full access to Quest or the Genomics Compute Cluster must specify the appropriate queue along with their allocation ID. To specify the queue, please include a -q option in your job submission script:
#MSUB -q <QueueName>
|Queue||Maximum Walltime||Maximum Cores/Nodes||Notes|
|short||04:00:00||1024 cores||Short jobs have access to more cores on Quest than do longer jobs. They are thus usually scheduled sooner than longer jobs. Jobs submitted without a walltime or queue explicitly specified will be assigned to the short queue and terminated after 4 hours.|
|normal||48:00:00||1536 cores||Normal jobs have higher priority with the scheduler than long jobs.|
|buyin||Allocation-specific (usually no limit)||Allocation-specific||The buyin queue is only available to those users with full access to Quest. When using the buyin queue, you must also specify the appropriate buyin allocation ID in your job submission script. The resources available and any limits on jobs are governed by the specific policies of the allocation.|
|genomics||48:00:00||10 nodes||Available to genomics researchers by application; see Genomics Compute Cluster. You must also specify the genomics allocation ID (b1042) when submitting to this queue. Special genomics queues for jobs exceeding these limits are also available.|
Additional specialized queues exist for specific allocations. You may be instructed to use a queue name that isn't listed above.
Jobs that have not finished on their own at the end of the requested walltime, or the upper limit of the queue if the walltime was not specified, will be terminated.
When resources for a job are not immediately available, the job will be assigned an idle status while the scheduler waits for resources to become available. There is a hard limit of 30 idle jobs per user. Any additional jobs will be put on a blocked list until the number of idle jobs for a user drops below 30. Jobs will be automatically moved from blocked to idle status.
If you need to run jobs longer than one week, contact Research Computing for a consultation. Some special accommodations can be made for jobs requiring the resources of up to a single node for a month or less.