GitLab

Sophie a rappelé un dernier problème de fonctionalité dans abyss-pipeline, qu'elle a essayé d'adresser par un issue dans le gitlab (#26) et qu'il est nécessaire de résoudre à la fois pour la viabilité du pipeline et pour la rigueur de l'organisation des données sous datarmor-dataref.

Dans cette issue #26, on avait un problème pour l'analyse de données issues de double PCR, ce problème a été résolu, Babett Guenther et Sophie confirment que ces données peuvent être analysées avec abyss-pipeline, il a déjà été utilisé pour 4 projets différents apparemment sans souci.

Le deuxième problème mentionné dans issue #26, et qui subsiste est le suivant: Le ligation-preprocess, c'est-à-dire le réassortiment et le re-pairing (recouplement) de données produites par ligation (et non PCR) des adaptateurs de séquençage (donc procédé transformant les R1 et R2 en R1f, R1r, R2f, et R2r), qui est nécessaire pour DADA2, doit pouvoir fonctionner avec des données de ligation standard, donc autres que celles du Genoscope. À présent, abyss-preprocessing ne fonctionne qu'avec des données nommées comme le fait actuellement le Genoscope, voir

"# NOTE : working only with files named like CCR_AAEXOSTA_2_1_HGWCMBCX2.12BA308_clean.fastq.gz"

ligne 105 de extractR1R2.py dans abyss-preprocessing.

Or il est essentiel de:

a) pouvoir utiliser le pipe avec d'autres types de données de ligation (chaque fournisseur tend à avoir un format différent)

b) pouvoir utiliser le pipe si les noms de fichiers que va produire le Genoscope changent, ce qui est prévu cette année car le Genoscope a changé son mode de fonctionnement avec ENA.

c) pouvoir renommer+sous-échantillonner des fichiers de séquences par chantier/publication, pour faciliter l'organisation rigoureuse des données sur datarmor et in fine sur dataref.

C'est pour cela que Sophie demandait dans l’issue #26 de "séparer" le renommage (nom ancien remplacé par nom nouveau) du ligation-preprocess en lui-même. Je penses qu'initialement Laure a intégré le renommage des fichiers de séquences avec le réassortiment des données de ligation (voir lignes 92-105 du config.sh), car les deux process se basent sur cutadapt (voir lignes 97-202 de extractR1R2.py dans abyss-preprocessing), et que faire appel à l’outil une seule fois au lieu de deux était censé être plus rapide...

Solution la plus simple que nous avons défini avec Sophie lors de notre réunion vendredi 17/04/2020:

1. intégrer un rename-process indépendant dans abyss-pipeline (et donc rajouter un "pipeline step" dans le config), qui ne fait que remplacer une chaine de caractères (colonne A) par une autre (colonne B) grâce à un fichier de correspondence en format csv, pour aboutir à des données normalement nommées, c'est à dire: nom_echantillon_R1.fastq.gz et nom_echantillon_R2.fastq.gz

Ce sera à l'utilisateur de faire attention à ce que le fichier csv est correctement rempli, et qu'il a bien identifié les fichiers de sequences _R1 et _R2. Laure avait fait un script de renommage (https://gitlab.ifremer.fr/lq05ffa/abyss-rename/-/blob/master/rename.py). Ce script renomme bien les fichiers de séquences contenus dans un fichier csv de deux colonnes, mais idem, il ne fonctionne qu'avec des fichiers à nomenclature Genoscope actuelle. De plus, actuellement, une fois les fichiers renommés, ils ne sont plus traitables par ligation-preprocess de abyss-preprocessing.

2. faire en sorte que le ligation-preprocess de abyss-preprocessing, donc en particulier les fichiers extract.py et extractR1R2.py, fonctionne SI ET SEULEMENT SI les données sont nommées nom_echantillon_R1.fastq.gz et nom_echantillon_R2.fastq.gz.

Le ligation preprocess devrait donc repérer le pattern _R1/_R2 (au lieu des x_1, x_2 utilisés actuellement), puis faire ce qu'il fait à présent, c'est à dire réassortir en R1f, R1r, R2f, et R2r, enlever les amorces (primers), et re-associer les paires de séquences avec bbmap, et au final créer l'archive pour frogs-process. Le script extractR1R2.py devrait donc être simplifié en enlevant toute la partie renameSampleFiles dans extractReads, et toutes les options associées comme rename et trimreads.

DADA2 devrait continuer à fonctionner sans problème car les paramètres R1name et R2name resteront inchangés dans le main.sh.