Page History

Interactive

A serial program can be executed in the standard UNIX way:

> ./program

This is allowed only for very short runs, since the interactive environment has a 10 minutes time limit: for longer runs please use the "batch" mode.

A parallel program can be executed interactively only within an "Interactive" SLURM batch job, using the "srun" command: the job is queued and scheduled as any other job, but when executed, the standard input, output, and error streams are connected to the terminal session from which srun was launched.

For example, to start an interactive session with the MPI program myprogram, using one node, two processors, launch the command:

> srun -N1 -n2 --ntasks-per-node=2 -A <account_name> --pty /bin/bash

SLURM will then schedule your job to start, and your shell will be unresponsive until free resources are allocated for you.

When the shell come back with the prompt, you can execute your program by typing:

> mpirun ./myprogram

or

> srun --mpi=pmi2 ./myprogram

Pay attention in putting the flag --mpi=pmi2 immediatly after srun.

SLURM automatically exports the environment variables you defined in the source shell, so that if you need to run your program myprogram in a controlled environment (i.e. specific library paths or options), you can prepare the environment in the origin shell being sure to find it in the interactive shell.

Batch

As usual on systems using SLURM, you can submit a script script.x using the command:

> sbatch script.x

You can get a list of defined partitions with the command:

> sinfo -d

For more information and examples of job scripts, see section Batch Scheduler SLURM.

Submitting serial Batch jobs

The gll_all_serial partition is available with one core and a maximum walltime of 4 hours. It runs on the login nodes and it is designed for pre/post-processing serial analysis, and for moving your data (via rsync, scp etc.) in case more than 10 minutes are required to complete the data transfer. In order to use this partition you have to specify the SLURM flag "-P":

#SBATCH -p gll_all_serial

The gll_all_serial partition has a limit of 4 tasks per job and 4GB of memory per job. If you wish to ask for more than a core on a single job, remember to add on your jobscript the specific about the memory limit, since the default per core is 3.5GB and therefore your job won't enter because the required memory exceeds the partition limit.

Graphic session

If a graphic session is desired we recommend to use the RCM tool or the EnginFrame environment. Both of them are under construction, we will report here all required information asap.

Submitting parallel Batch jobs

To run parallel batsch jobs on GALILEO you need to specify the partition gll_usr_prod, or any other partition we invited you to use.

If you do not specify the partition, your jobs will try to run on the bdw_all_serial partition, eventually failing if specific partition limits (maximum one core for maximum walltime of 4 hours) are violated.

The minimum number of cores to require is 1. The maximum number of cores that you can request is the 2304 (about 167 nodes) with a maximum walltime of 24 hours:

• If you do not specify the walltime (by means of the #SBATCH --time directive), a default value of 30 minutes will be assumed.
• If you do not specify the number of cores (by means of the "SBATCH -n" directive) a default value of 36 will be assumed.
• If you do not specify the amount of memory (as the value of the "SBATCH --mem" DIRECTIVE), a default value of 3000MB will be assumed.
• The maximum memory per node is 118000MB.

The special QOS (bdw_qos_special) is designed for not-ordinary types of jobs, and users need to be enabled in order to use it. Please write to superc@cineca.it in case you think you need to use it.

Summary

In the following table you can find all the main features and limits imposed on the queues of the shared A1 and A2 partitions. For Marconi-FUSION dedicated queues please refer to the dedicated document.

PLEASE NOTE: the SLURM characteristics have not completely defined for GALILEO, some changes will be possible.

Users with reserved resources

Users of projects that require reserved resources will be associated to a QOS.

Using the specific QOS (i.e. specifying the QOS in the submission script) , an specifying the partition gll_spc_prod partition, users associated to the allowed project will run their jobs on reserved nodes in the gll_spc_prod partitioN

>#SBATCH --partition="gll_spc_prod"

>#SBATCH --qos=<specific_qos>