Launch

Launch permet de soumettre en une seule fois un ensemble de batchs dont les caractéristiques sont définies à partir d'un fichier de configuration.

Les paramètres du fichier de configuration définissent les ressources nécessaires à l'exécution des batchs: temps CPU, taille mémoire, mémoire résidente et ressources d'exécution, comme l'accès à Irods ou à la base de données, ainsi que les arguments transmis aux batchs.

Pour permettre une bonne gestion des traitements réalisés, il est préférable que chaque batch porte un nom distinct. Ceci est possible en définissant le nom du batch à partir d'un pattern, et non pas d'une manière fixe. Le pattern définissant le nom du batch peut contenir des variables définies à partir des arguments à transmettre aux batchs ou à partir du contexte de réalisation.

La définition la plus naturelle pour le nom des batchs consiste à associer un préfixe identifiant la production et l'argument passé au job, comme par exemple:

jobname = Headers_${ARG}

Dans cet exemple, jobname représente le paramètre définissant le nom des jobs, Headers est la partie fixe permettant de regrouper tous les jobs d'une même 'production', et ARG est une variable représentant l'argument transmis à chacun des batchs.

Cette variable ARG est elle-même initialisée à partir d'un autre paramètre nommé args. Par exemple :

args = bs cg gn gs lm sm tm

Ce qui représente les codes identifiant les 7 programmes scientifiques majeurs d'Eros 2.

Avec ces deux définitions, Lauch va construire et soumettre 7 jobs:

$ Launch -verb -check
Jobname    . . .
---------- . . .
Headers_bs . . .
Headers_cg . . .
Headers_gn . . .
Headers_gs . . .
Headers_lm . . .
Headers_sm . . .
Headers_tm . . .

La réalisation des opérations dont le batch à la charge est pilotée soit par une commande soit par un script. Il peut s'agir de n'importe quelle commande ou script accessible du batch lors de son exécution. Le script doit être programmé en Bash, et bien sûr être exécutable.

La commande ou le script à exécuter est indiqué par le paramètre command. Par exemple :

command = ./extractHeaders.sh $ARG

La substitution de la variable ARG est effectuée pour chaque batch soumis.

Le dernier paramètre devant impérativement être renseigné est cpu, représentant le temps CPU, exprimé en secondes.

L'une des limitations du launcher est que le temps CPU est le même pour tous les batchs soumis.

Au final, le fichier de configuration de base ressemblerait à :

jobname = Headers_${ARG}
command = ./extractHeaders.sh $ARG
args = bs cg gn gs lm sm tm
cpu = 1500

Et la soumission des jobs :

$ Launch -verb -check
Jobname    Command                Cpu  Memory Resident Resources Mail
---------- ---------------------- ---- ------ -------- --------- ----
Headers_bs ./extractHeaders.sh bs 1500
Headers_cg ./extractHeaders.sh cg 1500
Headers_gn ./extractHeaders.sh gn 1500
Headers_gs ./extractHeaders.sh gs 1500
Headers_lm ./extractHeaders.sh lm 1500
Headers_sm ./extractHeaders.sh sm 1500
Headers_tm ./extractHeaders.sh tm 1500

Passage de plusieurs arguments

Dans les exemples précédents, un seul argument était passé à la commande exécutant les traitements. Dans la plus part des situations, c'est suffisant. Toutefois, il est possible de transmettre plusieurs arguments en redéfinissant le séparateur utilisé avec la définition args.

Dans le cas standard, le séparateur des arguments est un, ou plusieur, espaces. Il correspond à l'expression régulière Java: \s+. De ce fait, les définitions suivantes sont équivalentes :

args = bs cg lm sm
args =   bs   cg   lm   sm

Ces deux définitions déclarent 4 arguments: bs, cg, lm et sm, conduisant à la soumission de 4 batchs.

Il est possible de redéfinir le séparateur des arguments grâce au paramètre args.separator. La valeur de ce paramètre est une expression régulière. Par exemple, en utilisant la définition:

args.separator = \s*,\s*

les arguments pourront être séparés par des virgules, éventuellement entourées d'espace.

La définition des arguments de l'exemple précédent devra alors être:

args = bs, cg, lm, sm

Mais l'intérêt de cette redéfinition du séparateur est qu'il devient possible de définir comme arguments des groupes de valeurs, comme dans l'exemple ci-dessous:

args = bs b 0 4, bs b 5 7, bs r 0 4, bs r 5 7, ...

ce qui correspondrait aux images du programme bs subdivisées par couleur b et r et par groupe de CCD : de 0 à 4 et de 5 à 7.

Soit les 4 jobs:

$ Launch -check -verb -ignore
Jobname                         Command                      Cpu Memory Resident Resources Mail
------------------------------- ---------------------------- --- ------ -------- --------- ----
Headers_bs_b_0_4_20211008175036 ./extractHeaders.sh bs b 0 4 900                     
Headers_bs_b_5_7_20211008175036 ./extractHeaders.sh bs b 5 7 900                     
Headers_bs_r_0_4_20211008175036 ./extractHeaders.sh bs r 0 4 900                     
Headers_bs_r_5_7_20211008175036 ./extractHeaders.sh bs r 5 7 900

La redéfinition du séparateur présente toutefois deux contraintes:

1) il doit être déclaré avant la définition de la liste d'arguments;

2) le séparateur s'applique à toutes les listes, et donc également à la liste des ressources (voir Autres paramètres).

Longue liste d'arguments

Dans l'exemple où les traitements sont divisés par groupe de couleurs et de CCD, le nombre d'arguments à déclarer est multiplié par 4. Pour traiter l'ensemble de images des 7 programmes, il faut donc définir 28 arguments, ce qui est un peu fastidieux et difficile à relire.

Pour faciliter la relecture du fichier de configuration, il est possible de définir les arguments sur plusieurs lignes en terminant chaque ligne par la marque de continuation barre oblique inverse: **.

args = bs b 0 4, bs b 5 7, bs r 0 4, bs r 5 7, \
       cg b 0 4, cg b 5 7, cg r 0 4, cg r 5 7, \
       gn b 0 4, gn b 5 7, gn r 0 4, gn r 5 7, \
       gs b 0 4, gs b 5 7, gs r 0 4, gs r 5 7, \
       lm b 0 4, lm b 5 7, lm r 0 4, lm r 5 7, \
       sm b 0 4, sm b 5 7, sm r 0 4, sm r 5 7, \
       tm b 0 4, tm b 5 7, tm r 0 4, tm r 5 7, \

Autres paramètres

Les autres paramètres intervenant dans la soumission des batchs sont:

  • memory: la taille de la mémoire vive du processus
  • resident: la taille de la mémoire résidente
  • resources: la liste des ressources d'exécution demandées. Les ressources dépendent du gestionnaire de batchs, mais les plus usuelles sont sps: accès au SPS, irods: accès à Irods, oracle: accès à la base de données Oracle
  • mail: une adresse mail à laquelle les messages de fin d'exécution des jobs sont envoyés
  • setup: un script d'initialisation du contexte d'exécution du job. Ce script est sourcé par le pilote du job et doit être exécutable.

La commande de pilotage des traitements et le script d'initialisation du contexte d'exécution des batchs doivent être fournis par l'administrateur de la production.

Une définition usuelle du script d'initialisation dans le cas de traitements réalisées grâce aux outils ErosDb est :

setup = /sps/eros/softs/ErosDbIII/setup.sh

Unités des définitions

Les définitions de la mémoire ou du temps CPU peuvent être indiquées comme des valeurs numériques simples ou être associés à des unités.

Par exemple, les trois définitions suivantes sont équivalentes :

cpu = 900
cpu = 15 mn
cpu = 0.25 h

Plusieurs unités peuvent être combinées :

cpu = 1 h 15 mn

Les unités mémoires utilisables sont :

  • b, B: octets - c'est l'unité par défaut
  • k: 1000 octets
  • K: 1024 octets, ou 1 Kilooctet
  • m: 1000 x 1000 octets, ou 1 million
  • M: 1024 x 1024 octets, ou 1 Mégaoctet
  • G: 1 K x 1 K x 1 K, ou 1 Gigaoctet
  • T: 1 M x 1 M, ou 1 Téraoctet

Les unités de temps utilisables sont :

  • s: secondes - c'est l'unité par défaut
  • m: minutes
  • h: heures
  • d: jours

Les variables

Les variables supportées sont :

  • ARG: l'argument du job à soumettre
  • DATE: date en format yyyy-MM-dd
  • TIME: l'heure en format HH:mm:ss
  • DATETIME: date et l'heure en format yyyy-MM-dd:HH:mm:ss
  • TIMESTAMP: date et heure en format compacté

Les variables de temps sont intéressantes pour différencier automatiquement les noms des jobs en cas de reprise, par exemple pour corriger l'échec d'une exécution:

Exemple :

#
# Extraction des entetes FITS des images Eros
#

jobname = Headers_${ARG}_${TIMESTAMP}
args = bs cg gn gs lm sm tm
command = ./extractHeaders.sh $ARG
cpu = 15 m
memory = 12 G

Et la soumission des jobs :

$ Launch -check -verb
Jobname                   Command                Cpu Memory Resident Resources Mail
------------------------- ---------------------- --- ------ -------- --------- ----
Headers_bs_20211008152234 ./extractHeaders.sh bs 900  12288
Headers_cg_20211008152234 ./extractHeaders.sh cg 900  12288
Headers_gn_20211008152234 ./extractHeaders.sh gn 900  12288
Headers_gs_20211008152234 ./extractHeaders.sh gs 900  12288
Headers_lm_20211008152234 ./extractHeaders.sh lm 900  12288
Headers_sm_20211008152234 ./extractHeaders.sh sm 900  12288
Headers_tm_20211008152234 ./extractHeaders.sh tm 900  12288

Utilisation

Par défaut, la commande Launch lance tous les jobs définis à partir du fichier de configuration batches.properties.

Le nom du fichier de configuration peut être modifié par l'option -properties.

Il est possible de ne lancer que quelques jobs en indiquant les arguments correspondant sur la ligne de commande. Ceci peut être intéressant pour vérifier la validité de l'exécution des batchs et des ressources déclarées en lançant un seul batch 'pilote'.

Par exemple :

$ Launch -check -verb bs
Jobname                   Command                Cpu Memory Resident Resources Mail
------------------------- ---------------------- --- ------ -------- --------- ----
Headers_bs_20211008152641 ./extractHeaders.sh bs 900  12288

Le seul batch traitant les images du programme bs sera lancé. Cette possibilité est également intéressante pour traiter les reprises en cas d'échec.

A l'inverse, il est aussi possible d'indiquer les arguments des batchs à ne pas lancer grâce à l'option -ignore. Ce sera par exemple pour lancer le reste de la production une fois les paramètres correctement réglés grâce au batch pilote :

$ Launch -check -verb -ignore bs
Jobname                   Command                Cpu Memory Resident Resources Mail
------------------------- ---------------------- --- ------ -------- --------- ----
Headers_cg_20211008153419 ./extractHeaders.sh cg 900  12288
Headers_gn_20211008153419 ./extractHeaders.sh gn 900  12288
Headers_gs_20211008153419 ./extractHeaders.sh gs 900  12288
Headers_lm_20211008153419 ./extractHeaders.sh lm 900  12288
Headers_sm_20211008153419 ./extractHeaders.sh sm 900  12288
Headers_tm_20211008153419 ./extractHeaders.sh tm 900  12288

Une option intéressante pour la phase de mise au point est l'option *-checkonly. Elle affiche seulement les paramètres des jobs sans les soumettre effectivement.

Les différentes ressources d'exécution des batchs peuvent être redéfinies ponctuellement via les options éponymes -cpu, -memory, -resident, -resources, -mail, et même -jobname.

L'option -describe présente la liste de paramètres et variables supportées.