Document Actions

LoadLeveler

Description de la soumission des calculs avec le logiciels LoadLeveler

Introduction
Utilisation de Loadleveler
Fonctionnement du batch au CRIHAN
Codes d'erreur lors de la soumission
Gestion des ressources demandées
Scripts de soumission

Script job séquentiel
Script job MPI
Script job OpenMP
Script job Gaussian98
Script job Jaguar 6.0
Script job Gamess
Script job PVM

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.

llsummary

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)`
`------------------------------`	`-------------------------------------------------`
`ll-jack`	`ConsumableCpusCrihan(0,36) ConsumableMemCrihan(4400,36864)`
`ll-joe`	`ConsumableCpusCrihan(0,32) ConsumableMemCrihan(1556,32768)`

Les ConsumableCpusCrihan correspondent à des tickets processeurs sur chacun des noeuds : un ticket = un processeur Power4.
Les ConsumableCpusCrihan correspondent à des tickets mémoire sur chacun des noeuds : un ticket = un Mo de mémoire

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 ---------------- --------- ----------- -- --- ----------- ----------- ll-joe.19412.0 < login > 11/1 13:45 R 50 large ll-joe ll-joe.19475.0 < login > 11/4 16:12 R 50 medium ll-jack ll-joe.19448.0 < login > 11/4 09:37 R 50 large ll-joe ll-joe.19455.0 < login > 11/4 11:03 R 50 large ll-jack ll-joe.19510.0 < login > 11/5 15:22 R 50 large ll-jack ll-joe.19456.0 < login > 11/4 11:48 R 50 large ll-joe ll-joe.19536.0 < login > 11/8 10:43 R 50 large ll-jack ll-joe.19509.0 < login > 11/5 15:22 I 50 large ll-joe.19515.0 < login > 11/5 17:22 I 50 large ll-joe.19530.0 < login > 11/7 12:33 I 50 large ll-joe.19537.0 < login > 11/8 10:45 I 50 large 13 job step(s) in queue, 4 waiting, 0 pending, 9 running, 0 held, 0 preempted

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-joe.xxxxx.0) qui permet de suivre la soumission ou de détruire le job.

llq

La commande llq permet d'avoir la liste des jobs actuellement transmis à Loadleveler.
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.

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.

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 des performances des disques internes pour les entrées / sorties plutôt que de saturer la bande passante entre les noeuds de calcul et la baie FastT500 de disques externes, elle-même déjà utilisée par la partie interactive de l'exploitation du cluster (édition, compilation, exécutions en interactif). Selon la charge des liens FiberChannel entre les noeuds et la baie FastT500, le temps de transfert des fichiers peut varier. Ainsi, pour éviter de pénaliser les jobs soumis, les phases de transferts des fichiers sont prises en compte par le système de soumission.
Chaque noeud dispose de 400 Go de disques internes dédiés aux espaces temporaires et permet donc une utilisation souple de cet espace pour les fichiers scratch. La seule limitation est alors la taille de cet espace disque (il faut bien sûr tenir compte de l'espace restant disponible au moment où la soumission est traitée pour pouvoir réserver l'espace disque demandé !).

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).

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'un espace de travail temporaire dans les disques internes du noeud d'exécution et 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 l'espace temporaire crée dans le prologue.

En fin d'exécution, arrive l'épilogue.
Attention : si le wall_clock_limit est atteint, l'espace disque temporaire est immédiatement détruit ainsi que son contenu (i.e. tous vos fichiers). Il est donc important de bien évaluer le temps d'exécution du job, quitte à le majorer dans un premier temps.
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 un 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.

Variable employée	Usage
$LOCAL_WORK_DIR	Elle représente le répertoire temporaire crée par le système dans les disques locaux du noeud et alloué au job pour son exécution ; `->/local/run/ll-joe.xxxx.0` ou `->/dlocal/run/ll-joe.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 les disques internes du noeud ; `->/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 ; `->/work/projet/login/REPERTOIRE_SORTIE`
$LOCAL_SPOOL_DIR	Elle représente le répertoire temporaire crée par le système dans les disques locaux du noeud qui servent de transit avant le rapatriement vers l'espace permanent de l'utilisateur situé dans la baie FastT500. `->/local/spool/ll-joe.xxxx.0` ou `->/dlocal/run/ll-joe.xxxx.0`

Le diagramme suivant reprend la procédure de la gestion des jobs.

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 /local/run
111	on a perdu le système de fichiers /local/spool
112	la copie des fichiers du cri_initialdir vers l'espace temporaire s'est mal passée
113	il y a une erreur de syntaxe dans le nom du cri_initialdir (pas de ../ et de ;)
114	la variable cri_initialdir n'est pas renseignée
115	le cri_initialdir doit être un répertoire
116	le cri_initialdir n'est pas autorisé en lecture
117	il y a des liens symboliques dans l'arborescence du cri_initialdir qui ne sont jamais suivis
118	le répertoire $LOCAL_WORK_DIR ne peut pas être crée
119	le répertoire $LOCAL_SPOOL_DIR ne peut pas être crée
120	le cri_initdir est un chemin absolu qui n'est ni dans /home/.., ni dans /work/...
121	le cri_initdir n'existe pas
122	le cri_initdir est vide
Erreurs liées à l'épilogue
210	crash du job durant l'exécution
211	une erreur est survenue lors du déplacement des fichiers du cri_spool vers le répertoire $LOCAL_SPOOL_DIR
212	le répertoire /work/projet/login/SPOOL n'a pu être crée
213	la création du répertoire cri_finaldir n'a pu se faire
214	il y a une erreur de syntaxe dans la variable cri_spool (pas de ../ et de ;)
215	la variable cri_spool doit être un répertoire

Tous les codes supérieurs à 100 sont des codes CRIHAN.

Gestion des ressources demandées

Limitations des ressources demandées

Pour une plus grande souplesse de gestion et une meilleure utilisation des ressources, il n'y a plus de limites (processeurs / mémoire) à 8 processeurs, 8 Go pour toutes les applications qu'elles soient de type MPI, OpenMP, etc ... (voir la rubrique Pondération des jobs ci-dessous).
De plus les applications de cri_job_type mpi sont autorisées à s'exécuter à cheval sur plusieurs noeuds. Le mode de soumission (décrit ici) reste le même, mais les espaces de travail temporaires sont alloués dans la baie FastT500 au lieu des disques internes lorsqu'il n'y a qu'un seul noeud.
Il s'agit du mode de soumission par défaut pour les applications de cri_job_type mpi.

Remarque :
Pour forcer l'exécution de l'application mpi sur un seul noeud, il faut insérer la ligne suivante dans le script de soumission :

# @ blocking = la même valeur que cri_total_tasks

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.

Remarque :
Nous attirons votre attention sur le fait que les performances d'I/O sont moins bonnes vers la baie FastT500 que vers les disques internes et par conséquent les jobs MPI ayant une utilisation importante des I/O risquent d'être moins performants. Pour ces jobs-là, il peut être nécessaire d'imposer l'exécution sur un seul noeud, quitte à devoir attendre que les ressources demandées soient disponibles au sein d'un noeud.

Seules des limites liées à la taille du cluster ou au type de l'application persistent. Le tableau suivant les reprend :

Application / cri_job_type	Contraintes restantes
serial	1 processeur / 32 Go de mémoire
mpi	60 processeurs / 60 Go de mémoire
les jobs mpi ont la possibilité d'être à cheval sur les deux noeuds
openmp	32 processeurs / 32 Go de mémoire
gaussian	32 processeurs / 32 Go de mémoire
gamess	32 processeurs / 32 Go de mémoire
jaguar	32 processeurs / 32 Go de mémoire

Remarque :
Les 4 processeurs et 4 Go de mémoire de la partie interactive ne peuvent jamais être prises par le batch.

Pondération des jobs

Loadleveler pondère chaque soumission par rapport aux ressources demandées : temps de présence, nombre de processus, volume mémoire. Un poids est ainsi attribué. Ce poids permet de placer le job dans une des trois classes (nouvellement créees et remplaçant les précédentes) : small, medium, large. Moins le job est lourd plus il est prioritaire. Ensuite, la procédure de back filling tient compte des ressources demandées pour le lancement du job.

Par exemple, deux jobs demandant 32 processeurs pendant 24 heures ou bien 32 Go de mémoire pendant 24 heures auront le même poids. La formule de calcul du poids est basé sur la part de processeurs et la part de mémoire demandées par le job par rapport aux ressources physiques du cluster.
La formule de calcul est la suivante :

Poids = MAX( CPU demandé / CPU total , mémoire demandée / mémoire totale ) * wall_clock limit

Le poids maximal autorisé actuellement est fixé à l'occupation de l'ensemble du cluster (60 processeurs ou 60 Go de mémoire) pendant 3 journées complètes ou bien un quart du cluster pendant 12 jours, etc ...

Scripts de soumission

Les scripts de soumissions comportent plusieurs types d'informations :

l'expression des besoins des jobs : la mémoire 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.

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 ...
L'espace disque temporaire est pour l'instant fixé à 10 Go par processus de l'application. Les applications consommatrices d'espace de travail temporaire comme Gaussian, disposent de 40 Go.
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, pvm, g98.

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 2.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)
`# 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.out < in.dat > 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 2.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 = 256mb`	obligatoire	attention à l'option -bmaxdata du compilateur (rubrique édition des liens)
`# 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.out < in.dat > 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 2.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)
`# 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.out < in.dat > 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 98

`#!/bin/csh` `# Script de soumission Loadleveler, job Gaussian` `# CRIHAN v 2.00`	obligatoire	type de shell au choix de l'utilisateur
`# Nom du job` `# @ job_name = g98`	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 = g98` `# 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 par processus (mb, gb, mw, gw, ..)` `# @ data_limit = 256mb`	obligatoire
`# Repertoire initial a envoyer` `# @ cri_initialdir = /work/projet/login/IN_G98`	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_G98`	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/g98)` `setenv g98root /soft` `setenv GAUSS_SCRDIR .` `setenv GAUSS_EXEDIR /soft/g98` `setenv LD_LIBRARY64_PATH /soft/g98`	obligatoire	l'environnement d'exécution Gaussian
`g98 < molecule.com > molecule.log` `gzip molecule.log molecule.chk`		les commandes du job
`mv molecule.log.gz molecule.chk.gz $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 en C-shell.
Ce lien permet de récupérer le script pour un job Gaussian en Korn-shell.

----------------------------

Script job parallèle Jaguar 6.0

Attention changement !!! Jaguar 6.0 a son propre cri_job_type

`#!/bin/csh` `# Script de soumission Loadleveler, job Jaguar` `# CRIHAN v 2.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	Attention changement !!! Jaguar 6.0 a son propre cri_job_type
`# 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
`# 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.0` `setenv SCHRODINGER /soft/jaguar6.0` `set path=($path /soft/jaguar6.0)` `$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`		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 6.0 en C-shell.
Ce lien permet de récupérer le script pour un job Jaguar version 6.0 en Korn-shell.

----------------------------

Script job parallèle Gamess

Attention changement !!! Gamess a son propre cri_job_type

`#!/bin/csh` `# Script de soumission Loadleveler, job Gamess` `# CRIHAN v 2.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 = 2`	obligatoire	`# IMPORTANT :` `# Gamess 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 = 256mb`	obligatoire
`# 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
*Exécution du script "crihan" gamess* avec 4 processus sur 2 processeurs** `gamess exam33 2 > Gamess.out` `gzip .dat .out`		les commandes du job
`mv *.gz $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 Gamess en C-shell.
Ce lien permet de récupérer le script pour un job Gamess en Korn-shell.

----------------------------

Script job parallèle PVM

`#!/bin/csh` `# Script de soumission Loadleveler, job PVM` `# CRIHAN v 2.00`	obligatoire	type de shell au choix de l'utilisateur
`# Nom du job` `# @ job_name = PVM`	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 = pvm` `# Nombre de threads pvm` `# @ 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 = 256mb`	obligatoire	attention à l'option -bmaxdata du compilateur (rubrique édition des liens)
`# Repertoire initial a envoyer` `# @ cri_initialdir = /work/projet/login/IN_PVM`	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_PVM`	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` `echo quit \| pvm` `./a.out < in.dat > out.dat` `echo halt \| pvm` `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 PVM.

CRIHAN

Sections

Personal tools

Document Actions

LoadLeveler

Introduction

Utilisation de Loadleveler

llsummary

llsubmit

llq

llcancel

Fonctionnement du batch au CRIHAN

Codes d'erreur lors de la soumission

Gestion des ressources demandées

Limitations des ressources demandées

Pondération des jobs

Scripts de soumission

Script job séquentiel

Script job parallèle MPI

Script job parallèle OpenMP

Script job parallèle Gaussian 98

Script job parallèle Jaguar 6.0

Script job parallèle Gamess

Script job parallèle PVM