Job submission via PBS

Job submission

Prior to job submition the appropriate command which starts the application has to be embedded in the script to be correctly read by the queueing system:

/home/users/username/submit_script.sh

#!/bin/bash
#PBS -l nodes=1:ppn=2
#PBS -l mem=1gb

/path/to/binary/file.in >/path/to/binary/file.out

The above script reserves 2 processors for the task on a single node (#PBS -l nodes=1:ppn=2) and 1GB of RAM memory (#PBS -l mem=1gb).

To assign the job to given queue please use #PBS -q e.g.

#!/bin/bash
#PBS -q standard
#PBS -l nodes=1:ppn=2
#PBS -l mem=1gb

/path/to/binary/file.in >/path/to/binary/file.out

Job can be submitted using qsub command.

qsub /home/users/username/submit_script.sh

Checking queue status

Queue status can be checked running qstat command. The following parameters are available:

• -r - shows running jobs
• -i - shows waiting jobs
• -u - shows user jobs
• -f - show detailed info about job(s)

Example:

qstat -u username

Jobs scheduling

The user can submit the job to a queuing system without giving any detailed description which will result in running this job on any class computation node. The use may also schedule the job to different classes of nodes using the aforementioned descriptions (properties). To this end, the submission script has to provide the nodes classes the user wants to use.

#PBS -lnodes=1:ppn=1:<description>

Examples:

• Job submission with 1 node and 2GPGPU cards

#PBS -l nodes=1:ppn=1:gpu2

• Job submission to nodes with haswell processors

#PBS -l nodes=1:ppn=1:haswell_2600mhz

• Job submission to nodes with hehalem processors

#PBS -l nodes=1:ppn=1:nehalem_2400mhz

Note: Submitting jobs to given classes of nodes can result in longer wait for the their execution. This situation can happen when a larger number of users will use the same class for their jobs despite other free resources on a cluster. As a result, the job running on the nodes with slower processors onboard can run and finish quicker than the job submitted to nodes equipped with faster processors.

Interactive tasks

Interactive job allows the user to gain shell on a computing node. Since the compilation and run any of the applications on the access to the cluster machine (ui.inula.man.poznan.pl) is not allowed, then interactive jobs are one of the ways to run the software with a graphical user interface (eg. Matlab, Maple, etc.). Here is an example of how to run the job in interactive mode.

Zadanie interaktywne pozwala użytkownikowi na uzyskanie powłoki (shell-a) na węźle obliczeniowym. Ponieważ kompilacja oraz uruchamianie wszelkich programów na maszynie dostępowej do klastra (ui.inula.man.poznan.pl) jest niedozwolone, zdania interaktywne są jednym ze sposobów, aby uruchomic oprogramowanie z graficznym interfejsem użytkownika (np. Matlab, Maple, itp.) lub skompilować swoją aplikację. Poniżej przedstawiony został przykład jak uruchomić zadanie w trybie interaktywnym.

Command line
The easiest way is to execute the following command

[username@ui ~]$ qsub -I
qsub: waiting for job 102004.creamce.inula.man.poznan.pl to start
qsub: job 102004.creamce.inula.man.poznan.pl ready

[username@c085 ~]$

It is adviced to provide additional parameters to 'qsub' command, such as number of required processors or memory.

Checking job status on a computing node

To check where (which computing node) our tasks is computed the following command needs to be executed:

qstat -n1 -u username

To log on to computing node where job is executed:

ssh <computing_node_id>

To list job folder:

ls -ali /tmp/lustre/<job_number>.creamce.inula.man.poznan.pl

Removing jobs

To remove job from the queue the qdel command with job id as a parameter needs to be executed. Both, waiting and running jobs can be removed.

qdel job_id