segmentation fault spades

[jorondo1]

Peut-être que ça peut te donner une piste: https://github.com/ablab/spades/issues/834#issuecomment-908278943

[jorondo1]

Est-ce que ça pourrait être un manque de RAM ? Possible si les contigs assemblés sont plus longs dans ces samples ...

[jflucier]

avec 251G max pour la job, ce serait surprenant.

en plus ca plante pour certain echantillon apres l'utilisation de 3-4G de ram

[jorondo1]

suggestion pour nous permettre d'avancer malgré cela, serait de seulement run MegaHIT pour l'instant. Nos contigs risquent d'être plus petits mais au moins on va pouvoir continuer et aboutir.

[jflucier]

je viens de modifier le code et ajouter une option dans la config ou lon specifie les assembler a tuilise dans le pipeline.

je viens de repartir les 5 echantillons problematique

[jflucier]

les 5 echantillons ont passe en utilisant seulement megahit.

[jorondo1]

J'essaie d'explorer ce problème. Ça ne répond pas vite sur les issues du git spades, mais on n'est pas les seuls à qui ça arrive. L'auteur suggérait de tester l'option --assembly-only mais y'a pas de conclusion et je ne sais pas quel impact ça peut avoir sur metaWRAP.

Dans mon cours de cet été j'ai testé un autre pipeline très semblable à metaWrap, Atlas, qui utilise aussi metaspades et megahit. Peut-être que la solution se cacherait dans leur script? J'ai essayé de fouiller mais je me perds un peu dans snakemake.

C'est sûr qu'ultimement on veut rouler metaspades, parce qu'il est beaucoup plus sensible. Megahit c'est l'alternative rapide, qui crée des contigs à basse couverture, c'est pour ça que metaWRAP le roule après metaspades sur les reads non-mappés aux contigs de metaspades. Atlas utilise un ou l'autre, mais j'aime vraiment mieux la stratégie de metaWRAP pour les utiliser en séquence comme ça.

[jorondo1]

Fun fact : si tu mets en ordre croissant le nombre de kmers distincts estimé par sample, les 5 samples qui plantaient sont côte à côte. Je ne peux pas imaginer que ça puisse être un hasard, statistiquement c'est vraiment très très très peu probable. Il y en avait un 6e aussi, array=4, qui n'avait pas roulé, et il fait partie de l'exacte même séquence. J'aimerais ouvrir un issue sur son github, mais il requiert 2 fichiers que je ne trouve pas: spades.log et params.txt, es-tu capable de me les trouver pour 2 runs problématiques que tu avais faites?

[jflucier]

potentiellement mort ces fichiers car il ne sont pas copie back sur ip29

les fichier se situe a cet endroit:

<>/denovo_assembly/assembly/<>/metaspades/

[jflucier]

ceci dit, lerreur est dans metaspades lorsquil essaie assembler les reads... pas metawrap.

Pour Atlas, sur les memes echantillons, presque sur a 100% que tu aura la meme erreur. Je crois que c'est plus dans les reads le bug.

Pour tester, subsample le fastq et rerun l'assemblage voir si ca plante.

par exemple:

zcat file.fastq.gz | head -n 10000 > file.test.fastq

[jorondo1]

ok je vais tester un subset avec seulement metaspades. Quelle serait la commande pour loader l'environnement ?

[jflucier]

https://github.com/jflucier/ILL_pipelines/blob/291f878ae146d5428bc511083485b41366d141cd/generateslurm_assembly_bin_refinement.metawrap.sh#L289

[jorondo1]

j'arrive à rouler spades avec un subset. Now what? On split ces samples pour les rouler? Est-ce qu'on intègre ce split au pipeline pour que ça se fasse systématiquement ? as-tu d'autres idées?

[jflucier]

no c'est seulement pour prouver que c'est le fastq le probleme

essaie split 50/50 et roules deux fastq sub sampler. P-e un des 2 plantera et ceci sera la preuve ultime que le bug est dans le fastq.

ensuite augmente 75/25 et recheck

[jorondo1]

J'essaie de débugger mon script pour tester ça depuis beaucoup trop longtemps peux-tu m'aider? metawrap m'envoie l'erreur "please provide a sample name" mais j'ai tout testé et ma variable $__EXP_NAME fonctionne, elle imprime même juste avant d'envoyer la commande... voir /nfs3_ib/ip29-ib/ip29/ilafores_group/projet_PROVID19/denovo_assembly/test_metaspades/test_metaspades.sh

help!

[jflucier]

pour debug essaie tjr au prealable de tester ton script direct sur ip29. Je tai fait script minimal qui replique en ton script slurm

fait:

SLURM_ARRAY_TASK_ID=1
SLURM__TMPDIR=/nfs3_ib/ip29-ib/ip29/ilafores_group/projet_PROVID19/denovo_assembly/test_metaspades/temp
bash test_metaspades.jf.sh

Tu devrais etre en mesure de debug a partir de ca. Si tu rush encore, me dire.

[jorondo1]

ouin ben la deuxième moitié du subset fonctionne aussi!

Rendu là je me demande si on ne pourrait pas simplement écrire le script pour qu'il subset toujours l'échantillon en deux pour faire l'assemblage (metaspades seulement), avant d'envoyer le reste à megahit. Comme ça si ça introduit un certain biais dans l'assemblage, ce sera un biais uniforme dans tous nos échantillons. Je ne pense pas que ça biaise vraiment parce qu'au final le binning se fait par similarité de différentes propriétés des contigs, et la quantification se fait après une déréplication des mags.

Je vais penser à une stratégie je te reviens là dessus, pour l'instant je vais faire ça à la main et comme tu dis on fera seulement du megahit pour le "brute force" initial des prochains échantillons qu'on recevra (pas avant janvier à mon avis)

[jflucier]

on peut essayer d'integrer le split voir si ca fonctionne pour tout les echantillons...

va falloir pense a checker le header et renommer ca potentiellement

[jorondo1]

ok, priorise quand même la quantification des bins avec salmon pour l'instant pis peut-être que l'auteur aura trouvé un fix d'ici là...

[jorondo1]

Bon la solution va être de modifier la commande metaSpades (dans le code python de metawrap??) pour skip le error correcting. https://github.com/ablab/spades/issues/1036#issuecomment-1290937958

je pense que ça fait du sens parce qu'on utilise déjà des reads de haute qualité et je pourrais même crinquer ça un peu plus haut encore avec kneaddata.

[jflucier]

ouin c quand meme mauvais comme solution... ajoute ca par defaut a la commande et commit

[jorondo1]

ben en fait je pense que c'est très correct, parce que le error-correction est un genre de quality control, donc on n'en a pas besoin

je vais faire de tests avec la mock community et je commit éventuellement

[jorondo1]

Je sais pas ce que ça implique de forker le git de metawrap pour intégrer cette option, mais je sais que l'auteur n'est malheureusement plus très actif.

Je lui avais déjà écrit personnellement pour lui poser des questions cet hiver, donc si tu pense que ça peut aider je peux nous mettre en contact par courriel.

[jflucier]

laisse moi checker ca avant de pingner l'auteur

je peux forker sont code, le bug est plus sur la methode pour integrer ca au container singularity

[jflucier]

@jorondo1

viensde patcher le code de metawrap a l'interieur du container.

commit 0cb39bc

SVP test que ca fonctionne et reouvrir ce ticket si ya une erreur

tks

[jorondo1]

En train de tester et je vois encore le error correction comme première étape

less /nfs3_ib/ip29-ib/ip29/ilafores_group/projet_PROVID19/denovo_assembly/logs/assembly_bin_refinement-96628_7.slurm.out

je suis parti du main

[jflucier]

shit oublie uploader nouvelle image du container dans /project/def-ilafores/common/ILL_pipelines/containers

je viens de termine le transfert. Tu peux reessayer.

[jorondo1]

Ça ne semble pas fonctionner, j'ai toujours read error correction qui part voici ma commande

export PROVID=/nfs3_ib/ip29-ib/ip29/ilafores_group/projet_PROVID19 
export ILL_PIPELINES=/project/def-ilafores/common/ILL_pipelines 
module load singularity mugqic/BBMap/38.90
bash $ILL_PIPELINES/generateslurm_assembly_bin_refinement.metawrap.sh --sample_tsv $PROVID/preprocess/taxonomic_profile.sample.tsv --out $PROVID/denovo_assembly --slurm_email $__EMAIL --assembly --binning --refinement

dernier log: less /nfs3_ib/ip29-ib/ip29/ilafores_group/projet_PROVID19/denovo_assembly/logs/assembly_bin_refinement-96638_7.slurm.out

[jflucier]

bon je viens de recorriger la recette diu container.

tu peux retester.

[jorondo1]

seems to work! Merci !

[jorondo1]

Je confirme que j'ai réussi à assembler mes 54 échantillons! Good job

[jflucier]

good!

va essayer de clanche le dernier issue (clustering et quantification de bin) cette semaine