Je suis en train de regarder par rapport à la possibilité de charger nos données brutes de séquençage sur EMERGEN
=> Et le document à ce propos fait mention du fait que les données doivent être "de-hosted"
=> Avez-vous des recommandations d'outils / de workflows pour réaliser cette étape ?
Pour l'analyse des données nous utilisons le pipeline viralrecon
=> Paramétré de telle sorte que :
Les reads sont trimmés selon leur qualité
Les reads sont assignés par Kraken2 contre un index contenant seulement le génome humain et
Les reads assignés "Humain" sont filtrés et les reads restants sont alignés contre le génome du Sars-Cov-2 --> production d'un 1er BAM par échantillon
Les séquences des primers (ARTIC v4.1) sont soft-clippées avec ivar trim --> production d'un 2nd BAM par échantillon
Est-ce que l'un des 2 BAM produits peut convenir ?
=> Ou bien est-ce que les données ne sont plus assez "brutes" à ce stade et qu'il vaut mieux aller récupérer cette liste de reads non-humains dans les FASTQ d'origine ?
=> Un peu comme ce qui est expliqué dans ce tuto Galaxy
Désolé si la question a déjà été posée (je découvre "community.france-bioinformatique.fr")
Un grand merci d'avance !
Bien à vous,
Félix (bio-informaticien au CHU de Reims).
Merci d'avoir soulevé ce point qui pose également question ici !
Je suis bio-informaticienne au CHU de Bordeaux en charge de la soumission des données sars-Cov-2. Notre pipeline ncov2019-artic-nf ne prend pas en charge le de-hosting des reads, les alignant directement au génome viral avec bwa mem après QC des reads.
Je souhaitais partager avec vous le pipeline ncov-dehoster, aperçu sur GitHub au lien suivant . Ce pipeline sous Nextflow permet de traiter les données brutes Illumina ou Nanopore pour obtenir notamment des fichiers fastq contenant des reads "dehosted". Je ne l'ai pas testé mais il me semble être intéressant si nous devons déposer ce type de fichiers en particulier.
Dans l'attente d'une réponse de la part de l'équipe, le dépôt des données brutes sur IFB-core est en stand-by à Bordeaux.
Je te remercie de ta réponse !
J'avais également aperçu "ncov-dehoster", mais je trouvais un peu dommage de refaire des étapes qui finalement étaient déjà un peu réalisées par nos pipelines (même si pour ma part, pas directement d'alignement contre le génome humain dans viralrecon)
Entre temps j'ai donc opté pour l'approche suivante (pour chaque échantillon) :
Récupérer le BAM produit par le pipeline (donc reads d'abord de-hostés avec Kraken2 contre un index Humain, puis alignés contre le génome du Sars-Cov-2)
Récupérer la liste des reads qui s'alignent contre le génome du Sars-Cov-2
"grep" cette liste de reads dans chacun des 2 fichiers FASTQ de ce patient (à l'aide de seqkit) et génération d'une nouvelle paire de FASTQ "de-hostés"
A Reims aussi cela attendra probablement la rentrée
=> Si toujours pas de réponse de l'équipe ici, peut-être qu'on pourrait tenter directement l'adresse mentionnée sur le document EMERGEN à ce sujet ? ("support-emergen-workflows@...")
@fvandermeeren L'IFB accepte les fichiers de séquences brutes au format BAM seulement si la plateforme n'est pas en mesure de fournir des fichiers fastq pour une raison quelconque, mais nous préférons recevoir directement les fastq car cela nous évite les traitements intermédiaires quand nous recevons les données.
Par rapport a votre première question, nous vous conseillons de déposer des données brutes sans primers (donc les reads issus du "2nd" fichier BAM) car nous n'allons pas forcément disposer des kits de primers "homemade" de certaines plateformes pour faire le clipping des primers de notre côté... Le fichier BAM obtenu après élimination des primers reste exploitable.
L'approche que vous utilisez ensuite me parait tout a fait correcte (extraction des reads et concaténation dans des fastq pairés), et les fastq de sortie répondront au critère de dehosting des séquences humaines établi par l'IFB et SPF.
@vlesourdaubert J'ai jeté un oeil a ce pipeline nextflow de dehosting "ncov-dehoster", et nous utilisons une procédure similaire pour faire du dehosting de notre côté, a l'exception du pipeline utilisant "Nanostripper". Je garde le lien vers ce pipeline quelque part pour éventuellement l'ajouter a la procédure de dépot, cela pourra sans doute aider certaines plateformes pour faire cette étape de dehosting
Est ce que c'est quelque chose qui pourrait vous intéresser d'avoir une section "tutoriel" ou "ressources" dans la procédure de dépôt où vous pourriez trouver de l'aide pour le traitement des données en amont du téléversement (par exemple l'extraction de reads ou le dehosting) et de l'aide a l'automatisation du téléversement ?
Merci pour votre réponse, c'est vrai que je n'avais pas pensé aux primers !
=> Du coup j'ai changé de manière de faire, en repartant de mes BAM dé-hostés + avec primers soft-clippés
=> Et le plus dur c'est d'en tirer une paire de FASTQ sans ces portions soft-clippées justement
=> Car samtools fastq et bedtools bamtofastq les intègrent dans le FASTQ final et aucune option permettant de les exclure...
(ma méthode au paragraphe suivant, mais je suis preneur de vos solutions !)
Le plus simple aurait été que viralrecon produise directement un BAM avec les primers hard-clippés plutôt, mais ivar trim qui est utilisé ne le permet pas
=> Pour ceux que ça pourrait aider, j'ai d'abord appliqué à chaque BAM un pré-traitement utilisant la sous-commande bam-removeclipping de ngsutilsj (qui semble marcher, bien que marquée comme expérimentale dans le "--help")
=> Et ensuite seulement je pipe dans samtools fastq
Concernant les explications supplémentaires dans la procédure de dépôt, oui je pense que tout le monde pourrait en bénéficier, avec les items que vous mentionnez
=> Il faudrait peut-être aussi y préciser la relation entre le chargement des données brutes et le chargement des génomes consensus en multi-FASTA, notamment :
Je suppose que le XLSX de métadonnées à charger sur le cluster IFB en même temps que les données brutes, doit être identique à celui chargé via l'interface conviviale avec le mFASTA ?
Au niveau de la nomenclature des fichiers de données brutes, j'ai renommé mes fichiers pour être conforme au format attendu "semaine[XX]_[NUM_PRELEVEMEN].[EXTENSION]". Mais du coup est-ce que c'est problématique que ça ne colle plus avec les en-têtes de mes multi-FASTA qui sont sur le modèle "[NUM_PRELEVEMENT]_S[0-9]+_L001" ?
Encore merci d'avance pour votre aide !
Bien à vous,
Félix.
Avez vous essayé samtools ampliconclip (samtools-ampliconclip(1) manual page) ? Avec l'option --hard-clip cela devrait produire le résultat attendu.
Exactement, il s'agit du même fichier. Il est demandé de le déposer avec les données brutes car pour le moment nous n'avons malheureusement pas de méthode fiable à 100% (et rapide) permettant de retrouver le fichier trame associé a un prélèvement simplement avec le numéro de prélèvement. La procédure évoluera quand nous aurons un moyen de lier rapidement un numéro de prélèvement a son fichier trame dans EMERGEN-DB.
Aucun problème si les headers présents dans les fichiers fasta ne correspondent pas exactement au nom des fichier fastq téléversés. En fait pour nous l'important est de disposer du numéro de prélèvement (et éventuellement de l'indication R1/R2 - forward/reverse pour du séquencage paired-end avec le suffixe _R[1|2]) dans le nom du fichier fastq pour que le lancement automatique de nos traitements puisse se faire. Si le séquencage est fait sur plusieurs channels, vous pouvez simplement combiner vos fichiers fastq (en prenant soin de différencier les reads forward et reverse dans 2 fichiers si besoin). Ou alors je n'ai pas bien saisi la question
Oui je l'ai testé et vous avez raison cette option permet d'obtenir un BAM avec les primers hard-clippés
=> Mais finalement c'est le même type de traitement que ce que fait notre pipeline à l'étape de ivar trim et je trouvais ça dommage puisque j'avais déjà les données avec les primers clippés
=> Après, sur ce coup, c'est sûrement aussi moi qui me suis un peu trop pris la tête ^^
Non non vous avez bien saisi la question, encore merci pour vos réponses !
=> A Reims nous devrions pouvoir faire un 1er test de soumission de données brutes la semaine prochaine
=> Je suppose que si de votre côté les traitements ne se lancent pas automatiquement (ou mal), vous pourrez revenir vers nous pour voir ce qui coince dans nos données ?
Passez une belle journée et un bon week-end !
Bien à vous.
Félix.
Oui si jamais nous rencontrons des problèmes pour le traitement de certaines données nous reviendrons vers les plateformes pour plus de précisions ou pour qu'elles re fassent le dépôt s'il s'agit de fichiers incomplets/corrompus.
Du côté du CHU de Bordeaux, nous avons mis en place le pipeline ncov-dehoster et déposé les fichiers fastq ainsi que les fichiers xlsx associés sur le serveur. Sauf erreur de ma part, les fichiers en sortie de ce pipeline répondent au critère de dehosting des séquences humaines établi par l'IFB et SPF, comme vous indiquiez une procédure similaire plus haut.
Pour répondre à votre question, une section "tutoriel" serait très appréciée voir nécessaire ++ pour la plupart des participants aux dépôts de données ! Je vous remercie pour cette proposition.
Je reste disponible par ce biais ou par mail si les données posent problème,
Merci beaucoup pour le dépôt de vos données sur le serveur de l'IFB, content de savoir que tout est fonctionnel de votre côté, et je vous confirme que tout est en ordre pour nous concernant la conformité à la procédure de dépôt de données.
Nous allons procéder à leur traitement dès que possible, et nous reviendrons vers vous (et toutes les personnes contacts pour le CHU de Bordeaux) si nous avons besoin de renseignements supplémentaires sur la/les technique(s) de séquençage utilisée(s).
Nous allons également travailler à la mise en place de ces tutoriels pour le pré-traitement des données de séquençage et le téléversement de ces données, qui seront mis à disposition sur la page EMERGEN-DB - Question list.
