The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
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.