Babel : exécution d'un code parallèle en batch

La gestion des travaux sur l'ensemble des noeuds est faite par le système LoadLeveler. Pour pouvoir soumettre, il faut commencer par écrire un script de soumission : c'est l'étape qui est abordée ici. Les commandes de soumission et de suivi de job sont détaillées dans la page commandes de contrôle des travaux batch.

Les travaux multi-étapes sont abordé dans cette rubrique et les travaux multi-étapes avec transferts de fichiers avec Gaya sont présentés dans cette page.

Travaux parallèles simples

Voici un exemple de soumission d'un job pour exécuter un code sur 256 coeurs. La soumission se fait, en supposant que le fichier de soumission s'appelle job.ll, via la commande :

llsubmit job.ll

Le fichier de soumission contient les lignes suivantes :

# @ job_name = job_simple
# @ job_type = BLUEGENE
# Fichier sortie standard du travail
# @ output = $(job_name).$(jobid)
# Fichier erreur standard du travail
# @ error = $(output)
# Temps elapsed maximum demande
# @ wall_clock_limit = 1:00:00
# Taille partition d'execution
# @ bg_size = 64
# @ queue

# Copy executable and input file to TMPDIR
# Warning: if you need to transfer important volumes
# of data, please use a multi-step job
cp my_code $TMPDIR
cp data.in $TMPDIR
cd $TMPDIR

mpirun -mode VN -np 256 -mapfile TXYZ -exe ./my_code
# Copy output file to submission directory
# Warning: if you need to transfer important volumes
# of data, please use a multi-step job
# $LOADL_STEP_INITDIR is the submission directory
cp data.out $LOADL_STEP_INITDIR/

Le script de soumission est séparé en deux parties. La première contient les directives LoadLeveler (lignes commençant par #@ avec ou sans espaces). La deuxième, le script a exécuter.

Attention : si vous avez à copier/déplacer des volumes importants de données, utilisez des jobs multi-étapes ou des jobs multi-étapes avec transferts de fichiers (en cas de transferts avec Gaya).

Directives LoadLeveler

Un travail sur la Blue Gene/P doit contenir un certain nombre de directives LoadLeveler pour pouvoir être lancé correctement (les valeurs sont indépendantes de la casse majuscules/minuscules hormis les noms de fichiers).

  • Directives obligatoires :
    • # @ job_type = BLUEGENE : le type du job. Seul BLUEGENE est accepté pour tourner sur les noeuds de calcul. SERIAL peut être utilisé pour les phases de pre- ou post-processing sur la frontale ou de transferts de fichiers (voir pages jobs multi-étapes et jobs multi-étapes avec transferts de fichiers) ;
    • # @ bg_size : taille de la partition d'exécution réservée. Cette variable ne peut prendre que certaines valeurs (si autres, le système tentera de les ajuster) : 64, 128, 256, 512, 1024, 2048, 4096, 6144, 8192 ou 10240 (en voir les raisons). Le choix du nombre de processus MPI en dépend directement (voir ici). Attention, cela peut avoir des conséquences importantes sur la comptabilité de vos travaux ;
    • # @ wall_clock_limit : durée maximale d'exécution du code (donnée en temps elapsed ou d'horloge). Elle est donnée soit au format HH:MM:SS, soit directement en secondes ;
    • # @ queue : dernière directive LoadLeveler. Celles qui suivent ne seront pas prises en compte.
  • Directives optionnelles :
    • # @ bg_connection : peut prendre 3 valeurs : MESH, TORUS et PREFER_TORUS. Par défaut est à MESH. Seul MESH est accepté pour les partitions de moins de 512 noeuds de calcul. Pour les autres, l'utilisation de TORUS permet d'utiliser le tore 3D pour les communications. Cette valeur est donc vivement conseillée pour tous les jobs s'exécutant sur au moins 512 noeuds de calcul ;
    • # @ job_name : nom du travail (choix libre) ;
    • # @ output : nom du fichier de sortie standard ;
    • # @ error : nom du fichier d'erreur standard. Si vous voulez mettre l'erreur standard dans le même fichier que la sortie standard, il suffit de mettre la directive égale à $(output) ;
    • # @ notification : si mis à la valeur complete, vous recevrez automatiquement un email récapitulatif en fin d'exécution.

Cette liste n'est pas exhaustive. La documentation IBM vous les fournira toutes (certaines ne sont pas adaptées à la machine ou sont interdites).

Script

Le script exécuté ne doit normalement pas contenir de phase séquentielle (hormis des opérations très rapide comme la copie d'un petit fichier ou des changements de répertoire) pour éviter que seul un des coeurs réservés travaille (le temps gaspillé vous est facturé). Dans le cas de phases séquentielles, il est obligatoire de mettre en place des jobs multi-étapes (voir pages jobs multi-étapes et jobs multi-étapes avec transferts de fichiers).

L'exécution d'un code parallèle se fait toujours via un appel à la commande mpirun. Il faut toujours préciser le nombre de processus MPI qui doivent être lancés (option -np), valeur à bien choisir. Il faut également préciser le mode d'exécution des noeuds de calcul (option -mode; voir ici). Le choix du mapping (option -mapfile) peut avoir une influence importante sur les performances des communications MPI (voir ici). La valeur conseillée pour cette dernière est TXYZ. Cette option n'est par contre pas obligatoire.

Les options utiles pour mpirun sont données dans cette page.