Bonjour à tous,
Est ce que quelqu'un parmi vous a des infos récentes sur les versions spark d'outils de gatk4 qui sont encore en bêta?
J'ai des genomes humains à partir des quels je veux identifier des variants causant une maladie rare, donc je suis les "Best practices for snp on germline".
Si j'ai bien compris pour pouvoir faire du multithreading avec gatk4 il faut passer par spark (les clusters de l'ifb et de l'igbmc ne sont pas spark? Mais il suffit de rajouter une option telle que --spark-master local[2] c'est bien ça?).
Cependant certains outils nécessaires pour suivre les best practices sont encore en bêta. Je pense par exemple à BQSRPipelineSpark (BETA) ou à HaplotypeCallerSpark (BETA).
Sont ils suffisamment fiables pour les utiliser ou dois-je rester sur les versions classiques (mais du coup devoir trouver un autre moyen de parralleliser?).
J'ai également vu que Markduplicates a été intégré à gatk4 dans sa version MarkduplicatesSpark, qui elle n'est plus en version Bêta, donc je suppose qu'il n'y aucun problème à l'utiliser? Sinon j'avais pensé à samtools markdup. En revanche dans les deux cas il semble préférable d'avoir des bam triés par querynames, sauf que j'ai déjà trié les bam par coordonnées. Dans ces conditions quel outils est le mieux pour marquer les duplicats? Voilà ce qui est par exemple écrit pour MarkduplicatesSpark : " The tool is optimized to run on queryname-grouped alignments (that is, all reads with the same queryname are together in the input file). If provided coordinate-sorted alignments, the tool will spend additional time first queryname sorting the reads internally. This can result in the tool being up to 2x slower processing under some circumstances."
Merci par avance 
Bonjour Quentin,
Quelques éléments autour du parallélisme de GATK (je ne sais répondre sur le reste).
En effet, GATK en v4 a changé de fonctionnement pour paralléliser ses tâches.
Les clusters IFB Core cluster ou de l'IGBMC (à ma connaissance) ne sont pas de type "spark".
Mais il n'est pas indispensable d'avoir un cluster "spark" pour utiliser ce mécanisme: https://gatk.broadinstitute.org/hc/en-us/articles/360035890591
Si je comprends bien, il suffit de faire quelque chose comme:
#!/bin/bash
#SBATCH --cpus-per-task 10
module load gatk4/4.1.7.0
# Run on the local machine using $SLURM_CPUS_PER_TASK cores
gatk --spark-master local[${SLURM_CPUS_PER_TASK}] ...
N'hésitez pas à partager avec nous votre solution, je suis certains que cela en intéressera plus d'un.
Bonne journée
Après discussion et réflexion nous avons choisi d'utiliser les versions spark bien qu'elle soit en bêta. En effet nous sommes dans le cadre de la recherche, et nous pensons que les éventuels problèmes liés à l'utilisation de bêta sont surtout importants dans un cadre clinique et/ou d'une plate-forme.
En ce qui concerne MarkduplicatesSpark c'est vraiment dommage que l'igbmc n'ai pas de SSD. C'est le genre d'outils qui écrit et lit une grande quantité de données, je suis en train de faire un test avec un BAM de 60Go, j'utilise 40Go de ram, et 10 cpu. Ca fait 6h que ça tourne, dans le dossier temporaire il y a déjà 120Go...
Voilà ce que dit d'ailleurs Gatk à ce sujet :
" 1. This Spark tool requires a significant amount of disk operations. Run with both the input data and outputs on high throughput SSDs when possible. When pipelining this tool on Google Compute Engine instances, for best performance requisition machines with LOCAL SSDs.
2. Furthermore, we recommend explicitly setting the Spark temp directory to an available SSD when running this in local mode by adding the argument --conf 'spark.local.dir=/PATH/TO/TEMP/DIR'. See this forum discussion for details."
Bonjour Quentin,
Nous sommes bien conscient du gain apporté par les technologies SSD/NVMe/etc mais les choix technologiques sont toujours un compromis entre le coût (budget), la quantité (espace de stockage) et la performance.
Si vous disposer de disque local sur le nœud de calcul (par exemple /tmp), en quantité suffisante, et même si ce n'est pas du SSD, vous aurez probablement un gain quand même (par rapport à des espaces partagés de type /shared/...). P'tètre a essayer si le temps de calcul s'avérait bloquant.
Bonne journée
Bonjour,
Je me doute bien qu'il y a forcément des contraintes budgétaires et qu'on ne peut pas tout avoir (malheureusement)...
Pour le /tmp quelqu'un de l'igbmc peut il me confirmer ? Et la place disponible? @team.igbmc
Pour y accéder on utilise la variable $TMPDIR ?
Je suppose que c'est de ça dont il est question sur la page de description du cluster de l'igbmc:
" High-performance shared storage
The calculation farm has a high-performance storage volume of 70TB to accommodate your data to be processed."
Bonne journée,
Quentin.
J'ai essayé de mettre en dossier temporaire le /tmp (soit directement, soit via la variable ${TMPDIR} ) mais ça ne fonctionne pas, peut être n'y a t'il pas assez de place ? Le jobs s'arrête très vite (au bout de 5 / 6 minutes) avec comme erreur "no space left".
J'aimerais bien en savoir plus à ce sujet d'autant que MarkduplicatesSpark ne se comportent pas comme il faut, parfois il marche, parfois il plante (après avoir sorti le fichier de metrics), l'hypothèse de l'équipe de Gatk est un problème de disque i/o.
Quentin.
En effet, tout semble indiquer qu'il n'y a pas suffisamment d'espace disponible localement.
Je ne vois pas d'autre solution que d'utiliser l'espace partagé /shared/....
Pour le problème de MarkduplicatesSpark je précise que ça se produit même si j'utilise /shared/... en dossier temporaire.
Bonjour,
j'ai effectivement eu la confirmation que sur la plupart de nos noeuds il n'y a pas suffisamment d'espace.
En revanche et je ne sais pas pourquoi, si je demande un noeud en particulier ave sbatch --nodelist pour être sûr d'avoir un noeud avec assez d'espace, ca ne marche pas à tous les coup. J'ai pensé que le problème pouvez venir du fait qu'il y avait déjà des jobs en cours sur le noeud voulu mais après vérification il restait suffisamment de ressources sur le noeud, j'avais demandé 11 cpu et 40go de mem, à ce moment la, la commande scontrol show node m'indiquait pour ce noeud :
CPUAlloc=10 CPUTot=48 CPULoad=6.75
RealMemory=128470 AllocMem=51200 FreeMem=62119 Sockets=2 Boards=1
Mais bon après essai ca ne change rien du tout, je passe de 6h50 avec le tmp sur /shared/ à 6h46 avec le tmp sur /tmp donc bon.
Bonne journée,
Quentin