...
Architecture: Atos BullSequana XH21355 "Da Vinci" blade - Booster (in β preproduction) - 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 Perormance Storage 5.4 PB, 1.4 TB/s Based on 31 x DDN Exascaler ES400NVX2
...
|
| |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Peak performance details
...
Theoretical
Peak
Performance
...
Access
All the login nodes have an identical environment and can be reached with SSH (Secure Shell) protocol using the "collective" hostname:
> login.lrd.cineca.itFor information about data transfer from other computers please follow the instructions and caveats on the dedicated section Data storage or the document Data Management.
Accounting
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.
Budget Linearization policy
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).
Disks and Filesystems
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. This is a safe storage area to keep run time data for the whole life of the project.
...
Total Dimension (TB)
...
Quota (GB)
...
Notes
...
- permanent/backed up, user specific, local
...
- /leonardo_scratch/fast (confinata sugli OST flash))
- large (confinata sugli OST HDD)
- temporary, user specific, local
- no backup
- automatic cleaning procedure of data older than 40 days (time interval can be reduced in case of critical usage ratio of the area. In this case, users will be notified via HPC-News)
...
- permanent, project specific, local
- no backup
- extensions can be considered if needed (mailto: superc@cineca.it)
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 Marconi100 the $TMPDIR local area has 1 TB of available space.
$DRES environment variable points to the shared repository where Data RESources are maintained. This is a data archive area available only on-request, shared with all CINECA HPC systems and among different projects. $DRES is not mounted on the compute nodes of the production partitions and can be accessed only from login nodes and from the nodes of the serial partition. This means that you cannot access it within a standard batch job: all data needed during the batch execution has to be moved to $WORK or $CINECA_SCRATCH before the run starts, either from the login nodes or via a job submitted to the serial partition.
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) ???
> cindataModules environment
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 listIn order to detect all profiles, categories and modules available on LEONARDO the command “modmap” is available. 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>Spack environment
In case you don't find a software you are interested in, you can install it by yourself.
In this case, on Marconi100 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
GPU and intra/inter connection environment
Production environment
Since Leonardo is a general purpose system and it is used by several users at the same time, long production jobs must be submitted using a queuing system (scheduler). This guarantees that the access to the resources is as fair as possible. On Leonardo the available scheduler is SLURM.
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 1 GPUs. 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 and GPU 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.
Interactive
A serial program can be executed in the standard UNIX way:
> ./programThis is allowed only for very short runs on the login nodes, since the interactive environment has a 10 minutes cpu-time limit. Please do not execute parallel applications on the login nodes!
Batch
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 xxx_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 128
#SBATCH --gres=gpu:1 # 1 gpus per node out of 4
#SBATCH --mem=7100 # memory per node out of 246000MB
#SBATCH --job-name=my_batch_job
#SBATCH --mail-type=ALL
#SBATCH --mail-user=<user_email>
mpirun ./myexecutable #in case you compiled with spectrum-mpi
OR
srun ./myexecutable #in all the other cases
Please note that by requesting --ntasks-per-node=8 your job will be assigned 8 logical cpus (hence, the first 2 cpus with their 4 HTs). You can write your script file (for example script.x) using any editor, then you submit it using the command:
> sbatch script.xThe 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 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.
SLURM partitions
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 M100.
Note: core refers to a physical cpu, with its 4 HTs; cpu refers to a logical cpu (1 HT). Each node has 32 cores/128 cpus.
...
SLURM
partition
...
max running jobs per user/
max n. of cores/nodes/GPUs per user
...
lrd_all_serial
(default)
...
min = 33 nodes
max =256 nodes
...
max = 2 nodes
...
1 node per type
...
> 32 nodes
...
> 24:00:00
...
request to superc@cineca.it
...
max = 16 nodes
...
24:00:00
...
active projects with exhausted budget
request to superc@cineca.it
Submitting serial batch jobs
Submitting batch jobs for production
Examples
Graphic session
It will be available soon.
Programming environment
Compilers
...