Connexion vers un cluster par ssh

Le problème est récurrent car nous ne souhaitons pas ouvrir les clusters au monde entier.

Nous procédons donc en deux étapes :

  • soit vous avez un compte UM2 (connexion avec votre adresse email @univ-montp2.fr) ; dans ce cas, il vous suffit d'utiliser le VPN UM2 et de vous connecter au serveur VPN de l'UM2 vpnum2.univ-montp2.fr :

  • soit vous n'avez pas de compte UM2. Dans ce cas, il vous faudra faire une demande spécifique au service de la plateforme calcul de l'ISEM à cette adresse, en précisant dans la catégorie "Cluster access", votre groupe de travail, laboratoire, équipe (avec le nom de votre correspondant MBB de votre laboratoire s'il s'agit d'un accès SSH à la plateforme de calcul LabEx CeMEB MBB) et votre adresse IP publique.

Comment accéder au cluster depuis Windows

Pour vous connecter au cluster depuis Windows, il faut utiliser Putty. Un tutoriel est disponible ici : http://www.electrictoolbox.com/article/applications/ssh-putty/

Starter s Guide

Voici quelques pistes pour une prise en main rapide des clusters de calculs :

  • Voici quelques commandes SGE (pour plus d’infos man sge_intro ou https://arc.liv.ac.uk/SGE/htmlman/manuals.html) :

    • qsub submit a batch job to Grid Engine
    • qstat show the status of Grid Engine jobs and queues
    • qdel delete Grid Engine jobs from queues
    • qmon GUI front-end to user’s and administrator’s utilities
  • En general vous devez encapsuler la commande d’appel de votre executable dans un script ex.:

#! /bin/sh
# Ceci est un tres simple exemple de job sequentiel
# Options SGE:
# utilise /bin/sh:
#$ -S /bin/sh
#
# nom:
#$ -N mon_test_sge
#
# envoyer un mail à cet utilisateur
#$ -M belkhir univ-montp2.fr
# envoie de mail lorsque le job est fini
#$ -m e
#
# utilise le repertoire courant pour lancer le job test
# avec comme paramètre le fichier param1.txt
#$ -cwd

/home/khalid/bin/test /home/khalid/data/param1.txt

Pour soumettre ce script (monscript.sh) il faut:

qsub monscript.sh
  • Une alternative est d’utliser l’option “-b y” pour signifier que vous présentez un binaire à la commande qsub :
    qsub -b y /home/khalid/bin/test /home/khalid/data/param1.txt
    
  • qstat et qmon (version graphique) vous permettent de suivre l’état de votre job.

Utilisation basique de SGE et explication des options

Introduction

GridEngine est un gestionnaire de ressources et un job scheduler (SGE, édité à l'origine par Sun et aujourd'hui remplacé de manière OpenSource par OpenGrid Scheduler sur nos clusters).

Ça signifie que GridEngine est capable de surveiller les ressources disponibles et d'ordonnancer les jobs afin de garantir une utilisation optimale de l'ensemble des ressources gérées pour tous les utilisateurs et d'exécuter les tâches demandées par ces derniers (jobs) en fonction des politiques implémentées par l'administrateur.

Pour quels types de jobs

Comme indiqué sur cette page, GridEngine peut être utilisé pour des jobs "standards", c'est à dire séquentiels, ou des jobs peu ou fortement parallélisés (multithreads, tableaux de jobs, environnement parallèles (mpi...).

Exécution des jobs

Un job va être stocké (statut "qw" pour "queue wait job") dans une queue avant de passer en exécution (statut "r" pour "running job") en fonction des droits de l'utilisateur et des ressources disponibles. Si ce dernier demande une queue particulière, alors il pourra lancer des jobs dessus à condition d'y être autorisé; si les ressources sont utilisées alors ils seront en attente. Une queue correspond normalement à un groupe de machines appelés "noeuds" de calcul.

Lancer des jobs avec qsub

qsub

Pour "Queue Submit" est la commande principale à connaître pour utiliser GridEngine.Vous devez insérer votre commande ou votre script à soumettre au travers d'un script de soumission.

Ce dernier, que nous allons appeler test.sge pour l'exemple, doit être articulé de la manière suivante :

#!/bin/bash

# Shell to use
#$ -S /bin/bash
# Name of the job in SGE
#$ -N my_job
# Name of the queue to use
#$ -q cemeb.q
# Maximum hardware time allowed for this job
#$ -l h_rt=00:33:00
# Merge output (error and standard with '-j y') into one single file called my_job.out
#$ -o my_job.out -j y
# run in the current directory
#$ -cwd

YOUR_COMMAND_OR_SCRIPT_TO_EXECUTE

En bash, les commentaires commencent par « # ». Ainsi, les lignes d’options SGE ne sont pas lues par bash. Cependant, tout ce qui commence par « #$ » correspond à une option SGE, que ce dernier va ensuite interpréter. Chaque option SGE (prédéfinie par "#$") est suivie du nom de l'argument et de sa valeur. Les options peuvent également être directement appelées au moment du qsub.

Vous lancez ensuite ce script avec:

qsub test.sge
  • Intérêt de l'option -l h_rt=HH:MM:SS Cette option permet de faire tourner un job alors qu'une réservation de ressources sur le cluster (Advanced Reservation (AR)* est déjà en place sur un cluster. Si h_rt est inférieur à la durée restante avant que la réservation commence réellement il est alors possible que votre job soit soumis sur des ressources réservées. On appelle ça du backfilling.

  • s_rt fait la même chose que h_rt mais envoie un signal de type SIGXUSR1 qui peut être intercepté par le programme si ce dernier en a la capacité.

L'options -l h_rt est désormais OBLIGATOIRE. (sinon elle sera définie avec une valeur par défaut (-l h_rt=12:00:00).

  • Une autre option très utile pour qsub est "-v" ou mieux, "-V". Avec cette option, vous pouvez lancer votre job et conserver une partie (-v suivi de la ou des variable(s) d'environnement) ou la totalité (-V) de vos variables d'environnement.

  • Il est également possible de lancer directement des jobs sans passer par un script, mais ce n'est pas recommandé (option "-b y").

  • Concernant un usage plus avancé (tableaux de jobs, synchronisation, mailing...), pour plus d'informations, merci d'utiliser la commande man

Ici, un autre exemple de script de soumission basique</a>

Pour plus d'informations:

man qsub

Pour un exemple plus complet, vous pouvez regarder le fichier general_qsub_file.sh dans votre dossier personnel ($HOME).

Un petit exemple fournit par rocks cluster / SGE : http://www.rocksclusters.org/roll-documentation/sge/4.2.1/submitting-batch-jobs.html

Soumettre un job sur un noeud ou une queue précise

Choix de la queue longue :

qsub -q long.q myjob.sh
# ou
qsub -l qname=long.q myjob.sh

Choix du noeud 10 :

qsub -l hostname=compute-0-10 myjob.sh

Afficher l état des files d attente

Cette commande retourne plusieurs colonnes :
Le job id, suivi de sa priorité, son nom (ça serait my_job dans l'exemple), l'utilisateur qui a soumis le job, l'état, le moment où ça a été soumis, sur quelle queue ça s'exécute, le nombre de slots que ça prend et éventuellement l'id d'un job provenant d'un tableau de job.

```bash
qstat

#pour afficher uniquement vos jobs
qstat | grep $USER

#pour compter mes jobs
qstat | grep $USER | wc -l

#pour plus de détails
qstat -f

#pour une vue résumée de la charge des queues
qstat -g c

#uniquement les jobs qui tournent (état r)
qstat -sr

#cacher les queues vides
qstat -ne

#avoir tous les details sur le job n° 999
qstat -j 999
qstat -j JOB_ID;

Il y a plusieurs états:

  • "r" pour running (tourne)
  • "qw" pour queue wait (en attente)
  • "t" pour transfert
  • "dt" pour disable transfert (une erreur est survenue à la copie des informations du job)
  • "E" pour erreur ("qstat -explain E" pour afficher pourquoi)
  • ...

Vous pouvez combiner également plusieurs options pour qstat; exemple:

qstat -s r -l qname=cemeb.q,hostname=compute-0-5.local

Affiche les jobs en état "running" ("-s r" = state running (pour afficher ceux en attente, utiliser l'option "p" / pending)), sur les ressources de type "nom de la queue" = "cemeb.q" et "nom du noeud" = "compute-0-5.local".

L'option "-u" ne fonctionne pas chez nous car il y a un "alias" : alias qstat='qstat -u *'". Ce qui permet, par défaut, de faire un qstat sur tous les utilisateurs (si vous souhaitez tout de même filtrer les sorties par cette option, il vous faudra entrer le chemin complet de la commande (retourné par "which qstat") ou vous pouvez avoir le résultat équivalent en filtrant le résultat avec un grep).

Pour plus d'informations, sur qstat.

man qstat

Supprimer un job avec qdel

qdel permet de supprimer un job. Son utilisation est assez simple.

qdel JOB_ID

Pour rappel, vous pouvez récupérer le JOB_ID avec qstat.

Voir ici

Pour aller plus loin

Voir sur quelles machines tournent les jobs:

qhost -j

A quelles queues appartiennent les machines:

qhost -q

Voir également le HOW TO et ce document cirad.

Déterminer si vous avez accès à une queue

Lister les queues actives:

qconf -sql

Voir quelles sont les machines auxquelles vous avez accès dans cette queue:

qselect -q QUEUE -U $USER

Avoir des informations sur une queue spécifique:

qconf -sq QUEUE

Vous pouvez Repérer la ligne "user_lists". S'il y a écrit "NONE", et que "xuser_lists" est également à NONE, alors tout le monde est autorisé à lancer des jobs sur cette queue. Sinon, s'il y a autre chose, il faut que vous vérifiez que vous fassiez bien partie des "Userset" définis ici;

Exemple:

 qconf -su

Attention toutefois, vous pouvez aussi être associé à un Userset, non pas au travers de votre nom d'utilisateur, mais au travers de votre groupe d'appartenance.

Pour afficher des informations (uid, gid, groupes d'appartenance) sur votre compte:

id

(*) : pour voir s'il y a des réservations et afficher les détails d'une réservation: Pour les détails des réservations:

qrstat -u \*

Pour le détail d'une réservation (avec son id récupéré au-dessus):

qrstat -ar 103

Quels logiciels sont installés sur le cluster

Nous essayons de mettre la plupart des logiciels dans le dossier /share/apps/bin. Ce dossier est visible sur tous les noeuds de calcul et est le même sur les deux clusters (synchronisé toutes les nuits). Quand ce n'est pas possible nous installons directement sur le noeud (dans /usr/local/bin ou /usr/local/[nom_du_logiciel] ou dans un chemin standard contenant des binaires). En dernier recours, nous faisons un package ou un container spécifique.

Si l'application que vous souhaitez utiliser n'est pas disponible, deux choix s'offrent à vous :

  1. L'installer dans votre home quand c'est possible (à préférer). Votre répertoire personnel (home) est visible sur tous les noeuds.
  2. Demander son installation dans /share/apps/bin ou dans votre home (en faisant un ticket) (à éviter dans la mesure du possible).

Dans la grande majorité des cas, vous n'aurez pas besoin de privilèges élevés pour installer et utilier un logiciel sur le cluster. Même ceux qui nécessitent un make install peuvent normalement être utilisés à la suite d'un make (voir le sous-dossier bin). Par conséquent le point 2 est à éviter, sauf si vous pensez que le logiciel peut être utile ou est déjà utilisé par le reste de la communauté.

Dans le cas où le logiciel vous semble trop complexe à installer, nous l'installerons dans votre home ou créerons une solution appropriée.

Pour les packages/modules Perl, Python ou R, nous n'installons plus en standard ces derniers sur toutes les machines. Cette installation est à votre charge, sauf en cas de dépendances systèmes (librairies systèmes ou packages système autre (rpm) etc...).

PATH

Cette variable d'environnement Linux permet de lister tous les chemins censés contenir des binaires. Ainsi, vous pouvez utiliser des binaires, sans utiliser de chemin vers ces derniers, mais en les appelant directement.

Vous pouvez afficher son contenu simplement:

echo $PATH

Vous verrez ainsi les chemins les plus courants qui contiennent des binaires (/usr/bin, /bin, /usr/local/bin (...)). Ces chemins sont séparés par le caractère ":".

Vous pouvez la modifiant avec la commande suivante:

export PATH=$PATH:/autre_chemin_ves_binaires

Avec /autre_chemin_ves_binaires, le chemin à rajouter au PATH pour rechercher des binaires.

Il peut être pratique de rajouter ce type de ligne à la fin de votre fichier ~/.bashrc pour que ça se remette à chaque reconnexion de votre part.

Sinon, il faudra utiliser un chemin relatif ou absolu pour pouvoir lancer votre commande (notions de chemins).

Chercher avec l'auto-complétion

Sous Linux, un aspect très pratique est l'auto-complétion. Vous pouvez chercher un programme si vous connaissez le début de son nom (puis en appuyant sur la touche TAB).

Si ça ne répond pas, soit le logiciel n'est pas présent, soit il est installé, mais les binaires ne sont pas contenus dans le PATH. C'est le cas de certains logiciels installés dans /usr/local/, dans /opt ou dans votre dossier personnel /home/nom_d_utilisateur.

Le noeud maître est très allégé en programme! En effet, il est volontairement bridé pour qu'il reste disponible / pour que vous puissiez vous y connecter.

Si vous ne trouvez pas le programme que vous cherchez directement sur le noeud maître, vous devez essayer de le trouver sur les noeuds de calcul! Il convient donc de faire un qrsh au préalable, afin d'être connecté sur un noeud de calcul; vous pouvez ensuite réessayer de faire de l'auto-complétion.

A noter qu'avec qrsh, vos variables d'environnement sont modifiées, le PATH n'est donc pas tout à fait le même. Par ailleurs, pensez à faire un logout/exit à la fin de votre recherche. En effet, tous les jobs (sauf vos compilations / installations) doivent être lancés par qsub depuis le noeud maître.

Chercher avec which, whereis, find, locate

Hormis locate disponible uniquement pour le root, vous pouvez utiliser toutes les commandes listées ci-dessus:

La commande which retroune le premier chemin valide trouvé du PATH, alors que whereis continuera de chercher dans le PATH.

Comme pour l'auto-complétion, ci-dessus, sachez que le noeud maître est allégé en programme. Pensez à faire un qrsh pour vérifier la présence du logiciel à chercher sur les noeuds de calcul.

/share/apps/bin

Ce dossier contient un grand nombre de logiciel. Etant composé d'un grand nombre de sous-dossiers, nous n'ajoutons pas tous ces sous-dossiers à votre PATH. Un simple

ls

permet déjà de se faire une idée.

Roll bio

Le Roll Bio est une sorte de package contenant de nombreux logiciels orientés biologie: http://www.rocksclusters.org/roll-documentation/bio/5.4/pkglist.html

Voir aussi l'utilisation de module

Installer un logiciel

En tant qu'utilisateur vous avez des droits limités. Vous pouvez installer ce que vous voulez dans votre dossier personnel. Vous pouvez également le tester dans le répertoire /tmp. Certaines commandes nécessitent généralement des privilèges plus élevés, comme:

make install
yum install ...
rpm -[i|U]...

Parfois, des binaires sont disponibles en téléchargement pour votre logiciel. Dans ce cas, vous pouvez vous contenter de copier ce fichier (version 64 bits) dans votre Home.

make, make install

Un simple make suffit souvent pour faire fonctionner votre programme (parfois le make install ne fait que copier des binaires et des librairies dans des chemins systèmes plus standards (/usr/bin, etc...)). Par ailleurs, si vous avez pu faire un configure en passant l'option --prefix=~/chemin_vers_mon_nouveau_logiciel, il est possible que make install fonctionne. Tout dépendra des règles qui sont définies dans le fichier makefile.

Package rpm et yum

Pour ce type d'installation, seul le root est habilité à installer ces programmes. Cependant, vous pouvez peut-être trouver des sources plus à jour du logiciel que vous cherchez (non figées dans un rpm) et l'installer depuis les sources (souvent une archive compressée de type .tar.gz, .tgz, .tar.bz2...).

Installation de package R

En premier lieu, merci de lire comment utiliser module

R est disponible au travers de module.

Merci de vous référer à cet article: Installer un package R

Installation de package Perl

En premier lieu, merci de lire comment utiliser module

Perl est disponible au travers de module. Il s'agit de la version 5.14

Merci de lire cet article pour personnaliser votre environnement et utiliser des packages R depuis votre Home.

Installation de package Python

En premier lieu, merci de lire comment utiliser module

Python est disponible au travers de module.

Voir ici pour installer un package python.

Utiliser module

module est un système qui permet de changer rapidement d'un environnement à un autre pour des programmes ou des librairies. Pour celà, on utilise des "modulefiles". Pour l'instant, les modulefiles disponibles sont accessibles par la commande:

module avail

Comment l'utiliser ?

$ module load python3.3
$ python -V
Python 3.3.4
$ which python
alias python='python3.3'
/opt/python/bin/python3.3
$ module unload python3.3
$ python -V
Python 2.6.6
$ which python
/usr/bin/python

$ module load java1.8
$ which java
/etc/alternatives/jre_1.8.0_openjdk/bin/java
$ module show java1.8
-------------------------------------------------------------------
/etc/modulefiles/java1.8:

setenv JAVA_HOME /etc/alternatives/jre_1.8.0_openjdk
prepend-path PATH /etc/alternatives/jre_1.8.0_openjdk/bin/
prepend-path LD_LIBRARY_PATH /etc/alternatives/jre_1.8.0_openjdk/lib/
append-path PE_PRODUCT_LIST JAVA
-------------------------------------------------------------------

$ echo $PATH
/etc/alternatives/jre_1.8.0_openjdk/bin/:/usr/local/bin:....
$ echo $LD_LIBRARY_PATH
/etc/alternatives/jre_1.8.0_openjdk/lib/:/opt/gridengine/lib/linux-x64:/opt/openmpi/lib:/lib64:/usr/lib64:/usr/local/lib64:/usr/lib/:/usr/local/lib:/opt/python/lib
$ module load gcc4.9
$ module list
Currently Loaded Modulefiles:
1) rocks-openmpi 2) java1.8 3) gcc4.9

Dans vos scripts de soumission qsub, pensez à précéder la ligne d'exécution de votre script par le chargement de la version que vous souhaitez utiliser avec module, ou bien soumettez votre job/script de soumission avec l'option "-V" après avoir chargé votre environnement avec module dans votre shell. Exemple :

module load R-3.2.0
# l'option "-V" peut aussi être rajoutée à la liste des options SGE dans le script de soumission ($# -V).
# Cf le fichier general_qsub_file.sh dans votre home.
qsub -V my_submit_script.sh
# avec mon_script.sh qui contient, par ex. :
#$ -S /bin/bash
#$ -cwd
#$ -N myRscript
#$ -o my_output_file
R CMD BATCH my_script.R

ou

qsub my_submit_script.sh
# avec mon_script.sh qui contient, par ex. :
#$ -S /bin/bash
#$ -cwd
#$ -N myRscript
#$ -o my_output_file
module load R-3.2.0
R CMD BATCH my_script.R

Comment connaître les environnements parallèles disponibles sur le cluster

Faire qconf -spl pour avoir la liste de ces environnements puis qconf -sp nom_du_pe pour en connaitre la définition plus précisément la propriété allocation_rule qui peut être:

1. "pe_slots", i.e., tous les slots sont alloués sur le même noeud
2. "round robin", i.e. les slots sont distribués sur les noeuds un à la fois à tour de rôle.
3. "fill up", i.e. les slots sont alloués sur un premier noeud jusqu'à son remplissage avant de passer aux suivants ...

Limitations sur le cluster ISEM et le cluster MBB

Par défaut plusieurs types de limitations peuvent s'appliquer :

  1. quota disque
  2. accès ou non à certaines queues
  3. limitation en temps de calcul sur les queues
  4. limitation en nombre de jobs par queue ou par utilisateur

Comment connaître ces limites

Quotas disques

Pour connaître votre quota :

get_myquota.sh

Ce script va vous demander votre mot de passe pour interroger la base de données. IL vous propose également de calculer votre utilisation actuelle de disque. Si vous constatez que cette valeur n'est pas à jour dans la base, merci de contacter l'équipe ( http://kimura.univ-montp2.fr/calcul/ -> HelpDesk -> Nouvelle demande).

Accès aux queues

Pour savoir à quelles queues/machines vous avez accès :

qselect -U $USER

Limite en temps

Plusieurs paramètres dans SGE permettent de limiter le temps de calcul des jobs sur les clusters. Nous en utilisons deux :

  • la limite par "h_rt" (hardware runtime)
  • la limite définie par la queue elle-même

Connaître le h_rt

remy@cluster-mbb:~$ tail -1 $SGE_ROOT/$SGE_CELL/common/sge_request
-l h_rt=12:00:00

Par défaut, tout job sera donc tué au bout de 12h. Cependant, vous pouvez écraser cette valeur en mettant celle de votre choix en changeant cette option quand vous soumettez un job. Il est possible de marquer par exemple :

#$ -l h_rt=999:00:00

Vous pouvez aussi spécifier cette valeur en secondes.

Vous pouvez aussi écraser cette valeur pour toujours en créant un fichier nommé .sge_request à la racine de votre home directory.

Auparavant, il fallait aussi spécifier le s_rt (software runtime), mais ce n'est plus nécessaire.

Connaître les caractéristiques d'une queue

Lorsque vous savez sur quelle(s) queue(s) vous pouvez tourner (voir ci-dessus, avec qselect -U $USER), il vous suffit de faire par exemple :

qconf -sq <nom_de_queue>

Vous pouvez connaître l'ensemble des queues présentes avec qconf -sql

Ainsi, sur la queue ISE-M small.q, une limite de 10h a été fixée :

[remy@cluster-isem ~]$ qconf -sq small.q |grep h_rt
h_rt                  10:00:00

Limite par nombre de jobs

Afin de savoir si vous êtes limités en nombre de jobs simultanés, il vous faut d'abord savoir s'il existe des "ressources quotas" dans SGE :

qconf -srqsl

Lorsque vous avez la liste des "ressources quotas", vous pouvez afficher la caractéristique de chacune avec :

qconf -srqs <ma_ressource_quota>

Exemple :

remy@cluster-mbb:~$ qconf -srqs limit_slots_to_cores_rqs
{
   name         limit_slots_to_cores_rqs
   description  Prevents core oversubscription across queues.
   enabled      TRUE
   limit        hosts {*} to slots=$num_proc
}
remy@cluster-mbb:~$ qconf -srqs max_slots_on_sshqueues
{
   name         max_slots_on_sshqueues
   description  "limit the number of slots for queues cemeb(20).q for ssh \
   submissions"
   enabled      TRUE
   limit        users {*} queues {cemeb.q,cemeb20.q} to slots=80
}

Dans l'exemple ci-dessus, on remarque qu'on ne peut pas lancer plus de jobs qu'il n'y a de coeurs par noeud et les queues cemeb.q et cemeb20.q du cluster MBB sont limitées à 80 jobs/utilisateur.

Parallélisation avec R sur le cluster

Voir cet article

File staging : Allègement cluster, travailler sur les disques des noeuds de calcul

Les home directory du noeud maître sont exportés via NFS sur les noeuds de calcul pour vous faciliter le travail. Cependant, les applications nécessitant beaucoup d'accès disque ( blast, NGS, ... ) dégradent les performances du système.

Pour y remédier, vous devez adopter la démarche suivante:

  • Chaque noeud dispose d'un espace disque qui lui est propre. La taille de cet espace varie en fonction des noeuds de calcul (56G ou 250G).
  • Vérifier l'existence du dossier /export/scrach/$USER (avec $USER étant vôtre login). Si ce n'est pas le cas, le créer par la commande
    mkdir /export/scrach/$USER
    
  • Copier les fichiers à utiliser dans un emplacement temporaire de ce dossier (exemple: /export/scrach/$USER/tmp)
  • Réaliser les opérations de lecture et d'écriture dans ce dossier
  • Une fois les traitements effectués, vous pouvez copier les résultats attendus dans votre dossier personnel
  • Surtout ne pas oublier de supprimer son dossier temporaire une fois les jobs terminés

Voici un exemple de script sge utilisant ce dossier:

#!/bin/bash
#
#$ -S /bin/bash
#$ -cwd
#$ -e job_name.err
#$ -o job_name.out

# On créé notre dossier temporaire
mkdir -p /export/scrach/khalid/tmp

# On copie nos fichiers de travail dans notre dossier temporaire
cp /home/khalid/monfichier /export/scrach/khalid/tmp

# On exécute notre programme en travaillant dans le dossier temporaire
test.pl /export/scrach/khalid/tmp/monfichier /export/scrach/khalid/tmp/job_output

# On copie nos résultats, et on n'oublie pas de supprimer son dossier temporaire
cp -rp /export/scrach/khalid/tmp /home/$USER
rm -rf /export/scrach/khalid/tmp

Synchronisation des jobs et nombres aléatoires…

Les simulations c’est bien, car ça se parallélise facilement… sauf quand qsub les lance simultanément, et que du coup il calcule plusieurs fois la même chose car chaque simulation utilise la même graine aléatoire.

La solution propre, c’est de générer un index de graines que les jobs consultent en temps voulu.

La solution « Quick & Dirty (c) », mais au combien pratique, c’est de rajouter cette ligne dans votre script bash soumis:

n=$RANDOM; let « n %= 60 »; sleep $n

Ceci va attendre un temps aléatoire entre 0 et 60s avant de lancer le programme, ce qui devrait résoudre bien des problèmes !

Abyss en parallèle

Lancer la version MPI d’Abyss :

exemple de script : submit_abyss.sh

#!/bin/bash
#$ -cwd
#$ -j y
#$ -S /bin/bash
#$ -pe robin 8
#$ -N tst_abyss

fic=$1
kmer=$2
outname=$3

export PATH=$PATH:/opt/openmpi/bin/

abyss-pe k=$kmer n=10 in="$fic" name=$outname

Lancer sur données « simple end »:

qsub submit_abyss.sh reads.fastq 25 test

Lancer sur données « paired-end »:

qsub submit_abyss.sh 'reads_1.fastq reads_2.fastq' 25 test

Mapper des reads en parallèle

Une solution intéressante pour distribuer la charge de travail de quelques outils de mapping (bwa, bowtie, soap …) sur plusieurs noeuds du cluster est « pMap: Parallel Sequence Mapping Tool » :http://bmi.osu.edu/hpc/software/pmap/pmap.html .

Une installation est faite sur /share/apps/pmap.

Exemple d’utilisation avec bwa :

Indexation avec ce script « indexer.sh »

#!/bin/bash
#$ -cwd
#$ -j y
#$ -S /bin/bash
#$ -N pmap_idx_bwa

export PATH=$PATH:/usr/local/bin:/share/apps/pmap/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/SUNWhpc/HPC8.2.1/gnu/lib/lib64/

genomefile=$1
indexdir=$2
indexprefix=$3
pmap_index $genomefile $indexdir $indexprefix bwa -a bwtsw
qsub  indexer.sh speciesA.diploid.fa indexdir/ speciesA

Mapping de données paired-end avec ce script « mapper.sh »

#!/bin/bash
#$ -cwd
#$ -j y
#$ -S /bin/bash
#$ -pe mpirobin 4
#$ -N pmap_bwa

workdir=/tmp
readsfile=$1
readsfile2=$2
indexdir=$3
indexprefix=$4
outdir=$5

export PATH=$PATH:/opt/openmpi/bin/:/usr/local/bin:/share/apps/pmap/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/SUNWhpc/HPC8.2.1/gnu/lib/lib64/

mpiexec -n 4 pmap_dist $workdir $outdir $readsfile -r $readsfile2 -i $indexdir $indexprefix

#spécifier le chemin car un autre pmap existe dans le path
mpiexec -n 4 /share/apps/pmap/pmap -pe $workdir $outdir bwa
qsub mapper.sh ../reads1.fastq ../reads2.fastq indexdir/ speciesA resu/

wodirqstat

wodirqstat: ce programme en python permet de voir quels jobs tournent à quel endroit (noeud, queue, sge working directory).

Son utilisation est assez simple : sans option, ça liste tout. Sinon, il y a la possibilité de rajouter « -u username » afin d’afficher le résultat pour un utilisateur particulier.

Questions

Voir la FAQ