...
|
| ||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Peak performance details
| Node Performance | ||
Theoretical | CPU (nominal/peak freq.) | 1680 Gflops |
| GPU | 75000 Gflops | |
| Total | 76680 GFlops | |
| Memory Bandwidth (nominal/peak freq.) | 24.4 GB/s | |
...
Please note that the accounting is in terms of consumed core hours, but it strongly depends also on the requested memory and local storage, and number of GPUs, please refer to the dedicated section.
...
In addition to the home directory $HOME, for each user is defined a scratch area $SCRATCH (or $CINECA_SCRATCH), a large disk for the storage of run time data and files.
An new user specific area $PUBLIC is defined on LEONARDO, useful for example to share installations with other users (it is indeed the default directory for SPACK sub-directories, see more details in the dedicated page).
A $WORK area is defined for each active project on the system, reserved to all the collaborators of the project. A corresponding $FAST area is defined for each active project on the scratch filesystem, on its subset of "fast" NVMe SSD flash drives. As for $WORK, the $FAST area is reserved to all the collaborators of the project. An extension of the default $WORK quota (1 TB) can be granted if justified and essential for the course of the project's activity, while the use of the $FAST is limited to 1 TB of space per project.
Total Dimension (TB) | Quota (GB) | Notes | |
|---|---|---|---|
| $HOME | 0.46 PiB | 50GB per user |
|
| $CINECA_SCRATCH | 41.4 40 PiB | no quota |
|
| $PUBLIC | 0.46 PiB | 50GB per user |
|
| $WORK | 10 30 PB | 1TB per project |
|
| $FAST | 3.5PB | 1TB per project |
|
- The automatic cleaning of the scratch area is NOT active yet, but it will soon be enforced.
...
It is also available a temporary storage area local to nodes on login and compute nodes (on the latter it is generated when the job starts and removed when it ends) and accessible via environment variable $TMPDIR. For more details This area is:
- on the local SSD disks on login nodes (14 TB of capacity), mounted as /scratch_local (TMPDIR=/scratch_local). This is a shared area with no quota, remove all the files once they are not requested anymore. A cleaning procedure will be enforced in case of improper use of the area.
- on the local SSD disks on the serial node (lrd_all_serial, 14TB of capacity), managed via the slurm job_container/tmpfs plugin. This plugin provides a job-specific, private temporary file system space, with private instances of /tmp and /dev/shm in the job's user space (TMPDIR=/tmp, visible via the command "df -h"), removed at the end of the serial job. You can request the resource via sbatch directive or srun option "--gres=tmpfs:XX" (for instance: --gres=tmpfs:200G), with a maximum of 1 TB for the serial jobs. If not explicitly requested, the /tmp has the default dimension of 10 GB.
- on the local SSD disks on DCGP nodes (3 TB of capacity). Like with the serial node, the local /tmp and /dev/shm areas are managed via plugin, which at the start of the jobs mounts private instances of /tmp and /dev/shm in the job's user space (TMPDIR=/tmp, visible via the command "df -h /tmp"), and unmounts them at the end of the job (all data will be lost). You can request the resource via sbatch directive or srun option "--gres=tmpfs:XX", with a maximum of all the available 3 TB for DCGP nodes. Like with the serial node, if not explicitly requested, the /tmp has the default dimension of 10 GB. Please note: for the DCGP jobs the requested amount of gres/tmpfs resource contributes to the consumed budget, changing the number of accounted equivalent core hours, see the dedicated section on the Accounting
- on RAM on the diskless booster nodes (with a fixed size of 10 GB, no increase is allowed, and the gres/tmpfs resource is disabled).
For a general discussion on the TMPDIR area, please see the dedicated section of Data storage and FileSystems.
...