Aller au contenu principal

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 :

  1. Créer un script de soumission :
openmp.slurm
#!/bin/bash
#SBATCH --job-name=omp              # nom du job
#SBATCH --nodes=1                   # nombre de noeuds
#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:10:00             # temps d'exécution maximum demande (HH:MM:SS)
#SBATCH --output=omp%j.out          # nom du fichier de sortie (%j est remplacé par le numéro du travail)
#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
  1. 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 logiciel en chargeant les mêmes modules.
  • 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 physiques d'un nœud, vous aurez accès à 1/4 de sa mémoire RAM. Il est important d'être cohérent avec la configuration des nœuds utilisés pour éviter une surfacturation d'heures, tout en profitant de la mémoire à laquelle vous avez le droit. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire avec Slurm.
  • Dans ces exemples, 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 se situe au moment d'utiliser la commande sbatch : la variable $SLURM_SUBMIT_DIR est automatiquement valorisée par Slurm.
  • Le fichier de sortie du calcul se trouvera é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 travaux ont tous 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 partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos CPU.
  • 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 travail comme indiqué dans 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.