En prévision de l'EBAII, nous avons fait un point sur les génomes de références dispo dans /shared/bank pour les espèces modèles humain, souris, rat.
Avant de faire des mises à jour des bases et des index, j'avais quelques questions pour éviter de faire des bêtises:
Comment voulez-vous qu'on gère les versions de patch des assemblages ? Par exemple la version actuelle du génome humain (hg38) est l'assemblage GRCh38.p14 (patch 14) depuis Fev 2022, et avant ça la GRCh38.p13 depuis 2019, ...
Comment voulez-vous qu'on gère les sources des annotations ? Par exemple RefSeq vs Ensembl vs Gencode. Ce point là est particulièrement critique puisque les paramétrages et les résultats des pipelines peuvent être très différents en fonction de la base de référence utilisée.
Comment voulez-vous qu'on gère les versions des annotations ? Par exemple Ensembl.101 (la version dispo dans /shared/bank pour GRCh38) vs Ensembl.110 (la dernière version).
Quelle architecture des dossiers voulez-vous qu'on utilise pour les index ? Par exemple un index STAR va être défini par la version de star (star-2.7.10b), la version de l'assemblage (GRCh38.p14), la source de l'annotation (Ensembl, Refseq, ...) et la version de l'annotation (Ensembl.110).
Et dernier point, quelle différence est-elle faite entre les dossiers hg38 et GRCh38 pour l'humain ? Idem pour hg19 vs GRCh37 ?
Sinon, je manque personnellement d'expérience pour répondre mais quelques pistes de réflexions:
je ferais un dossier par base, par index, par outil, par annotation, etc.. en spécifiant la version à chaque fois (ou à défaut la date au format iso "2023-10-17").
je créerais dès que possible des liens symboliques (notamment "current" qui pointe vers la dernière version en date)
Pour un organisme particulier, j'ai regardé celui qui, naivement, me paraissait le + travaillé (homo-sapiens/*) et la synthèse correspond à ce que David décrit pour nt (sans le "current") :
/shared/bank/homo_sapiens/hg19/
.
├── bowtie2
│ ├── hg19.fa -> ../fasta/hg19.fa
│ └── ...
├── fasta
│ ├── hg19.fa
│ └── hg19.fa.fai
├── gtf # et/ou gff
│ ├── gencode.v19.annotation.gtf
│ └── README # => url (encode)
├── hisat2
│ ├── hg19.fa -> ../fasta/hg19.fa
│ ├── README # => ligne de commande lancee pour l'index hisat2
│ └── ...
├── ...
├── star -> star-2.7.2b # lien vers la dernière qd plusieurs versions
└── star-2.7.2b
├── ...
├── Log.out # => contient la Command Line
├── slurm.cpu-node-64.10172397.err # + .out
└── ...
J'ai commencé à faire une proposition, sans modifier/supprimer l'existant pour l'instant.
Du coup dans le dossier homo_sapiens j'ai créé un dossier GRCh38.p14/ et un lien symbolique current_hg38 qui pointe dessus.
En pratique hg38 et GRCh38 sont des synonymes. hg38 est la version language courant et GRCh38 le nom officiel par le genome reference consortium (Genome Reference Consortium). Idem pour hg19 et GRCh37. Du coup à un moment il faudra effectivement faire le nettoyage et ne pas laisser les 2 versions.
Normalement, le fasta devrait ne pas bouger entre plusieurs versions de l'annotation pour une même source et une même version de l'assemblage. Toutefois, comme tous les autres fichiers bougent, et que les fasta sont toujours republiés pour chaque nouvelle version de l'annotation, je recommande qu'on re-télécharge le fasta associé à chaque nouvelle release des annotations.
D'autant plus que entre les différentes sources (Ensembl, RefSeq, ...) la séquence de l'assemblage est normalement la même, mais les id dans le fasta peuvent être complètement différents.
Je confirme, c'est un peu la guerre quand tu bosses sur de l'humain ou du murin.
@dbenaben, @clairetn, @gildaslecorguille, j'essaye de finir mon exemple pour le génome humain d'ici la fin de la semaine et on pourra en rediscuter une fois que j'ai proposé une architecture complète ? Je suis bien entendu complètement ouvert à toutes les suggestions.
ces histoires de versions, d'identifiants, sources, ... Encore une guerre d'ego.