| Partition Name | Nodes per Job | Wall-clock Limit | Concurent Jobs Limit | Nodes | Remarks |
|---|---|---|---|---|---|
dev | 1-2 | 1h | 1 | 1-571 | For testing purposes only, max. two queued jobs |
small | 1-5 | 72h | - | 3-571 | Regular nodes, exclusive node reservation |
small_shared | 1-5 | 72h | - | 3-571 | Same settings as small but node resources are by default shared |
small_fat | 1-5 | 24h | - | 572-576 | Fat memory nodes, exclusive node reservation |
small_gpu | 1-5 | 24h | - | gpu 1-5 | Up to two GPUs can be allocated per job |
medium | 6-256 | 24h | - | 3-571 | Regular nodes, exclusive node reservation |
medium-s | 6-32 | 24h | 5 | 3-571 | Regular nodes, exclusive node reservation |
medium-m | 33-64 | 24h | 3 | 3-571 | Regular nodes, exclusive node reservation |
medium-l | 65-256 | 24h | 1 | 3-571 | Regular nodes, exclusive node reservation |
large | >256 | 24h | - | 3-571 | Regular nodes, exclusive node reservation ! available to selected users only ! |
Please note: We are currently working on a fairer job partition scheme. The idea is to limit the medium partition with the amount of concurrent jobs. This is currently set to 70 and may be reduced to 30 for the small partition. The current medium partition would be retired / limited to one concurent job.
The Concurent Jobs Limit column defines how many jobs can run concurrently per User. In general at most 1000 jobs can be submitted per user. This is to prevent very slow job scheduling.
You may use the Quality of Service preempt (e.g. #SBATCH --qos=preempt) to be allowed to have up to 1000 jobs running at the same time, but as soon as a job with a higher priority than yours is queued, your job will be cancelled within 30 seconds. So make sure to handle signals to create checkpoints or create checkpoints periodically to be able to resume from your last state once your job is scheduled again. Cancelled jobs due to preempting are automatically requeued.