INTRODUCTION GÉNÉRALE À l 'IDRIS

Ce document s'adresse principalement aux nouveaux utilisateurs de l'IDRIS. Il présente les principaux points indispensables à une bonne utilisation des machines de l'IDRIS.

1. Présentation de l'IDRIS
2. Présentation des machines
3. Demandes d'allocations d'heures sur les machines de l'IDRIS
4. Comment obtenir un compte ?
5. Comment se connecter pour calculer ?
6. Gestion de son compte et de son environnement
7. Présentation des espaces disques
8. Commandes de transferts de fichiers
9. La commande module
10. Comment soumettre un calcul ?
11. Formations proposées à l'IDRIS
12. Documentation de l'IDRIS
13. Le support aux utilisateurs

Pour une documentation complète sur les différents points abordés dans ce document, n’hésitez pas à consulter le site de l'IDRIS : www.idris.fr


1. Présentation de l'IDRIS

Missions et objectifs de l'IDRIS

L’IDRIS (Institut du développement et des ressources en informatique scientifique), fondé en novembre 1993, est le centre national du CNRS pour le calcul numérique intensif de très haute performance (HPC) et l’intelligence artificielle (IA), au service des communautés scientifiques de la recherche publique ou privée (sous condition de recherche ouverte avec publication des résultats), tributaires de l'informatique extrême.

À la fois centre de ressources informatiques et pôle de compétences en HPC et IA, l'IDRIS (www.idris.fr) est une unité propre de service du CNRS, dépendant de la Mission calcul-données (MiCaDo) du CNRS et rattachée administrativement à l’Institut des sciences de l’information et de leurs interactions (INS2I), mais dont la vocation à l’intérieur du CNRS est pluridisciplinaire. Les modalités de fonctionnement de l’IDRIS sont proches de celles des très grands équipements scientifiques.

Gestion scientifique des ressources

Deux fois par an, sous la coordination du GENCI (Grand équipement national de calcul intensif), un appel à propositions commun à l'ensemble des centres nationaux (CINES, IDRIS et TGCC) est organisé pour une allocation d’heures valable un an. Chaque appel permet de déposer des demandes d’heures de calcul pour un nouveau projet, pour renouveler un projet existant ou pour compléter une allocation obtenue lors de l’appel précédent.

Les demandes de ressources se font par le formulaire DARI (Demande d'attribution de ressources informatiques) à travers un site web commun pour l'ensemble des centres (voir Demandes d'allocations d'heures sur les machines de l'IDRIS).

Les demandes sont examinées du point de vue scientifique par des Comités thématiques, en s'appuyant le cas échéant sur l'expertise technique, réalisé par les équipes d'assistance applicative des centres. Puis un Comité d'évaluation se réunit pour statuer sur les demandes de ressources et indiquer au Comité d'attribution, placé sous la responsabilité de GENCI, les propositions d'affectation des heures de calculs sur les trois centres nationaux.

Entre ces deux appels à projets, la direction de l'IDRIS étudie les demandes spécifiques (dites “au fil de l'eau”) et effectue des attributions limitées pour éviter le blocage de projets en cours.

Pour les nouveaux projets une procédure appelée Accès préparatoire permet de bénéficier de :

  • 50000 heures.cœurs sur la partition CPU de Jean Zay
  • 1000 heures GPU sur la partition GPU de Jean Zay

afin de pouvoir évaluer et améliorer les performances des codes concernées sur ces super-calculateurs.

Le Comité des utilisateurs de l'IDRIS

Le rôle du comité des utilisateurs est de dialoguer avec le centre afin que tous les projets auxquels des ressources informatiques ont été attribuées puissent être menés à bien dans les meilleures conditions. Il transmet les observations de tous les utilisateurs sur le fonctionnement du centre et dialogue avec l'IDRIS pour définir les évolutions souhaitables.

Le comité des utilisateurs est constitué de 2 élus par discipline scientifique, soit 24 en 2014, qui peuvent être contactés collectivement à l'adresse :
cu-elus puis vous ajoutez après l'@ le domaine idris.fr

Réunion du Comité des utilisateurs de l'IDRIS :

La procahine réunion du Comité des utilisateurs de l'IDRIS aura lieu mercredi 4 novembre 2020.

Les pages du Comité des utilisateurs

Les pages du CU sont disponibles pour les utilisateurs de l'IDRIS en se connectant à l'Extranet de l'IDRIS, section Comité des utilisateurs.

C'est dans cet espace que sont mis à disposition les bilans d'exploitation des machines de l'IDRIS ainsi que les compte-rendu des dernières réunions.

Le personnel de l'IDRIS

Organisation

Pour remplir ses missions, l'IDRIS est organisé en équipes, coordonnées par la direction, de la manière suivante :

Organigramme IDRIS

Retour au sommaire


2. Présentation des machines

Jean Zay : calculateur HPE SGI 8600

jean-zay-annonce-01.jpg

  • copyright Photothèque CNRS/Cyril Frésillon

Jean Zay est un calculateur HPE SGI 8600 composé de deux partitions : une partition contenant des nœuds scalaires et une partition contenant des nœuds accélérés, qui sont des nœuds hybrides équipés à la fois de CPU et de GPU. L'ensemble des nœuds du calculateur sont interconnectés par un réseau Intel Omni-PAth et accèdent à un système de fichiers partagé à très forte bande passante.

Partition scalaire (ou partition CPU)

  • 1528 nœuds de calcul scalaires avec :
    • 2 processeurs Intel Cascade Lake 6248 (20 cœurs à 2,5 GHz), soit 40 cœurs par nœud
    • 192 Go de mémoire par nœud

Partition accélérée (ou partition GPU)

  • 261 nœuds de calcul accélérés quadri-GPU avec :
    • 2 processeurs Intel Cascade Lake 6248 (20 cœurs à 2,5 GHz), soit 40 cœurs par nœud
    • 192 Go de mémoire par nœud
    • 4 GPU Nvidia Tesla V100 SXM2 32 Go
  • 31 nœuds de calcul accélérés octo-GPU, actuellement dédiés à la communauté IA, avec :
    • 2 processeurs Intel Cascade Lake 6226 (12 cœurs à 2,7 GHz), soit 24 cœurs par nœud
    • 20 nœuds à 384 Go de mémoire, 11 nœuds à 768 Go de mémoire
    • 8 GPU Nvidia Tesla V100 SXM2 32Go
  • Extension été 2020 : 351 nœuds de calcul accélérés quadri-GPU avec :
    • 2 processeurs Intel Cascade Lake 6248 (20 cœurs à 2,5 GHz), soit 40 cœurs par nœud
    • 192 Go de mémoire par nœud
    • 4 GPU Nvidia Tesla V100 SXM2 16 Go

Pré et post-traitement

  • 4 nœuds de pré et post-traitement à large mémoire avec :
    • 4 processeurs Intel Skylake 6132 (12 cœurs à 3,2 GHz), soit 48 cœurs par nœud
    • 3 To de mémoire par nœud
    • 1 GPU Nvidia Tesla V100
    • un disque interne NVMe de 1,5 To

Visualisation

  • 5 nœuds de visualisation de type scalaire
    • 2 processeurs Intel Cascade Lake 6248 (20 cœurs à 2,5 GHz), soit 40 cœurs par nœud
    • 192 Go de mémoire par nœud
    • 1 GPU Nvidia Quatro P6000

Autres caractéristiques

  • La puissance crête cumulée est de 28 Pflop/s suite à l'extension de l'été 2020 avec un total de 2696 GPU Nvidia V100
  • Un réseau d'interconnexion Intel Omni-PAth 100 Gb/s : 1 lien par nœud scalaire et 4 liens par nœud convergé
  • Un système de fichiers parallèle IBM Spectrum Scale (ex-GPFS)
  • Un dispositif de stockage parallèle avec des disques SSD d'une capacité de 2,2 Po (GridScaler GS18K SSD) suite à l'extension de l'été 2020.
  • Un dispositif de stockage parallèle avec des disques d'une capacité supérieure à 30 Po
  • 5 nœuds frontaux
    • 2 processeurs Intel Cascade Lake 6248 (20 cœurs à 2,5 GHz), soit 40 cœurs par nœud
    • 192 Go de mémoire par nœud

Description logicielle sommaire

Environnement d'exploitation

  • RedHat version 8.1
  • Slurm 18.08.8

Compilateurs

  • Compilateurs Intel ifort et icc avec Intel(R) Math Kernel Library ;
  • Compilateurs PGI pgfortran et pgcc.

Retour au sommaire


3. Demandes d'allocations d'heures sur les machines de l'IDRIS

Les demandes d'allocations d'heures sur Jean Zay se font via le portail DARI commun aux 3 centres nationaux CINES, IDRIS, et TGCC : www.edari.fr.

La procédure à suivre pour votre demande est différente suivant l'usage que vous souhaitez faire des heures des calcul :

  • développer des algorithmes en Intelligence Artificielle (IA) sur la partition GPU de Jean Zay,
  • ou faire des calculs de haute performance (HPC) sur les partitions CPU et GPU de Jean Zay.

Avant toute demande d'heure, nous vous recommandons de consulter la note GENCI détaillant les conditions et critères d’éligibilité pour obtenir des heures de calcul.

Quel est votre usage ?

Développer des algorithmes en Intelligence Artificielle (IA) sur la partition GPU de Jean Zay

  • Cet usage est destiné aux chercheurs souhaitant développer des algorithmes, des méthodologies ou des outils (machine learning et deep learning) en Intelligence Artificielle.
  • Pour demander des heures de calcul pour ce type d'activité, consultez la section “Développer des algorithmes en Intelligence Artificielle (IA)” sur le portail DARI. Le lien “Création d’un compte ou connexion sur eDARI” vous permettra de créer/accéder à votre espace privé pour pouvoir :
    • renseigner un dossier d’accès dynamique qui sera examiné soit par la direction de l'IDRIS soit par des experts lorsque la demande est élevée,
    • et remplir une déclaration de compte calcul si vous n'avez pas de compte sur Jean Zay.
  • Si vous avez déjà un compte sur Jean Zay, vous pouvez demander à ce qu'il soit rattaché à ce dossier d'accès dynamique en remplissant le premier cadre “Compte multi projet : ajout d’un projet” de la page 1 du formulaire IDRIS FGC.
  • L'allocation d'heures est valable un an à partir de l'ouverture du compte de calcul sur la partition GPU de Jean Zay, Les demandes d'heures peuvent se faire toute l’année.

Calcul haute performance (HPC) sur les partitions CPU et GPU de Jean Zay

  • Cet usage est destiné aux chercheurs faisant de la modélisation et de la simulation numérique afin de résoudre des problèmes de calcul complexes et/ou utilisant des outils de l'IA.
  • Deux appels à projets pour des accès réguliers sont lancés chaque année :
    • en janvier-février pour une attribution des heures du 1er mai de la même année au 30 avril de l'année suivante
    • et en juin-juillet pour une attribution des heures du 1er novembre de l’année courante au 31 octobre de l'année suivante.
  • Pour demander des heures de calcul lors de ces appels à projets, consultez la section “Calcul haute performance (HPC) et utilisation IA” sur le portail DARI. Le lien “Création d’un compte ou connexion sur eDARI” vous permettra de créer/accéder à votre espace privé pour pouvoir :
    • renseigner un dossier d’accès régulier qui sera examiné par des experts,
    • ou renouveler un dossier d’accès régulier qui sera examiné par des experts,
    • ou encore migrer d'un accès préparatoire (voir ci-dessous) vers un accès régulier qui sera examiné par des experts.
  • Pour demander l'ouverture d'un compte consultez le document IDRIS sur la gestion des comptes.

Demandes particulières

Tout au long de l'année, à partir du portail DARI, vous avez la possibilité de faire :

  • des demandes de type accès préparatoire. Ce type de demandes a été mis en place pour favoriser le portage, l'optimisation et la parallélisation des codes de calcul HPC sur CPU et/ou GPU afin de préparer un dossier d’accès régulier. Les demandes seront examinées par le centre qui demandera le cas échéant un avis au président du Comité thématique dont votre projet relève. Le quota d’heures qui pourra alors vous être alloué pour une durée de 6 mois sera de :
    • 50 000 heures.cœurs sur la partition CPU de Jean Zay
    • 1000 heures GPU sur la partition GPU de Jean Zay
  • et des demandes au fil de l'eau pour tous les projets existants (accès dynamiques, accès réguliers HPC et accès préparatoires) ayant épuisé leurs quotas d'heures en cours d'année.

Retour au sommaire


4. Comment obtenir un compte ?

Gestion des comptes : ouverture et fermeture

Le compte utilisateur

Chaque utilisateur dispose d'un unique compte pouvant être associé à tous les projets auxquels il participe.

Pour plus d'information, vous pouvez consulter notre page web concernant la gestion des comptes multi-projet.

Toutes les démarches concernant votre compte se font en remplissant des formulaires qui doivent être envoyés à l'adresse .

En particulier, le formulaire de gestion de compte FGC permet d'effectuer des modifications sur un compte existant : ajout d'un projet, ajout/suppression de points d'accès, changement d'adresse postale, de téléphone, d'employeur, etc…

Ouverture du compte d'un utilisateur

Cas d'un nouveau projet

Il n'y a pas d'ouverture de compte automatique ou implicite. Chaque utilisateur d'un projet doit donc demander :

  • s'il n'a pas encore de compte IDRIS, l'ouverture d'un compte respectant les modalités d'accès définies par GENCI :
    • pour un accès régulier ou un accès préparatoire, utilisez le formulaire de demande de création de compte (GENCI) après que le projet correspondant ait obtenu des heures de calcul,
    • pour un accès dynamique, tout au long de l'année utilisez le portail DARI via la section “Développer des algorithmes en Intelligence Artificielle (IA)” et le lien “Création d’un compte ou connexion sur eDARI” qui vous permettra de créer/accéder à votre espace privé ;
  • ou s'il a déjà un compte ouvert à l'IDRIS, l'ajout de ce projet à son compte en remplissant le premier cadre “Compte multi projet : ajout d’un projet” de la page 1 du formulaire IDRIS FGC. Cette demande doit aussi être signée par le responsable du projet ajouté.

ATTENTION : sur décision du directeur de l’IDRIS ou du Fonctionnaire de Sécurité et de Défense (FSD) du CNRS, la création d’un nouveau compte peut être soumise à autorisation ministérielle, dans le cadre de l’application de la réglementation de Protection du Potentiel Scientifique et Technique de la nation (PPST). Dans un tel cas, une communication personnelle sera transmise afin de mettre en œuvre la procédure requise, sachant que l’instruction du dossier peut demander jusqu’à deux mois.

Remarque : L'ouverture effective d'un nouveau compte sur la machine ne sera faite que lorsque la demande d'accès (régulier, préparatoire ou dynamique) est validée (autorisation ministérielle) et que le projet correspondant a obtenu des heures de calcul.

Cas d'un renouvellement de projet

Les comptes existants sont automatiquement reportés d'un appel à projet à l'autre si les conditions d’éligibilité des membres du projet n'ont pas changé entre-temps (cf. document Modalités d'accès de l'appel à projets chez GENCI).

Par conséquent, si votre compte est ouvert et déjà associé au projet qui a obtenu des heures pour l'appel suivant aucune démarche n'est nécessaire.

Fermeture d'un compte utilisateur

Fermeture suite à l'expiration de l'autorisation ministérielle d'accès aux ressources informatiques de l'IDRIS

Les autorisations ministérielles ne sont accordées/valides que pour une période donnée. Lorsque votre autorisation ministérielle atteint sa date d'expiration, nous sommes dans l'obligation de fermer votre compte.

Dans ce cas, la procédure est la suivante :

  • envoi d'une première notification 90 jours avant la date d'expiration,
  • puis envoi d'une deuxième 70 jours avant la date d'expiration
  • et le compte est fermé le jour de l'expiration.

Pour éviter cette fermeture, dès réception du premier courriel, l’utilisateur est invité à envoyer à l'adresse , un nouveau Formulaire de demande de création de compte (GENCI) pour que l'IDRIS puisse démarrer l'instruction d'un dossier de prolongation. En effet, l’instruction du dossier peut demander jusqu’à deux mois.

Fermeture pour raison de sécurité

Un compte peut être fermé à tout moment et sans préavis sur décision de la Direction de l'IDRIS.

Déclaration des machines à partir desquelles un utilisateur se connecte à l'IDRIS

Toute machine utilisée pour accéder à un calculateur de l'IDRIS doit être enregistrée dans les filtres de l'IDRIS.

Pour cela, tout utilisateur doit fournir, lors de la demande de création de compte, la liste des machines avec lesquelles il se connectera au calculateur de l'IDRIS (adresse IP et nom). Il fait cette déclaration au moyen du formulaire de création de compte utilisateur GENCI disponible sur ce portail.

La mise à jour (ajout/suppression) de la liste des machines associées à un login peut être demandée par son propriétaire à l'aide du formulaire FGC (Formulaire de gestion de compte). Ce formulaire doit être complété et signé par l’utilisateur et le responsable sécurité du laboratoire.

Attention : les adresses IP personnelles ne sont pas autorisées pour se connecter aux machines de l'IDRIS.

Responsable sécurité du laboratoire

Le responsable sécurité du laboratoire est l'interlocuteur réseau /sécurité du laboratoire vis à vis de l'IDRIS. Il doit garantir que la configuration de la machine à partir de laquelle l'utilisateur se connecte à l'IDRIS est conforme aux règles et usages les plus récents en matière de sécurité informatique et doit pouvoir fermer immédiatement l'accès de l'utilisateur à l'IDRIS en cas d'alerte de sécurité.

Son nom et ses coordonnées sont transmis à l'IDRIS par le directeur du laboratoire à l'aide du formulaire FGC (Formulaire de gestion de compte). Ce formulaire est aussi utilisé pour informer l'IDRIS en cas de changement de responsable sécurité.

Comment accéder à l'IDRIS en télétravail ou en mission ?

Pour des raisons de sécurité, nous ne pouvons pas autoriser l'accès aux machines de l'IDRIS depuis des adresses IP non institutionnelles. Il est donc par exemple exclu que vous puissiez vous connecter directement depuis votre connexion personnelle.

Utilisation d'un VPN

La solution recommandée pour accéder aux ressources de l'IDRIS lorsque vous êtes en mobilité (télétravail, mission, etc) est d'utiliser le service VPN (Virtual Private Network) de votre laboratoire/institut/université. Un VPN vous permet d'accéder à des ressources distantes comme si vous étiez connecté directement au réseau local de votre laboratoire. Il reste néanmoins nécessaire d'enregistrer l'adresse IP attribuée à votre machine par le VPN en suivant la procédure décrite plus haut.

Cette solution a l'avantage de permettre l'utilisation des services de l'IDRIS accessibles via un navigateur web (par exemple l'extranet ou des produits comme Jupyter Notebook, JupyterLab et TensorBoard)

Utilisation d'une machine de rebond

Si l'utilisation d'un VPN est impossible, il est toujours possible de vous connecter en SSH à une machine de rebond de votre laboratoire, depuis laquelle Jean Zay est accessible (ce qui implique d'avoir fait enregistrer l'adresse IP de cette machine rebond).

vous@ordinateur_portable:~$ ssh login_rebond@machine_rebond
login_rebond@machine_rebond:~$ ssh login_idris@machine_idris

Notez qu'il est possible d'automatiser le rebond via les options ProxyJump ou ProxyCommand de SSH pour pouvoir vous connecter en utilisant une seule commande (par exemple ssh -J login_rebond@machine_rebond login_idris@machine_idris).

Comment accéder ponctuellement à l'IDRIS depuis l'étranger ?

La demande d'autorisation de la machine doit être faite par le missionnaire qui complète le 2e cadre page 3 du formulaire FGC (“Cadre à remplir dans le cas d’un séjour à l’étranger”). Un accès ssh temporaire sur l'ensemble des machines du centre est alors activé.

Retour au sommaire


5. Comment se connecter pour calculer ?

Comment accéder à Jean Zay ?

Vous ne pouvez vous connecter sur Jean Zay qu'à partir d'une machine dont l'adresse IP est enregistrée dans nos filtres. Si cela n'est pas le cas, consultez la procédure de déclaration des machines disponible sur notre site Web.

Les accès interactifs à Jean Zay ne sont possibles que via le protocole ssh sur les nœuds frontaux de la machine.
Pour de plus amples informations, vous pouvez consulter la description matérielle détaillée du cluster.

Chaque utilisateur de l'IDRIS est titulaire d'un login unique pour tous les projets auxquels il participe. Ce login est associé à un mot de passe obéissant à certaines règles de sécurité. Avant de vous connecter, nous vous conseillons de consulter la page gestion de mot de passe.

Jean Zay : accès et shells

Accès aux machines

Jean Zay :

Le cluster Jean Zay installé à l'IDRIS se compose de 1789 machines HPE bi-processeur Intel Cascade Lake 6248 20-cœurs avec 192 Go de mémoire. Parmi ces machines, 261 nœuds dits convergés XA780i sont équipés en supplément de 4 GPUs Nvidia V100. La frontale jean-zay est la seule qui soit visible et directement accessible par les utilisateurs ; elle offre les fonctionnalités suivantes : connexion interactive, compilation pour les autres nœuds du cluster, préparation, soumission et suivi des jobs. Les job parallèles doivent être exécutés via le gestionnaire de batch Slurm à partir de la frontale; la connexion à la frontale de Jean Zay se fait par ssh depuis une machine enregistrée à l'IDRIS :

ssh mon_login_idris@jean-zay.idris.fr

puis saisissez votre mot de passe, si vous n'avez pas configuré de clef ssh.

Jean Zay pré et post-traitement :

L'offre de pré/post-traitement installée à l'IDRIS se compose de quatre machines HPE équipées chacune de 3 Tio de mémoire, de bi-processeurs Intel Cascade Lake 6132 12-cœurs et d'un GPU Nvidia V100. La frontale jean-zay-pp offre les fonctionnalités suivantes : connexion interactive, compilation, préparation, soumission et suivi des jobs avec le gestionnaire de batch Slurm.
Pour utiliser les nœuds de pré et post-traitement en batch, il suffit de spécifier la partition prepost en préparant un job, que ce soit sur la frontale jean-zay ou jean-zay-pp.

La connexion interactive à la frontale de pré et post-traitement se fait par ssh depuis une machine enregistrée à l'IDRIS :

ssh mon_login_idris@jean-zay-pp.idris.fr

puis saisissez votre mot de passe, si vous n'avez pas configuré de clef ssh.

Connexion par clef ssh

La connexion par clef ssh est possible sur Jean Zay. Il vous suffit d'avoir générer une paire de clefs ssh en respectant les recommandations de l'IDRIS et de taper la commande :

ssh-copy-id <login>@jean-zay.idris.fr

Cela copie votre clef publique dans le fichier $HOME/.ssh/authorized_keys de Jean Zay.

Gestion de son environnement

Votre espace $HOME est commun à toutes les frontales de Jean-Zay. Par conséquent, chaque modification de vos fichiers d'environnement personnels s'applique automatiquement sur toutes les machines.

Quels sont les shells disponibles sur les machines de l'IDRIS ?

Le Bourne Again shell (bash) est le seul interpréteur de commandes supporté comme shell de login sur les machines de l'IDRIS : l'IDRIS ne garantit pas que l'environnement utilisateur par défaut soit correctement défini avec les autres shells. Le bash est une évolution importante du Bourne shell (ancien sh) avec des fonctionnalités avancées. Cependant, d'autres interpréteurs (ksh, tcsh, csh) sont aussi installés sur les machines pour permettre l'exécution de scripts utilisant ces shells.

Quels sont les fichiers d'environnement invoqués lors du lancement d'une session login en bash ?

Le fichier .bash_profile, s'il existe dans votre HOME, est exécuté au login une seule fois pendant une session. Sinon c'est le fichier .profile qui est exécuté, s'il existe. C'est dans un de ces fichiers que l'on place les variables d'environnement, les programmes à lancer à la connexion. La définition des alias, des fonctions personnelles et le chargement de modules sont à mettre dans le fichier .bashrc qui, lui, est exécuté au lancement de chaque sous-shell.

Il est préférable de n'utiliser qu'un seul fichier d'environnement : le .bash_profile ou .profile.

Attention, l'écrasement de la variable PATH conduit toujours à des catastrophes, c'est pourquoi il est toujours conseillé de conserver le PATH fourni par la machine. Si vous souhaitez ajouter un répertoire de recherche pour l'exécution de commandes locales lors de toutes vos futures sessions, il faut procéder de la manière suivante, dans votre .bash_profile ou .profile :

 export PATH=$PATH:repertoire_a_ajouter 

Comment faire pour avoir un environnement convivial en bash ?

Suivant le type d'éditeur que vous appréciez, le bash vous propose 2 modes d'édition à l'aide de la commande set :

set -o emacs # pour être en mode emacs
set -o vi # pour être en mode vi

Gestion des mots de passe

La connexion à Jean Zay se fait par la saisie de votre login et du mot de passe associé.

Pour votre première connexion vous devez utiliser un mot de passe initial qui sera changé immédiatement, afin de définir votre mot de passe courant.

Le mot de passe initial

Qu'est ce que le mot de passe initial ?

Le mot de passe initial est le résultat de la concaténation de deux mots de passe, en respectant leur ordre respectif :

  1. Le mot de passe généré aléatoirement par l'IDRIS, qui vous est envoyé par courriel lors de l'ouverture de votre compte et/ou lors de la réinitialisation de votre mot de passe. Il reste valide 20 jours.
  2. Le mot de passe initial utilisateur (8 caractères alphanumériques), que vous devez renseigner :
    • lors de la demande d'ouverture de votre compte (si vous êtes nouvel utilisateur) sur le portail DARI ;
    • lors d'une demande de réinitialisation du mot de passe initial dans le Formulaire de Gestion de Compte (FGC).
      Remarque : pour un utilisateur dont le compte a été créé en 2014 ou avant, il est constitué par le mot de passe initial indiqué dans la dernière lettre reçue de l'IDRIS.

Ce mot de passe initial doit être changé dans les 20 jours qui suivent la réception du courriel contenant le mot de passe généré aléatoirement :

Ce changement se fait automatiquement lors de la première connexion sur Jean Zay (c.f. ci-dessous Exemple de changement du mot de passe initial). Si la première connexion n'a pas été effectuée dans ce délai de 20 jours, le mot de passe initial est invalidé : un courriel vous est envoyé pour vous en informer. Il suffit de contacter par courriel pour demander la réinitialisation de la partie aléatoire du mot de passe initial, qui vous est alors renvoyée par courriel.

Le mot de passe initial est (ré)généré dans les cas suivants :

Réouverture de compte :

Un mot de passe initial est attribué à la création de chaque compte, mais aussi lors de la réouverture d'un compte fermé.

Oubli de votre mot de passe :

  • Si vous perdez votre mot de passe courant, contactez par courriel pour demander la réinitialisation de la partie aléatoire du mot de passe initial, qui vous est alors renvoyée par courriel ; vous aurez aussi besoin de votre mot de passe initial utilisateur.
  • Si vous avez aussi perdu votre mot de passe initial utilisateur, celui que vous avez vous-même fourni dans le FGC (ou reçu dans la lettre de l'IDRIS avant 2014), vous devez remplir dans le FGC le cadre de changement de mot de passe initial utilisateur, l'imprimer et le signer, puis le transmettre par courriel à ou l'envoyer par courrier postal. Vous recevrez alors un courriel dans lequel un nouveau mot de passe aléatoire vous sera communiqué.

Utilisation du mot de passe initial lors de la première connexion

Voici un exemple de première connexion avec entrée du mot de passe initial pour le compte login_idris sur la machine de l'IDRIS.

Attention : à la première connexion, le mot de passe initial est demandé deux fois. Une première fois pour établir la connexion sur la machine et une seconde fois par la procédure de changement du mot de passe qui est alors automatiquement exécutée.

Recommandation : comme vous êtes obligé de changer le mot de passe initial à votre première connexion, préparez soigneusement un autre mot de passe avant de commencer la procédure (c.f. Règles de constitution ci-dessous).

$ ssh login_idris@machine_idris.idris.fr                                                         
login_idris@machine_idris password:   ## Première demande du MOT DE PASSE INITIAL ##
Last login: Fri Nov 28 10:20:22 2014 from machine_idris.idris.fr
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user login_idris.
Enter login(    ) password:           ## Seconde demande du MOT DE PASSE INITIAL ##
New password:                         ## Entrez le nouveau mot de passe choisi ##
Retype new password:                  ## Confirmez le nouveau mot de passe choisi ##
     password information changed for login_idris
passwd: all authentication tokens updated successfully.
Connection to machine_idris closed.

Remarque : le fait d'être immédiatement déconnecté après que le nouveau mot de passe choisi ait été accepté (all authentication tokens updated successfully) est normal.

Vous pouvez maintenant vous reconnecter avec le nouveau mot de passe courant que vous venez d'enregistrer.

Le mot de passe courant

Une fois choisi correctement, sa durée de validité est d'un an (365 jours).

Comment changer votre mot de passe courant ?

Comme il est unique pour chaque login, vous pouvez changer votre mot de passe en utilisant la commande UNIX passwd sur Jean Zay. Le changement est immédiat ; la validité de ce nouveau mot de passe courant est d'un an à nouveau.

Règles de constitution des mots de passe courants :

  • Ils doivent comporter un minimum de 12 caractères.
  • Ces caractères doivent appartenir à au moins 3 familles de caractères parmi les 4 suivantes :
    • majuscules,
    • minuscules,
    • chiffres,
    • caractères spéciaux.
  • Un mot de passe ne doit pas non plus contenir le même caractère plus de deux fois consécutives.
  • Il ne doit pas être composé de mots issus de dictionnaires, ni de combinaisons triviales (1234, azerty, …).

À noter :

  • Un nouveau mot de passe n'est pas modifiable pendant 5 jours. Il est toujours possible, en cas de nécessité, de contacter l'Assistance pour demander une remise à zéro au mot de passe initial.
  • Un historique des 6 derniers mots de passe est conservé, afin de rejeter un mot de passe utilisé récemment.

Oubli ou expiration du mot de passe courant

Si vous avez oublié votre mot de passe courant ou si, malgré les courriels d'avertissement, vous n'avez pas changé votre mot de passe courant avant sa date d'expiration (un an après le dernier changement) alors votre mot de passe sera invalidé.

Vous devez alors contactez par courriel pour demander la réinitialisation de la partie aléatoire du mot de passe initial, qui vous est alors renvoyée par courriel.

Remarque : vous aurez aussi besoin de la partie utilisateur de votre mot de passe initial pour pouvoir vous connecter sur la machine après cette réinitialisation. En effet, vous aurez à suivre la procédure correspondant à une première connexion.

Compte bloqué suite à 15 connexions infructueuses :

Si votre compte est bloqué suite à 15 tentatives infructueuses, vous devez contacter l'Assistance de l'IDRIS.

Rappel sur la sécurité de votre compte

Ne communiquez jamais votre mot de passe en clair dans un message électronique adressé à l'IDRIS (Assistance, Gestion des Utilisateurs, etc.) et ce, quel qu'en soit le motif : nous serions alors obligés de générer immédiatement un nouveau mot de passe initial, afin d'inhiber le mot de passe courant que vous auriez ainsi publié et de nous assurer que vous en définissiez un nouveau dès la connexion suivante.

Chaque compte est strictement personnel. L'accès d'une personne non autorisée entraine dès sa découverte des mesures de protection immédiates allant jusqu'au blocage du compte.
En tant que titulaire d'un compte, vous êtes tenus de prendre quelques précautions élémentaires de bon sens :

  • prévenir immédiatement l'IDRIS de toute tentative de violation de son compte,
  • respecter les recommandations sur l'utilisation des clés ssh,
  • protéger ses fichiers en limitant les droits d'accès UNIX,
  • ne pas utiliser de mot de passe trop simple,
  • protéger son poste de travail personnel.

Retour au sommaire


6. Gestion de son compte et de son environnement

Comment modifier mes données personnelles ?

La modification de vos données personnelles se fait via l'interface Web Extranet.

  • Pour ceux qui n'ont pas de mot de passe Extranet ou qui l'ont perdu, les modalités d'accès sont décrites sur cette page.
  • Pour ceux qui ont leur mot de passe, cliquez sur Extranet, connectez vous avec vos identifiants puis ⇒ Votre compte ⇒ Vos données ⇒ Coordonnées.

Les seules données modifiables en ligne sont :

  • le courriel ;
  • le téléphone ;
  • le fax.

La modification de vos coordonnées postales se fait en nous envoyant le formulaire de gestion de compte FGC.

Quels espaces disques sont disponibles sur Jean Zay ?

Pour chaque projet, 5 espaces disques distincts sont disponibles sur Jean Zay : HOME, WORK, SCRATCH/JOBSCRATCH, STORE et DSDIR.

Vous trouverez les explications concernant ces espaces sur notre site web, à la page Espaces disques.
Attention : HOME, WORK et STORE sont soumis à des quotas !

Si votre login est rattaché à plusieurs projets, la commande IDRIS idrenv vous affichera toutes les variables d'environnement référençant tous les espaces disques de tous vos projets. Ces variables vous permettent d'accéder aux données de vos divers projets à partir de n'importe lequel d'entre eux.

Choisissez votre espace de stockage selon vos besoins (données permanentes, semi-temporaires, temporaires, gros ou petits fichiers, etc …).

Comment demander une extension d'espace disque ou d'inodes ?

Si votre utilisation de l'espace disque est conforme à son usage et si vous ne pouvez pas supprimer ou déplacer des données contenues dans cet espace, alors votre chef de projet peut effectuer une demande argumentée d'augmentation de quota (espace et/ou inodes) sur l'extranet de l'IDRIS.

Comment connaitre le nombre d'heures de calcul consommées par projet ?

Il vous suffit d'utiliser la commande IDRIS idracct pour connaitre les heures consommées par chaque collaborateur du projet ainsi que le pourcentage de l'allocation d'heures et le total consommés.

Notez que les informations retournées par cette commande ne sont mises à jour qu'une fois par jour (comme indiqué en première ligne de la sortie de la commande).

Si vous avez plusieurs projets à l'IDRIS, cette commande vous donnera les consommations CPU et/ou GPU de tous les projets auxquels votre login est rattaché.

Que faire lorsque je n'ai bientôt plus d'heures de calcul ?

Il est possible d'effectuer des demandes d'heures supplémentaires via :

  • soit une demande dite “au fil de l'eau” qui peut se faire tant que votre projet HPC ou IA dispose d'une allocation d'heures en cours.
  • soit une demande à mi-parcours de votre allocation d'Accès Régulier (HPC) pour obtenir un complément d'heures pour une période de six mois.

Ces demandes, qui doivent être justifiées, sont à effectuer via le portail du DARI comme indiqué dans notre page web traitant des demandes d'allocations d'heures.

Comment puis-je savoir si la machine est indisponible ?

La machine peut être indisponible en raison d'une maintenance préprogrammée ou d'un problème technique survenu subitement. Dans les deux cas, l'information est disponible sur la page d'accueil du site Web de l'IDRIS via le menu déroulant intitulé “Espace utilisateurs” puis la rubrique "Disponibilité des machines".

Les utilisateurs de l'IDRIS peuvent également s'inscrire à la liste de diffusion “info-machines” via l'Extranet. .

Comment récupérer des fichiers que j'ai malencontreusement détruits ?

Il n'est possible de récupérer des fichiers détruits que dans votre HOME et que dans les WORK de vos divers projets. En effet, seuls les espaces HOME et WORK sont sauvegardés via des snapshots dont le mécanisme est détaillé sur la page Espaces disques de notre site Web.

Pour des raisons de trop grande taille, ni le SCRATCH (espace semi-temporaire), ni le STORE (espace de stockage) ne sont sauvegardés.

Puis-je demander à l'IDRIS le transfert des fichiers d'un compte sur un autre compte ?

L'IDRIS considère que les données sont liées à un projet. Par conséquent, pour que le transfert soit possible, il faut que :

  1. les 2 comptes (le propriétaire et le destinataire) soient tous les deux rattachés au même projet ;
  2. que ce soit le chef du projet qui fasse la demande, par fax signé ou par courriel à l'assistance () en précisant bien :
    • la machine concernée ;
    • le compte source et le compte destinataire ;
    • la liste des fichiers et/ou répertoires à transférer.

Puis-je récupérer des fichiers sur un support externe ?

Il n'est plus possible de demander le transfert de ses fichiers sur un support externe.

Retour au sommaire


7. Présentation des espaces disques

Jean Zay : les espaces disques

Pour chaque projet, quatre espaces disques distincts sont accessibles : HOME, WORK et SCRATCH/JOBSCRATCH, enfin le STORE.

Chaque espace a des caractéristiques spécifiques adaptées à son utilisation, qui sont décrites ci-dessous. Les chemins d'accès à ces espaces sont stockés dans cinq variables d'environnement du shell : $HOME, $WORK, $SCRATCH et $JOBSCRATCH, enfin $STORE.

Vous pouvez connaitre l'occupation des différents espaces disques avec la commande idrquota.

Le HOME

$HOME : c'est le répertoire d'accueil lors d'une connexion interactive. Cet espace est destiné aux fichiers de petite taille, très souvent utilisés, comme les fichiers d'environnement du shell, les utilitaires, éventuellement les sources et les bibliothèques quand leur taille est raisonnable. Cet espace a une taille limitée (en espace comme en nombre de fichiers).
Voici ses caractéristiques :

  • le HOME est un espace permanent ;
  • il est sauvegardé via des snapshots : voir la rubrique intitulée Les sauvegardes ci-dessous ;
  • il est prévu pour accueillir des fichiers de petite taille ;
  • dans le cas d'un login multi-projets, le HOME est unique ;
  • il est soumis à des quotas par utilisateur volontairement assez faibles (3 Gio par défaut) ;
  • il est accessible en interactif ou dans un travail batch via la variable $HOME :
    $ cd $HOME
  • c'est le répertoire d'accueil lors d'une connexion interactive.

Le WORK

$WORK : c'est un espace de travail et de stockage permanent utilisable en batch. On y stocke généralement les fichiers de taille importante qui servent lors des exécutions en batch : les fichiers sources volumineux et les bibliothèques, les fichiers de données, les exécutables, les fichiers de résultats, les scripts de soumission.
Voici ses caractéristiques :

  • le WORK est un espace permanent ;
  • il est sauvegardé via des snapshots : voir la rubrique intitulée Les sauvegardes ci-dessous ;
  • il est prévu pour accueillir des fichiers de taille importante ;
  • dans le cas d'un login multi-projet, un WORK par projet est créé ;
  • il est soumis à des quotas par projet ;
  • il est accessible en interactif ou dans un travail batch ;
  • il est composé de 2 parties :
    • une partie propre à chaque utilisateur ; on y accède par la commande :
      $ cd $WORK
    • une partie commune au projet auquel l'utilisateur appartient, dans lequel on peut mettre des fichiers destinés à être partagés; on y accède par la commande :
      $ cd $ALL_CCFRWORK 
  • le WORK est un espace disque GPFS dont la bande passante est d'environ 100 Gb/s en écriture et en lecture. Celle-ci peut être ponctuellement saturée en cas d'utilisation exceptionnellement intensive.

Recommandations d'utilisation :

  • les travaux batch peuvent s'exécuter dans le WORK ; cependant, plusieurs de vos travaux pouvant s'exécuter en même temps, il vous faut gérer l'unicité de vos répertoires d'exécution ou de vos noms de fichiers.
  • De plus, il est soumis à des quotas (par projet) qui peuvent stopper brutalement votre exécution s'ils sont atteints. Ainsi, dans le WORK, il faut tenir compte non seulement de votre propre activité, mais aussi de celle de vos collègues de projet. Pour ces raisons, on pourra alors être amené à lui préférer le SCRATCH ou le JOBSCRATCH pour l'exécution de ses travaux batch.

Le SCRATCH/JOBSCRATCH

$SCRATCH : c'est un espace de travail et de stockage semi-temporaire utilisable en batch, la durée de vie des fichiers y est limitée à 30 jours. On y stocke généralement les fichiers de taille importante qui servent lors des exécutions en batch : les fichiers de données, les fichiers de résultats ou de reprise de calcul (restarts). Une fois le post-traitement effectué pour réduire le volume de données, il faut penser à recopier les fichiers significatifs dans le WORK pour ne pas les perdre après 30 jours, ou dans le STORE pour un archivage à long terme.
Voici ses caractéristiques :

  • le SCRATCH est un espace semi-permanent : la durée de vie des fichiers est de 30 jours ;
  • il n'est pas sauvegardé ;
  • il est prévu pour accueillir des fichiers de taille importante ;
  • il est soumis à des quotas par projet très larges, de l'ordre d'1/5 de l'espace disque total ;
  • il est accessible en interactif ou dans un travail batch ;
  • il est composé de 2 parties :
  • une partie propre à chaque utilisateur ; on y accède par la commande :
    $ cd $SCRATCH
  • une partie commune au projet auquel l'utilisateur appartient, dans lequel on peut mettre des fichiers destinés à être partagés; on y accède par la commande :
    $ cd $ALL_CCFRSCRATCH 
  • dans le cas d'un login multi-projet, un SCRATCH par projet est créé ;
  • le SCRATCH est un espace disque GPFS dont la bande passante est d'environ 300 Go/s en écriture et en lecture.

$JOBSCRATCH : c'est le répertoire temporaire d'exécution propre à un unique travail batch.
Voici ses caractéristiques :

  • le JOBSCRATCH est un répertoire temporaire : la durée de vie des fichiers est celle du travail batch ;
  • il n'est pas sauvegardé ;
  • il est prévu pour accueillir des fichiers de taille importante ;
  • il est soumis à des quotas par projet très larges, de l'ordre d'1/5 de l'espace disque total ;
  • il est créé automatiquement lorsqu'un travail batch démarre : il est donc unique à chaque travail ;
  • il est détruit automatiquement à la fin de ce travail : il est donc indispensable de recopier explicitement les fichiers importants sur un autre espace disque (le WORK ou le SCRATCH) avant la fin du travail ;
  • le JOBSCRATCH est un espace disque GPFS dont la bande passante est d'environ 300 Go/s en écriture et en lecture.

Recommandations d'utilisation :

  • On peut voir le JOBSCRATCH comme l'ancien TMPDIR.
  • Le SCRATCH peut être vu comme un WORK semi-temporaire, mais avec les performances d’entrées/sortie maximales offertes à l'IDRIS, au prix d'une durée de vie des fichiers de 30 jours.
  • Les caractéristiques semi-temporaires du SCRATCH permettent d'y stocker de gros volumes de données entre deux ou plusieurs jobs qui s’enchainent sur une durée limitée à quelques semaines : cet espace n'est pas “purgé” après chaque job.

Le STORE

$STORE : c'est l'espace d'archivage, de stockage à long terme de l'IDRIS. On y stocke généralement les fichiers de taille très importante, fruits du tar d'une arborescence de fichiers résultats de calcul, après post-traitement. C'est un espace qui n'a pas pour vocation d’être accédé ou modifié quotidiennement, mais de préserver dans le temps de très gros volumes de données avec une consultation épisodique.
Voici ses caractéristiques :

  • le STORE est un espace permanent ;
  • il n'est pas sauvegardé ;
  • nous déconseillons son accès systématique en écriture dans un travail batch ;
  • il est prévu pour accueillir des fichiers de taille très importante : la taille maximum est de 10 Tio par fichier et la taille minimum conseillée de 250 Mio (ratio taille disque / nombre d'inodes);
  • dans le cas d'un login multi-projet, un STORE par projet est créé ;
  • il est soumis à des quotas par projet avec un faible nombre d'inodes, mais un très grand espace ;
  • il est composé de 2 parties :
    • une partie propre à chaque utilisateur ; on y accède par la commande :
      $ cd $STORE
    • une partie commune au projet auquel l'utilisateur appartient, dans lequel on peut mettre des fichiers destinés à être partagés; on y accède par la commande :
      $ cd $ALL_CCFRSTORE

Recommandations d'utilisation :

  • Le STORE n'a pas de principe de limitation de la durée de vie des fichiers.
  • Comme il s'agit d'un espace d'archive, il n'est pas conçu pour des accès fréquents.

Le DSDIR

$DSDIR : l'espace disque contenant les bases de données publiques volumineuses (en taille ou en nombre de fichiers) nécessaires à l'utilisation d'outils de l'Intelligence Artificielle. Ces bases de données sont visibles par l'ensemble des utilisateurs de Jean Zay.

Si vous exploitez de telles bases de données et que celles-ci ne se trouvent pas dans l'espace $DSDIR, l'IDRIS les téléchargera et les installera dans cet espace disque à votre demande.

Vous trouverez la liste des bases de données disponibles actuellement sur la page : Jean Zay : bases de données disponibles dans l'espace de stockage $DSDIR.

Tableau récapitulatif des principaux espaces disques

Espace Capacité par défaut Spécificité Usage
$HOME 3 Go et 150 kinodes
par utilisateur
- Espace sauvegardé
- Accueil de connexion
- Stockage de fichiers de configuration
et de petits fichiers
$WORK 5 To et 500 kinodes
par projet (*)
- Espace sauvegardé
- Stockage sur disques rotatifs
(100 Gb/s en lecture/écriture)
- Stockage des sources et des
données d'entrée/sortie
- Exécution en batch ou interactif
$SCRATCH Pas de quota
1,3 Po partagés
par tous les utilisateurs
- Espace non sauvegardé
- Stockage SSD
(300 Go/s en lecture/écriture)
- Durée de vie des fichiers inutilisés :
30 jours
(inutilisés = non lus, non modifiés)
- Stockage des données
d'entrée/sortie volumineuses
- Exécution en batch ou interactif
- Performances optimales pour
les opérations de lecture/écriture
$STORE 50 To et 100 kinodes
par projet (*)
- Espace non sauvegardé - Stockage d'archives sur du long terme
(durée de vie du projet)
(*) les quotas par projet peuvent être augmentés sur demande du chef de projet ou de son suppléant via l'interface Extranet ou sur demande auprès du support utilisateurs.

Les sauvegardes

Les espaces $HOME et $WORK sont sauvegardés régulièrement via un mécanisme de snapshots : ce sont des instantanés de ces arborescences vous permettant de récupérer un fichier ou un répertoire que vous auriez corrompu ou effacé par erreur.

Tous les instantanés disponibles SNAP_YYYYMMDD, où YYYYMMDD correspond à la date de sauvegarde, sont visibles depuis tous les répertoires de votre HOME et de votre WORK via la commande :

$ ls .snapshots
SNAP_20191022  SNAP_20191220  SNAP_20200303  SNAP_20200511
SNAP_20191112  SNAP_20200127  SNAP_20200406  SNAP_20200609 

Remarque : dans cet exemple, vous noterez la présence de 8 sauvegardes. Pour récupérer un fichier à la date du 9 juin 2020, il vous suffit de sélectionner le répertoire SNAP_20200609.

Attention : le répertoire .snapshots n'est pas visible avec la commande ls -a donc ne soyez pas surpris de ne pas le voir. Seul son contenu peut être consulté.

Si, par exemple, vous désirez récupérer un fichier qui était dans le sous répertoire $WORK/MY_DIR, il vous suffit de suivre la procédure suivante :

  1. Vous vous placez dans le répertoire du fichier initial :
    $ cd $WORK/MY_DIR
  2. Vous retrouvez la sauvegarde qui vous intéresse via la commande ls :
    $ ls .snapshots
    SNAP_20191022  SNAP_20191220  SNAP_20200303  SNAP_20200511
    SNAP_20191112  SNAP_20200127  SNAP_20200406  SNAP_20200609 
  3. Vous pouvez alors consulter le contenu de votre répertoire $WORK/MY_DIR tel qu'il était à la date du 9 juin 2020 par exemple, avec la commande :
    $ ls -al .snapshots/SNAP_20200609 
    total 2
    drwx--S--- 2 login  prj  4096 oct.  24  2019 .
    dr-xr-xr-x 2 root  root 16384 janv.  1  1970 ..
    -rw------- 1 login  prj 20480 oct.  24  2019 my_file 
  4. Et finalement, vous pouvez récupérer le fichier tel qu'il était à la date du 9 juin 2020, avec la commande cp :
    1. en écrasant le fichier initial $WORK/MY_DIR/my_file (notez le “.” en fin de commande) :
      $ cp .snapshots/SNAP_20200609/my_file . 
    2. ou en renommant la copie $WORK/MY_DIR/my_file_20200609 pour ne pas écraser le fichier initial $WORK/MY_DIR/my_file:
      $ cp .snapshots/SNAP_20200609/my_file  my_file_20200609 

Remarques :

  • La commande ls -l .snapshots/SNAP_YYYYMMDD vous indique toujours le contenu du répertoire dans lequel vous êtes mais à la date du DD/MM/YYYY.
  • Vous pouvez ajouter l'option -p à la commande cp pour conserver la date et les droits d'accès Unix du fichier récupéré :
    $ cp -p .snapshots/SNAP_20200609/my_file . 
    $ cp -p .snapshots/SNAP_20200609/my_file  my_file_20200609 
  • Cette procédure s'applique de la même façon pour récupérer des fichiers de votre HOME.

Retour au sommaire


8. Commandes de transferts de fichiers

Les transferts de fichiers par la commande bbftp

Avant le premier transfert

Pour utiliser la commande bbftp il faut que le deamon correspondant soit installé sur la machine distante. Pour télécharger le package, vous devez aller à l'adresse : http://software.in2p3.fr/bbftp/download.html

Voici quelques conseils pour télécharger les fichiers qui vous conviennent :

  • Dans la liste qui vous est proposée, nous vous recommandons de choisir la dernière version, la 3.2.1 .
  • Les fichiers suffixés par i386.rpm contiennent les exécutables Linux.
  • Les fichiers suffixés par tar.gz contiennent les fichiers sources pouvant êtres compilés sur les machines Unix et Linux.
  • Le fichier dont le nom contient cygwin et est suffixé par .zip contient les exécutables Windows.
  • Si vous souhaitez passer des commande bbftp uniquement sur les machines de l'IDRIS vers votre machine locale, vous pouvez n'installer que le fichier serveur dans votre laboratoire. Si vous souhaitez passer des commandes de transfert également sur votre machine locale vers les machines de l'IDRIS, vous devez aussi installer le fichier client.
  • Pour Windows, seul le mode client est disponible, c'est à dire que bbftp ne vous permet pas de transférer des fichiers dans un job batch tournant sur une machine de l'IDRIS vers un PC Windows. En cas de difficulté lors de l'installation, un ingénieur réseau de l'IDRIS peut vous aider.

Transfert d'un fichier en interactif

Sur une machine locale (de votre laboratoire) à partir de laquelle vous pouvez accéder à la machine de calcul, vous pouvez utiliser les commandes suivantes pour :

  • transférer un fichier de votre machine locale sur la machine de l'IDRIS :
    $ bbftp -e 'put fichier_local' -u login_idris -s machine.idris.fr
    Password (max length = 8192):
    put fichier_local OK 
  • transférer un fichier de la machine de l'IDRIS sur votre machine locale :
    $ bbftp -e 'get fichier_idris' -u login_idris -s machine.idris.fr
    Password (max length = 8192):
    get fichier_idris OK

Transfert de fichiers dans un job batch tournant sur les machines de calcul

Pour transférer des fichiers dans un job batch, il faut utiliser la commande bbftp via une authentification SSH, après avoir généré des clés publiques avec une passphrase vide. Cf. la procédure à suivre pour mettre en place cette authentification SSH.

Pour ne pas consommer d'heures de calcul avec les transferts de fichiers, vous pouvez utiliser la partition archive pour votre job batch. Vous pouvez aussi enchainer un job pour les transferts avec un job de calcul comme indiqué dans notre documentation web.

Transfert d'un fichier

$ bbftp -e 'put fichier_idris' -u login_local -s machine_locale.domaine.fr
put fichier_idris OK

ou encore avec un changement du nom du fichier :

$ bbftp -e 'put fichier_idris fichier_local' -u login_local -s machine_locale.domaine.fr
put fichier_idris fichier_local OK

Transfert de plusieurs fichiers : l'option ''-i''

$ bbftp -i liste_commande -u login_local -s machine_locale.domaine.fr

Le fichier liste_commande contient des lignes correspondant aux commandes passées à l'option -e, par exemple :

$ cat liste_commande
put fichier_idris
put fichier_idris rep_local/fichier_local
mget rep_local/*

Transfert d'un répertoire :

$ bbftp -e 'mput rep_idris/*' -u login_local -s machine_locale.domaine.fr

ou encore avec création d'un répertoire rep_local pour y enregistrer les données sur votre machine locale :

$ bbftp -e 'mkdir rep_local; mput rep_idris/* rep_local' -u login_local -s machine_locale.domaine.fr

Les transferts de fichiers via le réseau CCFR

Comment transférer des données entre les 3 centres nationaux (réseau CCFR) ?

Présentation

Le réseau des Centres de Calcul Français (CCFR) est un réseau dédié à très haut débit, qui interconnecte les trois centres de calcul nationaux CINES, IDRIS et TGCC. Ce réseau est mis à la disposition des utilisateurs pour faciliter les transferts de données entre les centres nationaux. Sont actuellement raccordées sur ce réseau les machines Joliot-Curie au TGCC, Jean Zay à l'IDRIS et Occigen au CINES.

Remarques :

  • Votre login IDRIS doit être autorisé à accéder au réseau CCFR. Dans le cas contraire, vous devez remplir le cadre intitulé “Accéder au réseau CCFR” du formulaire de gestion de compte (FGC) et l'envoyer à à partir d'une adresse institutionnelle. Notez que cette procédure requiert les signatures de l'utilisateur et du responsable sécurité de votre laboratoire.
  • De plus, tous les nœuds de Jean Zay ne sont pas connectés à ce réseau. Pour l'utiliser depuis l'IDRIS, vous devez vous connecter sur la machine référencée par l'alias jean-zay-ccfr.idris.fr qui est accessible uniquement depuis jean-zay :
    $ ssh login_idris@jean-zay-ccfr.idris.fr

Pour plus d'information, n'hésitez pas à contacter l'assistance ().

Documentation

La documentation complète (pré-requis, authentification, certificats) est disponible ici.

Retour au sommaire


9. La commande module

Jean Zay : commande module

Afin de charger les produits installés sur Jean Zay, il est nécessaire d'utiliser la commande module.

Nouveautés avec Environment Modules v4

En plus de corriger de nombreux bugs, l'Environment Modules v4 introduit de nouvelles fonctionnalités, en particulier :

  • la gestion automatique des dépendances entre les modules (voir la section suivante) ;
  • un choix amélioré de la version par défaut des modules : la plus récente est utilisée par défaut, plutôt que la dernière version disponible dans l'ordre alphabétique. Par exemple, la version 1.10 est bien considérée comme étant plus récente que la version 1.9 ;
  • un filtrage avancé de la sortie de la commande module avail via des options :
    • -d n'affiche que la version par défaut de chaque module
    • -L n'affiche que la version la plus récente de chaque module
    • -C <texte> permet de chercher tous les modules dont le nom ou la version contient le motif <texte>
  • une colorisation de la sortie de la commande pour en améliorer la lisibilité ;
  • une amélioration des performances.

Pour plus de détails, nous vous invitons à consulter, sur le site officiel d'Environment Modules, les notes de version et la page Differences between versions 3.2 and 4.

Gestion automatique des dépendances

La fonctionnalité de gestion automatique des dépendances entre les modules, introduite dans l'Environment Modules v4, est utilisée à l'IDRIS afin de garantir la cohérence de l'environnement chargé.
Ceci signifie que la commande module s'assure que les prérequis en matière de compilateur et de bibliothèque MPI sont bien satisfaits à chaque chargement d'un module :

  • Lorsqu'un module est chargé dans un environnement vierge (sans aucun compilateur ni bibliothèque MPI déjà sélectionnés), un environnement par défaut est chargé si nécessaire (sélection du compilateur et/ou de la bibliothèque MPI). Par exemple, la bibliothèque NetCDF est disponible avec 2 environnements Intel (18.0.5 et 19.0.4); par défaut, c'est l'environnement Intel 19.0.4 qui est chargé :
    $ module purge
    $ module load netcdf
    Loading netcdf/4.7.2-mpi
      Loading requirement: intel-compilers/19.0.4 intel-mpi/19.0.4
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.4   2) intel-mpi/19.0.4   3) netcdf/4.7.2-mpi
    $ which ncdump
    /.../netcdf/4.7.2/intel-19.0.4-cqo7jj3yxaprhm23gr2tfq2f4epw7k3r/bin/ncdump
  • Lorsqu'on charge un module dans un environnement déjà contraint par le chargement antérieur d'un compilateur (et éventuellement d'une bibliothèque MPI), l’installation du produit effectuée avec cette même version du compilateur (et respectivement de la même bibliothèque MPI) est automatiquement sélectionnée. Prenons, par exemple, la bibliothèque NetCDF disponible pour les environnements Intel 18.0.5 et 19.0.4, on peut vérifier ce comportement de la commande module en chargeant préalablement l'environnement Intel 18.0.5 :
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/18.0.5   2) intel-mpi/18.0.5 
    $ module load netcdf
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/18.0.5   2) intel-mpi/18.0.5   3) netcdf/4.7.2-mpi  
    $ which ncdump
    /.../netcdf/4.7.2/intel-18.0.5-4q5xoewvla54i45rdh743eu7bm7wnsi7/bin/ncdump
  • Par contre, si aucune installation n'a été effectuée pour l'environnement déjà chargé, un message d'erreur sera affiché (indiquant un conflit, par exemple) ; dans ce cas le module n'est pas chargé. Par exemple, si on essaie de charger la bibliothèque NetCDF dans l'environnement Intel 19.0.5 alors qu'elle n'est pas disponible :
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.5  
    $ module load netcdf
    Loading intel-compilers/19.0.4
      ERROR: Conflicting intel-compilers is loaded
     
    Loading intel-compilers/18.0.5
      ERROR: Conflicting intel-compilers is loaded
     
    Loading netcdf/4.7.2-mpi
      ERROR: Load of requirement intel-compilers/19.0.4 or intel-compilers/18.0.5 failed
     
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.5

Remarque : lorsqu'un produit est disponible pour plusieurs environnements, il peut être nécessaire de charger le compilateur et/ou la bibliothèque MPI avant de charger le produit afin de s'assurer que l'environnement utilisé est le bon.

Affichage des produits installés

Pour afficher les produits installés sur Jean Zay, il faut utiliser la sous-commande avail.

$ module avail
------------------------- /gpfslocalsup/pub/module-rh/modulefiles -------------------------
arm-forge             intel-all/16.0.4        intel-compilers/18.0.1  intel-vtune/18.0.5     pgi/19.7   
cuda/9.2              intel-all/18.0.1        intel-compilers/18.0.5  intel-vtune/19.0.2     pgi/19.9   
cuda/10.0             intel-all/18.0.5        intel-compilers/19.0.2  intel-vtune/19.0.4     pgi/19.10  
cuda/10.1.1           intel-all/19.0.2        intel-compilers/19.0.4  intel-vtune/19.0.5     
cuda/10.1.2           intel-all/19.0.4        intel-compilers/19.0.5  nccl/2.4.2-1+cuda9.2   
cudnn/9.2-v7.5.1.10   intel-all/19.0.5        intel-itac/18.0.1       nccl/2.4.2-1+cuda10.1  
cudnn/10.1-v7.5.1.10  intel-itac/19.0.4       intel-itac/18.0.5       pgi/19.5               
 
------------------------- /gpfslocalsup/pub/modules-idris-env4/modulefiles/linux-rhel7-x86_64 -------------------------
abinit/7.0.5                fftw/3.3.8-mpi           nco/4.8.1                         trilinos/12.12.1-mpi      
abinit/8.8.2-mpi            fftw/3.3.8-mpi-cuda      ncview/2.1.7-mpi                  udunits2/2.2.24           
abinit/8.10.3-mpi           gaussian/g09-revD01      netcdf-fortran/4.5.2              uuid/1.6.2                
adf/2019.104-mpi-cuda       gaussian/g16-revC01      netcdf-fortran/4.5.2-mpi          valgrind/3.14.0-mpi
anaconda-py2/2019.03        gcc/4.8.5                netcdf/4.7.2                      valgrind/3.14.0-mpi-cuda
anaconda-py3/2019.03        gcc/5.5.0                netcdf/4.7.2-mpi                  vasp/5.4.4-mpi-cuda       
arpack-ng/3.7.0-mpi         gcc/6.5.0                netlib-lapack/3.8.0               vim/8.1.0338              
autoconf/2.69               gcc/8.2.0                netlib-scalapack/2.0.2-mpi        visit/2.13.0-mpi          
automake/1.16.1             gcc/8.3.0                netlib-scalapack/2.0.2-mpi-cuda   vtk/8.1.2-mpi  
bigdft/devel-0719-mpi-cuda  gcc/9.1.0                nwchem/6.8.1-mpi                  xedit/1.2.2               
blitz/1.0.1                 gcc/9.1.0-cuda-openacc   octave/4.4.1-mpi
boost/1.62.0                gdb/8.2.1                opa-psm2/11.2.77
[...]   

(affichage non exhaustif, basé sur une sortie de la commande éditée en décembre 2019)

Rechercher un produit particulier

Il est possible de rechercher un produit particulier en tapant : module avail <premières lettres du nom du produit>.
Par exemple pour afficher les produits commençant par cud :

$ module avail cud
 
------------------------- /gpfslocalsup/pub/module-rh/modulefiles -------------------------
cuda/9.2  cuda/10.0  cuda/10.1.1  cuda/10.1.2  cudnn/9.2-v7.5.1.10  cudnn/10.1-v7.5.1.10

Vérifier quels sont les modules déjà chargés

La sous-commande list permet de vérifier quels sont les modules chargés à un moment donné dans votre environnement courant :

$ module list
Currently Loaded Modulefiles:    
 1) intel-compilers/19.0.4   4) intel-vtune/19.0.4     7) intel-itac/19.0.4  
 2) intel-mkl/19.0.4         5) intel-advisor/19.0.4   8) intel-all/19.0.4   
 3) intel-mpi/19.0.4         6) intel-tbb/19.0.4      

Si aucun module n'est chargé le message suivant apparaît :

$ module list
No Modulefiles Currently Loaded.

Chargement d'un produit

Le chargement des produits se fait avec la sous-commande load suivie par :

  • soit le nom complet du module pour sélectionner une version précise du produit :
    $ module load intel-compilers/19.0.4
  • soit le début du nom du module qui sélectionne alors la version par défaut du produit :
    $ module load intel-compilers

La commande module load ne renvoie aucune information lorsqu'elle s'exécute sans problème. Il peut donc être nécessaire d'utiliser la commande module list pour savoir quelle version a été chargée.
Par contre, une erreur peut se produire et empêcher le chargement d'un module. Des messages d'erreur sont alors retournés, par exemple :

  • si le module à charger n'existe pas :
    $ module load intel-compilers-19/19.0.4
    ERROR: Unable to locate a modulefile for 'intel-compilers-19/19.0.4'
  • si un conflit existe entre le module à charger et un des modules déjà chargés :
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.5
     
    $ module load intel-compilers/19.0.4
    Loading intel-compilers/19.0.4
      ERROR: Conflicting intel-compilers is loaded

Chargement de plusieurs produits

Il est possible de charger plusieurs produits en une seule fois :

  • En les listant sur une même ligne de commande :
    $ module load intel-compilers/19.0.4 intel-mpi/19.0.4 intel-mkl/19.0.4

    Attention : l'ordre dans lequel les modules sont indiqués peut être important !
    Ainsi, la commande suivante ne donne pas le résultat escompté puisque les modules intel-compilers/18.0.5 et intel-mpi/18.0.5 ne sont finalement pas utilisés :

    $ module load netcdf intel-compilers/18.0.5 intel-mpi/18.0.5
    Loading netcdf/4.7.2-mpi
      Loading requirement: intel-compilers/19.0.4 intel-mpi/19.0.4
     
    Loading intel-compilers/18.0.5
      ERROR: Conflicting intel-compilers is loaded
     
    Loading intel-mpi/18.0.5
      ERROR: Conflicting intel-mpi is loaded
     
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.4   2) intel-mpi/19.0.4   3) netcdf/4.7.2-mpi

    Dans ce cas, il faut charger intel-compilers/18.0.5 et intel-mpi/18.0.5 avant netcdf pour avoir le résultat attendu :

    $ module load intel-compilers/18.0.5 intel-mpi/18.0.5 netcdf
     
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/18.0.5   2) intel-mpi/18.0.5   3) netcdf/4.7.2-mpi
  • Certains modules sont des raccourcis permettant de charger plusieurs modules en une seule opération. C'est le cas des modules nommés intel-all/XX.Y.Z, qui vont charger plusieurs modules définissant un environnement Intel complet pour une version XX.Y.Z choisie.
    Par exemple avec Intel 19.0.4 :
    $ module load intel-all/19.0.4
    Loading intel-all/19.0.4
      Loading requirement: intel-compilers/19.0.4 intel-mkl/19.0.4 intel-mpi/19.0.4
        intel-vtune/19.0.4 intel-advisor/19.0.4 intel-tbb/19.0.4 intel-itac/19.0.4
     
    $ module list
    Currently Loaded Modulefiles:
     1) intel-compilers/19.0.4   4) intel-vtune/19.0.4     7) intel-itac/19.0.4  
     2) intel-mkl/19.0.4         5) intel-advisor/19.0.4   8) intel-all/19.0.4   
     3) intel-mpi/19.0.4         6) intel-tbb/19.0.4

Déchargement d'un produit

Vous pouvez retirer un produit de votre environnement en utilisant la sous-commande unload; vous pouvez aussi supprimer tous les modules avec la sous-commande purge :

$ module list
Currently Loaded Modulefiles:
 1) intel-compilers/19.0.4   2) intel-mpi/19.0.4   3) intel-mkl/19.0.4
 
$ module unload intel-mkl/19.0.4
$ module list
Currently Loaded Modulefiles:
 1) intel-compilers/19.0.4   2) intel-mpi/19.0.4
 
$ module purge
$ module list
No Modulefiles Currently Loaded.

S'il s'effectue sans problème, le déchargement d'un produit ne renvoie aucune information.

Changement de version d'un produit

Lorsque vous souhaitez changer la version d'un produit déjà chargé, vous pouvez utiliser la sous-commande switch :

$ module list
Currently Loaded Modulefiles:
 1) intel-compilers/19.0.4   2) intel-mpi/18.0.5
$ module switch intel-mpi/19.0.4
$ module list
Currently Loaded Modulefiles:
 1) intel-compilers/19.0.4   2) intel-mpi/19.0.4

Là encore, si tout se passe bien la commande ne renvoie aucun message.

Mise en garde pour l’édition de liens

Lors de la compilation de vos codes, même après avoir chargé le module adéquat pour utiliser une bibliothèque, il sera sans doute nécessaire de spécifier les librairies à utiliser lors de l'édition de liens.
Par exemple, pour compiler avec la bibliothèque mathématique HYPRE :

$ module load hypre
$ ifort -o test -lHYPRE test.f90

Notez que, par contre, les chemins vers les fichiers headers, les modules Fortran, les librairies statiques (.a) et dynamiques (.so) sont positionnés automatiquement, sans qu'il soit nécessaire de les préciser.

Pour tous ces points, en cas de problème, contactez le Support de l'Assistance.

Retour au sommaire


10. Compilation

Jean Zay : Appel du système de compilation Fortran et C/C++ (Intel)

Les différentes versions du compilateur Intel disponibles sur Jean Zay sont activables au moyen de la commande module.

Exemple de chargement :

$ module avail intel-compilers
--------------------------------- /gpfslocalsup/pub/module-rh/modulefiles  ------------------------------------
intel-compilers/16.0.4 intel-compilers/18.0.1 intel-compilers/18.0.5 intel-compilers/19.0.2 intel-compilers/19.0.4
 
$ module load intel-compilers/19.0.4

Exemples de génération d'exécutables :

$ ifort prog.f90 -o prog
 
$ icc prog.c -o prog
 
$ icpc prog.C -o prog

Jean Zay : compilation d'un code parallèle MPI en Fortran, C/C++

L'environnement MPI à utiliser sur Jean Zay est l'environnement Intel.

Les différentes versions de l'environnement MPI Intel disponibles sur Jean Zay sont activables au moyen de la commande “module”. Il faut penser à activer également les compilateurs Intel avant de lancer la compilation.

Exemple de chargement :

$ module avail intel-mpi
------------------------- /gpfslocalsup/pub/module-rh/modulefiles  -------------------------
intel-mpi/16.0.4 intel-mpi/18.0.1 intel-mpi/18.0.5 intel-mpi/19.0.2 intel-mpi/19.0.4
 
$ module load intel-compilers/19.0.4 intel-mpi/19.0.4

Compilation :

La compilation et l'édition de liens d'un programme MPI se fait en utilisant les scripts mpiifort pour un code Fortran, mpiicc pour un code C ou encore mpiicpc pour un code C++ :

$ mpiifort source.f90
 
$ mpiicc source.c
 
$ mpiicpc source.C

les commandes de compilation mpiifort (respectivement mpiicc et mpiicpc) font référence au compilateur Intel ifort (respectivement icc et icpc). Elles incluent automatiquement les chemins du module fortran mpif.h et les bibliothèques nécessaires à MPI.

Remarque :

  • L'exécution d'un programme MPI peut se faire en batch.

Jean Zay : compilation d'un code parallèle OpenMP en Fortran, C/C++

La compilation d'un programme OpenMP avec les compilateurs Intel se fait en indiquant l'option -qopenmp comme indiqué dans l'exemple ci-dessous :

$ ifort -qopenmp source.f90
 
$ icc -qopenmp source.c
 
$ icpc -qopenmp source.C

Si vous faites la compilation et l'édition de liens séparément alors vous devez à nouveau spécifier l'option -qopenmp à l'édition de liens. Par exemple :

$ ifort -c -qopenmp source1.f
$ ifort -c source2.f
$ icc -c source3.c
$ ifort -qopenmp source1.o source2.o source3.o

L'exécution d'un programme OpenMP peut se faire aussi bien en batch qu'en interactif.

Jean Zay : Appel du système de compilation PGI pour C/C++ et Fortran

Les compilateurs PGI sont disponibles sur le calculateur Jean Zay. Cette page recense les informations utiles pour utiliser ces compilateurs.

Modules

L'environnement de compilation PGI est disponible en utilisant la commande module (voir documentation) :

Par exemple, si vous souhaitez utiliser la version 19.10 du compilateur PGI :

$ module avail pgi 
 
----------------------------- /gpfslocalsup/pub/module-rh/modulefiles -----------------------------
pgi/19.10  pgi/20.1  pgi/20.4
$ module load pgi/19.10
$ module list
Currently Loaded Modulefiles:
  1) pgi/19.10

Exemples de génération d'exécutables

$ pgcc prog.c -o prog
 
$ pgc++ prog.cpp -o prog
 
$ pgfortran prog.f90 -o prog

Jean Zay : Compilation d'un code OpenACC

Sur Jean Zay, les compilateurs PGI offrent la possibilité d'utiliser OpenACC.

Options de compilation pour PGI

La documentation des compilateurs est accessible sur le Web chez PGI.

Prise en compte de OpenACC

Les options de compilation pour la prise en charge d'OpenACC par le compilateur PGI sont les suivantes :

  • -acc : cette option active le support d'OpenACC. Il est possible de lui donner les sous-options suivantes :
    • [no]autopar : Active la parallélisation automatique pour la directive ACC PARALLEL. Le défaut est de l'activer.
    • [no]routineseq : Compile toutes les routines pour l'accélérateur. Le défaut est de ne pas compiler chaque routine comme séquentielle.
    • strict : Affiche des messages d'avertissement en cas d'utilisation de directives non OpenACC pour l'accélérateur.
    • verystrict : Arrête la compilation en cas d'utilisation de directives non OpenACC pour l'accélérateur.
    • sync : Ignore les clauses async.
    • [no]wait : Attend la fin de chaque noyau de calcul sur l'accélérateur. Le lancement de noyaux est bloqué par défaut, sauf si async est utilisé.
    • Exemple :
      $ pgfortran -acc=noautopar,sync -o prog_ACC prog_ACC.f90
  • -ta : Cette option active le déport de calcul sur l'accélérateur. Elle implique l'option -acc.
    • Elle est utile pour choisir l'architecture cible pour laquelle le code va être compilé.
    • Pour utiliser les GPU V100 de Jean Zay, il faut utiliser la sous-option tesla de -ta et la compute capability cc70. Par exemple :
      $ pgfortran -ta=tesla:cc70 -o prog_gpu prog_gpu.f90
    • Quelques exemples utiles de sous-options de tesla :
      • managed : Permet de créer une vue partagée de la mémoire des GPU et des CPU.
      • pinned : Active l'épinglage de la mémoire sur le CPU. Cela peut améliorer les performances des transferts de données.
      • autocompare : Active la comparaison des résultats sur CPU et GPU.

Les autres options sont disponibles dans la documentation Web PGI.

Jean Zay : MPI CUDA-aware et GPUDirect

Pour une performance optimale, des bibliothèques OpenMPI CUDA-aware supportant le GPUDirect sont disponibles sur Jean Zay.

Ces bibliothèques MPI permettent d'effectuer des communications utilisant des buffers d'envoi et de réception alloués sur la mémoire du GPU. Grâce au support de GPUDirect, ces transferts se font directement de GPU à GPU sans recopie intermédiaire sur la mémoire du CPU, lorsque c'est possible.

Compilation du code

Il est nécessaire de compiler le code en utilisant l'une des bibliothèques OpenMPI CUDA-aware disponibles sur Jean Zay.

Après avoir chargé le compilateur que vous souhaitez utiliser, vous devez charger l'un des modules suivants :

$ module avail openmpi/*-cuda
------------------------ /gpfslocalsup/pub/modules-idris-env4/modulefiles/linux-rhel8-skylake_avx512 ------------------------
openmpi/3.1.4-cuda  openmpi/3.1.6-cuda  openmpi/4.0.1-cuda  openmpi/4.0.2-cuda  openmpi/4.0.4-cuda
 
$ module load openmpi/4.0.4-cuda

Si OpenMPI n'est pas disponible pour le compilateur désiré, un message d'erreur sera affiché. N'hésitez pas à contacter l'assistance pour demander une nouvelle installation si nécessaire.

Pour connaître la liste des compilateurs pour lesquels une version donnée d'OpenMPI est disponible, vous pouvez utiliser la commande module show openmpi/<version>. Par exemple :

$ module show openmpi/4.0.2-cuda
------------------------------------------------------------------
/gpfslocalsup/pub/modules-idris-env4/modulefiles/linux-rhel8-skylake_avx512/openmpi/4.0.2-cuda:
 
module-whatis   {An open source Message Passing Interface implementation.}
prereq          intel-compilers/19.0.4 pgi/20.1 pgi/19.10 gcc/10.1.0 gcc/8.3.1
conflict        openmpi
conflict        intel-mpi
 
Available software environment(s):
- intel-compilers/19.0.4
- pgi/20.1
- pgi/19.10
- gcc/10.1.0
- gcc/8.3.1
 
If you want to use this module with another software environment,
please contact the support team.
-------------------------------------------------------------------

La compilation se fait en utilisant les wrappers d'OpenMPI :

$ mpifort source.f90
 
$ mpicc source.c
 
$ mpic++ source.C

Aucune option particulière n'est nécessaire pour la compilation, vous pouvez vous référer à la rubrique Compilation GPU de l'index pour plus d'information sur la compilation des codes utilisant les GPU.

Adaptation du code

L'utilisation de la fonctionnalité MPI CUDA-aware GPUDirect sur Jean Zay impose de respecter un ordre d'initialisation bien précis pour CUDA ou OpenACC et MPI dans le code :

  1. initialisation de CUDA ou OpenACC
  2. choix du GPU que chaque processus MPI doit utiliser (étape de binding)
  3. initialisation de MPI.

Attention : des plantages aléatoires peuvent survenir si cette contrainte sur l'initialisation n'est pas respectée.

Une légère adaptation de votre code peut donc être nécessaire pour pouvoir profiter de cette fonctionnalité sur Jean Zay.

Exécution du code

Lors de l'exécution, vous devez vous assurez de charger avec la commande module la même bibliothèque MPI que celle qui a été utilisée pour la compilation du code, puis de bien utiliser la commande srun pour démarrer celui-ci.

Le support de CUDA-aware et GPUDirect est alors activé par défaut sans opération supplémentaire.

Retour au sommaire


11. Exécution

Jean Zay : commande de contrôle des travaux

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

  • Pour soumettre un script de soumission :

     $ sbatch script.slurm 
  • Pour suivre ses jobs en attente ou en cours d'exécution :

     $ squeue -u $USER 

    Cette commande affiche l'information sous la forme suivante :

    JOBID  PARTITION  NAME  USER  ST   TIME  NODES  NODELIST(REASON)   
      235  part_name  test   abc   R  00:02      1  r6i3n1 


    JOBID : l'identifiant du job
    PARTITION : la partition utilisée
    NAME : le nom du job
    USER : le nom d'utilisateur du propriétaire du job
    ST : l'état d'exécution du job ( R=running, PD=pending, CG=completing )
    TIME : le temps Elapsed
    NODES : le nombre de nœuds utilisés
    NODELIST : la liste de des nœuds utilisés.

    Note : vous pouvez utiliser l'option --start pour que Slurm affiche une estimation de l'heure de démarrage de vos travaux (colonne “START_TIME”). Il est possible que Slurm ne soit pas encore en mesure d'avoir une estimation suffisamment fiable sur le démarrage de certains travaux, dans ce cas l'information apparaîtra comme non disponible (“N/A”). Comme la liste des travaux en attente est évolutive, il est important de garder à l'esprit que l'information donnée par Slurm n'est qu'une estimation qui est susceptible de changer en fonction de la charge de la machine.

  • Pour obtenir des informations complètes sur un job (ressources allouées et état d'exécution) :

     $ scontrol show job $JOBID 
  • Pour annuler une exécution :

     $ scancel $JOBID 

Remarques

  • Un tableau exhaustif des commandes Slurm est proposé ici.
  • En cas d'incident matériel sur la machine, la configuration par défaut de SLURM fait que les jobs en cours sont automatiquement redémarrés depuis le début. Si vous voulez éviter ce comportement, il vous faut utiliser l'option --no-requeue lors de la soumission, c'est-à-dire soumettre votre job en faisant

     $ sbatch --no-requeue script.slurm 

    ou ajouter la ligne

     $SBATCH --no-requeue 

    dans votre script de soumission.

Jean Zay : exécution de travaux multi-étapes et en cascade

Utilisation de la notion d'étape avec Slurm

Certains utilisateurs ont développé des chaînes de traitement complexes (flux de données), qui consistent à enchaîner des travaux dont les caractéristiques peuvent être différentes (nombre de cœurs, temps de calcul et mémoire nécessaires). Les fichiers de sortie d'un travail sont souvent utilisés comme fichiers d'entrée du travail suivant, ce qui ajoute des relations d'interdépendance entre les travaux. Slurm permet de gérer cette problématique d'une façon simple et efficace : chaque étape est définie dans un fichier à exécuter auquel sont associées des ressources propres (nombre de cœurs, mémoire, temps). Un travail multi-étapes consistera à définir autant d'étapes que de travaux à exécuter, ainsi que les relations d'interdépendance entre ces étapes : de cette façon, à chaque étape, les ressources réservées correspondent exactement aux ressources utilisées.

Enchaînement des travaux

Pour soumettre un job multi-étape sur Jean Zay, il faut :

  • Créer un script bash qui soumet plusieurs travaux Slurm (un job par étape) : à la soumission de chacune des étapes du calcul, on récupère le JOB_ID correspondant pour le transmettre lors de la soumission de l'étape suivante : le JOB_ID du travail est le quatrième champ dans le retour de la commande sbatch (commande cut).
    Dans l'exemple suivant, quatre étapes sont soumises, chaque étape (sauf la première) dépend de l'étape précédente et ne s’exécutera que si celle-ci s'est bien terminée (--dependency=afterok).

    multi_steps.bash
    #!/bin/bash
    JID_JOB1=`sbatch  job1.slurm | cut -d " " -f 4`
    JID_JOB2=`sbatch  --dependency=afterok:$JID_JOB1 job2.slurm | cut -d " " -f 4`
    JID_JOB3=`sbatch  --dependency=afterok:$JID_JOB2 job3.slurm | cut -d " " -f 4`
    sbatch  --dependency=afterok:$JID_JOB3 job4.slurm

    Attention : ce script n'est pas un travail Slurm, c'est un script bash à lancer de la façon suivante :

    $ chmod +x multi_steps.bash
    $ ./multi_steps.bash


  • Écrire toutes les étapes (jobN.slurm) comme étant des travaux indépendants : chaque étape soumise via la commande sbatch est un travail Slurm classique, comme ceux décrits dans la documentation disponible dans les rubriques Exécution/Contrôle d'un code CPU ou Exécution/Contrôle d'un code GPU. De cette façon, vous pouvez spécifier indépendamment la partition, la QoS, le temps CPU et le nombre de nœuds nécessaires pour chaque étape.

Attention :

  • S'agissant de travaux indépendants, la variable $JOBSCRATCH sera valorisée différemment dans chaque étape. Les fichiers devant être partagés entre deux étapes ne devront donc pas être enregistrés dans cet espace JOBSCRATCH mais dans le répertoire semi-temporaire SCRATCH, ou encore un répertoire permanent comme le WORK, mais avec une moins bonne bande passante : voir toutes les caractéristiques des Espaces Disques.
  • En cas d'échec d'un des travaux de l'enchaînement, les travaux suivants restent par défaut en attente avec la raison “DependencyNeverSatisfied” mais ne pourront jamais s'exécuter. Vous devez alors les supprimer en utilisant la commande scancel. Si vous souhaitez que ces travaux soient automatiquement annulés en cas d'échec, vous devez préciser l'option –kill-on-invalid-dep=yes lors de leur soumission.

Jean Zay : Collection de travaux similaires (Job Array)

Principe

Les Jobs Arrays offrent la possibilité à un utilisateur de soumettre en une seule fois une collection de travaux similaires.

Attention : à l'IDRIS, les Jobs Arrays ne sont admis que pour des travaux soumis via la commande sbatch car ils peuvent générer un très grand nombre de travaux.

Ils se distinguent par l'utilisation de la directive SLURM #SBATCH --array permettant de spécifier les indices, ou un rang d'indices, pour les travaux de la collection comme indiqué ci-dessous :

  • Pour une collection de travaux dont les indices vont successivement de 0 à NB_JOBS (i.e. 0, 1, 2, … , NB_JOBS) :
    #SBATCH --array=0-NB_JOBS
  • Pour une collection de travaux dont les indices varient de 0 à, au plus, NB_JOBS par pas de STEP_SIZE (i.e. 0, STEP_SIZE, 2*STEP_SIZE, etc…) :
    #SBATCH --array=0-NB_JOBS:STEP_SIZE
  • Pour une collection de N travaux ayant les indices prédéfinis J_1, J_2, … , J_N :
    #SBATCH --array=J_1,J_2,...,J_N

Remarque : afin de ne pas saturer la file d'attente des travaux SLURM, le nombre maximal de travaux exécutés simultanément à partir d'un Job Array peut être spécifié à l'aide du séparateur % :

  • Pour exécuter tous les travaux d'une collection par séries de NB_MAX_RUNNING_JOBS travaux, utilisez la syntaxe suivante :
    #SBATCH --array=0-NB_JOBS%NB_MAX_RUNNING_JOBS

Variables propres aux Job Arrays

Lors de l'utilisation des Job Arrays, certaines variables d'environnement SLURM peuvent être utilisées dans le script shell afin de personnaliser les divers travaux d'une même collection. Par exemple, pour que chaque travail de la collection utilise des répertoires d'entrées et/ou de sorties différents. Les variables d’environnement suivantes sont ainsi automatiquement valorisées par SLURM :

  • SLURM_JOB_ID : l'identifiant du job
  • SLURM_ARRAY_JOB_ID : aussi l'identifiant du job
  • SLURM_ARRAY_TASK_ID : l'indice propre à chaque travail de la collection (peut être vue comme un compteur des travaux)
  • SLURM_ARRAY_TASK_COUNT : le nombre total de travaux de la collection qui seront exécutés.
  • SLURM_ARRAY_TASK_MIN : le plus petit indice de tous les travaux de la collection
  • SLURM_ARRAY_TASK_MAX : le plus grand indice de tous les travaux de la collection

De plus, avec les Job Arrays, deux options supplémentaires sont disponibles pour spécifier les noms des fichiers d'entrée et de sortie de chaque travail dans les directives #SBATCH --output=... et #SBATCH --error=... :

  • %A qui est automatiquement substituée par la valeur de SLURM_ARRAY_JOB_ID
  • %a qui est automatiquement substituée par la valeur de SLURM_ARRAY_TASK_ID.

Remarques :

  • Par défaut, le format du nom de fichier de sortie pour un Job Array est slurm-%A_%a.out.
  • En Bash, les variables propres aux Job Arrays peuvent être récupérées de la manière suivante :
    echo ${SLURM_JOB_ID}
    echo ${SLURM_ARRAY_JOB_ID}
    echo ${SLURM_ARRAY_TASK_ID}
    echo ${SLURM_ARRAY_TASK_COUNT}
    echo ${SLURM_ARRAY_TASK_MIN}
    echo ${SLURM_ARRAY_TASK_MAX}
  • Pour les scripts Python, les variables propres aux Job Arrays peuvent être récupérées de la manière suivante :
    import os
    slurm_job_id=int(os.environ["SLURM_JOB_ID"])
    slurm_array_job_id=int(os.environ["SLURM_ARRAY_JOB_ID"])
    slurm_array_task_id=int(os.environ["SLURM_ARRAY_TASK_ID"])
    slurm_array_task_count=int(os.environ["SLURM_ARRAY_TASK_COUNT"])
    slurm_array_task_min=int(os.environ["SLURM_ARRAY_TASK_MIN"])
    slurm_array_task_max=int(os.environ["SLURM_ARRAY_TASK_MAX"])

Exemples d’utilisation

  • Remarque préliminaire : les exemples ci-dessous concernent des exécutions sur la partition CPU. Le principe reste le même pour des exécutions sur les partitions GPU.
  • Exemple de script de soumission pour 20 travaux identiques avec un maximum de 5 travaux placés dans la file (exécution par séries de 5 travaux) :
    job_array_20.slurm
    #!/bin/bash
    #SBATCH --job-name=job-array   # nom du job
    #SBATCH --ntasks=1             # Nombre total de processus MPI
    #SBATCH --ntasks-per-node=1    # Nombre de processus MPI par noeud
    # Dans le vocabulaire Slurm "multithread" fait référence à l'hyperthreading.
    #SBATCH --hint=nomultithread   # 1 processus MPI par coeur physique (pas d'hyperthreading)
    #SBATCH --time=00:01:00        # Temps d’exécution maximum demande (HH:MM:SS)
    #SBATCH --output=%x_%A_%a.out  # Nom du fichier de sortie contenant l'ID et l'indice
    #SBATCH --error=%x_%A_%a.out   # Nom du fichier d'erreur (ici commun avec la sortie)
    #SBATCH --array=0-19%5         # 20 travaux en tout mais 5 travaux max dans la file
     
    # on se place dans le répertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancées
    set -x
     
    # Execution du binaire "mon_exe" avec des donnees differentes pour chaque travail
    # La valeur de ${SLURM_ARRAY_TASK_ID} est differente pour chaque travail.
    srun ./mon_exe < fichier${SLURM_ARRAY_TASK_ID}.in > fichier${SLURM_ARRAY_TASK_ID}.out
  • Exemple de script de soumission pour 3 travaux identiques, ayant respectivement les indices 1, 3 et 8 :
    job_array_3.slurm
    #!/bin/bash
    #SBATCH --job-name=job-array   # nom du job
    #SBATCH --ntasks=1             # Nombre total de processus MPI
    #SBATCH --ntasks-per-node=1    # Nombre de processus MPI par noeud
    # Dans le vocabulaire Slurm "multithread" fait référence à l'hyperthreading.
    #SBATCH --hint=nomultithread   # 1 processus MPI par coeur physique (pas d'hyperthreading)
    #SBATCH --time=00:01:00        # Temps d’exécution maximum demande (HH:MM:SS)
    #SBATCH --output=%x_%A_%a.out  # Nom du fichier de sortie contenant l'ID et l'indice
    #SBATCH --error=%x_%A_%a.out   # Nom du fichier d'erreur (ici commun avec la sortie)
    #SBATCH --array=1,3,8          # 3 travaux en tout ayant les indices 1, 3 et 8
     
    # on se place dans le répertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancées
    set -x
     
    # Execution du binaire "mon_exe" avec des donnees differentes pour chaque travail
    # La valeur de ${SLURM_ARRAY_TASK_ID} est differente pour chaque travail.
    srun ./mon_exe < fichier${SLURM_ARRAY_TASK_ID}.in > fichier${SLURM_ARRAY_TASK_ID}.out
  • Exemple de script de soumission pour 6 travaux identiques, ayant des indices compris entre 0 et 11 par pas de 2 :
    job_array_0-11.slurm
    #!/bin/bash
    #SBATCH --job-name=job-array   # nom du job
    #SBATCH --ntasks=1             # Nombre total de processus MPI
    #SBATCH --ntasks-per-node=1    # Nombre de processus MPI par noeud
    # Dans le vocabulaire Slurm "multithread" fait référence à l'hyperthreading.
    #SBATCH --hint=nomultithread   # 1 processus MPI par coeur physique (pas d'hyperthreading)
    #SBATCH --time=00:01:00        # Temps d’exécution maximum demande (HH:MM:SS)
    #SBATCH --output=%x_%A_%a.out  # Nom du fichier de sortie contenant l'ID et l'indice
    #SBATCH --error=%x_%A_%a.out   # Nom du fichier d'erreur (ici commun avec la sortie)
    #SBATCH --array=0-11:2         # 6 travaux ayant les indices 0, 2, 4, 6, 8, et 10
     
    # on se place dans le répertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancées
    set -x
     
    # Execution du binaire "mon_exe" avec des donnees differentes pour chaque travail
    # La valeur de ${SLURM_ARRAY_TASK_ID} est differente pour chaque travail.
    srun ./mon_exe < fichier${SLURM_ARRAY_TASK_ID}.in > fichier${SLURM_ARRAY_TASK_ID}.out

Commande de contrôle des travaux

Un travail de type Job Array doit être exécuté via la commande sbatch en raison du grand nombre de travaux qu'il peut générer :

$ sbatch job_array.slurm

Le suivi de ces jobs s'effectue avec la commande squeue qui retourne alors une information adaptée. Par exemple, pour un Job Array comportant 7 travaux exécutés par séries de 2 travaux sur la partition cpu_p1 :

  • Le premier appel à squeue retourne :
    $ squeue -J 305813
                 JOBID PARTITION      NAME     USER ST       TIME  NODES NODELIST(REASON)
        305813_[2-6%2]    cpu_p1 job-array  mylogin PD       0:00      1 (JobArrayTaskLimit)
              305813_0    cpu_p1 job-array  mylogin  R       0:00      1 r7i1n0
              305813_1    cpu_p1 job-array  mylogin  R       0:00      1 r8i6n3

    Ici, on constate que les 2 premiers travaux sont en cours d'exécution et les 5 autres en attente.

  • Lorsque les 2 premiers travaux sont finis, un second appel à squeue retourne :
    $ squeue -J 305813
                 JOBID PARTITION      NAME     USER ST       TIME  NODES NODELIST(REASON)
        305813_[4-6%2]    cpu_p1 job-array  mylogin PD       0:00      1 (JobArrayTaskLimit)
              305813_2    cpu_p1 job-array  mylogin  R       0:05      1 r7i1n0
              305813_3    cpu_p1 job-array  mylogin  R       0:05      1 r8i6n3

    Maintenant, on constate que ce sont les 2 travaux suivants qui s'exécutent et qu'il n'en reste plus que 3 en attente. Notez qu'il n'y a plus aucune trace des 2 premiers travaux terminés.

Pour supprimer un Job Array, vous devez utiliser la commande scancel. Mais il y a alors plusieurs façons de procéder :

  • Pour annuler l'ensemble de la collection, indiquez son identifiant ${SLURM_JOB_ID}. Avec l'exemple ci-dessus, cela donne :
    $ scancel 305813
  • Pour annuler l'exécution d'un travail en particulier, indiquez l'identifiant de la collection ${SLURM_ARRAY_JOB_ID} et l'indice du travail ${SLURM_ARRAY_TASK_ID}. Avec l'exemple ci-dessus, cela donne :
    $ scancel 305813_2
  • Pour annuler l'exécution d'une série de travaux, indiquez l'identifiant de la collection ${SLURM_ARRAY_JOB_ID} et un intervalle d'indices (ici de 4 à 6). Avec l'exemple ci-dessus, cela donne :
    $ scancel 305813_[4-6]

Documentation

Connexion SSH à un nœud de calcul

Vous pouvez vous connecter en SSH aux nœuds de calcul qui ont été affectés à l'un de vos travaux afin de surveiller l'exécution de vos calculs avec des outils comme top, htop ou nvidia-smi par exemple.

Lorsque l'un de vos travaux est en cours d'exécution, les nœuds de calcul qui lui ont été attribués sont visibles avec la commande squeue -j <numero_du_travail> ou squeue -u $USER :

$ squeue -u $USER
     JOBID  PARTITION         NAME       USER  ST     TIME  NODES  NODELIST(REASON)
   2042259     cpu_p1  mon_travail  mon_login   R    01:42     10  nœud[1337-1346]

Dans cet exemple, le job n° 2042259 tourne sur 10 nœuds de calcul nommés respectivement nœud1337, nœud1338, …, nœud1345 et nœud1346. Vous pouvez alors vous connecter via ssh à l'un des nœuds de cette liste (par exemple nœud1337) avec la commande suivante :

$ ssh nœud1337

Notez que vous serez automatiquement déconnecté du nœud lorsque votre travail se terminera.

Si vous essayez de vous connecter à un nœud sur lequel aucun de vos travaux n'est en cours d'exécution, vous obtiendrez l'erreur suivante :

Access denied by pam_slurm_adopt: you have no active jobs on this node

Jean Zay : partitions Slurm CPU

Les partitions disponibles

Tous les projets DARI ou Accès Dynamique (AD) ayant des heures CPU ont à leur disposition des partitions Slurm définies sur Jean Zay :

  • La partition cpu_p1 est automatiquement utilisée si aucune partition n'est précisée, pour tous les travaux demandant des heures CPU. Par défaut, le temps d'exécution est de 10 minutes et il ne peut pas dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. ci-dessous).
  • La partition prepost permet de lancer un travail sur l'un des nœuds pré/post-traitement de Jean Zay jean-zay-pp, sur lesquels les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. ci-dessous).
  • La partition visu permet de lancer un travail sur l'un des nœuds de visualisation de Jean Zay jean-zay-visu, sur lesquels les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 1 heure (soit --time=HH:MM:SS ≤ 4:00:00 ci-dessous).
  • La partition archive est dédiée aux commandes permettant de gérer les données (copies ou déplacements de fichiers, création d'archives) : les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. ci-dessous).

Attention aux limites de temps par défaut des partitions, qui sont délibérément basses. Pour des exécutions longues, vous devez spécifier une limite de temps d'exécution, qui doit rester inférieure au maximum autorisé pour la partition et la QoS utilisées. Vous devez alors utiliser :

  • soit la directive Slurm #SBATCH --time=HH:MM:SS dans votre job,
  • soit l'option --time=HH:MM:SS des commandes sbatch, salloc ou srun.

La partition cpu_p1 étant la partition utilisée par défaut, elle n'a pas besoin d'être demandée. Par contre, toutes les autres doivent être spécifiées explicitement pour être utilisées. Par exemple, pour la partition prepost, vous pouvez utiliser :

  • soit la directive Slurm #SBATCH --partition=prepost dans votre job,
  • soit l'option --partition=prepost des commandes sbatch, salloc ou srun.

Attention : depuis le 11 octobre 2019, tout travail demandant plus d'un nœud tourne en mode exclusif : les nœuds ne sont pas partagés. L'utilisation d'une partie d'un nœud entraine alors la comptabilité de la totalité du nœud. Par exemple, la réservation de 41 cœurs (soient 1 nœud + 1 cœur) entraine la facturation des 80 cœurs (soient 2 nœuds). Par contre, la totalité de la mémoire des nœuds réservés est disponible (de l'ordre de 160 Go utiles par nœud).

Les QoS disponibles

Pour chaque job soumis dans une partition, vous pouvez spécifier une QoS (Quality of Service) qui va déterminer les limites et la priorité de votre job :

  • la QoS par défaut pour tous les travaux CPU : qos_cpu-t3
    • durée max : 20h00 de temps Elapsed,
    • 512 nœuds maximum par travail.
  • une QoS pour des exécutions mono-nœud plus longues et qui doit être spécifiée pour être utilisée (c.f. ci-dessous) : qos_cpu-t4
    • durée max : 100h00 de temps Elapsed,
    • 1 nœud maximum par travail,
    • 32 nœuds maximum par utilisateur,
    • 128 nœuds maximum pour l'ensemble des travaux demandant cette QoS.
  • une QoS pour des exécutions plus brèves et qui doit être spécifiée pour être utilisée (c.f. ci-dessous) : qos_cpu-dev
    • durée max : 2h00 de temps Elapsed,
    • 128 nœuds maximum par utilisateur,
    • 1000 nœuds maximum pour l'ensemble des travaux demandant cette QoS.

Pour spécifier une QoS différente du défaut, vous pouvez au choix :

  • utiliser la directive Slurm #SBATCH --qos=qos_cpu-dev dans votre job, par exemple,
  • ou spécifier l'option --qos=qos_cpu-dev aux commandes sbatch, salloc ou srun.
Tableau récapitulatif
QoS Limite en temps Limite en ressource
par job par utilisateur par QoS
qos_cpu-t3 (défaut) 20h 512 nœuds
qos_cpu-t4 100h 1 nœud 32 nœuds 128 nœuds
qos_cpu-dev 2h 128 nœuds 128 nœuds 1000 nœuds

Jean Zay : allocation mémoire avec Slurm sur les partitions CPU

Actuellement, les options Slurm --mem et --mem-per-cpu ne permettent pas de configurer convenablement l'allocation mémoire d'un job sur Jean Zay. Celle-ci est déterminée automatiquement à partir du nombre de CPU réservé.

Pour ajuster la quantité de mémoire allouée à votre job, il faut donc ajuster le nombre de CPU réservés par tâche (ou processus) en spécifiant l'option suivante dans vos scripts batch, ou lors d'un salloc en mode interactif :

--cpus-per-task=...     # --cpus-per-task=1 par défaut 

Remarque : par défaut, --cpus-per-task=1 et la quantité de mémoire allouée est suffisante pour la plupart des travaux lancés sur les partitions CPU. La majorité des utilisateurs n'a donc pas à modifier la valeur de cette option. Cette page s'adresse aux utilisateurs qui ont un besoin en mémoire plus important.

Sur la partition cpu_p1

Les nœuds de la partition cpu_p1 donnent accès à 160 Go de mémoire utile, pour 40 cœurs CPU. L'allocation mémoire y est déterminée automatiquement à hauteur de :

  • 4 Go par cœur CPU lorsque l'hyperthreading est désactivé (option Slurm --hint=nomultithread)

Par exemple, un job spécifiant --ntasks=1 --cpus-per-task=5 sur la partition cpu_p1 aura accès à 1 x 5 x 4 Go = 20 Go de mémoire si l'hyperthreading est désactivé (comptez la moitié sinon).

Sur la partition prepost

Les nœuds de la partition prepost donnent accès à 2,88 To de mémoire utile, pour 48 cœurs CPU. L'allocation mémoire y est déterminée automatiquement à hauteur de :

  • 60 Go par cœur CPU lorsque l'hyperthreading est désactivé (option Slurm --hint=nomultithread)

Par exemple, un job spécifiant --ntasks=1 --cpus-per-task=12 sur la partition prepost aura accès à 1 x 12 x 60 Go = 720 Go de mémoire si l'hyperthreading est désactivé (comptez la moitié sinon).

Remarques

  • Vous pouvez augmenter la valeur de --cpus-per-task tant que la demande ne dépasse pas la totalité de la mémoire disponible sur le nœud. Attention, les heures de calcul seront décomptées en proportion. Par exemple, en spécifiant les options --ntasks=10 --cpus-per-task=2, 20 cœurs CPU seront réservés et donc comptabilisés pour votre travail.
  • Si vous réservez un nœud de calcul en exclusivité, vous avez accès à la totalité de la mémoire du nœud, indépendamment de la valeur donnée à --cpus-per-task. L'équivalent d'un travail sur le nœud entier vous est alors facturé.
  • Pour les codes OpenMP : si la valeur donnée à l'option --cpus-per-task ne coïncide pas avec le nombre de threads sur lequel vous souhaitez exécuter votre code, il faut spécifier la variable d'environnement :
     export OMP_NUM_THREADS=... 
  • La quantité de mémoire allouée pour votre job est visible en lançant la commande Slurm :
    scontrol show job $JOBID    # chercher la valeur de la variable mem 

    Attention, tant que le job est en queue (PENDING), Slurm estime la mémoire allouée à un job sur la base de cœurs logiques. Si vous avez réservé des cœurs physiques (avec --hint=nomultithread), la valeur indiquée peut donc être deux fois inférieure à la valeur attendue. Celle-ci est mise à jour et devient correcte lors du lancement du job.

Jean Zay : exécution interactive d'un code CPU

Sur Jean Zay, l'accès interactif aux ressources de calcul peut se faire de plusieurs manières.

Connexion sur la frontale

L'accès à la frontale se fait par une connexion ssh :

$ ssh login@jean-zay.idris.fr

Les ressources de ce nœud interactif sont partagées entre tous les utilisateurs connectés : l'interactif sur la frontale est donc réservé uniquement pour la compilation et la mise au point des scripts.

Toute exécution interactive de vos codes doit s'effectuer sur les nœuds de calcul CPU en utilisant :

Par contre, il est nécessaire de soumettre un travail batch pour les calculs demandant des ressources CPU importantes (en nombre de cœurs, mémoire ou temps Elapsed).

Obtention d'un terminal sur un nœud de calcul CPU

Il est possible d'ouvrir un terminal directement sur un nœud de calcul sur lequel des ressources vous sont réservées (ici 4 cœurs) en utilisant la commande suivante :

$ srun --pty --ntasks=1 --cpus-per-task=4 --hint=nomultithread [--other-options] bash

Remarques :

  • L’option --pty permet d'obtenir un terminal interactif.
  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • Par défaut, la mémoire CPU allouée est proportionnelle au nombre de cœurs réservés. Par exemple, si vous demandez 1/4 des cœurs d'un nœud, vous aurez accès à 1/4 de sa mémoire. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions CPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code CPU.
  • Les réservations ont toutes des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Le terminal est opérationnel après validation de l'allocation :

$ srun --pty --ntasks=1 --cpus-per-task=4 --hint=nomultithread bash
srun: job 1365358 queued and waiting for resources
srun: job 1365358 has been allocated resources
bash-4.2$ hostname
r4i3n7

Vous pouvez vérifier que votre travail interactif a bien démarré grâce à la commande squeue, et obtenir des informations complètes sur l'état du job avec la commande scontrol show job <identifiant du travail>.

Une fois le terminal opérationnel, vous pouvez lancer vos exécutables de la manière habituelle ./votre_executable. Pour une exécution MPI, vous devez à nouveau utiliser srun : srun ./votre_executable_mpi. Attention, l'hyperthreading n'est pas utilisable via MPI dans cette configuration.

Pour quitter le mode interactif :

bash-4.2$ exit 

Attention : si vous ne quittez pas le mode interactif vous-même, la durée d'allocation maximale (par défaut ou spécifiée avec l'option --time) est appliquée et autant d'heures de calcul sont décomptées sur le projet que vous avez spécifié.

Exécution interactive sur la partition CPU

Si vous n'avez pas besoin d'ouvrir un terminal sur un nœud de calcul, il est également possible de démarrer directement depuis la frontale l'exécution interactive d'un code sur les nœuds de calcul en utilisant la commande suivante (ici avec 4 tâches) :

$ srun --ntasks=4 --hint=nomultithread [--other-options] ./mon_executable

Remarques :

  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • Par défaut, la mémoire CPU allouée est proportionnelle au nombre de cœurs réservés. Par exemple, si vous demandez 1/4 des cœurs d'un nœud, vous aurez accès à 1/4 de sa mémoire. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions CPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code CPU.
  • Les réservations ont toutes des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Réservation de ressources réutilisables pour plusieurs exécutions interactives

Chaque exécution interactive démarrée comme décrit dans la section précédente correspond à un travail différent. Comme tous les travaux, ils sont susceptibles d'être placés en attente pendant un temps plus ou moins long si les ressources de calcul ne sont pas disponibles.

Si vous souhaitez enchaîner plusieurs exécutions interactives, il peut être pertinent de préalablement réserver des ressources qui pourront être réutilisées pour plusieurs exécutions. Vous devrez alors attendre que les ressources soient disponibles une seule fois au moment de la réservation et non pour chaque exécution.

La réservation des ressources (ici pour 4 tâches) se fait via la commande suivante :

$ salloc --ntasks=4 --hint=nomultithread [--other-options]

Remarques :

  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • Par défaut, la mémoire CPU allouée est proportionnelle au nombre de cœurs réservés. Par exemple, si vous demandez 1/4 des cœurs d'un nœud, vous aurez accès à 1/4 de sa mémoire. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions CPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code CPU.
  • Les réservations ont toutes des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

La réservation devient utilisable après validation de l'allocation :

salloc: Pending job allocation 1367065
salloc: job 1367065 queued and waiting for resources
salloc: job 1367065 has been allocated resources
salloc: Granted job allocation 1367065

Vous pouvez vérifier que votre réservation est bien active grâce à la commande squeue, et obtenir des informations complètes sur l'état du job avec la commande scontrol show job <identifiant du travail>.

Vous pouvez alors démarrer des exécutions interactives en utilisant la commande srun :

$ srun [--other-options] ./code

Remarque : Si vous ne précisez aucune option pour la commande srun, les options utilisées pour le salloc (par exemple le nombre de tâches) seront utilisées par défaut.

Attention :

  • Après avoir réservé des ressources avec salloc, vous êtes toujours connecté sur la frontale (vous pouvez le vérifier en utilisant la commande hostname). Il est impératif d'utiliser la commande srun pour que vos exécutions utilisent les ressources réservées.
  • Si vous oubliez de libérer la réservation, la durée d'allocation maximale (par défaut ou spécifiée avec l'option --time) est appliquée et autant d'heures de calcul sont décomptées sur le projet que vous avez spécifié. Il est donc nécessaire de le faire explicitement :
$ exit
exit
salloc: Relinquishing job allocation 1367065 

Jean Zay : exécution d'un travail séquentiel en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm . Ils sont répartis dans des “classes” principalement en fonction du temps Elapsed, du nombre de cœurs et de la mémoire demandés.

Pour soumettre un travail séquentiel en batch sur Jean Zay, il faut :

  • Créer un script de soumission :

    seq.slurm
    #!/bin/bash
    #SBATCH --job-name=Seq              # nom du job
    #SBATCH --nodes=1                   # nombre de noeuds
    #SBATCH --ntasks-per-node=1         # nombre de taches MPI par noeud
    #SBATCH --time=00:01:00             # temps d execution maximum demande (HH:MM:SS)
    #SBATCH --output=Seq%j.out          # nom du fichier de sortie
    #SBATCH --error=Seq%j.out           # nom du fichier d'erreur (ici en commun avec la sortie)
     
    # on se place dans le repertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancees
    set -x
     
    # execution
    ./a.out
  • Soumettre ce script via la commande sbatch :

    $ sbatch seq.slurm

Remarques

  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable a.out se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch : la variable $SLURM_SUBMIT_DIR est automatiquement valorisée par Slurm.
  • Le fichier de sortie du calcul Seq_numero_job.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : exécution d'un code parallèle OpenMP en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail OpenMP en batch sur Jean Zay, il faut :

  • Créer un script de soumission :

    openmp.slurm
    #!/bin/bash
    #SBATCH --job-name=omp              # nom du job
    #SBATCH --ntasks=1                  # nombre de tâche (un unique processus ici)
    #SBATCH --cpus-per-task=20          # nombre de threads OpenMP
    # /!\ Attention, la ligne suivante est trompeuse mais dans le vocabulaire
    # de Slurm "multithread" fait bien référence à l'hyperthreading.
    #SBATCH --hint=nomultithread        # on réserve des coeurs physiques et non logiques
    #SBATCH --time=00:01:00             # temps d'exécution maximum demande (HH:MM:SS)
    #SBATCH --output=omp%j.out          # nom du fichier de sortie
    #SBATCH --error=omp%j.out           # nom du fichier d'erreur (ici commun avec la sortie)
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancées
    set -x
     
    # nombre de threads OpenMP
    export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK 
     
    # Binding
    export OMP_PLACES=cores
     
    # exécution du code
    ./executable_omp
  • Soumettre ce script via la commande sbatch :

    $ sbatch openmp.slurm

Remarques :

  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable executable_omp se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch.
  • Le fichier de sortie du calcul omp<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : exécution d'un code parallèle MPI en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail MPI en batch sur Jean Zay, il faut :

  • Créer un script de soumission : voici un exemple, enregistré dans le fichier intel_mpi.slurm :
    intel_mpi.slurm
    #!/bin/bash
    #SBATCH --job-name=TravailMPI      # nom du job
    #SBATCH --ntasks=80                # Nombre total de processus MPI
    #SBATCH --ntasks-per-node=40       # Nombre de processus MPI par noeud
    # /!\ Attention, la ligne suivante est trompeuse mais dans le vocabulaire
    # de Slurm "multithread" fait bien référence à l'hyperthreading.
    #SBATCH --hint=nomultithread       # 1 processus MPI par coeur physique (pas d'hyperthreading)
    #SBATCH --time=00:10:00            # Temps d’exécution maximum demande (HH:MM:SS)
    #SBATCH --output=TravailMPI%j.out  # Nom du fichier de sortie
    #SBATCH --error=TravailMPI%j.out   # Nom du fichier d'erreur (ici commun avec la sortie)
     
    # on se place dans le répertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load intel-all/19.0.4
     
    # echo des commandes lancées
    set -x
     
    # exécution du code
    srun ./exec_mpi
  • Soumettre ce script via la commande sbatch :
    $ sbatch intel_mpi.slurm

Attention : La configuration actuelle de la machine ne permet pas d'utiliser l'hyperthreading (exécution de 80 processus mpi sur les 40 cœurs d'un nœud de calcul) avec un code purement mpi.

Remarques :

  • Nous vous recommandons de compiler et d'exécuter vos codes sous le même environnement Intel : utilisez exactement la même commande module load intel… à l'exécution qu'à la compilation.
  • Dans cet exemple, on suppose que l'exécutable exec_mpi se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch : la variable SLURM_SUBMIT_DIR est automatiquement valorisée par Slurm.
  • Le fichier de sortie du calcul TravailMPI_numero_job.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis.
  • Pour éviter les erreurs de distribution automatique de tâches, nous vous recommandons d'utiliser srun pour exécuter votre code au lieu de mpirun, ce qui permet de garantir une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission Slurm.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : exécution d'un travail mixte MPI/OpenMP en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail mixte MPI + OpenMP en batch sur Jean Zay, il faut :

  • Créer un script de soumission : voici un exemple, enregistré dans le fichier intel_mpi_omp.slurm :
    intel_mpi_omp.slurm
    #!/bin/bash
    #SBATCH --job-name=Hybride         # nom du job
    #SBATCH --ntasks=8             # Nombre de processus MPI
    #SBATCH --cpus-per-task=10     # nombre de threads OpenMP
    # /!\ Attention, la ligne suivante est trompeuse mais dans le vocabulaire
    # de Slurm "multithread" fait bien référence à l'hyperthreading.
    #SBATCH --hint=nomultithread   # 1 thread par coeur physique (pas d'hyperthreading)
    #SBATCH --time=00:10:00            # Temps d’exécution maximum demandé (HH:MM:SS)
    #SBATCH --output=Hybride%j.out     # Nom du fichier de sortie
    #SBATCH --error=Hybride%j.out      # Nom du fichier d'erreur (ici commun avec la sortie)
     
    # on se place dans le répertoire de soumission
    cd ${SLURM_SUBMIT_DIR}
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load intel-all/19.0.4
     
    # echo des commandes lancées
    set -x
     
    # nombre de threads OpenMP
    export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK 
    # binding OpenMP
    export OMP_PLACES=cores
     
    # exécution du code
    srun ./exec_mpi_omp
  • Soumettre ce script via la commande sbatch :
    $ sbatch intel_mpi_omp.slurm

Remarques :

  • Nous vous recommandons de compiler et d'exécuter vos codes sous le même environnement Intel : utilisez exactement la même commande module load intel… à l'exécution qu'à la compilation.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis.
  • Dans cet exemple, on suppose que l'exécutable exec_mpi_omp se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch : la variable SLURM_SUBMIT_DIR est automatiquement valorisée par Slurm.
  • Le fichier de sortie du calcul Hybride<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Pour éviter les erreurs de distribution automatique de tâches, nous vous recommandons d'utiliser srun pour exécuter votre code au lieu de mpirun, ce qui permet de garantir une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission Slurm.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : exécution MPMD d'un couplage de codes en batch

Le modèle d’exécution MPMD (Multiple Program Multiple Data) est supporté sur Jean Zay. Différents exécutables sont lancés et communiquent entre eux en utilisant MPI ; tous les processus MPI sont inclus au sein du même communicateur MPI_COMM_WORLD.

Ce modèle d'exécution est réalisé à l'aide d'un fichier texte (nommé ici mpmd.conf) qui contient le mapping entre les processus MPI et les exécutables. L'option –multi-prog de la commande srun doit être spécifiée dans le script de soumission:

$ srun --multi-prog ./mpmd.conf

Couplage MPMD de codes MPI

A titre d'exemple, voici un fichier de configuration qui réalise le couplage de 3 codes MPI avec un total de 8 processus MPI générés :

mpmd.conf
0     ./a.out
1-3,7 ./b.out
4-6   ./c.out
  • le processus MPI de rang 0 est issu de l'exécutable ./a.out,
  • les 4 processus MPI de rang 1 à 3 et 7 sont issus de ./b.out,
  • les 3 processus MPI de rang 4 à 6 sont issus de ./c.out.

Le reste du script de soumission est identique à celui décrit pour l'exécution d'un code parallèle MPI en batch mais en prenant soin de réserver 8 cœurs.

Jean Zay : partitions Slurm GPU

Les partitions disponibles

Tous les projets DARI ou Accès Dynamique (AD) ayant des heures GPU ont à leur disposition des partitions Slurm définies sur Jean Zay :

  • La partition gpu_p1 est automatiquement utilisée si aucune partition n'est précisée, pour tous les travaux demandant des heures GPU. Elle permet de lancer des calculs sur les nœuds accélérés quadri-GPU de Jean Zay. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. ci-dessous).
  • La partition gpu_p2 est pour le moment uniquement accessible aux chercheurs en Intelligence Artificielle qui ont effectué une demande d'heures GPU via les Accès Dynamiques (AD). Elle permet de lancer des calculs sur les nœuds accélérés octo-GPU de Jean Zay. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. ci-dessous).
    • La sous-partition gpu_p2s donne accès au nœuds octo-GPU à 360 Go de mémoire.
    • La sous-partition gpu_p2l donne accès au nœuds octo-GPU à 720 Go de mémoire.
  • La partition prepost permet de lancer un travail sur l'un des nœuds pré/post-traitement de Jean Zay jean-zay-pp, sur lesquels les calculs ne sont pas déduits de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00, c.f ci-dessous).
  • La partition visu permet de lancer un travail sur l'un des nœuds de visualisation de Jean Zay jean-zay-visu, sur lesquels les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 1 heure (soit --time=HH:MM:SS ≤ 4:00:00 ci-dessous).
  • La partition archive est dédiée aux commandes permettant de gérer les données (copies ou déplacements de fichiers, création d'archives) : les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. ci-dessous).

Attention aux limites de temps par défaut des partitions, qui sont délibérément basses. Pour des exécutions plus longues, vous devez spécifier une limite de temps d'exécution, qui doit rester inférieure au maximum autorisé pour la partition et la Qos utilisées. Vous devez alors utiliser :

  • soit la directive Slurm #SBATCH --time=HH:MM:SS dans votre job,
  • soit l'option --time=HH:MM:SS des commandes sbatch, salloc ou srun.

La partition gpu_p1 étant la partition utilisée par défaut par les travaux demandant des GPU, elle n'a pas besoin d'être demandée. Par contre, toutes les autres doivent être spécifiées explicitement pour être utilisées. Par exemple, pour la partition prepost, vous pouvez utiliser :

  • soit la directive Slurm #SBATCH --partition=prepost dans votre job,
  • soit l'option --partition=prepost des commandes sbatch, salloc ou srun.

Attention : depuis le 11 octobre 2019, tout travail demandant plus d'un nœud tourne en mode exclusif : les nœuds ne sont pas partagés. En particulier, cela implique que les heures facturées sont calculées sur la base de la totalité des nœuds réquisitionnés, y compris ceux qui ne sont que partiellement exploités.
Par exemple, la réservation de 41 cœurs CPU (soit 1 nœud + 1 cœur) sur la partition cpu_p1 entraine la facturation de 80 cœurs CPU (soit 2 nœuds). De manière analogue sur la partition gpu_p1, la réservation de 5 GPU (soit 1 nœud quadri-GPU + 1 GPU) entraine la facturation de 8 GPU (soit 2 nœuds quadri-GPU). Par contre, la totalité de la mémoire des nœuds réservés est disponible dans les deux cas (de l'ordre de 160 Go utiles par nœud).

Les QoS disponibles

Pour chaque job soumis dans une partition, vous pouvez spécifier une QoS (Quality of Service) qui va déterminer les limites et la priorité de votre job :

  • la QoS par défaut pour tous les travaux GPU : qos_gpu-t3
    • durée max : 20h00 de temps Elapsed,
    • 96 nœuds GPU maximum par travail.
  • une QoS pour des exécutions mono-nœud plus longues et qui doit être spécifiée pour être utilisée (c.f. ci-dessous) : qos_gpu-t4
    • durée max : 100h00 de temps Elapsed,
    • 1 nœud maximum par travail,
    • 8 nœuds GPU maximum par utilisateur,
    • 32 nœuds GPU maximum pour l'ensemble des travaux demandant cette QoS.
  • une QoS pour des exécutions plus brèves et qui doit être spécifiée pour être utilisée (c.f. ci-dessous) : qos_gpu-dev
    • durée max : 2h00 de temps Elapsed,
    • 4 nœuds GPU maximum par utilisateur,
    • 64 nœuds GPU maximum pour l'ensemble des travaux demandant cette QoS.

Pour spécifier une QoS différente du défaut, vous pouvez au choix :

  • utiliser la directive Slurm #SBATCH --qos=qos_gpu-dev dans votre job par exemple,
  • ou spécifier l'option --qos=qos_gpu-dev aux commandes sbatch, salloc ou srun.
Tableau récapitulatif
QoS Limite en temps Limite en ressource
par job par utilisateur par QoS
qos_gpu-t3 (défaut) 20h 96 nœuds
qos_gpu-t4 100h 1 nœud 8 nœuds 32 nœuds
qos_gpu-dev 2h 4 nœuds 4 nœuds 64 nœuds

Jean Zay : allocation mémoire avec Slurm sur les partitions GPU

Actuellement, les options Slurm --mem, --mem-per-cpu et --mem-per-gpu ne permettent pas de configurer convenablement l'allocation mémoire d'un job sur Jean Zay. Celle-ci est déterminée automatiquement à partir du nombre de CPU réservé.

Pour ajuster la quantité de mémoire allouée à votre job, il faut donc ajuster le nombre de CPU réservés par tâche (ou GPU) en spécifiant l'option suivante dans vos scripts batch, ou lors d'un salloc en mode interactif :

--cpus-per-task=...     # --cpus-per-task=1 par défaut 

Attention, --cpus-per-task=1 par défaut. Si vous ne changez pas sa valeur comme expliqué ci-dessous, vous n'accédez pas à la totalité de la mémoire par GPU à laquelle vous pouvez prétendre. En particulier, vous risquez de faire rapidement des débordements mémoire.

Sur la partition gpu_p1

Les nœuds de la partition gpu_p1 donnent accès à 160 Go de mémoire utile. L'allocation mémoire y est déterminée automatiquement à hauteur de :

  • 4 Go par cœur CPU lorsque l'hyperthreading est désactivé (option Slurm --hint=nomultithread)

Un nœud de calcul de la partition gpu_p1 contient 4 GPU et 40 cœurs CPU. Vous pouvez donc réserver le 1/4 de la mémoire du nœud par GPU en réservant 10 CPU par GPU :

 --cpus-per-task=10     # reservation d'1/4 de la memoire par GPU (gpu_p1)

Vous réservez ainsi 40 Go de mémoire par GPU, lorsque l'hyperthreading est désactivé (comptez la moitié sinon).

Sur la partition gpu_p2

La partition gpu_p2 est subdivisée en deux sous-partitions :

  • la sous-partition gpu_p2s à 360 Go de mémoire utile par nœud
  • la sous-partition gpu_p2l à 720 Go de mémoire utile par nœud

L'allocation mémoire est déterminée automatiquement à hauteur de :

  • 15 Go par cœur CPU sur la partition gpu_p2s, lorsque l'hyperthreading est désactivé (option Slurm --hint=nomultithread)
  • 30 Go par cœur CPU sur la partition gpu_p2l, lorsque l'hyperthreading est désactivé

Un nœud de calcul de la partition gpu_p2 contient 8 GPU et 24 cœurs CPU. Vous pouvez donc réserver le 1/8 de la mémoire du nœud par GPU en réservant 3 CPU par GPU :

 --cpus-per-task=3     # reservation d'1/8 de la memoire par GPU (gpu_p2) 

Vous réservez ainsi, lorsque l'hyperthreading est désactivé (comptez la moitié sinon) :

  • 45 Go de mémoire par GPU sur la sous-partition gpu_p2s
  • 90 Go de mémoire par GPU sur la sous-partition gpu_p2l

Remarques

  • Vous pouvez réserver plus de mémoire par GPU en augmentant la valeur de --cpus-per-task, tant que la demande ne dépasse pas la totalité de la mémoire disponible sur le nœud. Attention, les heures de calcul seront décomptées en proportion. Par exemple, si vous réservez 1 GPU sur la partition gpu_p1 avec les options --ntasks=1 --gres=gpu:1 --cpus-per-task=20, l'équivalent d'un travail sur 2 GPU vous sera facturé.
  • Si vous réservez un nœud de calcul en exclusivité, vous avez accès à la totalité de la mémoire du nœud, indépendamment de la valeur donnée à --cpus-per-task. L'équivalent d'un travail sur le nœud entier vous est alors facturé.
  • La quantité de mémoire allouée pour votre job est visible en lançant la commande Slurm :
    scontrol show job $JOBID    # chercher la valeur de la variable mem 

    Attention, tant que le job est en queue (PENDING), Slurm estime la mémoire allouée à un job sur la base de cœurs logiques. Si vous avez réservé des cœurs physiques (avec --hint=nomultithread), la valeur indiquée peut donc être deux fois inférieure à la valeur attendue. Celle-ci est mise à jour et devient correcte lors du lancement du job.

  • Pour une réservation de ressource sur la partition prepost, vous pouvez vous référer à la page dédiée à l'allocation mémoire avec Slurm sur les partitions CPU. Le GPU disponible sur chacun des noeuds de la partition prepost vous est alloué automatiquement, sans avoir à spécifier l'option --gres=gpu:1.

Jean Zay : exécution interactive d'un code GPU

Connexion sur la frontale

L'accès à la frontale se fait par une connexion ssh :

$ ssh login@jean-zay.idris.fr

Les ressources de ce nœud interactif sont partagées entre tous les utilisateurs connectés : l'interactif sur la frontale est donc réservé uniquement pour la compilation et la mise au point des scripts.

Attention : les nœuds frontaux de Jean Zay ne sont pas équipés de GPU. Ils ne peuvent donc pas être utilisés pour des exécutions nécessitant un ou plusieurs GPU.

Pour effectuer les exécutions interactives de vos codes GPU sur les nœuds de calcul convergés, vous devez utiliser :

Par contre, il est nécessaire de soumettre un travail batch pour les calculs demandant des ressources GPU importantes (en nombre de GPUs, mémoire ou temps Elapsed).

Obtention d'un terminal sur un nœud de calcul GPU

Il est possible d'ouvrir un terminal directement sur un nœud de calcul convergé sur lequel des ressources vous sont réservées (ici 1 GPU sur la partition gpu_p1) en utilisant la commande suivante :

$ srun --pty --ntasks=1 --cpus-per-task=10 --gres=gpu:1 --hint=nomultithread --partition=gpu_p1 [--other-options] bash

Remarques :

  • L’option --pty permet d'obtenir un terminal interactif.
  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • La mémoire allouée pour le job est proportionnelle au nombre de cœurs CPU demandés. Par exemple, si vous demandez 1/4 des cœurs CPU d'un nœud, vous aurez accès à 1/4 de sa mémoire. Sur la partition gpu_p1, l'option --cpus-per-task=10 permet ainsi de réserver 1/4 de la mémoire du nœud par GPU. Sur la partition gpu_p2, il faut spécifier --cpus-per-task=3 pour réserver 1/8 de la mémoire du nœud par GPU, et ainsi être cohérent avec la configuration du nœud. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions GPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code GPU.
  • Les réservations ont toutes des ressources définies par une partition et une “Qualité de Service” QoS (Quality of Service) positionnées par défaut dans Slurm. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Le terminal est opérationnel après validation de l'allocation :

$ srun --pty --ntasks=1 --cpus-per-task=10 --gres=gpu:1 --hint=nomultithread --partition=gpu_p1 bash
srun: job 1369723 queued and waiting for resources
srun: job 1369723 has been allocated resources
bash-4.2$ hostname
r6i3n6
bash-4.2$ nvidia-smi 
Fri Apr 10 19:09:08 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 430.14       Driver Version: 430.14       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:1C:00.0 Off |                    0 |
| N/A   44C    P0    45W / 300W |      0MiB / 32510MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Vous pouvez vérifier que votre travail interactif a bien démarré grâce à la commande squeue, et obtenir des informations complètes sur l'état du job avec la commande scontrol show job <identifiant du travail>.

Une fois le terminal opérationnel, vous pouvez lancer vos exécutables de la manière habituelle ./votre_executable.

Attention : MPI n'est actuellement pas utilisable dans cette configuration.

Pour quitter le mode interactif :

bash-4.2$ exit 

Attention : si vous ne quittez pas le mode interactif vous-même, la durée d'allocation maximale (par défaut ou spécifiée avec l'option --time) est appliquée et autant d'heures de calcul sont décomptées sur le projet que vous avez spécifié.

Exécution interactive sur la partition GPU

Si vous n'avez pas besoin d'ouvrir un terminal sur un nœud de calcul, il est également possible de démarrer directement depuis la frontale l'exécution interactive d'un code sur les nœuds de calcul convergé en utilisant la commande suivante (ici avec 4 GPU sur la partition gpu_p1) :

$ srun --ntasks=4 --cpus-per-task=10 --gres=gpu:4 --hint=nomultithread --partition=gpu_p1 [--other-options] ./mon_executable

Remarques :

  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • La mémoire allouée pour le job est proportionnelle au nombre de cœurs CPU demandés. Par exemple, si vous demandez 1/4 des cœurs CPU d'un nœud, vous aurez accès à 1/4 de sa mémoire. Sur la partition gpu_p1, l'option --cpus-per-task=10 permet ainsi de réserver 1/4 de la mémoire du nœud par GPU. Sur la partition gpu_p2, il faut spécifier --cpus-per-task=3 pour réserver 1/8 de la mémoire du nœud par GPU, et ainsi être cohérent avec la configuration du nœud. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions GPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code GPU.
  • Les réservations ont toutes des ressources définies par une partition et une “Qualité de Service” QoS (Quality of Service) positionnées par défaut dans Slurm. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Réservation de ressources réutilisables pour plusieurs exécutions interactives

Chaque exécution interactive démarrée comme décrit dans la section précédente correspond à un travail différent. Comme tous les travaux, ils sont susceptibles d'être placés en attente pendant un temps plus ou moins long si les ressources de calcul ne sont pas disponibles.

Si vous souhaitez enchaîner plusieurs exécutions interactives, il peut être pertinent de préalablement réserver des ressources qui pourront être réutilisées pour plusieurs exécutions. Vous devrez alors attendre que les ressources soient disponibles une seule fois au moment de la réservation et non pour chaque exécution.

La réservation des ressources (ici pour 4 GPU sur la partition gpu_p1) se fait via la commande suivante :

$ salloc --ntasks=4 --cpus-per-task=10 --gres=gpu:4 --hint=nomultithread --partition=gpu_p1 [--other-options]

Remarques :

  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • La mémoire allouée pour le job est proportionnelle au nombre de cœurs CPU demandés. Par exemple, si vous demandez 1/4 des cœurs CPU d'un nœud, vous aurez accès à 1/4 de sa mémoire. Sur la partition gpu_p1, l'option --cpus-per-task=10 permet ainsi de réserver 1/4 de la mémoire du nœud par GPU. Sur la partition gpu_p2, il faut spécifier --cpus-per-task=3 pour réserver 1/8 de la mémoire du nœud par GPU, et ainsi être cohérent avec la configuration du nœud. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire sur les partitions GPU.
  • --other-options peut contenir toutes les options Slurm usuelles de configuration des travaux (--time=, etc ) : voir la documentation sur les scripts batch de soumission dans la rubrique Exécution/Contrôle d'un code GPU.
  • Les réservations ont toutes des ressources définies par une partition et une “Qualité de Service” QoS (Quality of Service) positionnées par défaut dans Slurm. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

La réservation devient utilisable après validation de l'allocation :

salloc: Pending job allocation 1369712
salloc: job 1369712 queued and waiting for resources
salloc: job 1369712 has been allocated resources
salloc: Granted job allocation 1369712

Vous pouvez vérifier que votre réservation est bien active grâce à la commande squeue, et obtenir des informations complètes sur l'état du job avec la commande scontrol show job <identifiant du travail>.

Vous pouvez alors démarrer des exécutions interactives en utilisant la commande srun :

$ srun [--other-options] ./code

Remarque : Si vous ne précisez aucune option pour la commande srun, les options utilisées pour le salloc (par exemple le nombre de tâches) seront utilisées par défaut.

Attention :

  • Après avoir réservé des ressources avec salloc, vous êtes toujours connecté sur la frontale (vous pouvez le vérifier en utilisant la commande hostname). Il est impératif d'utiliser la commande srun pour que vos exécutions utilisent les ressources réservées.
  • Si vous oubliez de libérer la réservation, la durée d'allocation maximale (par défaut ou spécifiée avec l'option --time) est appliquée et autant d'heures de calcul sont décomptées sur le projet que vous avez spécifié. Il est donc nécessaire de le faire explicitement :
$ exit
exit
salloc: Relinquishing job allocation 1369712 

Jean Zay : exécution d'un travail mono GPU en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail mono GPU en batch sur Jean Zay, il faut :

  • Créer un script de soumission :

    mono_gpu.slurm
    #!/bin/bash
    #SBATCH --job-name=gpu_mono         # nom du job
    #SBATCH --partition=gpu_p1          # partition GPU choisie
    #SBATCH --ntasks=1                  # nombre de taches a reserver (=nombre de GPU ici)
    #SBATCH --gres=gpu:1                # nombre de GPU a reserver
    #SBATCH --cpus-per-task=10          # nombre de coeurs CPU par tache (un quart du noeud ici)
    # /!\ Attention, "multithread" fait reference à l'hyperthreading dans la terminologie Slurm
    #SBATCH --hint=nomultithread        # hyperthreading desactive
    #SBATCH --time=00:10:00             # temps maximum d'execution demande (HH:MM:SS)
    #SBATCH --output=gpu_mono%j.out     # nom du fichier de sortie
    #SBATCH --error=gpu_mono%j.out      # nom du fichier d'erreur (ici commun avec la sortie)
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancees
    set -x
     
    # execution du code
    ./executable_mono_gpu
  • Soumettre ce script via la commande sbatch :

     $ sbatch mono_gpu.slurm

Remarques :

  • Pour une exécution sur la partition gpu_p2, il faut spécifier --partition=gpu_p2 et --cpus-per-task=3.
  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable executable_mono_gpu se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch.
  • Le fichier de sortie du calcul mono_gpu<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : exécution d'un travail multi GPU MPI en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail distribué multi GPU MPI en batch sur Jean Zay, il faut créer un script de soumission en vous inspirant des deux exemples donnés ci-dessous.

Si votre code requière la fonctionnalité MPI CUDA-aware, vous devez vous référer à la page exécution d'un travail multi GPU MPI CUDA-aware et GPUDirect en batch.

  • Pour une exécution utilisant 3 GPU (sur un même nœud) de la partition gpu_p1 :

    multi_gpu_mpi.slurm
    #!/bin/bash
    #SBATCH --job-name=gpu_multi_mpi     # nom du job
    #SBATCH --partition=gpu_p1           # partition GPU choisie
    #SBATCH --nodes=1                    # nombre de noeud
    #SBATCH --ntasks-per-node=3          # nombre de tache MPI par noeud (= nombre de GPU ici)
    #SBATCH --gres=gpu:3                 # nombre de GPU par nœud
    #SBATCH --cpus-per-task=10           # nombre de coeurs CPU par tache (un quart du noeud ici)
    # /!\ Attention, "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
    #SBATCH --hint=nomultithread         # hyperthreading desactive
    #SBATCH --time=00:10:00              # temps d’execution maximum demande (HH:MM:SS)
    #SBATCH --output=gpu_multi_mpi%j.out # nom du fichier de sortie
    #SBATCH --error=gpu_multi_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancees
    set -x
     
    # execution du code avec binding via bind_gpu.sh : 1 GPU pour 1 tache MPI.
    srun /gpfslocalsup/pub/idrtools/bind_gpu.sh ./executable_multi_gpu_mpi
  • Pour une exécution utilisant 8 GPU (soit 2 nœuds complets) de la partition gpu_p1 :

    multi_gpu_mpi.slurm
    #!/bin/bash
    #SBATCH --job-name=gpu_multi_mpi     # nom du job
    #SBATCH --partition=gpu_p1           # partition GPU choisie
    #SBATCH --ntasks=8                   # nombre de tache MPI (= nombre de GPU ici)
    #SBATCH --ntasks-per-node=4          # nombre de tache MPI par noeud
    #SBATCH --gres=gpu:4                 # nombre de GPU par nœud
    #SBATCH --cpus-per-task=10           # nombre de coeurs CPU par tache (un quart du noeud ici)
    # /!\ Attention, "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
    #SBATCH --hint=nomultithread         # hyperthreading desactive
    #SBATCH --time=00:10:00              # temps d'execution maximum demande (HH:MM:SS)
    #SBATCH --output=gpu_multi_mpi%j.out # nom du fichier de sortie
    #SBATCH --error=gpu_multi_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancees
    set -x
     
    # execution du code avec binding via bind_gpu.sh : 1 GPU pour 1 tache MPI.
    srun /gpfslocalsup/pub/idrtools/bind_gpu.sh ./executable_multi_gpu_mpi

Puis soumettre le script via la commande sbatch :

$ sbatch multi_gpu_mpi.slurm

Remarques :

  • Les exécutions sur la partition gpu_p2 se font de manière analogue, en spécifiant --partition=gpu_p2 et --cpus-per-task=3.
  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable executable_multi_gpu_mpi se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch.
  • Le fichier de sortie du calcul multi_gpu_mpi<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis, rendant l'exécution de votre job dépendant de ce que vous aurez fait avant.
  • Pour éviter les erreurs de distribution automatique de tâches, nous vous recommandons d'utiliser srun pour exécuter votre code au lieu de mpirun, ce qui permet de garantir une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission.
  • Le script /gpfslocalsup/pub/idrtools/bind_gpu.sh permet d'associer un GPU différent à chaque tâche MPI. Il n'est pas nécessaire de l'utiliser si votre code gère explicitement l'association des tâches MPI aux GPU. Attention, ce script est pour l'instant basique et ne permet de gérer que le cas simple 1 GPU pour 1 tâche MPI. Il ne fonctionne donc que pour un nombre de tâches MPI par nœud inférieur ou égal à 4. Si vous avez des besoins plus complexes, merci de contacter l'assistance de l'IDRIS.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Jean Zay : Utilisation de CUDA MPS

Présentation

Le service multi-processus MPS (Multi-Process Service) est une variante d'implémentation compatible de l'interface de programmation CUDA. L'architecture d'exécution MPS est conçue pour permettre aux applications CUDA coopératives multi-processus, généralement pour les travaux MPI, d'utiliser les fonctionnalités Hyper-Q sur les tous derniers GPU NVIDIA. Hyper-Q permet de traiter simultanément des noyaux CUDA sur le même GPU, ce qui peut améliorer les performances lorsque la capacité de calcul du GPU est sous-utilisée par un seul processus d'application.

Utilisation

Le service CUDA MPS est inclus par défaut dans les différents modules CUDA mis à dispositions des utilisateurs.

Pour un travail distribué multi GPU MPI en batch, l'utilisation de CUDA MPS peut être activée via l'option -C mps. Le nœud devra quant à lui être réservé de manière exclusive via l'option --exclusive.

  • Pour une exécution utilisant 40 processus MPI répartis sur 4 GPU, soit 10 processus par GPU, sur la partition gpu_p1 :

    mps_multi_gpu_mpi.slurm
    #!/bin/bash
    #SBATCH --job-name=gpu_cuda_mps_multi_mpi     # nom du job
    #SBATCH --partition=gpu_p1            # partition GPU choisie
    #SBATCH --ntasks=40                   # nombre de tache MPI
    #SBATCH --ntasks-per-node=40          # nombre de tache MPI par noeud
    #SBATCH --gres=gpu:4                  # nombre de GPU par nœud
    #SBATCH --cpus-per-task=1             # nombre de coeurs CPU par tache
    # /!\ "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
    #SBATCH --hint=nomultithread          # hyperthreading desactive
    #SBATCH --time=00:10:00               # temps d'execution maximum demande (HH:MM:SS)
    #SBATCH --output=gpu_cuda_mps_multi_mpi%j.out # nom du fichier de sortie
    #SBATCH --error=gpu_cuda_mps_multi_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
    #SBATCH --exclusive                   # on réserve le noeud de manière exclusive 
    #SBATCH -C mps                        # le service MPS est activé   
     
    # nettoyage des modules charges en interactif et herites par defaut
    module purge
     
    # chargement des modules
    module load ...
     
    # echo des commandes lancees
    set -x
     
    # execution du code avec binding via bind_gpu.sh : 4 GPU pour 40 taches MPI.
    srun ./executable_multi_gpu_mpi

Puis soumettre le script via la commande sbatch :

$ sbatch mps_multi_gpu_mpi.slurm

Remarques :

  • Une exécution sur un nœud complet de la partition gpu_p2 se fait de manière analogue, en spécifiant :
    #SBATCH --partition=gpu_p2            # partition GPU choisie
    #SBATCH --ntasks=24                   # nombre de tache MPI
    #SBATCH --ntasks-per-node=24          # nombre de tache MPI par noeud
    #SBATCH --gres=gpu:8                  # nombre de GPU par nœud
    #SBATCH --cpus-per-task=1             # nombre de coeurs CPU par tache
  • Attention, même si vous travaillez sur une partie seulement du nœud, celui-ci doit être réservé en exclusivité. La totalité du nœud vous est donc facturée.
  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable executable_mps_multi_gpu_mpi se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch.
  • Le fichier de sortie du calcul gpu_cuda_mps_multi_mpi<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis, rendant l'exécution de votre job dépendant de ce que vous aurez fait avant.
  • Pour éviter les erreurs de distribution automatique de tâches, nous vous recommandons d'utiliser srun pour exécuter votre code au lieu de mpirun, ce qui permet de garantir une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites, ou spécifier une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les //Qos//.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay, pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Documentation

La documentation officielle chez NVIDIA.

Retour au sommaire


12. Formations proposées à l'IDRIS

Formations proposées à l'IDRIS

L’IDRIS dispense des formations à destination aussi bien de ses utilisateurs que de ceux du calcul scientifique en général. La plupart de ces formations figurent au catalogue de CNRS Formation Entreprises, ce qui les rend accessibles à tous les utilisateurs du calcul scientifique, appartenant aussi bien au monde académique qu'industriel.

Ces formations sont principalement orientées vers les méthodes de programmation parallèles : MPI, OpenMP et hybride MPI / OpenMP, clés de voûte pour l’utilisation des supercalculateurs d’aujourd’hui. Elles concernent aussi les langages de programmation scientifique généraux : Fortran et C.

Le catalogue des formations proposées par l'IDRIS, régulièrement remis à jour, est disponible sur notre serveur web à l’adresse : https://cours.idris.fr

Ces formations sont gratuites si votre employeur est soit le CNRS soit une université française. L'inscription se fait alors directement sur le site web des formations de l'IDRIS. Sinon, contactez CNRS Formation Entreprises pour vous inscrire.

Les supports des formations dispensées à l'IDRIS sont disponibles en ligne ici

Retour au sommaire


13. Documentation de l'IDRIS

  • Le site Web : l’IDRIS maintient à jour un site Web : www.idris.fr regroupant l’ensemble de la documentation technique (nouvelles du centre, fonctionnement des machines, etc.).
  • Les documentations constructeurs : des documents, fournis par les constructeurs, sont accessibles sur le site Web de l’IDRIS. Ils permettent, par exemple, d’avoir une documentation complète sur les compilateurs (Fortran, C et C++), les bibliothèques scientifiques, les bibliothèques de passage de messages (MPI), etc.
  • Les manuels : tous les manuels UNIX sont disponibles en ligne grâce à la commande man exécutée à partir de votre login sur tous les calculateurs de l'IDRIS.

Retour au sommaire


14. Le support aux utilisateurs

La permanence de l'IDRIS

Questions et/ou problèmes techniques

Pour toute question, demande d'information ou problème sur les machines de l'IDRIS, contactez la permanence de l’équipe Support aux utilisateurs. Cette permanence est assurée conjointement par les membres de l’équipe Support utilisateurs HPC (SU-HPC) et les membres de l'équipe Support utilisateurs IA (SU-IA).

Vous pouvez soumettre vos questions :

  • par téléphone au 01 69 35 85 55, ou
  • par courriel adressé à

Cette permanence est assurée sans interruption :

  • du lundi au jeudi de 9h à 18h
  • et le vendredi de 9h à 17h30

Note : En période de vacances scolaires (par exemple : Noël, vacances d'été), les horaires peuvent être réduits :
du lundi au vendredi de 9h à 12h et de 13h30 à 17h30.

En dehors des heures ouvrées, les horaires en cours sont indiqués dans le message du répondeur téléphonique de la permanence.

Gestion administrative des utilisateurs de l'IDRIS

Pour tout problème de mot de passe, d'ouverture de compte, d'autorisation d’accès, ou pour nous envoyer les formulaires d'ouverture ou de gestion de compte, vous devez envoyer un courriel à :