CRAY XC30 Using the Batch System SLURM

The only way to start a parallel job on the compute nodes of this system is to use the batch system. The installed batch system is based on

• the resource management system SLURM (Simple Linux Utility for Resource Management)

SLURM is designed to operate as a job scheduler over Cray's Application Level Placement Scheduler (ALPS). Use SLURM's sbatch or salloc commands to create a resource allocation in ALPS. Then use ALPS' aprun command to launch parallel jobs within the resource allocation. Additional you have to know on CRAY XC30 the user applications are always launched on the compute nodes using the application launcher, aprun, which submits applications to the Application Level Placement Scheduler (ALPS) for placement and execution!

Detailed information about how to use this system and many examples can be found in Cray Programming Environment User's Guide and Workload Management and Application Placement for the Cray Linux Environment.

Writing a submission script is typically the most convenient way to submit your job to the batch system. You generally interact with the batch system in two ways: through options specified in job submission scripts (these are detailed below in the examples) and by using slurm commands on the login nodes. There are some main commands used to interact with slurm:

• sbatch is used to submit a job script for later execution.
• scancel is used to cancel a pending or running job or job step. It can also be used to send an arbitrary signal to all processes associated with a running job or job step.
• sinfo reports the state of partitions and nodes managed by SLURM. It has a wide variety of filtering, sorting, and formatting options.
• squeue reports the state of jobs or job steps. It has a wide variety of filtering, sorting, and formatting options. By default, it reports the running jobs in priority order and then the pending jobs in priority order.
• srun is used to submit a job for execution or initiate job steps in real time.
• salloc is used to allocate resources for a job in real time.
• sacct is used to report job or job step accounting information about active or completed jobs.

Check the man page of slurm for more advanced commands and options

 man slurm

or read the SLURM Documentation

Resource Allocation with SLURM

Defining the required resources for a batch job

• The number of required nodes and cores can be determined by the parameters in the job script header with "#SBATCH" before any executable commands in the script.

 #SBATCH --job-name=MYJOB
 #SBATCH --nodes=1
 #SBATCH --time=00:10:00

• The job is submitted by the sbatch command (all script head parameters #SBATCH can also be submitted directly by sbatch command options).
• The batch script is not necessarily granted resources immediately, it may sit in the queue of pending jobs for some time before its required resources become available.
• At the end of the execution output and error files are returned to submission directory

Other SLURM options

• File names of stdout and stderr

 #SBATCH --output=std.out
 #SBATCH --error=std.err

• Start N PEs (tasks)

 #SBATCH --ntasks=N

• Start M tasks per node. Total Nodes used are N/M (+1 if mod(N,M)!=0). Max of M=32

 #SBATCH --ntasks-per-node=M

• Number of threads per tasks. Most used together with OMP_NUM_THREADS

 #SBATCH --cpus-per-task=8

SLURM and aprun

The following SLURM options are translated to these aprun options. SLURM options not listed below have no equivalent aprun translation and while the option can be used for the allocation within Slurm it will not be propagated to aprun.

SLURM options	aprun optioins
--ntasks=$PE --cpu-per-task=$threads --ntasks-per-node=$N --ntasks-per-socket=$S	-n $PE -d $threads -N $N -S $S	Number of PE to start #threads/PE #(PEs per node) #(PEs per numa_node)

• The following aprun options have no equivalent in srun and must be specified by using the SLURM --launcher-opts

options: -a, -b, -B, -cc, -f, -r, and -sl.

• -B will provide aprun with the SLURM settings for -n, -N , -d and -m

 aprun -B ./a.out

Core specialization

System 'noise' on compute nodes may significantly degrade scalability for some applications The Core Specialization can mitigate this problem.

• 1 core per node will be deddicated for system work (service core)
• As many system interrupts as possible will be forced to execute on the service core
• The application will not run on the service core

To get core specialization use aprun -r

 aprun -r1 -n 100 a.out

highest numbered cores will be used, starting with 31 on current nodes. (independent on aprun -j setting)

apcount provided to compute total number of cores required

 man apcount