Slurm Reference
This page is under construction! We cannot guarantee completion or accuracy of information herein while in development.
Overview
This page includes many commonly used Slurm options, but it is not an exhaustive list. Please refer to the official Slurm documentation for additional information.
SLURM Output Filename Patterns
SLURM offers ways to make your job's output filenames customizable through the use of character replacements. A table is provided below as a guide with some examples. Variables may be used or combined as desired. Note: character replacements may also be used with other SBATCH directives such as error filename, input filename, and job name.
Variable | Meaning | Example Slurm Directive(s) | Output |
|---|---|---|---|
| A job array's main job ID |
| 12345.out |
| A job array's index number |
| 12345_1.out |
| Job ID plus stepid |
| 12345.out |
| Job ID |
| 12345.out |
| Hostname of the first compute node allocated to the job |
| r1u11n1.out |
| Username |
| netid.out |
| Jobname |
| JobName.out |
Batch Job Directives
Command | Purpose |
|---|---|
| Specify the account where hours are charged. Don't know your group name? Run the command "va" to see which groups you belong to |
| Set the job partition. This determines your job's priority and the hours charged. See Job Partition Requests for additional information |
| Set the job's runtime limit in days, hours, minutes, and seconds. A single job cannot exceed 10 days or 240 hours. |
| Allocate N nodes to your job. For non-MPI enabled jobs, this should be set to "–-nodes=1" to ensure access to all requested resources and prevent memory errors. |
| ntasks specifies the number of tasks (or processes) the job will run. For MPI jobs, this is the number of MPI processes. Most of the time, you can use ntasks to specify the number of CPUs your job needs. However, in some odd cases you might run into issues. For example, see: Using Matlab By default, you will be allocated one CPU/task. This can be increased by including the additional directive --cpus-per-task. The number of CPUs a job is allocated is cpus/task * ntasks, or M*N |
| |
| Select N gb of memory per node. If "gb" is not included, this value defaults to MB. Directives --mem and --mem-per-cpu are mutually exclusive. |
| Select N GB of memory per CPU. Valid values can be found in the Node Types/Example Resource Requests section below. If "gb" is not included, this value defaults to MB. |
| Optional: Request N GPUs. |
| Optional: Request N A100 GPUs. |
| Optional: Request N V100s GPUs. |
| Optional: Request a high memory node (Ocelote and Puma only). |
| Submits an array job from indices N to M |
| Optional: Specify a name for your job. This will not automatically affect the output filename. |
| Optional: Specify output filename(s). If -e is missing, stdout and stderr will be combined. |
| Optional: Append your job's output to the specified output filename(s). |
| Optional: Request email notifications. Beware of mail bombing yourself. |
| Optional: Specify email address. If this is missing, notifications will go to your UArizona email address by default. |
| Optional: Request exclusive access to node. |
#SBATCH --export=VAR | Optional: Export a comma-delimited list of environment variables to a job. |
| Optional: Export your working environment to your job. |
| Optional: Do not export working environment to your job. |
SLURM Environment Variables
Variable | Purpose | Example Value |
|---|---|---|
| Job array's parent ID | 399124 |
| Total number of subjobs in the array | 4 |
| Job index number (unique for each job in the array) | 1 |
| Maximum index for the job array | 7 |
| Minimum index for the job array | 1 |
| Job array's index step size | 2 |
| Which cluster your job is running on | elgato |
| Points to the SLURM configuration file | /var/spool/slurm/d/conf-cache/slurm.conf |
| Number of CPUs allocated to target node | 3 |
| Number of GPUs allocated to the target node | 1 |
| Number of GPUs per node. Only set if --gpus-per-node is specified | 1 |
| Account being charged | groupname |
| The global GPU IDs of the GPUs allocated to the job. Only set in batch and interactive jobs. | 0 |
| Your SLURM Job ID | 399072 |
| Number of CPUs per node. This can be a list if there is more than one node allocated to the job. The list has the same order as SLURM_JOB_NODELIST | 3,1 |
| The job's name | interactive |
| The nodes that have been assigned to your job | gpu[73-74] |
| The number of nodes allocated to the job | 2 |
| The job's partition | standard |
| The job's QOS/Partition | qos_standard_part |
| The username of the person who submitted the job | netid |
| Same as SLURM_JOB_ID, your SLURM Job ID | 399072 |
| The memory/CPU ratio allocated to the job | 4096 |
| Same as SLURM_JOB_NUM_NODES – the number of nodes allocated to the job | 2 |
| Same as SLURM_JOB_NODELIST, The nodes that have been assigned to your job | gpu[73-74] |
| The number of tasks allocated to your job | 4 |
| Same as SLURM_NPROCS, the number of tasks allocated to your job | 4 |
| The directory where sbatch was used to submit the job | /home/u00/netid |
| The hostname where sbatch was used to submit the job | |
| The number of tasks to be initiated on each node. This can be a list if there is more than one node allocated to the job. The list has the same order as SLURM_JOB_NODELIST | 3,1 |
| Valid for interactive jobs, will be set with remote sibling cluster's IP address, port and RPC version so that any sruns will know which cluster to communicate with. | elgato:foo:0000:0000:000 |
SLURM Reason Codes
Sometimes, if you check a pending job using squeue, there are some messages that show up under Reason indicating why your job may not be running. Some of these codes are non-intuitive so a human-readable translation is provided below:
Reason | Explanation |
|---|---|
| This is a per-group limitation on the number of CPUs that can be used simultaneously by all group members. Your job is not running because this limit has been reached. Check your group's limits using "job-limits <group_name>". |
| This is a per-group limitation on the amount of memory that can be used simultaneously by all group members. Your job is not running because this limit has been reached. Check your group's limits using "job-limits <group_name>". |
| Either your group is out of CPU hours or your job will exhaust your group's CPU hours. |
| This is a per-group limitation on the number of GPUs that can be used simultaneously by all group members. Your job is not running because this limit has been reached. Check your group's limits using "job-limits <group_name>". |
| Your job depends on the completion of another job. It will wait in queue until the target job completes. |
| This message indicates that your high priority or qualified hours allocation has been exhausted for the month. |
| Your job's time limit exceeds the max allowable and will never run. Generally, the limit is 10 days or 240 hours. To see an individual job's limits, run "job-limits <group_name>". |
| This very long message simply means your job is waiting in queue until there is enough space for it to run |
| Your job is waiting in queue until there is enough space for it to run. |
| This is a per-user limitation on the number of CPUs that you can use simultaneously among all of your jobs. Your job is not running because this limit has been reached. Check your user limits using "job_limits <group_name>". |
| Your job's time limit overlaps with an upcoming maintenance window. Run "uptime_remaining" to see when the system will go offline. If you remove and resubmit your job with a shorter walltime that does not overlap with maintenance, it will likely run. Otherwise, it will remain pending until after the maintenance window. |
| Your job is waiting in queue until the required resources are available. |