Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
vidjil
vidjil
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,712
    • Issues 1,712
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 87
    • Merge Requests 87
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • vidjil
  • vidjilvidjil
  • Issues
  • #1165

Closed
Open
Opened Nov 29, 2016 by Vidjil Team@vidjilteamMaintainer

Représentative : trop courte ? Graine utilisée ? Et en multi-système ?

./vidjil -c clones -G germline/IGH -r 5 -R 5 -a -d data/Stanford_S22.fasta puis regarder out/seq/sequences.fa-1

representative : [105,232] aligner : pourquoi est-elle si courte ? Il s'arrête à une position où pourtant 5/8 des séquences sont d'accord. (50% ?) Et moralement, quasiment tout devrait être retrouvé dans la représentative.

cf aussi mail de Filip


à non, je suis bête, ce n'est pas les positions mais les k-mer


c'est quand même méga-exigeant, avec k=12/span=13 : si deux erreurs de séquençage sont espacée de 13 et concernent 25% des séquences, cela ne passe plus...


Et si on générait des représentatives avec des N à certaines positions ?


Dans le cas présent, la graine est ######-######, la représentative va jusqu'à la fin du read, on ne peut pas étendre plus de ce côté-là. De l'autre côté, le premier k-mer est GCTGTA-CTGCAA qu'on retrouve 6 fois dans le jeu. Si on prend le k-mer précédent CGCTGT-CCTGCA on ne le retrouve que 4 fois or le min_cover est à 5 (c'est la valeur du -R, ou du -r je ne sais plus entre les deux…)


En passant le -R à 4, on gagne 5 nt dans la représentative…


bon, ce n'est pas un bug, et mis en basse priorité.

À voir si on veut mettre une graine de représentative de 8 ou de 6 (au lieu de la graine par défaut, ici span 13). Justificatif : on ne fait pas trop de bêtises, pour que cela aille vraiment plus loin il faut que plusieurs k-mers à la suite passent.


Au passage, la graine utilisée par la représentative est la variable "seed" dans vidjil.cpp. Elle n'est pas affectée par les multi-germlines (même problème que -w...).

Ainsi, les deux commandes suivantes, sur Stanford, n'utilisent pas la même graine pour la représentative (alors qu'elles utilisent toutes les deux la même graine, s13, pour le KmerSegmenter) : ./vidjil -g germline -w 60 (graine par défaut, s10 actuellement) ./vidjil -G germline/IGH (graine réglée pour IGH, s13, et -w 60 se réglant tout seul)

Les commandes segmentent donc les mêmes reads mais n'ont pas la même longueur de représentative (1 base de différence). Hihihi :)


Allez pour être positif : Jeu de données de Lille au Diag (BAI 167 BC89-L1500956). Le premier clone qui sort en TRG a une représentative de 217 bp (214bp en électrophorèse ?!). Dans le cluster (157396 reads), la longueur médiane des reads est de 217bp et en fait près de 82% des reads font 217bp. Par contre dans ce même cluster il y a des reads chimériques allant jusqu'à 494bp (il y a 530 reads, soit 0,3% qui font plus de 250bp). Même jeu de données : en TRD et VdJa on trouve deux clones qui sont en fait les mêmes → les représentatives sont identiques. Même jeu de données en IGK, prenons au hasard le clone à 1,038% Intron -5/3/-2 KDE. La représentative fait 285bp et la longueur médiane des reads dans ce jeu est de 285bp (environ les 2/3 des séquences ont cette longueur). Là aussi il y a des séquences plus longues (0,6% font plus de 300bp… soit 10 séquences).

Mais tout cela c'est sur du Ion Torrent, il faudrait voir sur de l'Illumina


Voir aussi "Représentative : mesure de qualité"


Je ne sais pas si je suis sur la bonne tâche. En tout cas, un examen attentif du "make snapshot_diff" entre la 2016.08 et sans-aho (0a3bc4ca) montre une différence significative sur la représentative calculée dans should-get-tests/vidjil_s22.should_get (avec -k 9).

Peut-être que cela va naturellement s'améliorer avec les trucs en cours sur la représentative.


@mikael-s

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: vidjil/vidjil#1165