Exécuter des tâches

From CC Doc
Jump to: navigation, search
This page is a translated version of the page Running jobs and the translation is 100% complete.

Other languages:
English • ‎français

Cette page présente l'information sur comment soumettre des tâches sur les grappes de Calcul Canada; elle s'adresse aux utilisateurs qui connaissent les concepts de préparation de scripts et d'ordonnancement des tâches. Si vous n'avez jamais travaillé sur une grappe partagée de grande taille, nous vous recommandons de lire d'abord Qu'est-ce qu'un ordonnanceur?

Toutes les tâches doivent être soumises via l'ordonnanceur.
Les seules exceptions sont pour les tâches de compilation et autres tâches qui devraient utiliser moins de 10 CPU-minutes et moins de 4Go de mémoire vive. Ces tâches peuvent être exécutées sur un nœud frontal. Aucun processus ne doit être exécuté sur un nœud de calcul sans d’abord avoir été traité par l’ordonnanceur.

L'ordonnancement des tâches sur les grappes de Calcul Canada se fait à l'aide de Slurm Workload Manager. La documentation Slurm est préparée par SchedMD. Si vous êtes un utilisateur de PBS/Torque, SGE, LSF ou LoadLeveler, ce tableau de correspondance des commandes vous sera utile.

Soumettre des tâches avec sbatch

La commande sbatch est utilisée pour soumettre une tâche.

[someuser@host ~]$ sbatch simple_job.sh
Submitted batch job 123456

Un script simple Slurm ressemble à ceci :

File : simple_job.sh

#!/bin/bash
#SBATCH --time=00:01:00
#SBATCH --account=def-someuser
echo 'Hello, world!'
sleep 30


Les directives (ou options) comprises dans le script ont le préfixe #SBATCH et doivent précéder toutes les commandes exécutables. La page sbatch décrit toutes les directives disponibles. Pour chaque tâche, la politique de Calcul Canada demande de fournir au moins une durée (--time) et un nom de compte (--account); voyez la section Comptes et projets ci-après.

La quantité de mémoire peut être demandée avec --mem-per-cpu (mémoire par cœur) ou --mem (mémoire par nœud). Nous vous recommandons de spécifier la quantité en mégaoctets (par exemple 8000Mo) plutôt qu'en gigaoctets (par exemple 8Go). Dans plusieurs cas, le fait de demander la quantité de mémoire en milliers de mégaoctets résultera en des temps d'attente plus courts. Par exemple, une quantité de --mem=128Go (l'équivalent de 131072Mo) est plus grande que ce qui est disponible pour une tâche sur les nœuds de 128Go. Une tâche pour laquelle on demande --mem=128G se qualifie pour moins de nœuds que celle pour laquelle on demande --mem=128000M et elle est susceptible de rester en attente plus longtemps. Ceci vaut également pour les demandes de --mem-per-cpu.

À moins que votre demande ne soit différente, la quantité par défaut est de 256Mo.

Les directives peuvent aussi être des arguments en ligne de commande pour sbatch. Par exemple,

[someuser@host ~]$ sbatch --time=00:30:00 simple_job.sh 

soumet le script présenté plus haut en limitant la durée à 30 minutes. Les formats de date valides sont minutes, minutesːsecondes, heuresːminutesːsecondes, jours-heures, jours-heuresːminutes, jours-heuresːminutesːsecondes.

L'exécution d'un script qui soumet plusieurs tâches à de courts intervalles risque d'affecter la disponibilité de l'ordonnanceur Slurm pour les autres utilisateurs (voir l'information sur le message d'erreur sbatch:_error:_Batch_job_submission_failed:). Utilisez plutôt un vecteur de tâches ou espacez les appels à sbatch de une seconde ou plus avec la commande sleep.

Lister les tâches avec squeue

La commande squeue est utilisée pour lister les tâches en attente et les tâches en exécution. Pour lister uniquement vos propres tâches, entrez en argument votre nom d'utilisateur avec -u.

[someuser@host ~]$ squeue -u $USER
      JOBID PARTITION      NAME     USER ST   TIME  NODES NODELIST(REASON)
     123456 cpubase_b  simple_j someuser  R   0:03      1 cdr234
     123457 cpubase_b  simple_j someuser PD             1 (Priority)

En sortie, la colonne ST montre l'état de chaque tâche. Les états les plus communs sont PD (pending) pour en attente, et R (running) pour en cours. Voir la page squeue pour des renseignements sur le choix, le formatage et l'interprétation du résultat de squeue.

Veuillez ne pas exécuter à plusieurs reprises et à de courts intervalles la commande squeue à partir d'un script ou d'une application. Cette commande surcharge Slurm et risque fort de nuire à sa performance ou à son bon fonctionnement.

Enregistrer le résultat

Par défaut, le résultat est placé dans le répertoire à partir duquel la tâche a été soumise, dans un fichier nommé slurm- suivi du numéro identifiant de la tâche et du terme out, par exemple slurm-123456.out. Pour spécifier un endroit ou un nom différent, utilisez la commande --output. Le nom du fichier peut contenir certains symboles de remplacement; %j par exemple donne le numéro d'identification de la tâche. Voyez la page sbatch pour la liste complète.

Le prochain script définit le nom de la tâche (job name) à paraître dans squeue et enregistre le résultat dans un fichier identifié par le job name (%x) comme préfixe suivi du numéro d'identification de la tâche (%j).


File : name_output.sh

#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --time=00:01:00
#SBATCH --job-name=test
#SBATCH --output=%x-%j.out
echo 'Hello, world!'


Les erreurs paraissent normalement dans le même fichier que le résultat standard en sortie, tout comme si les commandes étaient données interactivement. Pour diriger le canal standard d'erreurs (stderr pour standard error) vers un autre fichier, utilisez --error.

Comptes et projets

Chaque tâche doit être associée à un nom de compte correspondant à un projet d'allocation de ressources.

En soumettant une tâche avec sbatch, vous pourriez recevoir un des messages suivants :

 You are associated with multiple _cpu allocations...
 Please specify one of the following accounts to submit this job:

 You are associated with multiple _gpu allocations...
 Please specify one of the following accounts to submit this job:

Ceci signifie que vous avez plus d'un compte valide; indiquez le compte approprié avec la directive --account.

#SBATCH --account=def-user-ab

Pour connaître le nom du compte correspondant à un projet, connectez-vous à CCDB et cliquez sur Mon compte -> Détails sur le compte pour faire afficher la liste des projets dont vous êtes membre. Le deuxième champ (Nom du groupe) contient la chaîne de caractères à utiliser avec la directive --account. Sachez qu'un projet qui a reçu une allocation de ressources peut être associé à une grappe en particulier (ou à un groupe de grappes) et qu'il se peut qu'il ne puisse être transféré de cette grappe à une autre.

Dans l'exemple suivant, les tâches soumises par --account=def-rdickson-ac seront attribuées à wnp-003-ac.

Nom du groupe


Si vous prévoyez utiliser toujours le même compte pour toutes les tâches, vous trouverez utile de définir les variables d'environnement suivantes dans votre fichier ~/.bashrc :

export SLURM_ACCOUNT=def-someuser
export SBATCH_ACCOUNT=$SLURM_ACCOUNT
export SALLOC_ACCOUNT=$SLURM_ACCOUNT

Slurm utilisera dans le script la valeur de SBATCH_ACCOUNT plutôt que la directive --account. Même si vous spécifiez un nom de compte dans le script, la variable d'environnement a priorité. Pour remplacer la variable d'environnement, il faut fournir un nom de compte comme argument en ligne de commande avec sbatch.

SLURM_ACCOUNT joue le même rôle que SBATCH_ACCOUNT, mais pour la commande srun plutôt que sbatch. Il en est de même pour SALLOC_ACCOUNT.

Exemples de scripts

Tâches séquentielles

Une tâche séquentielle est une tâche qui ne nécessite qu'un seul cœur. Il s'agit du type de tâche le plus simple dont un exemple se trouve ci-dessus dans la section Soumettre des tâches avec sbatch.

Lot de tâches

Un lot de tâches (task array ou array job) sert à soumettre un ensemble de tâches à l'aide d'une seule commande. Chacune des tâches du lot se distingue par la variable d'environnement $SLURM_ARRAY_TASK_ID comportant une valeur distincte pour chaque instance de la tâche. L'exemple suivant crée 10 tâches avec $SLURM_ARRAY_TASK_ID ayant les valeurs de 1 à 10 :


File : array_job.sh

#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --time=0-0:5
#SBATCH --array=1-10
./myapplication $SLURM_ARRAY_TASK_ID


Voyez d'autres exemples à la page Vecteurs de tâches et la documentation détaillée Slurm de SchedMD.com.

Tâche multifil ou tâche OpenMP

Le prochain exemple comprend un seul processus et huit cœurs CPU. N'oubliez pas que pour utiliser OpenMP, une application doit avoir été compilée avec les indicateurs (flags) appropriés, soit gcc -fopenmp ... ou icc -openmp ....


File : openmp_job.sh

#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --time=0-0:5
#SBATCH --cpus-per-task=8
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
./ompHello


Tâche MPIMessage Passing Interface

Le prochain script lance quatre processus MPIMessage Passing Interface, chacun nécessitant 1024Mo de mémoire. Le temps d'exécution est limité à cinq minutes.


File : mpi_job.sh

#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --ntasks=4               # number of MPI processes
#SBATCH --mem-per-cpu=1024M      # memory; default unit is megabytes
#SBATCH --time=0-00:05           # time (DD-HH:MM)
srun ./mpi_program               # mpirun or mpiexec also work


Les tâches intensives avec MPIMessage Passing Interface, et spécifiquement celles qui peuvent utiliser efficacement des nœuds entiers, devraient utiliser --nodes et --ntasks-per-node plutôt que --ntasks. Il est aussi possible d'avoir des tâches hybrides qui sont à la fois exécutées en MPIMessage Passing Interface et en fils multiples. Pour plus d'information sur les tâches distribuées en parallèle, consultez Contrôle de l'ordonnancement avec MPI.

Pour plus d'information, consultez la page OpenMP.

Tâche GPU (avec processeur graphique)

Pour utiliser un GPU, il faut considérer plusieurs options, surtout parce que

  • les nœuds de Cedar et Graham qui sont équipés de GPU ne sont pas tous configurés uniformément,
  • il y a deux configurations différentes sur Cedar,
  • les politiques sont différentes pour les nœuds GPU de Cedar .

Pour des informations et des exemples d'ordonnancement sur les ressources GPU, consultez Ordonnancement Slurm des tâches avec GPU.

Tâches interactives

Si la soumission de tâches en lot est la façon la plus efficace d'utiliser les grappes de Calcul Canada, il est cependant possible de soumettre des tâches interactivement, ce qui peut s'avérer utile pour :

  • l'exploration de données en mode ligne de commande;
  • l'utilisation des outils de console interactifs de R et iPython;
  • les projets intensifs de développement, de débogage ou de compilation.

Pour démarrer une session interactive sur un nœud de calcul, utilisez salloc. Dans l'exemple suivant, nous avons deux tâches sur deux cœurs CPU, pour une durée d'une heure.

[name@login ~]$ salloc --time=1:0:0 --ntasks=2 --account=def-someuser 
salloc: Granted job allocation 1234567
[name@node01 ~]$ ...             # effectuer du travail
[name@node01 ~]$ exit            # cesser l'allocation
salloc: Relinquishing job allocation 1234567

La durée d'exécution d'une tâche interactive est limitée à 3 heures.

Il est aussi possible d'exécuter des applications graphiques en mode interactif sur un nœud de calcul en ajoutant l'indicateur --x11 à la commande salloc. Pour ce faire, il faut d'abord activer la redirection X11 (Enable X11 forwarding); consultez la page SSH.

Suivi des tâches

Tâches en cours

Par défaut, squeue montre toutes les tâches gérées à ce moment par l'ordonnanceur. Le résultat sera plus rapide si vous demandez uniquement vos propres tâches avec

squeue -u $USER

Pour connaître les tâches en cours d'exécution ou en attente, utilisez

squeue -u <username> -t RUNNING
squeue -u <username> -t PENDING

Pour connaître les détails d'une tâche en particulier, utilisez scontrol :

scontrol show job -dd <jobid>

Obtenir des renseignements par courriel

Pour recevoir par courriel certains renseignements sur une tâche, utilisez les diverses options avec sbatch, par exemple

#SBATCH --mail-user=<email_address>
#SBATCH --mail-type=BEGIN
#SBATCH --mail-type=END
#SBATCH --mail-type=FAIL
#SBATCH --mail-type=REQUEUE
#SBATCH --mail-type=ALL

Tâches complétées

La commande seff permet d'obtenir un sommaire de l'efficacité en CPU et mémoire pour une tâche complétée.

$ seff 12345678
Job ID: 12345678
Cluster: cedar
User/Group: jsmith/jsmith
State: COMPLETED (exit code 0)
Cores: 1
CPU Utilized: 02:48:58
CPU Efficiency: 99.72% of 02:49:26 core-walltime
Job Wall-clock time: 02:49:26
Memory Utilized: 213.85 MB
Memory Efficiency: 0.17% of 125.00 GB

Pour avoir plus de renseignements sur une tâche complétée, utilisez sacct; ajoutez --format pour savoir le résultat de la tâche, ainsi

sacct -j <jobid>
sacct -j <jobid> --format=JobID,JobName,MaxRSS,Elapsed

S'il y a défaillance d'un nœud au cours de l'exécution d'une tâche, celle-ci peut être relancée. sacct montre normalement le dernier enregistrement pour la dernière exécution (présumée réussie). Pour consulter tous les enregistrements relatifs à une tâche, ajoutez l'option --duplicates.

Le champ MaxRSS donne la quantité de mémoire utilisée par une tâche; il retourne la valeur du plus grand resident set size. Pour connaître la tâche et le nœud en cause, imprimez aussi les champs MaxRSSTask et MaxRSSNode.

La commande sstat fournit des renseignements sur l'état d'une tâche en cours d'exécution; la commande sacct est utilisée pour les tâches qui sont complétées.

Surveillance d'une tâche en cours

Il est possible de se connecter à un nœud sur lequel une tâche est en cours et d'y exécuter de nouveaux processus. Ceci est utile en particulier pour des opérations de dépannage ou pour suivre le déroulement d'une tâche.

L'utilitaire nvidia-smi est employé pour surveiller l'utilisation d'un GPU sur un nœud où une tâche est en cours d'exécution. L'exemple suivant exécute watch sur le nœud qui à son tour lance nvidia-smi toutes les 30 secondes et affiche le résultat au terminal.

[name@server ~]$ srun --jobid 123456 --pty watch -n 30 nvidia-smi

Plusieurs commandes de surveillance peuvent être lancées avec tmux. L'exemple suivant exécute htop et nvidia-smi dans des fenêtres distinctes pour faire le suivi de l'activité sur le nœud où la tâche est exécutée.

[name@server ~]$ srun --jobid 123456 --pty tmux new-session -d 'htop -u $USER' \; split-window -h 'watch nvidia-smi' \; attach

Les processus lancés avec srun partagent les ressources utilisées par la tâche en question. Il faut donc éviter de lancer des processus qui utiliseraient les ressources au détriment de la tâche. Dans les cas où les processus utilisent trop de ressources, la tâche pourrait être arrêtée; le fait d'utiliser trop de cycles CPU ralentit une tâche.

Note ː Dans les exemples précédents, srun fonctionne uniquement sur des tâches soumises avec sbatch. Pour faire le suivi d'une tâche interactive, ouvrez plusieurs fenêtres avec tmux et démarrez les processus dans des fenêtres distinctes.

Annulation d'une tâche

Pour annuler une tâche, spécifiez son identifiant ainsi

 scancel <jobid>

Annulez toutes vos tâches ou uniquement vos tâches qui sont en attente ainsi

 scancel -u $USER
scancel -t PENDING -u $USER

Resoumettre une tâche pour un calcul de longue durée

Pour les calculs nécessitant une durée plus longue que la limite de temps du système, l'application doit pouvoir gérer des points de contrôle (checkpointing). Elle doit aussi permettre la sauvegarde de son état intégral dans un fichier de point de contrôle (checkpoint file) et pouvoir redémarrer et poursuivre le calcul à partir du dernier état.

Plusieurs utilisateurs auront peu d'occasions de redémarrer un calcul, et ceci peut se faire manuellement. Dans certains cas cependant, des redémarrages fréquents sont requis et une certaine forme d'automatisation peut être appliquée.

Les deux méthodes recommandées sont

  • l'utilisation de vecteurs de tâches (job arrays) Slurm;
  • la resoumission à partir de la fin du script.

Redémarrage avec des vecteurs de tâches

La syntaxe --array=1-100%10 mentionnée plus haut permet de soumettre une collection de tâches identiques en n'exécutant qu'une tâche à la fois. Le script doit faire en sorte que le dernier point de contrôle soit toujours utilisé pour la prochaine tâche. Le nombre de redémarrages est spécifié avec l'argument --array.

Dans l'exemple suivant en dynamique moléculaire, la simulation comporte 1 million d'étapes et dépasse la limite de temps imposée pour la grappe. La simulation peut cependant être divisée en 10 tâches de 100,000 étapes séquentielles.

Redémarrage d'une simulation avec un vecteur de tâches :

File : job_array_restart.sh

#!/bin/bash
# ---------------------------------------------------------------------
# SLURM script for a multi-step job on a Compute Canada cluster. 
# ---------------------------------------------------------------------
#SBATCH --account=def-someuser
#SBATCH --cpus-per-task=1
#SBATCH --time=0-10:00
#SBATCH --mem=100M
#SBATCH --array=1-10%1   # Run a 10-job array, one job at a time.
# ---------------------------------------------------------------------
echo "Current working directory: `pwd`"
echo "Starting run at: `date`"
# ---------------------------------------------------------------------
echo ""
echo "Job Array ID / Job ID: $SLURM_ARRAY_JOB_ID / $SLURM_JOB_ID"
echo "This is job $SLURM_ARRAY_TASK_ID out of $SLURM_ARRAY_TASK_COUNT jobs."
echo ""
# ---------------------------------------------------------------------
# Run your simulation step here...


if test -e state.cpt; then 
     # There is a checkpoint file, restart;
     mdrun --restart state.cpt
else
     # There is no checkpoint file, start a new simulation.
     mdrun
fi

# ---------------------------------------------------------------------
echo "Job finished with exit code $? at: `date`"
# ---------------------------------------------------------------------


Resoumettre à partir d'un script

Dans le prochain exemple, la tâche exécute la première partie du calcul et enregistre un point de contrôle. Lorsque la première partie est terminée, mais avant que le temps d'exécution alloué pour la tâche n'est échu, le script vérifie si le calcul est complété. Si le calcul n'est pas complété, le script soumet une copie de lui-même et poursuit le travail.

Resoumission avec un script :

File : job_resubmission.sh

#!/bin/bash
# ---------------------------------------------------------------------
# SLURM script for job resubmission on a Compute Canada cluster. 
# ---------------------------------------------------------------------
#SBATCH --job-name=job_chain
#SBATCH --account=def-someuser
#SBATCH --cpus-per-task=1
#SBATCH --time=0-10:00
#SBATCH --mem=100M
# ---------------------------------------------------------------------
echo "Current working directory: `pwd`"
echo "Starting run at: `date`"
# ---------------------------------------------------------------------
# Run your simulation step here...

if test -e state.cpt; then 
     # There is a checkpoint file, restart;
     mdrun --restart state.cpt
else
     # There is no checkpoint file, start a new simulation.
     mdrun
fi


# Resubmit if not all work has been done yet.
# You must define the function work_should_continue().
if work_should_continue; then
     sbatch ${BASH_SOURCE[0]}
fi

# ---------------------------------------------------------------------
echo "Job finished with exit code $? at: `date`"
# ---------------------------------------------------------------------


Remarque ː Le test servant à déterminer s'il faut soumettre une seconde tâche (work_should_continue dans notre exemple) doit être un test positif. Vous pourriez être tenté de vérifier l'existence d'une condition d'arrêt (par exemple, la rencontre d'un critère de convergence) et soumettre une seconde tâche si la condition n'est pas détectée. Cependant, si une erreur inattendue survient, la condition d'arrêt pourrait ne pas être repérée et la séquence de tâche se poursuivrait indéfiniment.

Autres considérations

Sélectionner une architecture CPU

Deux architectures CPU différentes sont disponibles sur Cedar, soit Broadwell et Skylake. Pour indiquer votre choix, utilisez l'indicateur --constraint lors de la soumission de la tâche avec le nom de l'architecture en minuscules.

Par exemple, pour skylake :

#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --constraint=skylake
#SBATCH --time=0:5:0
# Display CPU-specific information with 'lscpu'. 
# Skylake CPUs will have 'avx512f' in the 'Flags' section of the output.
lscpu

Remarquez qu'une tâche qui aurait obtenu un nœud entier de type Skylake avec par exemple #SBATCH --cpus-per-task=32 partagerait les 16 cœurs CPU restants avec une autre tâche; pour réserver le nœud entier, il faut demander les 48 cœurs ou ajouter l'option #SBATCH --constraint=broadwell au script de la tâche.

N'utilisez pas cette option si vous êtes incertain que votre tâche nécessite une architecture particulière. Les tâches qui ne nécessitent pas une architecture CPU particulière peuvent être dirigées vers un nœud Broadwell ou Skylake et seront généralement traitées plus rapidement.

Dépannage

Pour éviter les caractères cachés

Le fait d'utiliser un logiciel de traitement de texte plutôt qu'un éditeur de texte peut causer des problèmes à vos scripts. En travaillant sur la grappe directement, il est préférable d'utiliser un éditeur comme nano, vim ou emacs. Si vous préparez vos scripts hors ligne,

  • sous Windows
    • utilisez un éditeur de texte comme Notepad ou Notepad++
    • téléversez le script et changez les codes de fin de ligne Windows pour des codes de fin de ligne Linux avec dos2unix
  • sous Mac
    • dans une fenêtre terminal utilisez un éditeur comme nano, vim ou emacs

Annulation de tâches dont les conditions de dépendance ne sont pas satisfaites

Une tâche dépendante soumise avec dependency=afterok:<jobid> attend que la tâche parent soit complétée avant de s'exécuter. Si la tâche parent s'arrête avant sa complétion (c'est-à-dire qu'elle produit un code de sortie non nul), la tâche dépendante ne sera jamais exécutée et elle est automatiquement annulée. Pour plus d'information sur la dépendance, voir sbatch.

Module non chargé par une tâche

L'erreur suivante peut survenir si une condition n'est pas satisfaite :

Lmod has detected the following error: These module(s) exist but cannot be
loaded as requested: "<module-name>/<version>"
   Try: "module spider <module-name>/<version>" to see how to load the module(s).

Par exemple,

[name@server]$ module load gcc
[name@server]$ module load quantumespresso/6.1
Lmod has detected the following error:  These module(s) exist but cannot be loaded as requested: "quantumespresso/6.1"
   Try: "module spider quantumespresso/6.1" to see how to load the module(s).
[name@server]$ module spider quantumespresso/6.1

-----------------------------------------
  quantumespresso: quantumespresso/6.1
------------------------------------------
    Description:
      Quantum ESPRESSO is an integrated suite of computer codes for electronic-structure calculations and materials modeling at the nanoscale. It is based on density-functional theory, plane waves, and pseudopotentials (both
      norm-conserving and ultrasoft).

    Properties:
      Chemistry libraries/apps / Logiciels de chimie

    You will need to load all module(s) on any one of the lines below before the "quantumespresso/6.1" module is available to load.

      nixpkgs/16.09  intel/2016.4  openmpi/2.1.1

    Help:

      Description
      ===========
      Quantum ESPRESSO  is an integrated suite of computer codes
       for electronic-structure calculations and materials modeling at the nanoscale.
       It is based on density-functional theory, plane waves, and pseudopotentials
        (both norm-conserving and ultrasoft).


      More information
      ================
       - Homepage: http://www.pwscf.org/

Pour résoudre ce problème, ajoutez au script la ligne module load nixpkgs/16.09 intel/2016.4 openmpi/2.1.1 avant de charger quantumespresso/6.1

Propagation de variables d’environnement

Par défaut, une tâche hérite des variables d’environnement de l’interpréteur (shell) duquel elle a été lancée. La commande de chargement d’un module modifie et configure les variables d’environnement qui se propagent ensuite aux tâches soumises à partir de l’interpréteur. Une tâche pourrait donc se trouver incapable de charger des modules si toutes les conditions ne sont pas satisfaites. Il est donc recommandé d’ajouter au script la ligne module purge avant le chargement des modules dont vous avez besoin pour faire en sorte que les tâches soient soumises de manière uniforme et qu’elles ne soient pas affectées par les modifications faites dans l’interpréteur.

Les problèmes sont quelquefois difficiles à diagnostiquer quand les paramètres de l'environnement sont hérités de l'interpréteur qui soumet la tâche; la directive --export=none empêche ce type d'héritage.

État des tâches et priorité

Consultez Politique d'ordonnancement des tâches pour des renseignements sur la politique de priorisation des tâches sur Cedar et Graham et connaitre les éléments pouvant influer sur l'ordonnancement de vos tâches.

Pour plus d'information

Categorie:SLURM