Document Actions
LoadLeveler
Description de la soumission des calculs avec le logiciel LoadLeveler
- Introduction
- Utilisation de Loadleveler
- Fonctionnement du batch au CRIHAN
- Codes d'erreur lors de la soumission
- Gestion des ressources demandées
- Estimation des ressources mémoire et utilisation des processeurs
- Scripts de soumission
Introduction
Le mode d'exécution batch consiste à préparer un ensemble de commandes dans un fichier (appelé script) puis à le soumettre à Loadleveler, le gestionnaire de travaux d'IBM.Cet ensemble de commandes est appelé "job". La soumission d'un job correspond à une requête de la part de l'utilisateur et l'exécution de ce job peut être caractérisée par un ou plusieurs processus.
Les ressources par job, demandées par l'utilisateur, correspondent à :
- la mémoire par requête et par processus,
- le temps de présence du job dans la queue (temps de restitution pour la requête),
- le nombre de processus,
- l'espace disque temporaire nécessaire à l'exécution (imposé pour le moment).
Lorsqu'un job est soumis à Loadleveler, celui-ci va analyser le script, prendre en compte les ressources demandées par le job et chercher un créneau pour l'exécution. Il utilise le principe du backfilling. C'est pour cette raison qu'il n'y a plus de queues batch avec des limites spécifiques pour chacune d'entre-elles.
Utilisation de Loadleveler
Quatre commandes permettent aux utilisateurs de gérer les soumissions de job sur le cluster IBM.llstatus
La commande llstatus -R permet de connaitre les ressources disponibles (d'après les ionformations en possession de Loadleveler) :| llstatus -R | |
| Machine | Consumable Resource(Available, Total) |
| ------------------------------ | ------------------------------------------------- |
| p5-a1-n1.crihan.fr | ConsumableCpusCrihan(5,8) ConsumableMemCrihan(8640,10240) ConsumableStackCrihan(1648,2048) |
| p5-a1-n10.crihan.fr | ConsumableCpusCrihan(0,8) ConsumableMemCrihan(6240,10240) ConsumableStackCrihan(1048,2048) |
| p5-a1-n11.crihan.fr | ConsumableCpusCrihan(0,8) ConsumableMemCrihan(6640,10240) ConsumableStackCrihan(1148,2048) |
| p5-a1-n12.crihan.fr | ConsumableCpusCrihan(4,8) ConsumableMemCrihan(3240,10240) ConsumableStackCrihan(1460,2048) |
| p5-a1-n13.crihan.fr | ConsumableCpusCrihan(2,8) ConsumableMemCrihan(4270,10240) ConsumableStackCrihan(764,2048) |
| p5-a1-n14.crihan.fr | ConsumableCpusCrihan(0,8) ConsumableMemCrihan(640,10240) ConsumableStackCrihan(148,2048) |
| p5-a1-n17.crihan.fr | ConsumableCpusCrihan(3,8) ConsumableMemCrihan(1240,10240) ConsumableStackCrihan(48,2048) |
| p5-a1-n18.crihan.fr | ConsumableCpusCrihan(2,8) ConsumableMemCrihan(1240,10240) ConsumableStackCrihan(548,2048) |
| p5-a1-n19.crihan.fr | ConsumableCpusCrihan(4,8) ConsumableMemCrihan(8984,10240) ConsumableStackCrihan(1548,2048) |
| p5-a1-n2.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n20.crihan.fr | ConsumableCpusCrihan(6,8) ConsumableMemCrihan(7240,10240) ConsumableStackCrihan(1548,2048) |
| p5-a1-n21.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n22.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n23.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n24.crihan.fr | ConsumableCpusCrihan(0,8) ConsumableMemCrihan(7390,10240) ConsumableStackCrihan(1148,2048) |
| p5-a1-n3.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n4.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n5.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n6.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n7.crihan.fr | ConsumableCpusCrihan(3,8) ConsumableMemCrihan(1240,10240) ConsumableStackCrihan(48,2048) |
| p5-a1-n8.crihan.fr | ConsumableCpusCrihan(8,8) ConsumableMemCrihan(10240,10240) ConsumableStackCrihan(2048,2048) |
| p5-a1-n9.crihan.fr | ConsumableCpusCrihan(0,8) ConsumableMemCrihan(6990,10240) ConsumableStackCrihan(1048,2048) |
Les ConsumableCpusCrihan correspondent à des tickets processeurs sur chacun des noeuds : un ticket = un processeur Power5.
Les ConsumableMemCrihan correspondent à des tickets mémoire (pour les données) sur chacun des noeuds : un ticket = un Mo de mémoire de LARGE PAGES
Les ConsumableStackCrihan correspondent à des tickets mémoire (pour la stack) sur chacun des noeuds : un ticket = un Mo de mémoire de SMALL PAGES
llsubmit
La commande llsubmit permet de soumettre un travail au calculateur. La syntaxe est llsubmit job_script. On obtient alors une référence numéro_job (de la forme ll-william.xxxxx.0 ou ll-averell.xxxxx.0) qui permet de suivre la soumission ou de détruire le job.
llq
La commande llq permet de suivre son exécution.
On obtient un tableau récapitulatif de tous les jobs présents à ce moment classés par autres décroissant de priorité. Pour chaque job, on connait son numéro_job, le login de son propriéraire, le jour et l'heure de sa soumission, son statut (R = Running, I = Idle soit en attente) et le cas échéant le noeud d'exécution.
Pour les jobs MPI à cheval, il s'agit du noeud père.
| Id | Owner | Submitted | ST | PRI | Class | Running On |
| ------------------------ | ---------- | ----------- | -- | --- | ------------ | ----------- |
| william-a1.1761.0 | < login > | 1/25 08:14 | R | 50 | court | p5-a1-n1 |
| william-a1.1765.0 | < login > | 1/25 09:18 | R | 50 | long | p5-a1-n24 |
| william-a1.1770.0 | < login > | 1/25 09:57 | R | 50 | hps_long | p5-a1-n18 |
| william-a1.1793.0 | < login > | 1/25 17:12 | R | 50 | court | p5-a1-n11 |
| william-a1.1794.0 | < login > | 1/25 17:12 | R | 50 | long | p5-a1-n24 |
| william-a1.1870.0 | < login > | 1/30 13:22 | R | 50 | hps_court | p5-a1-n2 |
| william-a1.1867.0 | < login > | 1/30 11:59 | R | 50 | indus | p5-a1-n19 |
| william-a1.1848.0 | < login > | 1/30 09:21 | I | 50 | hps_indus | |
| william-a1.1869.0 | < login > | 1/30 12:41 | I | 50 | long | |
| 9 job step(s) in queue, 2 waiting, 0 pending, 9 running, 0 held, 0 preempted | ||||||
llcancel
La commande llcancel permet de détruire un job à n'importe quel moment. L'espace temporaire est détruit sans récupération de fichiers résultats. La syntaxe est llcancel numéro_job.Fonctionnement du batch au CRIHAN
Le batch repose sur l'utilisation de scripts de soumission, des exemples sont proposés.
Ces scripts contiennent l'expression des besoins en ressources diverses pour la bonne exécution des travaux à soumettre. Il s'agit de :
- le nombre de processeurs (applications parallèles) avec le mot clé # @ cri_total_tasks
- la quantité de mémoire PAR processus (au sens AIX, attention aux codes threadés tels OpenMP, Gaussian, ...) avec le mot clé # @ data_limit
- la quantité de stack PAR processus (au sens AIX, attention aux codes threadés tels OpenMP, Gaussian, ...) avec le mot clé # @ stack_limit
- le temps de présence de l'application avec le mot clé # @ wall_clock_limit
- la limite en taille des fichiers core avec le mot clé # @ core_limit
L'UTILISATEUR DOIT SPECIFIER SES BESOINS À L'AIDE DES MOTS CLES PRECEDENTS.
La procédure contient un prologue et un épilogue pour gérer l'espace disque et les transferts des fichiers. En effet, les exécutions des jobs des utilisateurs n'ont pas lieu dans les espaces permanents mais dans un espace temporaire spécialement conçu à cette fin. Cela permet de profiter d'espaces diques plus grands que ceux alloués de manière permanente aux utilisateurs.
L'espace temporaire total est de l'ordre de 8 To.
Les différentes étapes de la procédure sont les suivantes :
- Le job est soumis à Loadleveler au travers d'un script par la commande llsubmit.
- Le script est alors analysé pour vérifier que les informations nécessaires sont bien présentes. Si ce n'est pas le cas, la soumission est rejetée.
- Loadleveler cherche à réserver les ressources demandées. Si elles sont disponibles, le job est alors exécuté. Dans le cas contraire, il est mis en attente et Loadleveler recherche un créneau horaire pour le faire passer. Cela signifie qu'il réserve les ressources demandées pour un moment bien précis. Cette procédure, appelée backfilling, lui permet de boucher les trous entre les gros jobs avec ses petits jobs. Pour pouvoir appliquer cette stratégie, Loadleveler utilise le temps de restitution du job sur le calculateur (paramètre wall_clock_limit).
- C'est à ce moment que l'on connait le(s) noeud(s) d'exécution : c'est forcément un noeud p575.
- Une fois les ressources disponibles, commence le prologue : la préparation de l'environnement d'exécution. Elle consiste d'une part en la création d'espace de travail temporaire d'autre part au transfert des fichiers spécifiés par l'utilisateur vers cet espace.
- Les commandes utilisateurs sont alors exécutées. Seule cette partie est concernée par le wall_clock_limit, i.e. le temps de restitution du job sur la machine. L'exécution a lieu dans les espace temporaire crée dans le prologue.
- En fin d'exécution, arrive l'épilogue. A ce moment est renvoyée dans la sortie standard une valeur échantillonnée de la mémoire consommée par processus pour les données globales. Elle donne un ordre de grandeur fiable pour la data_limit à renseigner dans les scripts et permet d'affiner ainsi les besoins en ressources pour des soumissions analogues ultérieures.
Attention : si le wall_clock_limit est atteint, l'espace disque temporaire est préservé pendant trois semaines (et non plus détruit immédiatement) afin de permettre à l'utilisateur de récupérer ses fichiers).Les fichiers spécifiés par l'utilisateur sont alors mis de côté (déplacés et non pas copiés pour être le plus rapide possible) dans un espace spool. Ils sont ensuite transférés vers le répertoire spécifique de l'espace permanent de l'utilisateur. Si un problème survient lors du transfert final (e.g., quota disque de l'espace permanent atteint), l'utilisateur est averti et les fichiers sont préservés quelques jours le temps qu'il fasse le ménage.
Il faut noter que le but est de ne renvoyer dans l'espace de l'utilisateur que les fichiers réellement souhaités par celui-ci : on pourrait en effet renvoyer tous les fichiers en fin d'exécution, mais dans le cas de certaines applications très gourmandes en espace disque temporaire, cela remplirait l'espace permanent de l'utilisateur et engorgerait le réseau entre les noeuds et la baie de stockage FastT500 sans intérêt pour lui.
Le diagramme suivant reprend la procédure de la gestion des jobs. Voici la signification des variables y figurant :
| Variable employée | Usage |
|---|---|
| $LOCAL_WORK_DIR | Elle représente le répertoire temporaire crée par le système et alloué au job pour son exécution ; ->/dlocal/run/ll-william.xxxx.0 ou ->/dlocal/run/ll-averell.xxxx.0 |
| CRI_INITIALDIR | Elle représente le répertoire spécifié par l'utilisateur dans son espace permanent sur la baie FastT500 dont le contenu est dupliqué dans l'espace temporaire $LOCAL_WORK_DIR. Ce répertoire est soit dans le /home, soit dans le /work de l'utilisateur, il doit être lisible, non vide et ne doit contenir aucun lien symbolique ; ->/work/projet/login/REPERTOIRE_ENTREE |
| CRI_FINALDIR | Elle représente le répertoire spécifié par l'utilisateur dans son espace permanent sur la baie FastT500 dans lequel les fichiers spécifiés par l'utilisateur sont rapatriés par le système. Il doit être dans le/home ou le /work de l'utilisateur avec des droits d'écriture. S'il n'existe pas, le système essaye de le créer ; ->/work/projet/login/REPERTOIRE_SORTIE |
| $LOCAL_SPOOL_DIR | Elle représente le répertoire temporaire crée par le système qui sert de transit avant le rapatriement vers l'espace permanent de l'utilisateur situé dans la baie FastT500. ->/dlocal/spool/ll-william.xxxx.0 ou ->/dlocal/run/ll-averell.xxxx.0 |
| $LOCAL_SCRATCH_DIR | Variable obsolète |
Codes d'erreur lors de la soumission
Lors de la soumission des jobs, une erreur fatale peut survenir. Dans ce cas elle renvoie un code qui se trouve dans le tableau ci-dessous :| Codes d'erreur | Signification |
|---|---|
| 0 | tout va bien ! |
| Erreurs liées à l'environnement | |
| 101 | l'exécution a lieu en dehors de l'environnement Loadleveler |
| 102 | utilisateur ou groupe non autorisé |
| 103 | les variables d'environnement Loadleveler sont absentes |
| 104 | les variables d'environnement $HOME_DIR et $WORK_DIR ne désignent pas des répertoires |
| 105 | l'utilisateur n'a pas les droits de lecture et d'écriture sur $HOME_DIR |
| 106 | l'utilisateur n'a pas les droits de lecture et d'écriture sur $WORK_DIR |
| Erreurs liées au prologue | |
| 110 | on a perdu le système de fichiers /dlocal/run |
| 111 | on a perdu le système de fichiers /dlocal/spool |
| 112 | la variable cri_initialdir n'est pas renseignée |
| 113 | il y a une erreur de syntaxe dans le nom du cri_initialdir (pas de ../ et de ;) |
| 114 | le répertoire cri_initialdir n'est pas dans /home/... ou /work/... |
| 115 | le répertoire cri_initialdir n'existe pas |
| 116 | le cri_initialdir doit être un répertoire |
| 117 | le cri_initialdir n'est pas autorisé en lecture |
| 118 | le cri_initialdir est vide |
| 119 | il y a des liens symboliques dans l'arborescence du cri_initialdir qui ne sont jamais suivis |
| 120 | la variable cri_finaldir n'est pas renseignée |
| 121 | il y a une erreur de syntaxe dans le nom du cri_finaldir (pas de ../ et de ;) |
| 122 | le répertoire cri_finaldir n'est pas dans /home/... ou /work/... |
| 123 | le répertoire cri_finaldir n'existe pas et n'a pu être crée |
| 124 | le cri_finaldir doit être un répertoire |
| 125 | le cri_finaldir n'est pas autorisé en écriture |
| 126 | la copie des fichiers du cri_initialdir vers le $LOCAL_WORK_DIR s'est mal passée |
| 127 | le répertoire $LOCAL_WORK_DIR ne peut pas être crée |
| 128 | le répertoire $LOCAL_SPOOL_DIR ne peut pas être crée |
| 129 | le répertoire $LOCAL_SCRATCH_DIR ne peut pas être crée |
| Erreurs liées à l'épilogue | |
| 210 | crash du job durant l'exécution |
| 211 | le répertoire temporaire $LOCAL_SPOOL_DIR n'existe plus |
| 212 | $LOCAL_SPOOL_DIR n'est plus un répertoire |
| 213 | une erreur est survenue lors de la recopie des fichiers du $LOCAL_SPOOL_DIR vers le répertoire cri_finaldir |
| 255 | autre erreur ; contacter l'assistance technique |
Tous les codes supérieurs à 100 sont des codes CRIHAN.
Gestion des ressources demandées
Expressions des ressources demandées
Le batch repose sur l'utilisation de scripts de soumission.
Ces scripts contiennent l'expression des besoins en ressources diverses pour la bonne exécution des travaux à soumettre. Il s'agit de :
- le nombre de processeurs (applications parallèles) avec le mot clé # @ cri_total_tasks
- la quantité de mémoire PAR processus (au seins AIX, attention aux codes threadés tels OpenMP, Gaussian, ...) avec le mot clé # @ data_limit
- la quantité de stack PAR processus (au seins AIX, attention aux codes threadés tels OpenMP, Gaussian, ...) avec le mot clé # @ stack_limit
- le temps de présence de l'application avec le mot clé # @ wall_clock_limit
- la limite en taille des fichiers core avec le mot clé # @ core_limit
L'UTILISATEUR DOIT SPECIFIER SES BESOINS À L'AIDE DES MOTS CLES PRECEDENTS.
Limitations des ressources demandées
Les applications de cri_job_type mpi sont par défaut autorisées à s'exécuter à cheval sur plusieurs noeuds.Remarque :
Pour forcer l'exécution d'une application mpi sur un seul noeud, pour un nombre de tâches inférieur ou égal à huit, il faut insérer la ligne suivante dans le script de soumission :
Cela a pour effet d'imposer le partage de votre application en blocs de processus dont la taille est le nombre total de processus de l'application MPI, soit 1 seul bloc et donc 1 seul noeud. Bien évidemment, les noeuds n'étant qu'octo-processeurs, cela ne fonctionne qu'avec moins de 8 processeurs et moins de 10 Go de mémoire pour les données.
Les limites ne sont pas liées uniquement au type de l'application et la taille du cluster : pour les travaux MPI, les nombre de processeurs et la mémoire accessibles dépendant de la durée demandée (wall_clock_limit).- Les 6 noeuds de calcul non switchés reçoivent des travaux de type serial, openmp, mpi (4 tâches), gaussian, gamess, jaguar, de classe "court" (durée inférieure ou égale à 48 H), "long" (durée inférieure ou égale à 100 H) ou "tlong" (durée inférieure ou égale 300 H).
- Sur les 16 noeuds de calcul switchés (interconnectés par le réseau haute performance Federation) :
- les jobs de tous types d'une durée supérieure à 48 H (16 tâches MPI au maximum), de classe "long" ou "hps_long", accèdent à 4 noeuds,
- les jobs de tous types d'une durée inférieure ou égale à 48 H (64 tâches MPI au maximum), de classe "court" ou hps_court", accèdent à la totalité des 16 noeuds.
La durée maximale d'un job est de 300 H.
Le tableau suivant résume les limitations de ressources :
| Application / cri_job_type | Contraintes |
| serial | 1 processeur / 10 Go de mémoire data 2 Go de mémoire stack |
| openmp | 8 processeurs / 10 Go de mémoire data 2 Go de mémoire stack |
| gaussian | 8 processeurs / 10 Go de mémoire data 2 Go de mémoire stack |
| gamess (version 2003) | 8 processeurs / 10 Go de mémoire data 2 Go de mémoire stack |
| jaguar | 8 processeurs / 10 Go de mémoire data 2 Go de mémoire stack |
| mpi | Si wall_clock_limit inférieur ou égal à 48 H : 64 processeurs / 80 Go de mémoire data 16 Go de mémoire stack Si wall_clock_limit supérieur à 48 H, inférieur ou égal à 100 H : 16 processeurs / 20 Go de mémoire data 4 Go de mémoire stack Si wall_clock_limit supérieur à 100 H, inférieur ou égal à 300 H : 4 processeurs / 10 Go de mémoire data 2 Go de mémoire stack |
Estimation des ressources mémoire et utilisation des processeurs
L'épilogue des travaux fournit des informations aux utilisateurs concernant la consommation mémoire et l'utilisation des processeurs.
La consommation mémoire maximale (max_rss) des données du programme (le "heap" ou "tas") est déterminé par LoadLeveler durant l'exécution en échantillonnant. Cela donne une idée assez précise du besoin maximal de l'application.
La valeur est comparée à la quantité de mémoire par processus transmise à LoadLeveler avec la data_limit. Si la proportion est inférieure à 80%, cela signifie que la demande mémoire est surdimensionnée de manière trop importante. Dans le cas d'une soumission ultérieure d'un travail analogue, il faut revoir à la baisse la quantité de mémoire requise. Ainsi le travail demandant moins de ressources peut être un peu plus facilement exécuté et les ressources réservées sont mieux utilisées.
Exemple de retour :
==========================================================================
ESTIMATION DE LA CONSOMMATION MEMOIRE DE VOTRE JOB
Utilisateur : gm
Projet : crihan
Script : /home/crihan/gm/.../omp_script.cmd
Maximum de memoire consommee : 5245012 ko
Memoire demandee a la soumission : 5632000 ko
Pourcentage utilise : 93 %
Quotient > 80 % : OK
==========================================================================
ou alors en situation de trop grand surdimensionnement :
==========================================================================
ESTIMATION DE LA CONSOMMATION MEMOIRE DE VOTRE JOB
Utilisateur : gm
Projet : crihan
Script : /home/crihan/gm/.../run/ll_mpi
Maximum de memoire consommee : 264068 ko
Memoire demandee a la soumission : 593920 ko
Pourcentage utilise : 44 %
Quotient < 80 % : probleme, vous demandez beaucoup trop de memoire
==========================================================================
L'occupation des processeurs permet de s'assurer que les processeurs demandés sont réellement occupés. Cela ne donne pas pour autant une estimation de la scalabilité ou de l'efficacité de l'application parallèle.
L'occupation des processeurs n'est effectuée que dans le cas de programmes parallèles et une durée d'exécution supérieure à 10 minutes. Exemple de sortie :
==========================================================================
ESTIMATION DE L'UTILISATION DES PROCESSEURS PAR VOTRE JOB
Utilisateur : gm
Projet : crihan
Script : /home/crihan/gm/.../run/ll_mpi
dispatchtime : 2007 Jan 23 15 01
currenttime : 2007 Jan 23 15 15
cputime : 24
nbprocs : 2
Utilisation : 85.714286 %
Utilisation > 80 % : OK
==========================================================================
Scripts de soumission
Les scripts de soumissions comportent plusieurs types d'informations :- l'expression des besoins des jobs : la mémoire par processus (pour les données ET pour la stack), le temps de présence du job dans la queue (temps de restitution pour la requête), le nombre de processus.
- des informations relatives aux fichiers transférés et aux espaces permanents correspondants.
- des informations sur l'environnement de l'utilisateur (variables, mails, ...).
- les commandes utilisateurs proprement dites.
Les trois premiers points reposent sur des directives, des mots-clés et exigent une syntaxe particulière. Le quatrième demande une syntaxe analogue aux commandes shell.
Plusieurs paramètres sont essentiels lors de la soumissions : le type de job, le nombre de processeurs demandés, le besoin en mémoire, etc ...
La liste des types de job est exhaustive et peut être complétée selon les besoins des utilisateurs. Elle comprend les types suivants : serial, mpi, openmp, gaussian, jaguar, gamess.
Les rubriques suivantes décrivent des exemples de scripts pour les différents types de jobs. Cette liste est exhaustive et sera complétée selon les besoins des utilisateurs.
----------------------------Script job séquentiel
| #!/bin/csh # Script de soumission Loadleveler, job sequentiel # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = sequentiel | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = serial | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit = 256mb | obligatoire | attention à l'option -bmaxdata du compilateur (rubrique édition des liens) |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 100mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ..) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_SEQ | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_SEQ | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| gunzip in.dat.gz ./a_seq_pwr5.out < in.dat > $LOCAL_SPOOL_DIR/out.dat gzip resultat.dat | les commandes du job | |
| mv out.dat resultat.dat.gz $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoire de spool adéquat |
Ce lien permet de récupérer le script pour un job séquentiel. ----------------------------
Script job parallèle MPI
| #!/bin/csh # Script de soumission Loadleveler, job MPI # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = MPI | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = mpi # Nombre de processus MPI # @ cri_total_tasks = 4 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit = 550mb | obligatoire | attention à l'option -bmaxdata du compilateur (rubrique édition des liens) |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 100mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ..) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_MPI | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_MPI | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| gunzip in.dat.gz ./a_mpi_pwr5.out < in.dat > $LOCAL_SPOOL_DIR/out.dat gzip resultat.dat | les commandes du job | |
| mv out.dat resultat.dat.gz $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoire de spool adéquat |
N.B. :
Les bonnes variables d'environnement de tuning MPI sont mises en place par Loadleveler.
Ce lien permet de récupérer le script pour un job parallèle MPI.
----------------------------Script job parallèle OpenMP
Attention !!
Sur les machines IBM, les threads OpenMP ne sont pas des "vrais" processus, mais des processus légers. D'un point de vue ressources consommées, elles sont donc incluses au sein de la thread maîtresse soit le "vrai" processus de l'application.
Il ne faut pas oublier que la data_limit est la mémoire par processus (au sens IBM), il faut donc que vous déterminez la consommation mémoire de toutes les threads et que vous affectiez cette somme à la variable data_limit dans le script de soumission batch.
| #!/bin/csh # Script de soumission Loadleveler, job OpenMP # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = openmp | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = openmp # Nombre de threads openmp # @ cri_total_tasks = 4 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ data_limit = 1024mb | obligatoire | attention à l'option -bmaxdata du compilateur (rubrique édition des liens) |
| # Stack maximale POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ stack_limit = 256mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_OMP | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_OMP | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| gunzip in.dat.gz ./a_omp_pwr5.out < in.dat > $LOCAL_SPOOL_DIR/out.dat gzip resultat.dat | les commandes du job | |
| mv out.dat resultat.dat.gz $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoire de spool adéquat |
N.B. :
Les bonnes variables d'environnement de tuning OpenMP sont mises en place par Loadleveler.
Ce lien permet de récupérer le script pour un job parallèle OpenMP.
----------------------------Script job parallèle Gaussian
Le descriptif ci-dessous fait référence à la version G03 c02 du code Gaussian. A la fin de cette rubrique vous pouvez aussi récupérer des scripts pour Gaussian G98.| #!/bin/csh # Script de soumission Loadleveler, job Gaussian # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = gaussian | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = gaussian # Nombre de threads gaussian # @ cri_total_tasks = 4 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ data_limit = 1500mb | obligatoire | |
| # Stack maximale POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ stack_limit = 256mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal POUR L'APPLICATION (mb, gb, mw, gw, ..) # @ core_limit = 100mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_GAUSSIAN | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_GAUSSIAN | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| set path=($path . /soft/g03c02) setenv g03root /soft setenv GAUSS_SCRDIR $LOCAL_WORK_DIR setenv GAUSS_EXEDIR /soft/g03c02 setenv LD_LIBRARY64_PATH /soft/g03c02 | obligatoire | l'environnement d'exécution Gaussian |
| g03 < molecule.com > $LOCAL_SPOOL_DIR/molecule.log gzip molecule.log molecule.chk | Compilation crihan | les commandes du job |
| mv molecule.chk $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoirede spool adéquat |
Ce lien permet de récupérer le script pour un job Gaussian G03 en C-shell.
Ce lien permet de récupérer le script pour un job Gaussian G03 en Korn-shell.
Ce lien permet de récupérer le script pour un job Gaussian G98 en C-shell.
Ce lien permet de récupérer le script pour un job Gaussian G98 en Korn-shell. ----------------------------
Script job parallèle Jaguar
Le descriptif ci-dessous fait référence à la version 6.5 du code Jaguar. A la fin de cette rubrique vous pouvez aussi récupérer des scripts pour les versions 6.0, 5.1 et 4.0 .| #!/bin/csh # Script de soumission Loadleveler, job Jaguar # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = jaguar | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = jaguar # Nombre de processus Jaguar # @ cri_total_tasks = 4 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit = 600mb | obligatoire | |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 100mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ..) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_JAGUAR | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_JAGUAR | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| setenv JAGUAR_HOME /soft/jaguar6.5 setenv SCHRODINGER /soft/jaguar6.5 set path=($path /soft/jaguar6.5) $JAGUAR_HOME/make.hosts | obligatoire | l'environnement d'exécution Jaguar Constitution du fichier schrodinger.hosts |
| jaguar run -w -p 4 data.in gzip job.log data.out | Compilation crihan | les commandes du job |
| mv job.log.gz data.out.gz $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoire de spool adéquat |
Ce lien permet de récupérer le script pour un job Jaguar version 7.0 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 7.0 en Korn-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 6.5 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 6.5 en Korn-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 6.0 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 6.0 en Korn-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 5.1 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 5.1 en Korn-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 4.0 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 4.0 en Korn-shell. ----------------------------
Script job parallèle Gamess 2003
| #!/bin/csh # Script de soumission Loadleveler, job Gamess 2003 # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = mpi | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = gamess # Nombre de threads Gamess # @ cri_total_tasks = 4 | obligatoire | # IMPORTANT : # Gamess 2003 lance 2 processus par processeur donc positionnez le # nombre de processeurs à la moitié du nombre de processus ($(cri_total_tasks)/2) # Ici 4 processus donc exécution sur 2 processeurs |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 1:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit = 800mb | obligatoire | |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 100mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ..) # @ core_limit = 100mb | optionnel | Valeur mise à zéro par défaut |
| # Repertoire initial a envoyer # @ cri_initialdir = /work/projet/login/IN_Gamess | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job |
| # Repertoire final pour les resultats # @ cri_finaldir = /work/projet/login/OUT_Gamess | obligatoire | répertoire où sont placés les fichiers récupérés par le système, à la demande de l'utilisateur, à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = login@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| setenv NBPROC 2 setenv SCR $LOCAL_WORK_DIR/.gamess.scr | obligatoire | l'environnement d'exécution Gamess 2003 |
| Exécution du script "crihan" gamess avec 4 processus sur 2 processeurs gamess exam33 2 > $LOCAL_SPOOL_DIR/Gamess.out gzip *.dat *.out | Compilation crihan | les commandes du job |
| mv *.gz $LOCAL_SPOOL_DIR | obligatoire | déplacement (et non pas copie !!) des fichiers à récupérer dans le répertoire de spool adéquat |
Ce lien permet de récupérer le script pour un job Gamess version 2003 en C-shell.
Ce lien permet de récupérer le script pour un job Gamess version 2003 en Korn-shell.
# IMPORTANT :
# Gamess 2003 lance 2 processus par processeur donc positionnez le
# nombre de processeurs à la moitié du nombre de processus ($(cri_total_tasks)/2)
# Ici 4 processus donc exécution sur 2 processeurs ----------------------------
Script job parallèle Gamess 2009
La version 2009 de Gamess offre davantage fonctionnalités que celle de 2003 ( http://www.msg.ameslab.gov/gamess/index.html ).
Les limites de ressources pour un job Gamess 2009 sont celles d'un job parallèle MPI ; le nombre maximal de processus est donc fixé à 64.
Pour obtenir un bon compromis entre les temps d'attente et d'exécution d'un job, il est conseillé de ne pas dépasser 16 processus (voir Gestion des ressources demandées ).
Ce lien permet de récupérer le script pour un job Gamess version 2009 en C-shell.
Script de calcul en 2 étapes avec reprise automatique
L'exemple suivant s'applique à un calcul MPI 16 tâches de 96 H, réalisé en deux étapes de 48 H avec reprise automatique à la fin de la première étape.
ll est directement transposable aux autres types de job (serial, openmp, etc.) : remplacer le mot clé "mpi" du paramètre "# @ cri_job_type" et enlever "#@ cri_total_tasks" dans le cas serial.
Dans le script de la première étape, on ne se place pas dans le scratch (/dlocal/run) mais dans dans le "cri_initialdir" qui sert ici de répertoire de travail.
Le "cri_initialdir" ne doit contenir que le minimum : les données d'entrée de la première étape du calcul ainsi que le script de soumission de la deuxième étape (appelé ici "ll_mpi_job2"), lancé par la commande llsubmit à la fin du script de la première étape.
| #!/usr/local/bin/bash # Script de soumission Loadleveler, job MPI # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = reprise_mpi | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = mpi # Nombre de processus MPI # @ cri_total_tasks = 16 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 48:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit =1000mb | obligatoire | attention à l'option -bmaxdata du compilateur dans le cas 32 bits (rubrique édition des liens) |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 256mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ..) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
| # @ cri_initialdir = /work/crihan/pbousq01/TEST_MPI/Input_1 | obligatoire | répertoire de travail qui ne doit contenir que le minimum : input et script de lancement de la 2e étape |
| # @ cri_finaldir = /work/crihan/pbousq01/TEST_MPI/Input_1 | obligatoire | ne sert pas dans ce cas, mais le filtre le requiert |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = pbm@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### #### Le script du 2e job doit etre place dans le "cri_initialdir" | ||
| OUT_JOB1=/home/crihan/pbousq01/TEST_MPI/Output_1 # Resultats du 1er job mkdir -p $OUT_JOB1 | obligatoire | Répertoire de résultats du 1er job |
| # On choisit le "cri_initialdir" comme repertoire de travail cd $CRI_INITDIR | obligatoire | Répertoire de travail |
| ./a_mpi_pwr5.out < in.dat > job1.log gzip resultat.dat | les commandes du job | |
| # On sauvegarde les resultats du 1er job cp result.dat.gz job1.log $OUT_JOB1 | obligatoire | |
# Les fichiers de reprise doivent être dans le repertoire de travail. | obligatoire |
Ce lien permet de récupérer le script précédent (1e étape d'un calcul en deux parties avec reprise)
Le script ll_mpi_job2, lancé à la fin du script précédent, est le suivant.
Le répertoire "cri_initialdir" est le même que dans le script de la première étape.
| #!/usr/local/bin/bash # Script de soumission Loadleveler, job MPI # CRIHAN v 3.00 | obligatoire | type de shell au choix de l'utilisateur |
| # Nom du job # @ job_name = reprise_mpi | optionnel | |
| # Nom du fichier de sortie standard # @ output = $(job_name).o$(jobid) # Nom du fichier d'erreur standard # @ error = $(job_name).e$(jobid) | obligatoire | |
| # Type du job # @ cri_job_type = mpi # Nombre de processus MPI # @ cri_total_tasks = 16 | obligatoire | |
| # temps de restitution (heures[:minutes[:secondes]]) # @ wall_clock_limit = 48:00:00 | obligatoire | pour utiliser le backfilling |
| # Memoire maximale par processus (mb, gb, mw, gw, ..) # @ data_limit = 1000mb | obligatoire | attention à l'option -bmaxdata du compilateur dans le cas 32 bits (rubrique édition des liens) |
| # Stack maximale par processus (mb, gb, mw, gw, ..) # @ stack_limit = 256mb | optionnel | Valeur mise à 256mb par défaut |
| # Fichier core maximal par processus (mb, gb, mw, gw, ...) # @ core_limit = 500mb | optionnel | Valeur mise à zéro par défaut |
# Même cri_intialdir que dans la 1e étape # Repertoire initial a envoyer | obligatoire | répertoire copié par le système dans l'espace temporaire au début du job. |
| # Repertoire final pour les resultats # @ cri_finaldir=/work/crihan/pbousq01/TEST_MPI/Output | obligatoire | répertoire où sont placés les fichiers récupérés par le système à la fin du job |
| # Politique d'envoi des mels # @ notification = complete # Adresse d'envoi des mels # @ notify_user = pbm@crihan.fr | optionnel | envoi d'un mel à l'utilisateur à la fin du job |
| # # @ queue | obligatoire | conclut les directives du job |
| ### ### Commandes utilisateur ### | ||
| # # On se positionne dans le repertoire temporaire # cd $LOCAL_WORK_DIR | obligatoire | déplacement dans l'espace temporaire |
| /a_mpi_pwr5.out < in.dat > job2.log gzip resultat.dat | obligatoire | les commandes du job |
| # On deplace les fichiers resultats dans le repertoire # temporaire de rappatriement : $LOCAL_SPOOL_DIR # mv result.dat.gz job2.log $LOCAL_SPOOL_DIR | obligatoire | |
Ce lien permet de récupérer le script précédent (deuxième étape d'un calcul en deux parties avec reprise)
Script de soumissions de jobs en cascade
L'exemple suivant s'applique à un calcul MPI 16 tâches réalisé en plusieurs étapes de 48 H chacune. Le nombre d'étapes est paramétré.
La reprise automatique se fait à l'aide de la commande llsubmit à la fin du script qui sexécute lui-même de manière récursive.
Cet exemple est directement transposable aux autres types de job (serial, openmp, etc.) : remplacer le mot clé "mpi" du paramètre "# @ cri_job_type" et enlever "#@ cri_total_tasks" dans le cas serial.
Le script doit être lancé depuis le "cri_initialdir" qui sera le répertoire de travail dans lequel la séquence de jobs s'exécutera. Les données d'entrée du premier job doivent s'y trouver. Ne pas y placer de fichiers inutiles. Il est conseillé de changer de répertoire "cri_initialdir" pour chaque séquence de jobs.
L'indice du job (itération) est placé dans un fichier step.dat créé par le script.
Si on ne modifie pas la variable RESTART, le nombre de jobs executés sera egal a MAXJOBS.
En cours d'exécution, pour stopper l'enchaînement des jobs,il suffit d'éditer le script pour y mettre "RESTART=NO" a la place de "RESTART=YES" puis de le sauvegarder : le calcul en cours se terminera et ne lancera pas d'autre job. Dans ce cas, ne pas oublier de réinitialiser RESTART à la valeur YES si on lance le même script pour une nouvelle séquence.
===============================================================================
#!/bin/sh
# Script de soumission Loadleveler, job MPI
# CRIHAN v 3.00 - janvier 2006
# crihan-sci@crihan.fr
#
# Nom du job
# @ job_name = resub
#
# Nom du fichier de sortie standard
# @ output = $(job_name).o$(jobid)
#
# Nom du fichier d'erreur standard
# @ error = $(job_name).e$(jobid)
#
# Type du job
# @ cri_job_type = mpi
#
# Nombre de processus MPI
# @ cri_total_tasks = 16
#
# temps de restitution (heures[:minutes[:secondes]])
# @ wall_clock_limit = 48:00:00
#
# Memoire maximale par processus (mb, gb, mw, gw,..)
# @ data_limit = 1000mb
#
# Stack maximale par processus (mb)
# @ stack_limit = 256mb
#
# Repertoire de travail
# @ cri_initialdir = /work/crihan/pbousq01/jobs_mpi_280708
# @ cri_finaldir = /work/crihan/pbousq01/jobs_mpi_280708
#
# Politique d'envoi des mels
# @ notification = complete
#
# Adresse d'envoi des mels
# @ notify_user = pbm@crihan.fr
#
# Obligatoire
# @ queue
###
### Commandes utilisateur
###
# On lance ce script depuis le "cri_initialdir"
# qui sera le repertoire de travail dans lequel
# la sequence de jobs s'executera.
# L'input du premier job doit s'y trouver.
# Ne pas y placer de fichiers inutiles.
# Il est conseille de changer de repertoire
# "cri_initialdir" d'une sequence de jobs a une autre.
cd $CRI_INITDIR
# L'indice du job (iteration) est place dans un fichier step.dat
# cree par le script.
# Si on ne modifie pas la variable RESTART, le nombre de jobs executes
# sera egal a MAXJOBS.
# En cours d'execution, pour stopper l'enchainement des jobs,
# il suffit d'editer le script pour y mettre
# "RESTART=NO" a la place de "RESTART=YES"
# puis de le sauvegarder : le calcul en cours se terminera
# et ne lancera pas d'autre job.
# Dans ce cas, ne pas oublier de reinitialiser RESTART a la valeur YES
# si on lance le meme script pour une nouvelle sequence.
if ! test -f step.dat; then echo 1 > step.dat; fi
isub0=`cat step.dat`
echo Run $isub0
###############################
RESTART=YES
# Nom de ce fichier
SCRIPT=ll_mpi_recursive
# Nombre maximal de jobs
MAXJOBS=4
# Execution du calcul
./a.out < input_reprise.dat > a.log
# Repertoire de sauvegarde du calcul
OUTPUT=RESULT
mkdir -p $OUTPUT.$isub0
mv a.log $OUTPUT.$isub0 # Rangement de ce qui ne sert pas pour le job suivant
cp input_reprise.dat $OUTPUT.$isub0 # Copie du ou des fichier(s) de reprise
################################
# On incremente l'indice du run
isub=`expr $isub0 + 1`
echo $isub > step.dat
# On lance le run suivant
if test $isub -le $MAXJOBS && test `grep ^RESTART $SCRIPT | sed 's/.*=//'` = YES
then
llsubmit $SCRIPT
else
echo DONE
mv step.dat step.dat_old
fi
===============================================================================
Ce lien permet de récupérer le script précédent.