- Démarrer un serveur JupyterLab en utilisant le service JupyterHub de l'IGBMC
- Lancer un Terminal
- Lancer la commande :
- Naviguez dans le répertoire
tutoriel_slurmainsi créé et ouvrez le notebooktutoriel.ipynb
git clone https://gitlab.com/ifb-elixirfr/cluster/tutoriel_slurm.gitrm -rf results *.outIntroduction à SLURM
SLURM (Simple Linux Utility for Resource Management) est le logiciel utilisé pour assurer la gestion des ressources sur le cluster de calcul de l’IFB. Il permet de réserver des ressources et lancer des programmes sur les noeuds de calcul du cluster. Les commandes SLURM commencent toutes par la lettre s
Le vocabulaire SLURM
CPU : le CPU est la plus petite unité d’un processeur d’ordinateur.
Cette unité correspond généralement à un thread ou un coeur hyperthreadé.
À l’IFB sur la plupart des noeuds nous avons 2 processeurs Haswell E5-2695 v3. Chaque processeur a 14 coeurs physiques et 28 threads (ou coeurs virtuels) SLURM considère donc 56 CPU par noeud.
RAM : la RAM est la mémoire utilisée par le processeur pour stocker les données analysées
À l’IFB nous avons en moyenne 252 Go de mémoire vive par noeud
Task : une task est un processus (exécution d’un outil). Elle peut utiliser plusieurs CPU.
Job : un job est une réservation de ressources (CPU, RAM et tasks) pour effectuer une analyse.
On peut imaginer un job comme une usine dans laquelle on va organiser l’exécution de son analyse.
La taille de l’usine va être définie par une quantité de CPU, de RAM et de tasks (on définit généralement le nombre de CPU en fonction du nombre de tasks).
Job step : un “job step” est la partie d’un job qui consiste à exécuter un programme
Un “job step” peut utiliser plusieurs “tasks” mais ceci est spécifique à certains programmes compatibles avec le calcul parallèle. Dans la plupart des cas, un job step utilise une “task”.
On peut imaginer un job step comme un atelier de la chaîne de production dans notre usine.
Maîtriser SLURM
Au travers de l’utilisation des commandes SLURM nous allons apprendre à réserver des ressources (une usine) et mettre en route des chaînes de production pour nos analyses.
Plus nous aurons de grandes chaînes de production et plus nos ateliers seront gourmands en ressources, plus nous aurons besoin de réserver de grandes usines !
Soumettre un “job”
Lancer des jobs ou analyse interactive
Il existe deux modes d’utilisation d’une infrastructure de calcul :
Analyse par soumission de jobs
- Nécessite l’écriture de scripts
- Est adaptée pour des traitements longs et/ou répétitifs
- Est adaptée aux outils non interactifs (ne nécessitant pas d’interaction avec un humain)
Analyse interactive
- L’utilisateur est intégré au coeur du processus d’analyse
- Est adaptée aux traitements courts et uniques
- Est adaptée aux outils interactifs (nécessitant une interaction avec un humain)
Nous allons apprendre à soumettre des jobs.
Les commandes sbatch et srun
Une analyse bioinformatique que l’on souhaite lancer sur le cluster se présente sous la forme d’un ou plusieurs scripts shell.
Pour soumettre un job sur le cluster on utilise principalement deux commandes SLURM :
sbatchpermet de réserver des ressources (l’usine) et demander le lancement de son scriptsrunpermet de lancer un “job step” dans son script
Les options les plus utiles
sbatch et srun proposent les mêmes options de base :
-cpus-per-task: Nombre de CPU par tasks-mem: Quantité de mémoire vive allouée par noeud de calcul (exprimée en Mo par défaut)-mem-per-cpu: Quantité de mémoire exprimée en fonction du nombre de CPU-ntasks: Nombre de tasks (par défaut un job est dimensionné avec 1 task)
Récupérer les données d’exemple
Nous allons utiliser 6 séquences pour illuster nos exemples d’utilisation de SLURM.
Ces séquences sont disponibles sur Zenodo : DOI 10.5281/zenodo.5035749
Nous allons utiliser l’outil zenodo_get pour télécharger ces données :
module load zenodo_get
zenodo_get -o data -t 60 -R 3 10.5281/zenodo.5035749
Title: Sample data for sequencing reads alignment
Keywords:
Publication date: 2021-06-27
DOI: 10.5281/zenodo.5035749
Total size: 2259.1 MB
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/KO1_1.fastq.gz size: 330.7 MB
KO1_1.fastq.gz is already downloaded correctly.
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/KO2_1.fastq.gz size: 374.2 MB
KO2_1.fastq.gz is already downloaded correctly.
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/KO3_1.fastq.gz size: 375.1 MB
KO3_1.fastq.gz is already downloaded correctly.
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/WT1_1.fastq.gz size: 406.8 MB
WT1_1.fastq.gz is already downloaded correctly.
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/WT2_1.fastq.gz size: 409.5 MB
WT2_1.fastq.gz is already downloaded correctly.
Link: https://zenodo.org/api/files/352ed986-503b-437f-adf6-f108af03aa8e/WT3_1.fastq.gz size: 362.8 MB
WT3_1.fastq.gz is already downloaded correctly.
All files have been downloaded.Effectuer un alignement de séquences
Nous allons utiliser deux outils de bioinformatique pour réaliser notre première analyse avec SLURM :
- bowtie2 : permet d’aligner une séquence sur un génome de référence. On utilise un index réalisé à partir du génome de référence pour effectuer l’alignement
- samtools : permet de filtrer, trier et convertir une cartographie d’alignement de séquences
Pour chaque étape successive du traitement nécessite au moins 1 CPU et 1 Go de RAM.
Nous devons donc réserver au moins 1 task, 1 CPU et 1Go de RAM pour réaliser ce traitement.
Le script scripts/alignement_KO1_1-v1.sh permet de réaliser l’alignement du fichier KO1_1.fastq.gz
#!/bin/bash
module load bowtie2 samtools
reference_index="/shared/bank/arabidopsis_thaliana/TAIR10.1/bowtie2/Arabidopsis_thaliana.TAIR10.1_genomic"
file_id="KO1_1"
mkdir -p results
srun bowtie2 -x "${reference_index}" -U "data/${file_id}.fastq.gz" -S "results/${file_id}.sam"
srun samtools view -hbS -q 30 -o "results/${file_id}.filtered.bam" "results/${file_id}.sam"
srun samtools sort -o "results/${file_id}.bam" "results/${file_id}.filtered.bam"Nous soumettons le script au cluster à l’aide de la commande sbatch en précisnat nos besoins de ressources :
job_id=`sbatch --parsable --cpus-per-task=1 --mem=1G scripts/alignement_K01_1-v1.sh`
echo $job_id
17392163La soumission du job a entraîné la création d’un fichier slurm-<job_id>.out. Ce fichier continent le résultat des commandes executées au sein du job.
Suivre son job avec squeue
La commande squeue permet de visualiser des informations sur les jobs dans la file d’attente de SLURM
Consulter l’état d’un job :
squeue -j $job_id
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17392163 fast aligneme jseiler R 5:17 1 cpu-node-7Consulter les jobs de votre utilisateur :
squeue -u $USER
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17387293 fast jupyter jseiler R 1:18:55 1 cpu-node-20
17392163 fast aligneme jseiler R 6:45 1 cpu-node-7Consulter les jobs de votre utilisateur en cours d’exécution :
squeue -u $USER -t RUNNING
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17387293 fast jupyter jseiler R 1:19:09 1 cpu-node-20
17392163 fast aligneme jseiler R 6:59 1 cpu-node-7Consulter les jobs en attente :
squeue -t PENDING
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17234573_[333-336, long simNosta alerouzi PD 0:00 1 (JobArrayTaskLimit)
17234502_[101,187, long simStab2 alerouzi PD 0:00 1 (JobArrayTaskLimit)
17234699_[116-125, long simStep2 alerouzi PD 0:00 1 (JobArrayTaskLimit)
17384610 long canu_out ewicker PD 0:00 1 (Dependency)
17384624 long canu_out ewicker PD 0:00 1 (Dependency)
17385291 long canu_out ewicker PD 0:00 1 (Dependency)
17386338 long canu_out ewicker PD 0:00 1 (Dependency)
17386630 fast scikitsu pgladieu PD 0:00 1 (QOSMaxMemoryPerUser)
17386631 fast scikitsu pgladieu PD 0:00 1 (QOSMaxMemoryPerUser)
17387180 fast betascan pgladieu PD 0:00 1 (QOSMaxMemoryPerUser)
17387181 fast betascan pgladieu PD 0:00 1 (QOSMaxMemoryPerUser)
17387182 fast betascan pgladieu PD 0:00 1 (QOSMaxMemoryPerUser)
17392511 fast g814525_ galaxy PD 0:00 1 (Priority)
17392512 fast g814527_ galaxy PD 0:00 1 (Priority)
17392513 fast g814524_ galaxy PD 0:00 1 (Priority)
17392514 fast g814523_ galaxy PD 0:00 1 (Priority)
17392515 fast g814528_ galaxy PD 0:00 1 (Priority)
17392516 fast g814526_ galaxy PD 0:00 1 (Priority)
17392517 fast g814529_ galaxy PD 0:00 1 (Priority)
17392518 fast g814530_ galaxy PD 0:00 1 (Priority)
17392519 fast g814532_ galaxy PD 0:00 1 (Priority)
17392521 fast g814533_ galaxy PD 0:00 1 (Priority)
17392523 fast g814534_ galaxy PD 0:00 1 (Priority)
17392524 fast g814537_ galaxy PD 0:00 1 (Priority)
17392525 fast g814536_ galaxy PD 0:00 1 (Priority)
17392526 fast g814531_ galaxy PD 0:00 1 (Priority)
17392527 fast g814535_ galaxy PD 0:00 1 (Priority)
17392528 fast g814541_ galaxy PD 0:00 1 (Priority)
17392530 fast g814539_ galaxy PD 0:00 1 (Priority)
17392532 fast g814542_ galaxy PD 0:00 1 (Priority)
17392534 fast g814538_ galaxy PD 0:00 1 (Priority)
17392535 fast g814544_ galaxy PD 0:00 1 (Priority)
17392537 fast g814540_ galaxy PD 0:00 1 (Priority)
17392538 fast g814549_ galaxy PD 0:00 1 (Priority)
17392542 fast g814551_ galaxy PD 0:00 1 (Priority)
17392543 fast g814543_ galaxy PD 0:00 1 (Priority)
17392545 fast g814554_ galaxy PD 0:00 1 (Priority)
17392564 fast g814619_ galaxy PD 0:00 1 (Priority)
17392570 fast g814620_ galaxy PD 0:00 1 (Priority)
17384700 long canu_CH0 fcharria PD 0:00 1 (Dependency)
17392510 fast job-4818 nverstra PD 0:00 1 (Priority)
17392520 fast job-a05d nverstra PD 0:00 1 (Priority)
17392522 fast job-968b nverstra PD 0:00 1 (Priority)
17392529 fast job-a5b7 nverstra PD 0:00 1 (Priority)
17392531 fast job-200c nverstra PD 0:00 1 (Priority)
17392533 fast job-fb2f nverstra PD 0:00 1 (Priority)
17392536 fast job-bcdf nverstra PD 0:00 1 (Priority)
17392539 fast job-0159 nverstra PD 0:00 1 (Priority)
17392540 fast job-bf8c nverstra PD 0:00 1 (Priority)
17392541 fast job-da00 nverstra PD 0:00 1 (Priority)Suivi de l’utilisation des ressources avec sacct
SLURM intègre un mécanisme pour suivre la consommation des ressources de chaque job.
Les jobs ne respectant pas leur réservation de ressources peuvent être tués automatiquement par le cluster.
La commande sacct permet d’interroger la base de données de SLURM afin de suivre la consommation des ressources :
Consulter les informations de bases d’un job :
sacct -j $job_id
JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
17392163 alignemen+ fast fair_bioi+ 1 RUNNING 0:0
17392163.ba+ batch fair_bioi+ 1 RUNNING 0:0
17392163.0 bowtie2 fair_bioi+ 1 RUNNING 0:0Afficher des informations détaillées d’un job :
sacct --format=JobID,JobName,State,Start,Elapsed,CPUTime,NodeList -j $job_id
JobID JobName State Start Elapsed CPUTime NodeList
------------ ---------- ---------- ------------------- ---------- ---------- ---------------
17392163 alignemen+ RUNNING 2021-06-29T14:45:59 00:09:43 00:09:43 cpu-node-7
17392163.ba+ batch RUNNING 2021-06-29T14:45:59 00:09:43 00:09:43 cpu-node-7
17392163.0 bowtie2 RUNNING 2021-06-29T14:46:06 00:09:36 00:09:36 cpu-node-7Pour connaître l’ensemble des informations disponibles, on peut utiliser :
sacct --helpformat
Account AdminComment AllocCPUS AllocGRES
AllocNodes AllocTRES AssocID AveCPU
AveCPUFreq AveDiskRead AveDiskWrite AvePages
AveRSS AveVMSize BlockID Cluster
Comment Constraints ConsumedEnergy ConsumedEnergyRaw
CPUTime CPUTimeRAW DerivedExitCode Elapsed
ElapsedRaw Eligible End ExitCode
Flags GID Group JobID
JobIDRaw JobName Layout MaxDiskRead
MaxDiskReadNode MaxDiskReadTask MaxDiskWrite MaxDiskWriteNode
MaxDiskWriteTask MaxPages MaxPagesNode MaxPagesTask
MaxRSS MaxRSSNode MaxRSSTask MaxVMSize
MaxVMSizeNode MaxVMSizeTask McsLabel MinCPU
MinCPUNode MinCPUTask NCPUS NNodes
NodeList NTasks Priority Partition
QOS QOSRAW Reason ReqCPUFreq
ReqCPUFreqMin ReqCPUFreqMax ReqCPUFreqGov ReqCPUS
ReqGRES ReqMem ReqNodes ReqTRES
Reservation ReservationId Reserved ResvCPU
ResvCPURAW Start State Submit
Suspended SystemCPU SystemComment Timelimit
TimelimitRaw TotalCPU TRESUsageInAve TRESUsageInMax
TRESUsageInMaxNode TRESUsageInMaxTask TRESUsageInMin TRESUsageInMinNode
TRESUsageInMinTask TRESUsageInTot TRESUsageOutAve TRESUsageOutMax
TRESUsageOutMaxNode TRESUsageOutMaxTask TRESUsageOutMin TRESUsageOutMinNode
TRESUsageOutMinTask TRESUsageOutTot UID User
UserCPU WCKey WCKeyID WorkDirAnnuler un job
La commande scancel permet d’arrêter un ou plusieurs jobs.
Pour arrêter le job que nous avons lancer précédemment, on utilise la commande suivante
scancel $job_idAméliorer les performances de son analyse
La commande bowtie2 est capable d’utiliser plusieurs threads (fils d’exécution) en parallèle :
--threads <int> number of alignment threads to launchPour accélérer l’alignement, nous pouvons donc réserver plus de CPU et indiquer à bowtie2 de les utiliser.
L’allocation de ressources pour notre traitement doit être adaptée comme suit :
Nous devons réserver au moisn 1 task, 10 CPU et 1Go de RAM pour réaliser ce traitement
Le script scripts/alignement_KO1_1-v2.sh permet de réaliser l’alignement du fichier KO1_1.fastq.gz avec 10CPU :
#!/bin/bash
module load bowtie2 samtools
reference_index="/shared/bank/arabidopsis_thaliana/TAIR10.1/bowtie2/Arabidopsis_thaliana.TAIR10.1_genomic"
file_id="KO1_1"
mkdir -p results
srun bowtie2 --threads=10 -x "${reference_index}" -U "data/${file_id}.fastq.gz" -S "results/${file_id}.sam"
srun samtools view -hbS -q 30 -o "results/${file_id}.filtered.bam" "results/${file_id}.sam"
srun samtools sort -o "results/${file_id}.bam" "results/${file_id}.filtered.bam"job_id=`sbatch --parsable --cpus-per-task=10 --mem=1G scripts/alignement_K01_1-v2.sh`
echo $job_id
17393006On peut à présent observer que notre traitement dispose de 10 CPU :
sacct --format=JobID,JobName,State,Start,Elapsed,CPUTime,NodeList -j $job_id
JobID JobName State Start Elapsed CPUTime NodeList
------------ ---------- ---------- ------------------- ---------- ---------- ---------------
17393006 alignemen+ RUNNING 2021-06-29T14:59:55 00:00:18 00:03:00 cpu-node-39
17393006.ba+ batch RUNNING 2021-06-29T14:59:55 00:00:18 00:03:00 cpu-node-39
17393006.0 bowtie2 RUNNING 2021-06-29T14:59:56 00:00:17 00:02:50 cpu-node-39Pour chaque seconde de temps réel, le temps de calcul est 10 fois plus important.
Bonnes pratiques pour la reproductibilité
Afin de faciliter la réutilisabilité et reproductibilité de ce script, on peut apporter quelques petites amélioration :
Les options utlisées avec sbatch peuvent être déclarée directement dans le préambule du script :
#SBATCH --cpus-per-task=10
#SBATCH --mem=1GAinsi, lorsque l’on reprendra ce script après quelques jours, mois ou semaine, il ne sera pas nécessaire de se souvenir de la réservation de ressources nécessaire pour l’exécuter.
SLURM et sbatch propose également des variables d’environnement que l’on peut utiliser au sein d’un job pour connaitre la réservation effectuer.
On peut ainsi utiliser la variable SLURM_CPUS_PER_TASK pour connaitre le nombre de CPU par tâche réservés pour ce job.
C’est très utile pour l’exécution de la commande bowtie2 pour laquelle on doit spécifier le nombre de threads à utiliser :
srun bowtie2 --threads="${SLURM_CPUS_PER_TASK}" -x "${reference_index}" -U "/shared/projects/dubii2021/trainers/module1/cluster/${file_id}.fastq.gz" -S "${file_id}.sam"Plus d’options pour sbatch et srun
--cpus-per-task
--mem
--mem-per-cpu
--ntasks
-J
--time
--output
--error
--mail-type
--mail-user
Nombre de CPU par tasks
Quantité de mémoire vive allouée au job par noeud (exprimée en Mo par défaut)
Quantité de mémoire exprimée en fonction du nombre de CPU
Nombre de tasks (par défaut un job est dimensionné avec 1 task)
Nom du job ou du job step
Durée maximum (D-HH:MM:SS)
Orientation de la sortie standard (peut contenir l’identifiant du job : %j)
Orientation de la sortie d’erreur (peut contenir l’identifiant du job : %j)
Activer les notifications par mail (BEGIN, END, FAIL, REQUEUE ou ALL)
Adresse email pour les notifications par mail
Voici un exemple d’un script complet utilisant certaines de ces options :
#!/bin/bash
#SBATCH --cpus-per-task=10
#SBATCH --mem=1G
#SBATCH --time=05:00
#SBATCH --output=alignment-%j.out
#SBATCH --error=alignment-%j.err
#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=mon@email.fr
module load bowtie2 samtools
reference_index="/shared/bank/arabidopsis_thaliana/TAIR10.1/bowtie2/Arabidopsis_thaliana.TAIR10.1_genomic"
file_id="KO1_1"
mkdir -p results
srun bowtie2 --threads="${SLURM_CPUS_PER_TASK}" -x "${reference_index}" -U "data/${file_id}.fastq.gz" -S "${file_id}.sam"
srun -J "filter" samtools view -hbS -q 30 -o "results/${file_id}.filtered.bam" "results/${file_id}.sam"
srun -J "sort" samtools sort -o "results/${file_id}.bam" "results/${file_id}.filtered.bam"
rm "${file_id}.sam" "${file_id}.filtered.bam"Le calcul parallèle
Comment aligner plusieurs fichiers fastq en parallèle ?
Dans l’exercice précédent, notre job traite l’alignement d’un seul fichier fastq.
Pour aligner plusieurs fichiers fastq, nous avons deux grandes stratégies possibles : * Lancer un “grand” job qui traitera l’ensemble des fichers au travers de processus parallèles * Lancer plusieurs petits jobs parallèle : chaque job sera chargé de traiter un fichier
La comparaison des deux approches est en faveur de la stratégie des plusieurs petits jobs en parallèle :
- Un script complexe à écrire (avec une boucle
for) et l’utilisation de tasks parallèles - Nécessite de faire une grande réservation de ressources : toutes les ressources nécessaires doivent être disponibles en même temps
- En cas de crash, il faut modifier le script pour ne relancer que les alignements n’ayant pas réussi
- Un script simple pour chaque job
- Nécessite des petites réservations de ressources : permet de lancer une partie des alignements si toutes les ressources ne sont pas immédiatement disponibles
- En cas de crash, il suffit de relancer les jobs qui n’ont pas réussi
Utilisation d’un “job array”
SLURM propose un mécanisme appelé job array permettant de lancer plusieurs fois un job similaire sous la forme d’une collection (ou array) de jobs.
Chaque job de l’array aura un index qui lui est propre.
On peut retrouver l’index du job courant à l’aide de la variable d’environnement $SLURM_ARRAY_TASK_ID
On utilise l’option --array de sbatch pour lancer une collection de jobs
-array=1,2,3: soumet 3 jobs au cluster, index 1 pour le premier job, index 2 pour le second et index 3 pour le dernier-array=0-15: soumet 16 jobs, avec une séquence d’index allant de 0 à 15, index 0 pour le premier job et 15 pour le dernier job-array=0-15:2: définit une séquence d’index de 0 à 15 avec un pas de 2 équivalent à –array=0,2,4,6,8,10,12,14-array=5-15%4: définit une séquence d’index de 0 à 15, mais seulement 4 jobs maximum sont exécutés simultanément
Notre dossier data contient 6 fichiers de séquences. Nous devons donc créer un array de 6 jobs (donc 6 numéro d’index) !
ls -l data
total 2313376
-rw-rw-r-- 1 jseiler jseiler 346797117 Jun 28 10:37 KO1_1.fastq.gz
-rw-rw-r-- 1 jseiler jseiler 392388228 Jun 28 10:37 KO2_1.fastq.gz
-rw-rw-r-- 1 jseiler jseiler 393345980 Jun 28 10:37 KO3_1.fastq.gz
-rw-rw-r-- 1 jseiler jseiler 294 Jun 29 14:41 md5sums.txt
-rw-rw-r-- 1 jseiler jseiler 426528611 Jun 28 10:37 WT1_1.fastq.gz
-rw-rw-r-- 1 jseiler jseiler 429377486 Jun 28 10:37 WT2_1.fastq.gz
-rw-rw-r-- 1 jseiler jseiler 380399546 Jun 28 10:37 WT3_1.fastq.gzLe language Bash nous permet de récupérer facilement la liste des fichiers à traiter dans une variable de type tableau :
files=(data/*fastq.gz)La varaible files continent à présent un tableau avec dans chaque case le chemin d’un fichier .fastq.gz différent.
Par exemple, la première case du tableau file contient :
echo ${files[2]}
data/KO3_1.fastq.gzPour ne garder que l’identifiant de la séquence (K01_1) on peut utiliser la commande basename.
La commande basename retourne uniquement le nom du fichier à partir de son chemin.
L’option -s permet en plus de supprimer un suffixe du nom du fichier
basename -s .fastq.gz ${files[0]}
KO1_1Nous pouvons à présent modifier notre script d’alignement pour l’adapter à une execution multiple dans le cadre d’un job array.
#!/bin/bash
#SBATCH --array=0-5
#SBATCH --cpus-per-task=10
#SBATCH --mem=1G
module load bowtie2/2.4.1 samtools/1.10
reference_index="/shared/bank/arabidopsis_thaliana/TAIR10.1/bowtie2/Arabidopsis_thaliana.TAIR10.1_genomic"
files=(data/*fastq.gz)
file_id=$(basename -s .fastq.gz "${files[$SLURM_ARRAY_TASK_ID]}")
mkdir -p results
srun -J "${file_id} bowtie2" bowtie2 --threads="${SLURM_CPUS_PER_TASK}" -x "${reference_index}" -U "data/${file_id}.fastq.gz" -S "results/${file_id}.sam"
srun -J "${file_id} filter" samtools view -hbS -q 30 -o "results/${file_id}.filtered.bam" "results/${file_id}.sam"
srun -J "${file_id} sort" samtools sort -o "results/${file_id}.bam" "results/${file_id}.filtered.bam"
rm "results/${file_id}.sam" "results/${file_id}.filtered.bam"Le job sera exécuté 6 fois (--array=0-5) et pour chaque exécution, il traitera un fichier différent en fonction de l’index du job courant (file_id=$(basename -s .fastq.gz "${files[$SLURM_ARRAY_TASK_ID]}")).
job_id=`sbatch --parsable --cpus-per-task=10 --mem=1G scripts/alignement.sh`
echo $job_id
17393670sacct --format=JobID,JobName%15,State,Start,Elapsed,CPUTime,NodeList -j $job_id
JobID JobName State Start Elapsed CPUTime NodeList
------------ --------------- ---------- ------------------- ---------- ---------- ---------------
17393670_0 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_0.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_0.0 KO1_1 bowtie2 RUNNING 2021-06-29T15:11:57 00:02:30 00:25:00 cpu-node-24
17393670_1 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_1.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_1.0 KO2_1 bowtie2 COMPLETED 2021-06-29T15:11:57 00:02:27 00:24:30 cpu-node-24
17393670_1.1 KO2_1 filter RUNNING 2021-06-29T15:14:24 00:00:03 00:00:30 cpu-node-24
17393670_2 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_2.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_2.0 KO3_1 bowtie2 RUNNING 2021-06-29T15:11:57 00:02:30 00:25:00 cpu-node-24
17393670_3 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_3.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_3.0 WT1_1 bowtie2 RUNNING 2021-06-29T15:11:58 00:02:29 00:24:50 cpu-node-24
17393670_4 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_4.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-24
17393670_4.0 WT2_1 bowtie2 RUNNING 2021-06-29T15:11:57 00:02:30 00:25:00 cpu-node-24
17393670_5 alignement.sh RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-45
17393670_5.+ batch RUNNING 2021-06-29T15:11:54 00:02:33 00:25:30 cpu-node-45
17393670_5.0 WT3_1 bowtie2 COMPLETED 2021-06-29T15:11:56 00:02:31 00:25:10 cpu-node-45
17393670_5.1 WT3_1 filter RUNNING 2021-06-29T15:14:27 00:00:00 00:00:00 cpu-node-45