Guide d'utilisation du cluster Austral¶

Architecture¶

Une description matérielle du cluster Austral est disponible.

Se connecter¶

• Serveurs de connexion SSH (frontales) : ssh -l votre_login austral.criann.fr
• Serveur de connexion spécialisé au transfert de données avec l'extérieur : ssh -l votre_login austral-transfert.criann.fr
• Serveurs de connexion VNC : les informations sont fournis lors de la réservation d'une session de visualisation

Firewall¶

Si votre structure a un firewall limitant les flux en sortie de votre site, voici les ports à ouvrir :

• Connexions SSH (port TCP/22) vers les frontales
  • IPv4 : 195.221.22.130 (austral.criann.fr; austral-front1.criann.fr)
  • IPv4 : 195.221.22.131 (austral.criann.fr; austral-front2.criann.fr)
  • IPv4 : 195.221.22.132 (austral.criann.fr; austral-front3.criann.fr)
  • IPv4 : 195.221.22.133 (austral.criann.fr; austral-front4.criann.fr)
  • IPv4 : 195.221.22.134 (austral-transfert.criann.fr)

Gestion de vos données¶

Une documentation sur la gestion des données est disponible.

Suivi des consommations¶

Une commande est mise à disposition sur les frontales pour avoir accès à un relevé de la consommation en h.cpu : maconso

Spécificités¶

Compiler¶

Lire entièrement le paragraphe Compilation

Pour les raisons développées dans ce dernier : dans vos fichiers makefile, vous devez remplacer

• icc, gcc, mpicc ou mpiicc par cc
• icpc, g++, mpicxx ou mpiicpc par CC
• ifort, g77, gfortran, mpif90 ou mpiifort par ftn

Les codes MPI ciblant le serveur à large mémoire (SMP) font exception à cela (voir plus bas).

Nomenclature des modules d’applications ou de bibliothèques¶

Sur Austral, la nomenclature des modules mentionne leur catégorie scientifique ou technique.

Par exemple, les modules pour NAMD ne se nomment plus namd/version comme sur Myria, mais atomic_simu/namd/version, les modules pour OpenFOAM ne se nomment pas openfoam/version mais cfd_fem/openfoam/version. Les modules pour PyTorch se nomment aidl/pytorch/version.

Lire le paragraphe Logiciels disponibles

Intelligence Artificielle / apprentissage profond¶

Lire la page dédiée au domaine IA - Deep Learning pour Austral

GPUs SMT¶

Le SMT (Simultaneous MultiThreading) est activé sur les serveurs à GPU, faisant passer le nombre de cpus disponibles de 64 à 128 dans les serveurs à GPU NVIDIA (partitions Slurm hpda, gpu, gpu_all), et de 32 à 64 dans les serveurs à GPU AMD (partition Slurm amdgpu).

Pour la soumission de travaux d'intelligence artificielle (PyTorch, TensorFlow), il est recommandé de demander 16 cpus par GPU. Le SMT peut améliorer les performances des codes d'IA, en particulier lors du chargement multithreadé des données.

Un exemple complet basé sur le tutoriel mnist pour PyTorch est disponible sur Austal : /soft/slurm/Modeles_scripts/pytorch-smt/

Pour l'application de dynamique moléculaire Gromacs en partition gpu, la directive de Slurm --cpus-per-task peut aussi être élevée de 8 à 16 afin d'examiner l'effet sur la performance. Si --cpus-per-task 8 est préférable, il est conseillé d'ajouter la directive #SBATCH --hint nomultithread.

Pour des codes de de simulation dont le paradigme de programmation multi-GPU exploite MPI avec 1 seule tâche MPI par GPU, il est conseillé d'ajouter #SBATCH --hint nomultithread.

GPUs MIG¶

La technologie MIG (Multi-instance GPU) de NVIDIA permet de partitionner un processeur graphique A100 jusqu'à sept instances distinctes, chacune étant entièrement isolée avec sa propre mémoire à bande passante élevée, son cache spécial ainsi que des Stream Multiprocessor (SM) et tensor core (TC) dédiés.

Sur Austral, les 8 A100 d'un serveur complet ont été partitionnées afin de proposer un total de 31 devices GPUs de puissances variées :

• 10 devices a100_1g.10gb avec 10 GB de Mémoire, 14 SM et 56 TC
• 17 devices a100_2g.20gb avec 20 GB de Mémoire, 28 SM et 108 TC
• 4 devices a100_3g.40gb avec 40 GB de Mémoire, 42 SM et 164 TC

Bien que leur puissance soit moindre que celle d'un A100 complet, ces devices offrent de bonnes performances pour l'entraînement de réseaux de neurones avec l'utilisation des tensor cores.

Pour utiliser l'un de ces devices dans vos calculs il faut :

• cibler la partition hpda_mig avec l'option --partition hpda_mig de sbatch
• préciser le type de device souhaité avec l'option --gres de sbatch :
  • --gres=gpu:a100_1g.10gb pour l'architecture a100_1g.10gb
  • --gres=gpu:a100_2g.20gb pour l'architecture a100_2g.20gb
  • --gres=gpu:a100_3g.40gb pour l'architecture a100_3g.40gb

Un exemple complet basé sur le tutoriel mnist pour pytorch est disponible sur Austal : /soft/slurm/Modeles_scripts/pytorch-mig/

Scripts d'exécution par Slurm : /soft/slurm/Modeles_scripts

Compilation¶

Environnement¶

Le CPE (Cray Programming Environment) comprend les modules de compilateurs (Gnu, Cray, Intel) et de bibliothèques MPI Cray MPICH pour le réseau Slingshot.

Dans vos fichiers makefile, vous devez remplacer (hormis pour les codes MPI ciblant le serveur à large mémoire (SMP))

• icc, gcc, mpicc ou mpiicc par cc
• icpc, g++, mpicxx ou mpiicpc par CC
• ifort, g77, gfortran, mpif90 ou mpiifort par ftn

Le compilateur de Gnu est suggéré par défaut.

Le module cpe_env/gcc-milan-08.23 est pré-chargé.

Il regroupe le compilateur de Gnu (11.2.0) avec optimisations intégrées pour l’architecture des CPU AMD Milan, et la librairie MPI Cray MPICH (8.1.20).

Concrètement :

• La commande cc correspond à gcc + Cray MPICH
• La commande CC correspond à g++ + Cray MPICH
• La commande ftn correspond à gfortran + Cray MPICH

Regroupements alternatifs d'environnements

Après module load cpe_env/craycc-genoa-08.23

• cc correspond au compilateur C de Cray + Cray MPICH
• CC correspond au compilateur C++ de Cray + Cray MPICH
• ftn correspond au compilateur FORTRAN de Cray + Cray MPICH

avec optimisations intégrées pour l’architecture AMD Genoa.

Après module load cpe_env/icc-milan-08.23

• cc correspond au compilateur C d'Intel + Cray MPICH
• CC correspond au compilateur C++ d'Intel + Cray MPICH
• ftn correspond au compilateur FORTRAN d'Intel + Cray MPICH

avec application de jeu d'instructions AVX2, compatibles avec les processeurs AMD Milan et Genoa.

Environnements les plus récents

Suite à la mise à jour de février 2024 et des suivantes, les modules initiaux de compilation cpe_env/*.08.23 ont été conservés et restent supportés par la nouvelle configuration d’Austral (le module pré - chargé à la connexion est resté le même que précédemment : cpe_env/gcc-milan-08.23).

Les modules de février 2024 cpe_env/*.02.24 et d'août 2024 cpe_env/*.08.24 (voir module avail cpe_env) fournissent des versions plus récentes de compilateur ou de bibliothèque MPI ou de bibliothèque scientifique (cray-libsci). Les développeurs qui souhaiteraient re-compiler leurs applications avec ces environnements, doivent nous contacter s’ils emploient des bibliothèques externes partagées (autres que cray-hdf5, cray-fftw, cray-libsci) car nous devrons compiler ces bibliothèques avec ces nouveaux compilateurs.

Commandes utiles

• cc --version, CC --version et ftn --version rappellent le compilateur (Gnu, Cray ou Intel) et sa version auxquels ces wrappers correspondent.
• man gcc, man g++, man gfortran, man craycc, man crayCC, man crayftn, man icx, man ifort pour la documentation d'options de compilation.

Remarque

• Les serveurs fins (purement CPU) d’Austral ont un CPU de génération Genoa, la plus récente d’AMD lors de l'ouverture d’Austral (septembre 2023). Les compilateurs de Gnu version 10 à 12 intègrent l'option pour l'architecture précédente Milan (-march=znver3, automatiquement appliquée sous l'environnement du module cpe_env/gcc-milan-08.23). Cette architecture Milan est d'ailleurs celle des CPU des serveurs HPDA et GPGPU d'Austral. Compte tenu d’une compatibilité ascendante, un code compilé pour l’architecture Milan fonctionne sur l’architecture Genoa.
• Le compilateur de Gnu en version 13 supporte l'option d'optimisation -march=znver4 pour Genoa, automatiquement appliquée sous l'environnement du module cpe_env/gcc13.2.1-mpich8.1.30-genoa-02.25.
• Le compilateur de Cray supporte l'option d'optimisation -march=znver4 pour Genoa, automatiquement appliquée sous l'environnement du module cpe_env/craycc-genoa-08.23.

Bibliothèques scientifiques directement intégrées au CPE (Cray Programming Environment)¶

• HDF5 s'active par la commande module load cray-hdf5 ou module load cray-hdf5-parallel
• FFTW (séquentielle, threadée ou MPI) s'actvie par la commande module load cray-fftw
• BLAS, LAPACK et SCALAPACK sont activées par le module cray-libsci qui est pré - chargé à la connexion sur Austral

À condition que cc / CC / ftn soient utilisés, le chargement de ces modules cray-* permet la prise en compte de ces librairies lors de vos compilations, sans aucun ajout dans vos fichiers makefile.

Remarques :

• Les modules cray-hdf5 fournissent des versions de HDF5 qui n’ont pas toutes les fonctions optionnelles de cette bibliothèque. En particulier, pour la compression de format szip utiliser l’un des modules data/hdf5 comprenant -szip_ dans leur nom (dans ce cas, vos fichiers makefile devront être complétés par vos soins : appliquer la commande module show au module ciblé pour obtenir le nom des variables utilisables).

• Si une fonction d'algèbre linéaire n'est pas fournie par cray-libsci, essayer les versions Gnu du standard MKL par le module math/mkl/2023.0.0/lp64/blas-lapack_gcc (charger ce module, puis inclure dans vos fichiers makefile les variables dont la commande module show math/mkl/2023.0.0/lp64/blas-lapack_gcc fournit le nom).

Codes GPU¶

Une page consacrée à la compilation des codes GPU est disponible.

Codes ciblant le serveur à large mémoire (SMP)¶

• Un code séquentiel ou multi-threads devant être exécuté sur le serveur SMP peut être compilé sous l'un des environnements de modules cpe_env mentionnés ci-dessus, avec les commandes de compilation cc / CC / ftn

• La bibliothèque MPI supportée et optimisée pour le serveur SMP n'est pas Cray MPICH, mais HPE MPI. Un code MPI ciblant ce serveur SMP doit alors être compilé après exécution des commandes suivantes

  module purge
  module load hpe_env/mpt/2.29-gcc11
  module list
  

• utiliser des commandes de compilation mpicc / mpicxx / mpif90 (correspondant à gcc / g++ / gfortran + HPE MPI)

• ajouter explicitement dans les fichiers makfile l'option d'optimisation -march=cooperlake pour l'architecture Intel Cooper Lake de ce serveur SMP
• si des bibliothèques extérieures faisant appel à MPI (comme par exemple la version MPI de HDF5 ou de FFTW) sont requises pour votre application, contacter support@criann.fr pour demander leur installation car elles devront être compilées avec HPE MPI

Environnement de soumission (Slurm)¶

La soumission des travaux se fait par la suite logicielle Slurm.

Le répertoire /soft/slurm/Modeles_scripts contient des modèles de scripts de soumission.

• Pour les travaux ciblant le serveur à large mémoire (SMP), se référer aux modèles job_SMP_serial.sl, job_SMP_Mutli-threads.sl ou job_SMP_MPI.sl (qui conseillent la directive --hint nomultithread)

Commandes¶

Ce tableau fournit les commandes utiles pour la soumission des travaux.

Les partitions (classes de soumission)¶

Partitions pour architectures spécifiques

Le nombre de GPU max utilisés par un utilisateur sur les partitions gpu + gpu_all + hpda est de 16 GPU et 128 cœurs en semaine et 32GPU et 256 cœurs pendant le week-end (du vendredi 17h au dimande 20h).

Partitions pour calculs parallèles

Un nœud comprend 192 cœurs AMD Genoa et 714 GB de mémoire (DDR5) disponible pour les applications (#SBATCH--mem 714gb ou #SBATCH --mem 732000 au maximum pour la demande de mémoire par nœud).

Le nombre de cœurs max utilisés par un utilisateur sur les partitions parallèles est de 4224 cœurs ou 22 nœuds en semaine et 8448 cœurs ou 44 nœuds pendant le week-end (du vendredi 17h au dimande 20h).

Usage exclusif d'un serveur¶

• L'option --exclusive réserve l'intégralité d'un nœud pour le job. Cela permet de s'assurer qu'aucun autre job ne tournera sur le nœud utilisé durant le calcul.
• L'option --exclusive=user permet le partage des serveurs entre différents jobs d'un même utilisateur.

Afin d'exécuter plusieurs jobs sur un seul et même serveur vous pouvez appliquer la méthode suivante :

1. soumettre un premier job avec l'option --exclusive=user :
   • sbatch --exclusive=user script01.sl
2. lorsque ce 1er job est en cours d'exécution (running) identifier le nom du serveur sur lequel le job s'exécute
3. soumettre les jobs suivants avec l'option --exclusive=user en ciblant le nœud sur lequel le 1er job est en cours d'exécution à l'aide de l'option -w :
   • sbatch --exclusive=user -w <nodename> script02.sl

Un exemple de script bash automatisant cette méthode est disponible sur Austral à l'emplacement suivant : /soft/slurm/Modeles_scripts/exclusive_user

Bilan en fin de calcul¶

Slurm génère un fichier .o (standart output) et .e (standart error). Nous vous suggérons fortement de consulter le fichier .e.
Les chemins et noms de ces deux fichiers sont paramétrables dans le script de soumission (voir fichiers d'exemples).

Nous complétons le fichier .o par un rapport de consommation du calcul extraite avec la commande sacct. Vous y retrouvez en autre la consommation horaire, les ressources mémoire demandées et utilisées, les noeuds réservées.

Plus de détails sur la page Rapport de consommation.

Logiciels disponibles¶

Les commandes suivantes sont utiles pour rechercher les applications disponibles.

• Modules scientifiques
  • module avail aidl
  • module avail atom
  • module avail bio
  • module avail cfd_fem
  • module avail math
  • module avail climate
  • module avail data
  • module avail mesh
  • module avail couplers
• Environnements
  • module avail py_env
  • module avail cpe_env
  • module avail tools/

Le nom d’un module peut aussi être recherché à partir du nom de l’application (exemples : module avail python, module avail anaconda, module avail gromacs).

Pour une application mise en production par le Criann, le script de soumission par Slurm qui est fourni (dans /soft/slurm/Modeles_scripts si elle est partagée) applique la commande de chargement de son module.

Suivi de la consommation horaire¶

À partir des frontales, la commande maconso affiche votre consommation ainsi que celle du projet. Si vous êtes responsable de projet ou responsable adjoint maconso -u indique le détail pour tous les comptes.

Ces informations sont également accessibles au format JSON dans le fichier ~/.acct.json.

Les consommations sont actualisées toutes les nuits.

Calcul de la comptabilité horaire¶

Le calcul des heures sur Austral se base sur les ressources réservées par les calculs dans Slurm :

• 1 calcul 56 cœurs de 3h : 56 x 3 = 168h
• 1 calcul intra-noeud 56 cœurs de 3h en mode --exclusif sur un serveur "fin" (192 cœurs) : 192 x 3 = 576h

Plus d'information sur la page Rapport de consommation.