humann runtime

[jorondo1]

j'ai fini de run les 187 samples à sarah. Les samples prennent en moyenne 6 heures ± 2h à rouler sur les fat nodes; là-dessus, y'a 4h ±1h d'alignement DIAMOND.

Je pense à PROVID où on pourrait avoir plusieurs milliers de samples à process. De mémoire c'est kraken qui a fait en sorte qu'on s'en va sur les fat nodes, alors penses-tu que le script 03 (humann) on serait mieux de l'envoyer sur les base nodes, quitte à baisser le block-size parameter de DIAMOND si la mémoire est limitée? ou est-ce que la db est trop grosse pour ça aussi?

[jflucier]

as-tu teste script3 sur les base node dan sa verison actuel?

tuner pour fitter ca sur les base node est un must selon moi pour provid.

Pour Kraken, comme je t'ai deja mentionne, ils serait mieux de faire une premiere run kraken en utilisant la bd avec index de 16G sur les base nodes et si vous voyez qq choses d'interessant sur une partie des echantillons, reourler ceux-ci avec la full db.

Il est impossible de roule la grosse bd kraken sur les base node. La version d'index de 16G fiterais p-e.

[jorondo1]

oui pour kraken j'avais saisi que la full db a besoin des grosses nodes

dans ce cas je vais tester quelques échantillons dans le script 03 sur les base nodes sur une copie du script

[jflucier]

prend bien soin de reecrire tes conclusions ici pour quon puisse fermer le ticket ensuite.

[jorondo1]

will do pour l'instant je vais changer les global slurm config manuellement dans les scripts après avoir généré mon script custom, mais si c'est concluant faudra avoir un slurm config par script

[jflucier]

c'est direectement configurable a partir du fichier my.example.config

[jorondo1]

Bon ça ne semble pas fonctionner, je pense que bowtie bust la mémoire si je mets juste 30G:

Error message returned from bowtie2 :
(ERR): bowtie2-align died with signal 9 (KILL) 

Je vais quand même faire un test en translate search seul pour voir l'impact sur diamond, voir si ça vaut la peine de splitter le code en deux pour faire le nucleotide search avec 125G de mem, puis le translate avec 30G, puis on merge les 2 résultats ensuite avec un des utility humann. Le nt-alignment + post-proc prend seulement 1h par sample à 125G donc c'est pas trop pire, 500 samples par jour environ... À moins que tu penses qu'on serait mieux de carrément envoyer ça sur Narwahl

[jflucier]

je suis surpris que bowtie plante et bust memoire... me semble quil y a option pour dire max mem

faudrait que je test ca. Selon la doc, plus tu prend de threads... plus ca prend de memoire...

-p/--threads NTHREADS | Launch NTHREADS parallel search threads (default: 1). Threads will run on separate processors/cores and synchronize when parsing reads and outputting alignments. Searching for alignments is highly parallel, and speedup is close to linear. Increasing -p increases Bowtie 2's memory footprint. E.g. when aligning to a human genome index, increasing -p from 1 to 8 increases the memory footprint by a few hundred megabytes. This option is only available if bowtie is linked with the pthreads library (i.e. if BOWTIE_PTHREADS=0 is not specified at build time).

[jorondo1]

en effet c'est étrange, mais j'utilise pas moins de threads, je reste à 24... est-ce que je devrais baisser d'après toi ?

[jflucier]

a essaye

[jorondo1]

je confirme que DIAMOND prend à peu près le même temps à rouler sur 30G de mémoire vs 125G (un peu plus, mais c'est expected parce que j'ai bypass l'alignement nucleotide alors y'a un peu plus de reads à chercher)

est-ce que c'est possible, à l'intérieur d'un même script, d'envoyer un sample d'abord sur des fat nodes (pour faire le nt-search), puis sur des base nodes une fois la job terminée? si oui je pourrais t'écrire les deux commandes humann à runner (une qui bypass-protein-search et la suivante qui bypass-prescreen)

[jflucier]

est-ce que c'est possible, à l'intérieur d'un même script, d'envoyer un sample d'abord sur des fat nodes (pour faire le nt-search), puis sur des base nodes une fois la job terminée? si oui je pourrais t'écrire les deux commandes humann à runner (une qui bypass-protein-search et la suivante qui bypass-prescreen)

oui mais ce sera 2 soumissions independantes. Est-ce que ceci bypasserais les fatnodes? Si oui ecrit moi les commande et je vais faire 2 script humann

[jorondo1]

ok j'embarque là dessus.

On a besoin des fatnodes si l'erreur de Bowtie mentionnée ci-haut est bien causée par un manque de mémoire :

Bon ça ne semble pas fonctionner, je pense que bowtie bust la mémoire si je mets juste 30G:

Error message returned from bowtie2 :
(ERR): bowtie2-align died with signal 9 (KILL) 

Est-ce qu'on va avoir besoin de se créer yet un autre TSV file pour faire le pont entre le nt-search sur fat node et le translated-search sur les base nodes? Le principe est d'utiliser tous les fastq pas alignés par le nt-search comme input dans translated-search, donc nécéssairement le nom de fichier change... mais si on peut éviter ça serait pratique de ne pas avoir un autre TSV à préparer. Y'aurait sûrement moyen de juste caller le fichier en utilisant le nom du sample?

[jflucier]

Est-ce qu'on va avoir besoin de se créer yet un autre TSV file pour faire le pont entre le nt-search sur fat node et le translated-search sur les base nodes? Le principe est d'utiliser tous les fastq pas alignés par le nt-search comme input dans translated-search, donc nécéssairement le nom de fichier change... mais si on peut éviter ça serait pratique de ne pas avoir un autre TSV à préparer. Y'aurait sûrement moyen de juste caller le fichier en utilisant le nom du sample?

possiblement on peut s'arranger oui. Va falloir fournir le tsv et a partir des info dedans on devrait etre en mesure de deduire ou se trouve les resultats. On s'en reparle de vive voix.

[jorondo1]

c'est good je pense avoir figure out! Je t'envoie un long commentaire dès que j'ai fini de spliter/adapter le script

[jorondo1]

En gros, on veut rouler le nt-search sur les fat nodes (1h/sample ±10min) donc ~2 jours par 1000 samples si on met 125G et qu'on a constamment accès à 10 nodes (me semble que c'est ça le max par user), puis rouler le translated-search sur les base nodes. On n'aura pas besoin de fournir un autre tsv.

J'attache les scripts 03.humann_nt_search.sh et 04.numann_prot_search.sh qui pourraient accomplir ça. En gros, j'ai modif la commande humann et enlevé les copies de db inutiles et leurs variables. Aussi, aux lignes 52-67 (script 04) je définis le mode de fonctionnement de humann selon l'input file. La fonction --resume est bien utile pour ce qu'on veut faire.

Note 1. J'imagine qu'on va avoir besoin de 2 sets de variables SLURM, je te laisserais choisir comment les nommer et les changer à travers tous les scripts et le config file.

Note 2. J'ai changé le nom du shell et du slurm shell pour mieux refléter la fonction de ce pipeline. Je vais ouvrir une autre issue avec un nouveau flowchart (in progress) qui va nous aider à mieux nommer nos différents scripts.

Note 3. Y'aurait tu moyen de faire en sorte que le deuxième script soit appelé par le premier une fois que celui-ci est terminé? Ça éviterait un temps mort, surtout que chaque sample prend des temps différents.

Note 4. Pour m'assurer que le script 04 puisse être roulé indépendamment (i-e translate search only) j'ai créé le if-then-else des lignes 52-68. Pourrais-tu le vérifier rapidement? Je vais le tester avant qu'on le commit mais comme je ne retravaillerai pas dessus avant début next week probablement, ça m'aiderait. Les gros changements sont:

03.humann_nt_search.txt loop 52-66

04.humann_prot_search.txt lignes 49-68, 72-78, 88, la grosse loop 104-140, la loop 136-141

[jflucier]

Note 4. Pour m'assurer que le script 04 puisse être roulé indépendamment (i-e translate search only) j'ai créé le if-then-else des lignes 52-68. Pourrais-tu le vérifier rapidement?

je viens de checker et ca l'air ok.

Je check pour les autres points sous peu.

[jflucier]

y'a cette ligne que je comprend pas si c'est un commentaire a moi ou bien juste une trace:

SOMETHING TO COPY THE FOLDER HERE !

pourtant plus bas ligne 73 tu fais le copie du fastq...

[jorondo1]

oui après avoir posté j'ai vu que j'avais oublié ce point ! c'est que l'option --resume fonctionne en regardant quels fichiers sont déjà produits et part à partir de là. On doit donc recopier le dossier (qui avait été output par 03) dans le slurm tmpdir. D'après moi on peut juste mettre cp ${OUPUT_PATH}/${__sample} $SLURM_TMPDIR/${__sample} avant le >> de la ligne 59

c'est d'ailleurs pour cette raison que je mets les conditions et le rm -r aux lignes 136-141

makes sense?

[jflucier]

D'après moi on peut juste mettre cp ${OUPUT_PATH}/${__sample} $SLURM_TMPDIR/${__sample} avant le >> de la ligne 59

exactement ca quil faut faire je crois

c'est d'ailleurs pour cette raison que je mets les conditions et le rm -r aux lignes 136-141

je crois pas que ce soit necessaire ce if.... fait juste un cp -fr du dossier:

cp -fr $SLURM_TMPDIR/${__sample} '${OUPUT_PATH}'

sinon ya aussi rsync qui est possible

[jorondo1]

ok super !! Je vais faire des tests localement et quand c'est good to go je t'envoie ça pour un commit

merci de l'input rapide !

[jorondo1]

Je vais ouvrir une autre issue avec un nouveau flowchart (in progress) qui va nous aider à mieux nommer nos différents scripts.

j'ai pas ouvert un autre issue, j'ai carrément ajouté le flowchart dans les fichiers si tu veux regarder ça

[jflucier]

je vois que tu commence a t'amuser avec git!

je vais checker ca.

Je ferme cet issue car commence a etre trop gros et diffcile a suivre car plusieurs sujets discute en lien avec humann.... on devrait splitter en plusieurs issue ce sera plus facile a suivre.

good job pour git!