sbatch==
La commande sbatch est utilisée pour soumettre une tâche.
#SBATCH et doivent précéder toutes les commandes exécutables. La [https://slurm.schedmd.com/sbatch.html page sbatch] décrit toutes les directives disponibles. Pour chaque tâche, notre politique demande de fournir au moins une durée (--time) et un nom de compte (--account); voyez la section [[Running jobs/fr#Comptes_et_projets|Comptes et projets]] ci-après.
Les directives peuvent aussi être des arguments en ligne de commande pour sbatch. Par exemple,
$ 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. Sachez que la durée a une incidence importante sur le temps d'attente avant que la tâche soit exécutée. En effet, les tâches de longue durée sont [[Job_scheduling_policies/fr|susceptibles d'être exécutées sur moins de nœuds]].
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 et utilisatrices (voir l'information sur le message d'erreur [[Frequently_Asked_Questions/fr#sbatch:_error:_Batch_job_submission_failed:_Socket_timed_out_on_send/recv_operation|Batch job submission failed: Socket timed out on send/recv operation]]). Utilisez plutôt un [[Running jobs/fr#Redémarrage_avec_des_vecteurs_de_tâches|vecteur de tâches]] ou espacez les appels à sbatch de une seconde ou plus avec la commande sleep.
=== Mémoire ===
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). Avec les grappes d'usage général, 256Mo par cœur sont alloués par défaut. Avec [[Niagara/fr|Niagara]], il n'est pas nécessaire de spécifier la quantité de mémoire car seuls les nœuds entiers sont alloués avec toute la mémoire disponible.
Une source commune de confusion est qu'une certaine quantité de la mémoire du nœud n'est pas disponible pour la tâche, étant réservée pour le système d'exploitation, etc. Chaque type de nœud a donc une quantité maximum à la disposition des tâches; par exemple, les nœuds de 128Go sont configurés de façon à offrir 125Go pour l'exécution des tâches soumises. Si vous demandez plus que cette quantité, votre tâche devra être exécutée avec des nœuds de plus de mémoire qui pourraient être moins nombreux.
Pour compliquer davantage, K, M, G, etc. sont interprétés par Slurm comme étant des [https://fr.wikipedia.org/wiki/Pr%C3%A9fixe_binaire préfixes binaires]; ainsi --mem=125G équivaut à --mem=128000M. La quantité de mémoire que vous pouvez demander est indiquée dans le tableau Caractéristiques des nœuds pour [[Béluga#Caractéristiques_des_nœuds|Béluga]], [[Cedar/fr#Caractéristiques_des_nœuds|Cedar]], [[Graham/fr#Caractéristiques_des_nœuds|Graham]] et [[Narval#Caractéristiques_des_nœuds|Narval]].
==Lister les tâches avec squeue ou sq==
La commande utilisée pour vérifier le statut des tâches Slurm est squeue; par défaut, elle fournit l'information sur toutes les tâches. La forme courte sq ne listera que vos propres tâches.
sq et squeue, et comment modifier les résultats, consultez la [https://slurm.schedmd.com/squeue.html documentation pour squeue]. sq est une commande créée pour nos environnements.
N'exécutez pas à plusieurs reprises et à de courts intervalles les commandes squeue ou sq à partir d'un script ou d'une application. Ceci surcharge Slurm et risque fort de nuire à sa performance ou à son bon fonctionnement. Pour savoir quand une tâche commence et se termine, voyez plutôt [[Running jobs/fr#Obtenir_des_renseignements_par_courriel | Obtenir des renseignements par courriel]] ci-dessous.
==Enregistrer le résultat==
Par défaut, le résultat est écrit dans un fichier dont le nom commence par slurm-, suivi de l'ID de la tâche et du suffixe .out, par exemple slurm-123456.out. La présence de l'ID dans le nom du fichier s'avère pratique pour le débogage. Le fichier est placé dans le répertoire à partir duquel la tâche a été soumise.
Si vous avez besoin de spécifier un endroit ou un nom différent, utilisez la commande --output.
Le nom du fichier peut contenir certains symboles de remplacement, par exemple l'ID de la tâche, le nom de la tâche ou l'ID du [[Job arrays/fr|vecteur de tâches]]. Voyez la [https://slurm.schedmd.com/sbatch.html page sbatch] pour la liste complète.
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 [[Frequently_Asked_Questions_about_the_CCDB/fr#Qu.27est-ce_qu.27un_RAP.3F|RAP (pour Resource Allocation Project]]). Si vous êtes membre d'un seul compte, l'ordonnanceur associe automatiquement vos tâches à ce compte.
Si vous recevez un des messages suivants en soumettant une tâche, vous avez accès à plus d'un compte.
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:Dans ce cas, utilisez la directive
--account pour spécifier un des comptes listés dans le message d'erreur, par exemple
#SBATCH --account=def-user-ab
Pour connaître le nom du compte correspondant à un projet,
connectez-vous à [https://ccdb.alliancecan.ca CCDB]
et cliquez sur Mon compte -> Mes ressources et allocations 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-fuenma seront attribuées à zhf-914-aa.
[[File:Find-group-name-FR.png|750px|frame|left| Comment trouver le nom du groupe pour un projet d'allocation de ressources (RAP)]]
~/.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|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
|name=array_job.sh
|lang="sh"
|contents=
#!/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 [[Job arrays/fr|Vecteurs de tâches]] et la documentation détaillée [https://slurm.schedmd.com/job_array.html 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
|name=openmp_job.sh
|lang="sh"
|contents=
#!/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 MPI ===
Le prochain script lance quatre processus MPI, chacun nécessitant 1024Mo de mémoire. Le temps d'exécution est limité à cinq minutes.
{{File
|name=mpi_job.sh
|lang="sh"
|contents=
#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --ntasks=4 # nombre de processus MPI
#SBATCH --mem-per-cpu=1024M # memoire (par défaut en mégaoctets)
#SBATCH --time=0-00:05 # limite de temps (JJ-HH:MM)
srun ./mpi_program # mpirun et mpiexec fonctionnent aussi
}}
Les tâches intensives avec MPI, 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 MPI et en fils multiples. Pour plus d'information sur les tâches distribuées en parallèle, consultez [[Advanced_MPI_scheduling/fr|Contrôle de l'ordonnancement avec MPI]].
Pour plus d'information, consultez la page [[OpenMP/fr|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/fr|Cedar]] et [[Graham/fr|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 [[Using GPUs with Slurm/fr|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 [https://slurm.schedmd.com/salloc.html salloc]. Dans l'exemple suivant, nous avons une tâche sur un cœur CPU et 3Go de mémoire, pour une durée d'une heure.
$ salloc --time=1:0:0 --mem-per-cpu=3G --ntasks=1 --account=def-someuser
salloc: Granted job allocation 1234567
$ ... # do some work
$ exit # terminate the allocation
salloc: Relinquishing job allocation 1234567
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/fr|SSH]]. Prenez note qu'une tâche interactive d'une durée de moins de trois (3) heures est susceptible d'être lancée peu de temps après sa soumission puisque nous leur avons dédié des nœuds de test. Les tâches de plus de trois (3) heures sont exécutées sur les nœuds réguliers d'une grappe et peuvent être en attente pour plusieurs heures et même plusieurs jours avant d'être lancées à un moment imprévisible et possiblement inopportun.
== Suivi des tâches ==
=== Tâches en cours ===
Par défaut, [https://slurm.schedmd.com/squeue.html 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
Vous pouvez aussi utiliser la forme courte sq.
Pour connaître les tâches en cours d'exécution ou en attente, utilisez
$ squeue -u squeue à plusieurs reprises et à de courts intervalles à partir d'un script ou d'une application. Cette commande surcharge Slurm et risque fort de nuire à sa performance ou à son bon fonctionnement.
==== Obtenir des renseignements par courriel ====
Pour recevoir par courriel certains renseignements sur une tâche, utilisez les diverses options avec
#SBATCH --mail-user=your.email@example.com
#SBATCH --mail-type=ALL
Utilisez ces options uniquement si vous avez l'intention de lire tous les messages qui seront générés.
Il arrive que nos fournisseurs de service (Google, Yahoo, etc.) limitent le nombre de courriels en provenance de nos domaines parce que trop de messages sont générés.
Pour la liste des options pour --mail-type, consultez [https://slurm.schedmd.com/sbatch.html#OPT_mail-type la documentation de SchedMD].
==== Résultats en mémoire tampon ====
Normalement, les résultats d'une tâche non interactive sont mis en mémoire tampon (buffered), ce qui veut dire qu'il y a habituellement un temps d'attente entre le moment où les données de la tâche sont enregistrées et celui où vous pouvez voir les résultats dans un nœud de connexion. Ce temps d'attente dépend de l'application que vous utilisez et de la charge exercée sur le système de fichiers; il peut varier de moins d'une seconde à jusqu'à ce que la tâche se termine.
Il existe des façons de réduire ou même d'éliminer ce temps d'attente, mais elles ne sont pas recommandées parce que l'utilisation de la mémoire tampon assure la bonne performance générale du système de fichiers. Si vous avez besoin de faire le suivi des résultats d'une tâche en temps réel, utilisez plutôt une [[#Tâches_interactives|tâche interactive]], comme décrit ci-dessus.
=== Tâches terminées ===
La commande seff permet d'obtenir un sommaire de l'efficacité en CPU et mémoire pour une tâche terminé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 [https://slurm.schedmd.com/sacct.html sacct]; ajoutez --format pour savoir le résultat de la tâche, ainsi
$ sacct -j sacct inclut généralement des enregistrements .bat+ et .ext+, et possiblement aussi .0, .1, .2, ....
L'étape batch (.bat+) est votre script de soumission; pour plusieurs tâches, c'est ici que s'effectue la plus grande part du travail et que les ressources sont consommées.
Si vous utilisez srun dans votre script de soumission, une étape .0 serait créée, ce qui consommerait presque toutes les ressources.
L'étape externe (.ext+) est surtout en prologue et en épilogue et ne consomme habituellement pas une grande quantité de ressources.
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 [https://fr.wikipedia.org/wiki/Resident_set_size resident set size]. Pour connaître la tâche et le nœud en cause, imprimez aussi les champs MaxRSSTask et MaxRSSNode.
La commande [https://slurm.schedmd.com/sstat.html sstat] fournit des renseignements sur l'état d'une tâche en cours d'exécution; la commande [https://slurm.schedmd.com/sacct.html sacct] est utilisée pour les tâches qui sont terminé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 [https://developer.nvidia.com/nvidia-system-management-interface 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.
$ srun --jobid 123456 --pty watch -n 30 nvidia-smi
Plusieurs commandes de surveillance peuvent être lancées avec [https://fr.wikipedia.org/wiki/Tmux 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.
$ 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.
== Annuler une tâche ==
Pour annuler une tâche, spécifiez son identifiant ainsi
$ scancel --array=1-100%10 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
|name=job_array_restart.sh
|lang="sh"
|contents=
#!/bin/bash
# ---------------------------------------------------------------------
# script Slurm pour une tâche de plusieurs étapes
# ---------------------------------------------------------------------
#SBATCH --account=def-someuser
#SBATCH --cpus-per-task=1
#SBATCH --time=0-10:00
#SBATCH --mem=100M
#SBATCH --array=1-10%1 # exécuter un vecteur de 10 tâches, une à la fois
# ---------------------------------------------------------------------
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 ""
# ---------------------------------------------------------------------
# exécuter l'étape de simulation ici...
if test -e state.cpt; then
# il y a un point de contrôle, redémarrer
mdrun --restart state.cpt
else
# il n'y a pas de point de contrôle, commencer une nouvelle 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 ne soit échu,
le script vérifie si le calcul est terminé.
Si le calcul n'est pas terminé, le script soumet une copie de lui-même et poursuit le travail.
Resoumission avec un script :
{{File
|name=job_resubmission.sh
|lang="sh"
|contents=
#!/bin/bash
# ---------------------------------------------------------------------
# script Slurm pour resoumettre une tâche
# ---------------------------------------------------------------------
#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`"
# ---------------------------------------------------------------------
# exécuter l'étape de simulation ici...
if test -e state.cpt; then
# il y a un point de contrôle, redémarrer
mdrun --restart state.cpt
else
# il n'y a pas de point de contrôle, commencer une nouvelle simulation
mdrun
fi
# resoumettre si le travail n'est pas encore terminé
# définir la fonction 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.
== Automatiser la soumission de tâches ==
Comme nous l'avons déjà mentionné, [[Running jobs/fr#Lot_de_tâches|les lots de tâches]] peuvent être utilisés pour automatiser la soumission des tâches. Nous offrons quelques autres outils plus avancés pour l'exécution d'un grand nombre de tâches séquentielles, parallèles ou utilisant des GPU. Ces outils appliquent une technique nommée farming, serial farming ou task farming qui se traduit par grappe de serveurs et parfois ferme de serveurs ou ferme de calcul. En plus d'automatiser le flux du travail, ces outils améliorent l'efficacité du traitement en regroupant plusieurs petites tâches de calcul pour créer moins de tâches, mais qui ont des durées plus longues.
Les outils suivants sont disponibles sur nos grappes :
* [[META-Farm/fr | META-Farm]]
* [[GNU Parallel/fr | GNU Parallel]]
* [[GLOST/fr | GLOST]]
=== Ne pas spécifier de partition ===
Avec certains paquets logiciels comme [https://github.com/alekseyzimin/masurca Masurca], les tâches sont soumises à Slurm de façon automatique et le logiciel s'attend à ce qu'une partition soit spécifiée pour chacune des tâches. Ceci est contraire à nos meilleures pratiques qui veulent que l'ordonnanceur assigne les tâches de lui-même, selon les ressources requises. Si vous utilisez un tel logiciel, vous pouvez le configurer afin qu'il utilise --partition=default pour que le script l'interprète comme si aucune partition n'est spécifiée.
== Particularités de certaines grappes ==
Les politiques d'ordonnancement ne sont pas les mêmes sur toutes nos grappes.
/home; ceci a pour but de diminuer la charge et d'améliorer le temps de réponse en mode interactif. La durée maximale d'une tâche est de 28 jours. Si la commande readlink -f $(pwd) | cut -d/ -f2 retourne le message you are not permitted to submit jobs from that directory, transférez les fichiers vers un répertoire /project ou /scratch et soumettez la tâche à partir du nouvel emplacement.
L'ordonnancement se fait par nœud, donc en multiples de 40 cœurs.
La durée d'exécution maximale d'une tâche est de 24 heures.
L'écriture doit se faire dans les répertoires scratch ou project (sur les nœuds de calcul, ''home'' est en lecture seulement).
Les nœuds de calcul n'ont pas d'accès internet.
[[Data management at Niagara/fr#Déplacer_des_données|Déplacez vos données]] vers Niagara avant de soumettre votre tâche.
dos2unix
* sous Mac
** dans une fenêtre de 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: attend que la tâche parent soit terminée avant de s'exécuter. Si la tâche parent s'arrête avant sa fin (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 [https://slurm.schedmd.com/sbatch.html#OPT_dependency 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 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 [[Utiliser des modules|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.
==== Tâche gèle / pas de résultats / résultats incomplets ====
Il arrive qu'aucun résultat (ou seulement une partie) ne soit enregistré dans le fichier .out pour une tâche qui a été soumise, et qu'il semble qu'elle soit arrêtée. Ceci se produit surtout parce que la [[#Résultats_en_mémoire_tampon|mise en mémoire tampon]] effectuée par l'ordonnanceur Slurm est agressive, car il regroupe plusieurs lignes de résultat avant de les acheminer vers le fichier, et souvent celui-ci n'est produit que quand la tâche se termine. Pire encore, si une tâche est annulée ou manque de temps, une partie des résultats peut être perdue. Si vous voulez suivre le progrès de la tâche en cours au fur et à mesure de son exécution, vous pouvez le faire avec une [[#Tâches_interactives|tâche interactive]]. C'est aussi une bonne façon d'observer combien de temps la tâche a besoin.
==État des tâches et priorité==
* Consultez [[Job scheduling policies/fr|Politique d'ordonnancement des tâches]] pour des renseignements sur la politique de priorisation des tâches sur Cedar et Graham et connaître les éléments pouvant influer sur l'ordonnancement de vos tâches.
* Si des tâches dans votre groupe de recherche sont en concurrence entre elles, consultez [[Managing_Slurm_accounts/fr|Gestion des comptes Slurm]].
== Pour plus d'information ==
* SchedMD : [https://slurm.schedmd.com/documentation.html documentation Slurm] et [https://slurm.schedmd.com/tutorials.html tutoriels]
** options pour la commande [https://slurm.schedmd.com/sbatch.html sbatch]
* [https://slurm.schedmd.com/rosetta.pdf correspondance de commandes et directives] Slurm avec PBS/Torque, LSF, SGE et LoadLeveler
* CÉCI, Belgique : [http://www.ceci-hpc.be/slurm_tutorial.html tutoriel Slurm]
* Bright Computing : tutoriel concis [http://www.brightcomputing.com/blog/bid/174099/slurm-101-basic-slurm-usage-for-linux-clusters Slurm sous Unix]
[[Categorie:SLURM]]