BACK to Local User Guide, main document

The table below shows the queues available and an indication of the limits which may apply on the AC. These are the default queue limits - users can request variations to these limits.

Queue Walltime Limit(1) Memory(2,3) Ncpus(3) #Qued Charge(4)
express(5) 2hrs / Ncpus½ 100MB / 16GB 4 2 3*Ncpus*T
normal(5) 48hrs / Ncpus½ 100MB / 128GB 64 150 Ncpus*T
copyq 10hrs 100MB / 400MB 1 50 cputime
interactive(6) 24mins 200MB 4 6(7) 2*cputime

Notes:

  1. The job time limit is imposed on wall clock time. All jobs will have exclusive access to those cpus assigned to the job. If a job is suspended, its wall clock time will also be suspended.

  2. The memory limit is imposed on virtual memory (job size).
    The memory limit specification in this column is (default without request) / (maximum possible request) - users are encouraged to make (accurate) requests

  3. Shared memory jobs are limited to the size of the largest node (default is 24 cpus and 48GB, but a small number of nodes allow up to 96GB). Requests for shared memory jobs must use the request notation -lncpus=N:N to avoid the job being distributed over multiple nodes.

  4. T is the walltime used by the job, not the walltime requested.

  5. The qsub option -I can be used to gain an batch interactive shell running as a batch job (in one of the batch queues) - all the usual limits and charging rates of that queue apply. Batch interactive sessions probably need to be run in the express queue to ensure they start before you fall asleep at the terminal waiting for them. Note that a batch interactive shell is charged on elapsed walltime just like any other batch job, so it is important not to walk away from your terminal and leave your session go idle.

  6. Unix limits are imposed on interactive login processes. Interactive mpirun/prun jobs have similar limits per MPI process.

  7. The number of interactive login shells is limited.

BACK to Local User Guide, main document