Introduction
Dans cet exemple, on veut calculer des temps-fréquence pour 3 sujets, dans 2 conditions. Pour cela, nous utilisons le programme temps-fréquence qui prend 2 paramètres en entrée: un fichier de données et un nom de marker qui identifie une condition dans le fichier de données. Nous avons donc 3 x 2 = 6 calculs à faire que l'on peut lancer avec l'un des deux scripts suivants (sujet1 désigne le fichier de données du premier sujet et marker1 identifie la première condition):
#! /bin/bash temps-frequence sujet1 marker1 >& sujet1_marker1.log temps-frequence sujet1 marker2 >& sujet1_marker2.log temps-frequence sujet2 marker1 >& sujet2_marker1.log temps-frequence sujet2 marker2 >& sujet2_marker2.log temps-frequence sujet3 marker1 >& sujet3_marker1.log temps-frequence sujet3 marker2 >& sujet3_marker2.log
#! /bin/bash
for sujet in "sujet1 sujet2 sujet3"
do
for marker in "marker1 marker2"
do
temps-frequence $sujet $marker >& sujet${sujet}_${marker}.log
done
done
Les calculs étant complètement indépendants les uns des autres (sujets/markers), on va profiter des nœuds du cluster pour répartir les calculs.
Prérequis pour utiliser le cluster de l'ICM
Il faut posséder un compte ICM (voir avec votre correspondant informatique) puis demander à Romain de créer un compte sur le cluster de l'ICM.
Toutes les données utilisées par les calculs (les fichiers de données de chaque sujet) doivent être copiées sur votre compte (rsync).
Les programmes utilisés (temps-frequence) doivent être accessibles depuis votre compte: soit ils sont déjà installés pour les plus utilisés (matlab), soit vous pouvez demander une installation (spm), soit vous devez les copier vous-même sur votre compte (temps-fréquence).
Par la suite, on considère que l'on se trouve dans un répertoire qui contient les fichiers de données sujet1, sujet2, sujet3 et un répertoire vide cluster_jobs destiné à contenir tous les scripts permettant de lancer les calculs sur le cluster et les fichiers créés par le cluster contenant des informations sur le déroulement des calculs.
Principes
Le but est d'envoyer tous les calculs au cluster qui se charge ensuite de répartir l'exécution des calculs sur ses différents nœuds.
Chaque calcul est envoyé au cluster avec la commande suivante:
qsub -l //options_de_cluster// -o //fichier_de_log// -e //fichier_d_erreur// //fichier_de_calcul//
qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet1_marker1_cluster.log -e cluster_jobs/sujet1_marker1_cluster.err cluster_jobs/sujet1_marker1.bash
nodes=1:ppn=4 est une liste d'options transmises au scheduler du cluster: paramétrage du nombre de nœuds (nodes=1) et de processeurs par nœuds (ppn=4) demandés au cluster pour faire le calcul).
cluster_jobs/sujet1_marker1_cluster.log est un fichier créé par le cluster contenant des infos sur les ressources utilisées par le calcul:
############################### # EPILOGUE : RESSOURCES # ############################### Ressources demandees (hh:mm:ss): 10000:00:00 Ressources utilisees (hh:mm:ss): 00:05:07
cluster_jobs/sujet1_marker1_cluster.err est un fichier créé par le cluster qui est vide si le calcul s'est bien déroulé au niveau du cluster. Il faut toujours vérifier sa taille pour détecter d'éventuelles erreurs survenues au niveau de la gestion du calcul par le cluster (dépassement du temps maximum autorisé pour le calcul).
cluster_jobs/sujet1_marker1.bash contient la commande de calcul à effectuer:
#! /bin/bash temps-frequence sujet1 marker1 >& cluster_jobs/sujet1_marker1.bash.log
Tous les calculs peuvent être adressés au cluster en une seule fois et regroupés dans submit_cluster.bash:
#! /bin/bash qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet1_marker1_cluster.log -e cluster_jobs/sujet1_marker1_cluster.err cluster_jobs/sujet1_marker1.bash sleep 1 qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet1_marker2_cluster.log -e cluster_jobs/sujet1_marker2_cluster.err cluster_jobs/sujet1_marker2.bash sleep 1 qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet2_marker1_cluster.log -e cluster_jobs/sujet2_marker1_cluster.err cluster_jobs/sujet2_marker1.bash sleep 1 qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet2_marker2_cluster.log -e cluster_jobs/sujet2_marker2_cluster.err cluster_jobs/sujet2_marker2.bash sleep 1 qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet3_marker1_cluster.log -e cluster_jobs/sujet3_marker1_cluster.err cluster_jobs/sujet3_marker1.bash sleep 1 qsub -l nodes=1:ppn=4 -o cluster_jobs/sujet3_marker2_cluster.log -e cluster_jobs/sujet3_marker2_cluster.err cluster_jobs/sujet3_marker2.bash sleep 1
Note: La création des scripts submit_cluster.bash et cluster_jobs/sujet1_marker1.bash, cluster_jobs/sujet1_marker2.bash, cluster_jobs/sujet2_marker1.bash, cluster_jobs/sujet2_marker2.bash, cluster_jobs/sujet3_marker1.bash et cluster_jobs/sujet3_marker2.bash peut être automatisée avec le script :create_submit_cluster.py|.
Exécuter le script submit_cluster.bash pour envoyer la liste des calculs au cluster: la liste des identifiants associant chaque calcul à un job sur le cluster est affichée.
Le cluster répartit ensuite les jobs sur ses nœuds/processeurs, en fonction des ressources disponibles.
Contrôles
Pour consulter l'état des jobs sur le cluster (en train de tourner sur un nœud, en attente, ...), utiliser la commande:
qstat -a -n -1
Un job est terminé quand il disparaît de la liste.
Pour vérifier que tous les jobs ont bien été effectués par le cluster, il faut vérifier que les fichiers d'erreur sont vides: :list_non_empty_files.py| cluster_jobs/*cluster.err
La liste des fichiers d'erreur non vides correspondant aux jobs en erreur sur le cluster est affichée.
On peut aussi classer les jobs par vitesse d'exécution en utilisant les fichiers de log du cluster: :sort_cluster_log.py| cluster_jobs/*cluster.log
Les jobs et leur vitesse d'exécution sont affichés par ordre croissant:
[lemarechal@blade4 ]$ sort_cluster_log.py cluster_jobs/*cluster.log sujet1_marker2_cluster.log : 00:02:27 sujet2_marker1_cluster.log : 00:02:46 sujet2_marker2_cluster.log : 00:03:28 sujet1_marker1_cluster.log : 00:03:32 sujet3_marker2_cluster.log : 00:05:07 sujet3_marker1_cluster.log : 00:05:24
Stratégies de répartitions
Plusieurs stratégies de répartitions sont possibles.
Si le programme temps-fréquence est capable d'utiliser plusieurs processeurs en parallèle, on peut lancer un calcul sur un nœud du cluster = 1 job en l'autorisant à utiliser plusieurs processeurs du nœud (par exemple, pour allouer 4 proc: ppn=4). Sinon, il faut lui interdire d'utiliser plusieurs processeurs (ppn=1) pour éviter de réserver inutilement des ressources processeurs sur ce nœud.
Règles de bonne conduite
Le cluster est une ressource PARTAGÉE: vous devez faire en sorte de ne pas monopoliser les ressources.
Pour essayer de partager "équitablement" les ressources entre utilisateurs, des priorités sont attribuées aux jobs en attente en fonction de l historique récent de chaque utilisateur associe. Plus vous avez utilise de ressources cluster récemment et moins vos jobs seront prioritaires.
Attention, ce système de priorité n est pas suffisant pour l instant. Si a un moment donne, le cluster est complètement libre, rien ne vous empêchera de lancer des calculs sur tous les nœuds et en utilisant tous les processeurs (comme vous êtes le seul utilisateur, les priorités n auront aucun rôle). Si chaque calcul dure plusieurs jours (plusieurs semaines?), c est le cluster entier qui est monopolise pendant plusieurs jours (plusieurs semaines) !!!
Avant de lancer de gros calculs, vérifier bien les paramètres, ...
Il est plus efficace de lancer un seul calcul, de vérifier que ça s est bien passe, d avoir une idée du temps de calcul avant de lancer les 99 suivants!!!
Il est très important de pouvoir être capable d estimer le temps de chaque calcul.
Il est très important de savoir exactement comment va se faire la répartition.