You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Serial and small parallel jobs, called fractional, run on the gpil partition and use the same QoS, typically nf for regular users.

These are the default queue and partition. They will be used if no directives are specified.

See man sbatch or https://slurm.schedmd.com/sbatch.html for the complete set of options that may be used to configure a job.

ECS users

All examples here are using the nf queue, which is available to users of the HPCF service. If using ECS, you should submit the job to the ef queue instead

Submitting a serial job

A serial job will not use more than one cpu, so it is intended for non-threaded non-MPI applications. This is the default type of job if no settings are specified in the job.

Minimal serial job example 
#!/bin/bash
hostname

Submitting the script above with sbatch would just configure the job with the default settings, including the output and error files being named slurm-<jobid>.out and slurm-<jobid>.err on the current directory. A more complete serial job with some changes on the configuration would be the following:

Serial job example 
#!/bin/bash
#SBATCH --job-name=test-serial
#SBATCH --qos=nf
#SBATCH --time=10:00
#SBATCH --mem=100
#SBATCH --output=test-serial.%j.out
#SBATCH --error=test-serial.%j.out
#SBATCH --chdir=/scratch...

hostname

This would name the job "test", set a wall clock time limit of 10 minutes and a memory limit of 100 MiB. The working directory would be set to /scratch... (to be changed by the actual value of the directory), and the output would be sent to /scratch/.../test-serial.%N.%j.out, with %N being the name of the node running the job and %j the job ID.

Submitting a fractional job

Fractional jobs are small parallel jobs that will share the same GPIL node with other jobs. This is intended for small threaded applications or small MPI executions. 

Threaded application

If you want to run a threaded application, you should allow for as many cpus as threads you want to spawn with the cpus-per-task option

Threaded job example 
#!/bin/bash
#SBATCH --job-name=test-threaded
#SBATCH --qos=nf
#SBATCH --time=10:00
#SBATCH --cpus-per-task=4
#SBATCH --mem=100
#SBATCH --output=test-threaded.%j.out
#SBATCH --error=test-threaded.%j.out
#SBATCH --chdir=/scratch...
my_threaded_app

Small MPI or multiprocess application

For small (up to few tens of tasks) MPI or multiprocess runs, you may run using the fractional QoS as well.

To spawn an MPI application you must use srun


MPI job example 
#!/bin/bash
#SBATCH --job-name=test-mpi
#SBATCH --qos=nf
#SBATCH --ntasks=16
#SBATCH --time=10:00
#SBATCH --mem=100
#SBATCH --output=test-mpi.%j.out
#SBATCH --error=test-mpi.%j.out
#SBATCH --chdir=/scratch...

srun my_mpi_app

The example above would run a 16 task MPI application

Small hybrid  application

For small (up to few tens of CPUS) hybrid (MPI + multithreaded) runs, you may run using the fractional QoS as well.

To spawn an MPI application you must use srun

The following example woud run a small hybrid MPI + OpenMP application, spawning 4 MPI tasks with 4 threads each one of them.

MPI job example 
#!/bin/bash
#SBATCH --job-name=test-hybrid
#SBATCH --qos=nf
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=4
#SBATCH --time=10:00
#SBATCH --mem=100
#SBATCH --output=test-hybrid.%j.out
#SBATCH --error=test-hybrid.%j.out
#SBATCH --chdir=/scratch...

srun my_mpi_opemp_app
  • No labels