hostname: login.leonardo.cineca.it
early availability: March, 2023
start of pre-production: May, 2023 (Booster)
last quarter 2023 (Data Centric)
This system is the new pre-exascale Tier-0 EuroHPC supercomputer hosted by CINECA and currently built in the Bologna Technopole, Italy. It is supplied by ATOS, based on a BullSequana XH2135 supercomputer nodes, each with four NVIDIA Tensor Core GPUs and a single Intel CPU. It also uses NVIDIA Mellanox HDR 200Gb/s InfiniBand connectivity, with smart in-network computing acceleration engines that enable extremely low latency and high data throughput to provide the highest AI and HPC application performance and scalability.
Architecture: Atos BullSequana XH21355 "Da Vinci" blade - Booster - Atos BullSequana X2610 compute blade - Data-centric (will be available in the last quarter of the 2023)
Internal Network: Nvidia Mellanox HDRDragonFly+ 200 Gb/s
Storage: 106 PB (raw) Large capacity storage, 620 GB/s
High Performance Storage 5.4 PB, 1.4 TB/s Based on 31 x DDN Exascaler ES400NVX2
Login nodes: in β production 1 (16 later): login14 accessible via IP 131.175.43.130, icelake nogpu
|
---|
The following guide is already with the production configuration. In the very next few days the pre-production phase will begin, which is mandatory the access via 2FA. Please refer to the Access section below in the Leonardo User Guide.
Node Performance | ||
Theoretical | CPU (nominal/peak freq.) | 1680 Gflops |
GPU | 75000 Gflops | |
Total | 76680 GFlops | |
Memory Bandwidth (nominal/peak freq.) | 24.4 GB/s |
All the login nodes have an identical environment and can be reached with SSH (Secure Shell) protocol using the "collective" hostname:
> login.leonardo.cineca.it
The mandatory access to Leonardo is the two-factor authentication (2FA). Please refer to this link of the User Guide to activate and connect via 2FA. For information about data transfer from other computers please follow the instructions and caveats on the dedicated section Data storage or the document Data Management.
The accounting is still unavailable in this pre-production phase and will soon be implemented.
For accounting information please consult our dedicated section.
The account_no (or project) is important for batch executions. You need to indicate an account_no to be accounted for in the scheduler, using the flag "-A"
#SBATCH -A <account_no>
With the "saldo -b" command you can list all the account_no associated with your username.
> saldo -b (reports projects defined on LEONARDO )
Please note that the accounting is in terms of consumed core hours, but it strongly depends also on the requested memory and number of GPUs, please refer to the dedicated section.
On LEONARDO, as on the other HPC clusters in Cineca, a linearization policy for the usage of project budgets has been defined and implemented. The goal is to improve the response time, giving users the opportunity of using the cpu hours assigned to their project in relation to their actual size (total amount of core-hours).
The storage organization conforms to the CINECA infrastructure (see Section Data Storage and Filesystems).
In addition to the home directory $HOME, for each user is defined a scratch area $CINECA_SCRATCH, a large disk for the storage of run time data and files.
A $WORK area is defined for each active project on the system, reserved for all the collaborators of the project. In this pre-production phase the $WORK area is not yet available. Until the $WORK areas will be configured and put in place the automatic cleaning of the scratch area will NOT be active.
Total Dimension (TB) | Quota (GB) | Notes | |
---|---|---|---|
$HOME | 0.46 PiB | 70GB per user |
|
$CINECA_SCRATCH | 41.4 PiB | no quota |
|
$WORK | not yet available (10PB) |
|
It is also available a temporary storage local on compute nodes generated when the job starts and accessible via environment variable $TMPDIR. For more details please see the dedicated section of UG2.5: Data storage and FileSystems. On LEONARDO the $TMPDIR local area has 1 TB of available space.
Since all the filesystems are based on Lustre, the usual unix command "quota" is not working. Use the local command cindata to query for disk usage and quota ("cindata -h" for help) that will be available soon.
> cindata
The software modules are collected in different profiles and organized by functional categories (compilers, libraries, tools, applications,...). The profiles are of two types: “programming” type (base and advanced) for compilation, debugging and profiling activities, and “domain” type (chem-phys, lifesc,..) for the production activity. They can be loaded together.
"Base" profile is the default. It is automatically loaded after login and it contains basic modules for the programming activities (ibm, gnu, pgi, cuda compilers, math libraries, profiling and debugging tools,..).
If you want to use a module placed under other profiles, for example an application module, you will have to load preventively the corresponding profile:
>module load profile/<profile name>
>module load autoload <module name>
For listing all profiles you have loaded you can use the following command:
>module list
In order to detect all profiles, categories and modules available on LEONARDO the command “modmap” will be soon available as for the other clusters. With modmap you can see if the desired module is available and which profile you have to load to use it.
>modmap -m <module_name>
In case you don't find a software you are interested in, you can install it by yourself.
In this case, on Leonardo we also offer the possibility to use the “spack” environment by loading the corresponding module. Please refer to the dedicated section in UG2.6: Production Environment
Please note that we are still optimizing Leonardo software stack, and more installations may be added/replaced. Always check with "module av" (the hash in the module name can change).
It will be described soon.
Since LEONARDO is a general purpose syste and is used by several users at the same time, long production jobs must be submitted using a queuing system (scheduler). The scheduler guarantees that the access to the resources is as fair as possible
The production environment on LEONARDO is based on the slurm scheduler, already in place on the cluster but still not complete and in a pre-production configuration.
Leonardo is based on a policy of node sharing among different jobs, i.e. a job can ask for resources and these can also be a part of a node, for example few cores and 1GPU. This means that, at a given time, one physical node can be allocated to multiple jobs of different users. Nevertheless, exclusivity at the level of the single core is guaranteed by low-level mechanisms.
Roughly speaking, there are two different modes to use an HPC system: Interactive and Batch. For a general discussion see the section Production Environment.
A serial program can be executed in the standard UNIX way:
> ./program
This is allowed only for very short runs on the login nodes. Soon we will impose 10 minutes cpu-time limit for the interactive processes. Please do not execute parallel applications on the login nodes!
As usual on HPC systems, the large production runs are executed in batch mode. This means that the user writes a list of commands into a file (for example script.x) and then submits it to a scheduler (SLURM for Leonardo) that will search for the required resources in the system. As soon as the resources are available script.x is executed and the results and sent back to the user.
This is an example of script file:
#!/bin/bash
#SBATCH -A <account_name>
#SBATCH -p boost_usr_prod
#SBATCH --time 00:10:00 # format: HH:MM:SS
#SBATCH -N 1 # 1 node
#SBATCH --ntasks-per-node=8 # 8 tasks out of 32
#SBATCH --gres=gpu:1 # 1 gpus per node out of 4
#SBATCH --mem=123000 # memory per node out of 494000MB
#SBATCH --job-name=my_batch_job
#SBATCH --mail-type=ALL
#SBATCH --mail-user=<user_email>
srun ./myexecutable
You can write your script file (for example script.x) using any editor, then you submit it using the command:
> sbatch script.x
The script file must contain both directives to SLURM and commands to be executed, as better described in the section Batch Scheduler SLURM.
Using SLURM directives you indicate the account_number (-A: which project pays for this work), where to run the job (-p: partition), what is the maximum duration of the run (--time: time limit). Moreover you indicate the resources needed, in terms of cores, GPUs (later) and memory.
One of the commands will be probably the launch of a parallel MPI application. In this case the right command is srun, as an alternative to the usual mpirun command. In this way you will get full support for process tracking, accounting, task affinity, suspend/resume and other features
A list of partitions defined on the cluster, with access rights and resources definition, can be displayed with the command sinfo:
> sinfo -o "%10D %20F %P"
The command returns a more readable output which shows, for each partition, the total number of nodes and the number of nodes by state in the format "Allocated/Idle/Other/Total".
In the following table you can find the main features and limits imposed on the partitions of Leonardo.
SLURM partition | Job QOS | # cores/# GPU per job | max walltime | max running jobs per user/ max n. of cores/nodes/GPUs per user | priority | notes |
lrd_all_serial not yet available | normal | max = 1 core, 1GPU | 04:00:00 | 4 cpus/1 GPU | 40 | |
qos_install | max = 16 cores | 04:00:00 | max = 16 cores 1 job per user | 40 | request to superc@cineca.it | |
boost_usr_prod | normal | max = 32 nodes | 24:00:00 | 40 | ||
boost_qos_dbg | max = 2 nodes | 00:30:00 | 2 nodes / 64 cores / 8 GPUs | 80 | ||
boost_qos_bprod | min = 33 nodes max =256 nodes * | 24:00:00* | 256 nodes * | 60 | runs on 512 nodes min is 33 FULL nodes | |
boost_qos_lprod | max = 3 nodes | 4-00:00:00 | 3 nodes /12 GPUs | 40 |
It will be available soon.
It will be available soon.
It will be available soon.