vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-01-19T12:31:44+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1397Heuristique 1.9b : tester toutes les germlines, renvoyer la meilleure2024-01-19T12:31:44+01:00Vidjil TeamHeuristique 1.9b : tester toutes les germlines, renvoyer la meilleureDemandé par Aurélie
***
ad552cb76
Une demande sur l'heuristique par un bio, cela ne se refuse pas.
Au passage, on a
- perdu chimera.should_get. À voir.
- gagné les deux tests multi-*.should_get. Gniark, ils sont dans master mainten...Demandé par Aurélie
***
ad552cb76
Une demande sur l'heuristique par un bio, cela ne se refuse pas.
Au passage, on a
- perdu chimera.should_get. À voir.
- gagné les deux tests multi-*.should_get. Gniark, ils sont dans master maintenant, on ne pourra plus s'en débarasser aussi facilement...
- et c'est tout. Cela m'étonne, on devrait avoir d'autres tests type multi-*should_get. Les 3 séquences de bug d'aujourd'hui ?
***
Maintenant, une petite analyse de temps
vdj/data/runs/14-08-Necker/UPNT715-MRD1-141209_S7_R1.fastq (300 MB)
== 2015.01
12s 1 système, -G germline/TRG
48s 14 systemes, -g germline -i
111s 14 systèmes, juste en enlevant le return, il teste effectivement les 14 systèmes jusqu’au bout
== maintenant
188s 14 systèmes, on prend le meilleur.
Mais j'ai du faire un truc de goret pour que cela passe (supprimer KmerSegmenter::~KmerSegmenter()), il doit y avoir des fuites de mémoire partout, cela devrait faire 111s.
***
Et l'analyse de résultats...
- on segmente un peu plus (c'est normal, avant si un germline était "détecté" mais pas segmenté, poubelle), Peut-être segmente-t-on trop ? On pourrait raffiner le score pour que si on hésite entre deux germlines, poubelle/
- quelques gros paquets ne sont pas au même endroit (ici, TRD + au lieu de TRD).
14-08-Necker/UPNT715-MRD1-141209_S7_R1.fastq
==> segmented 547992 reads (97.6%) /// 548383 reads (97.7%)
==> found 93060 40-windows in 547978 segments (97.6%) //// 104364 40-windows in 548372 segments (97.7%) inside 561433 sequences
2015.01 /// maintenant
TRG -> 153 -> 14
IGH -> 265 -> 5
TRD -> 520551 -> 37655
IGK -> 4 -> 3
TRA -> 45 -> 21
TRB -> 30 -> 12
IGL -> 11 -> 7
IGH+ -> 0 -> 0
VdJa -> 7892 -> 5491
TRD+ -> 12192 -> 497162
TRD+ -> 5339 -> 1686
TRD+ -> 1484 -> 6301
IGK+ -> 5 -> 5
IGK+ -> 21 -> 21
? -> 0 -> 0
SEG_+ -> 547485 -> 548142
SEG_- -> 507 -> 241
UNSEG too short -> 0 -> 0
UNSEG strand -> 10777 -> 11081
UNSEG too few (zero) -> 140 -> 143
UNSEG too few V -> 42 -> 43
UNSEG too few J -> 1752 -> 1769
UNSEG < delta_min -> 0 -> 0
UNSEG > delta_max -> 359 -> 7
UNSEG ambiguous -> 371 -> 7
= SEG, with window -> 547978 -> 548372
= SEG, but no window -> 14 -> 11
***
bon, j'ai du être vraiment trop crade, segment.cpp:260, KmerSegmenter kseg(seq, germline), créer cela dans la boucle et le renvoyer...
***
Mikaël, pourrais-tu voir à un moment si tu arrives à trouver le souci valgrind ? Il y a segment.cpp:245/246, j'ai commenté le delete, sinon cela ne passait plus... cela cache sûrement un truc crade que j'ai fait.
merci
***
Sur 0130-Jack/lisacellsb (le fichier a été copié sur bioinfo-inria)
http://rbx.vidjil.org/browser/?custom=940&custom=941&
== Temps (sur rbx)
2015.01: 3'10 , maintenant : 4' . C'est plus que correct (et avant correction pb fuite mem)
(au passage, 21 minutes sur bioinfo-inria avec -uU)
== Résultats
on passe de 29.5% à 30%.
Qui a le courage de regarder ? Le out/ est sur bioinfo-inria.
***
merci Mikaël !
Le temps est revenu à 3'50, ok
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2318Plusieurs recombinaisons dans une séquence, scFv2023-06-28T17:25:24+02:00Mathieu GiraudPlusieurs recombinaisons dans une séquence, scFvDiscussion avec Véronique ~"repseq-IMGT" : depuis mi-2016, V-QUEST a une option pour analyser les scFv, avec du VJ (à confirmer) après un VJ normal.
https://en.wikipedia.org/wiki/Single-chain_variable_fragment
http://www.imgt.org/IMGT_...Discussion avec Véronique ~"repseq-IMGT" : depuis mi-2016, V-QUEST a une option pour analyser les scFv, avec du VJ (à confirmer) après un VJ normal.
https://en.wikipedia.org/wiki/Single-chain_variable_fragment
http://www.imgt.org/IMGT_vquest/share/textes/imgtvquest.html#afunc
Si on souhaite un jour détecter ce type de choses, cela pose des questions à la fois côté algo et côté client.
cc @flothoni @mikael-s @aurelBZHhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1607Des e-valeurs sont supérieures à 12023-03-01T17:05:07+01:00Vidjil TeamDes e-valeurs sont supérieures à 1Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé....Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé... à voir si on peut le refaire sur un autre fichier, et surtout sur la nouvelle version. En attendant, la séquence en question est dans notable, et elle donne une e-valeur correcte seule.
***
Ici on en a aussi : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2 : e-valeur de 568 pour le clone en J3
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1724SEG_METHOD_ONE : séquences non recombinées, usages2022-02-25T18:21:15+01:00Vidjil TeamSEG_METHOD_ONE : séquences non recombinées, usages
Utilisations :
- (voir Sarah) détecter les `IGHC=*.fa` (même si le read n'est pas assez long) + quantification relative
- détecter les V / J sans détecter les recombinaisons
- détecter en RNA-Seq ou capture d'autres choses : CD, ......
Utilisations :
- (voir Sarah) détecter les `IGHC=*.fa` (même si le read n'est pas assez long) + quantification relative
- détecter les V / J sans détecter les recombinaisons
- détecter en RNA-Seq ou capture d'autres choses : CD, ... #1801
- détecter des adaptateurs mal enlevés #1669
- standards / spikes ? ~"user-request"
(Anciens commentaires ci-dessous, implémenté depuis... 2018 !)
> Cela me tente très fort d'avoir une méthode expérimentale pour retrouver des reads matchant *une* séquence dans une germline de référence, non recombinée.
>
> Implémentation proposée (temps estimé : moins qu'un chapitre d'HdR :)
> - en KmerSegmenter, récupérer simplement le k-mer maximum + test e-valeur + extraction d'une fenêtre *centrée* les k-mers détectés. Selon ce qu'on prend comme taille de fenêtre, on fera plus ou moins n'importe quoi. (edit: mieux, minimizers, voir #2643)
> - éventuellement continuer en FineSegmenter avec une DP standard pour identifier la séquence.
>
> On s'éloigne du dogme, "Vidjil analyse les recombinaisons"... mais on reste focus sur choses immuno. Mais il ne faut pas recoder Blast/Yass :-)Algo 2022.01Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/922src/align.cgi : faire un aligneur flexible, cgi / texte2021-10-21T19:17:38+02:00Vidjil Teamsrc/align.cgi : faire un aligneur flexible, cgi / texte
***
@nobody
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/978segmenter.cpp: séparer UNSEG_strand en deux cas (vraiment pas beaucoup d'affe...2021-03-31T17:26:04+02:00Vidjil Teamsegmenter.cpp: séparer UNSEG_strand en deux cas (vraiment pas beaucoup d'affect ou pas)On voit souvent du STRAND (mail Manuel, mais aussi d'autres)... et peut-être que cela ne veut pas dire grand chose. Et c'est un de nos premiers tests.
- séparer en deux cas : c'est le minimum
- et, même, je me demande quelle est main...On voit souvent du STRAND (mail Manuel, mais aussi d'autres)... et peut-être que cela ne veut pas dire grand chose. Et c'est un de nos premiers tests.
- séparer en deux cas : c'est le minimum
- et, même, je me demande quelle est maintenant la pertinence de la détection de strand (et le RATIO_STRAND à 5 semble gros). Comme on a une e-valeur, ne devrait-on pas faire les deux côtés et prendre la meilleure ?
***
73178e8
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2107Indication onlyV trompeuse sur anayse de capture2021-03-22T09:31:46+01:00Thonier FlorianIndication onlyV trompeuse sur anayse de captureSur un set issu d'analyses de Necker :
Sur 4 millions de séquences issus de capture, avec de nombreuses sondes autre que les J, on a une forte proportion de séquences faussement anotées "only V" suite à quelques Kmer éparses trouvés da...Sur un set issu d'analyses de Necker :
Sur 4 millions de séquences issus de capture, avec de nombreuses sondes autre que les J, on a une forte proportion de séquences faussement anotées "only V" suite à quelques Kmer éparses trouvés dans la séquence ( ~25% des reads sont concernés).
En détails, ceux-ci ne sont composés que de 5 ou 6 kmer répartis sur toute la longueur du read.
@magiraud @mikael-s Algo 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1579k-mers communs entre IGHV et IGHD2021-03-17T23:19:38+01:00Vidjil Teamk-mers communs entre IGHV et IGHDMikaël, à propos d'IGH : "Une partie du problème vient du fait que deux gènes D ont des k-mers partagés avec des gènes V. Cela peut être vérifié facilement :
./vidjil -G germline/IGH -K germline/IGHD.fa
Du coup cela décale la fenêtre ver...Mikaël, à propos d'IGH : "Une partie du problème vient du fait que deux gènes D ont des k-mers partagés avec des gènes V. Cela peut être vérifié facilement :
./vidjil -G germline/IGH -K germline/IGHD.fa
Du coup cela décale la fenêtre vers la droite et on a une moins bonne
spécificité."
La sotie en question :
>J00234|IGHD2-15*01|Homo
AGGATATTGTAGTGGTGGTAGCTGCTACTCC
_ _ _ _ _ _ _ _+X+X _ _ _ _ _ _ _ _ _
>X93616|IGHD3-22*01|Homo
GTATTACTATGATAGTAGTGGTTATTACTAC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+X _ _
***
- modifier notre graine d'IGH pour que cela n'arrive pas ?
- prendre en compte le répertoire D pour marquer certains k-mers de V et de J ambigus ? (Finalement, jusqu'à maintenant le rep D ne sert pas du tout pour le KmerSegmenter !)
- décaler la window pour compenser ?
***
J'avais oublié, mais ton merge de voodooj me l'a rappelé : le -t 100 solutionne cela : « Interestingly with -w 100, the number of foud windows is much larger because now the window is better centered around the junction. ». Par chance les k-mers partagés avec les gènes D ne sont pas dans les 100 derniers nucléotides des V.
***
la chance est avec nous :-)
La solution 2 "prendre en compte le répertoire D pour marquer certains k-mers de V et de J ambigus" me semble tout de même raisonnable et robuste.
***
On n'était pas si chanceux que cela, même avec le -t 100 :
../../vidjil -y 0 -s '#####-#####' -K -G ../../germline/IGH -u ../../data/common-D-V.fa
+X+X+X+X+X+X+X+X+X+X _ _ _ _ _ _ _ _ _+X _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+x+x+x+x+x+x+x+x+x+x
en insérant aussi les D :
+X+X+X+X+X+X+X+X+X+X _ _ _ _ _ _ _ _ _ ?+f+f+f+f+f+f _ _ _ _ _ _ _ _ _ _+x+x+x+x+x+x+x+x+x+x
ok, c'est une graine non-standard.
***
c23b5d2
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2643SEG_METHOD_ONE: mettre un minimizer pour extraire une fenêtre normalisée2021-02-10T19:47:40+01:00Mathieu GiraudSEG_METHOD_ONE: mettre un minimizer pour extraire une fenêtre normaliséeActuellement, quand `SEG_METHOD_ONE` réussit, on extrait la fenêtre au milieu, bref cela ne clustérise pas si des reads sont légèrement décalées. Une solution serait d'extraire la fenêtre par minimisation.
- minimisation sur toutes les ...Actuellement, quand `SEG_METHOD_ONE` réussit, on extrait la fenêtre au milieu, bref cela ne clustérise pas si des reads sont légèrement décalées. Une solution serait d'extraire la fenêtre par minimisation.
- minimisation sur toutes les fenêtres possibles ?
- ou bien uniquement sur les k-mers détectés ?
On peut (ou pas) restreindre cela à des positions plutôt centrales pour éviter que la fenêtre ne soit trop au bord... mais est-ce que cela gène vraiment ? Pour les recombinaisons on peut tout à fait avoir une fenêtre au bord.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2910Clone manqué avec une grosse délétion (read trop court pour la fenêtre)2021-01-26T13:29:14+01:00Anne de SeptenvilleClone manqué avec une grosse délétion (read trop court pour la fenêtre)IGH https://app.vidjil.org/index.html?set=25178&config=2
multi+inc https://app.vidjil.org/index.html?set=25178&config=26IGH https://app.vidjil.org/index.html?set=25178&config=2
multi+inc https://app.vidjil.org/index.html?set=25178&config=26Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2920Documenter germline/homo-sapiens.g et les méthodes de recombinaison2020-09-22T10:49:35+02:00Mathieu GiraudDocumenter germline/homo-sapiens.g et les méthodes de recombinaisonEn faisant !75/!76, je me rends compte que ni `doc/vidjil-algo.md`, ni `doc/locus.md` ne détaillent la syntaxe de `homo-sapiens.g`.
Derrière les questions de syntaxe, il y a aussi les questions de méthodes de recombinaison... qui ne so...En faisant !75/!76, je me rends compte que ni `doc/vidjil-algo.md`, ni `doc/locus.md` ne détaillent la syntaxe de `homo-sapiens.g`.
Derrière les questions de syntaxe, il y a aussi les questions de méthodes de recombinaison... qui ne sont tout simplement pas expliquées. Même si on peut renvoyer aux papiers, la ~doc doit fournir quelques éléments d'explications.
- la différence entre `53` et `543` peut sembler triviale, mais autant le dire.
- `MAX12` est évoquées cryptiquement dans `vidjil-algo.md`, c'est un peu mieux dans `locus.md`... alprs que c'est une option quasi "par défaut"
- `MAX1U` n'est pas évoqué (mais pas utilisé / à retester ?)
- et la nouvelle ONE #1724 (et d'ailleurs, trouver mieux que 31581d712d ?)
====
From duplicate #4012:
vidjil-algo is able to handle different germlines, either from IMGT/GENE-DB, or for other sources. Beyond the `-V / `-D`/`-J`options, the`.g\` file is very flexible. However (Zhang, 2019) reports that "more effort should be made to manage customization" vdj#919.
We should ensure that this is properly documented. What is the syntax of the `.g` file, and what are the recommended steps for anyone wishing to better use a custom germline ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/918Profiler vidjil-algo: gprof, callgrind2020-05-20T16:58:20+02:00Vidjil TeamProfiler vidjil-algo: gprof, callgrindAvoir une vue claire de ce qui prend du temps dans vidjil-algo, au niveau des fonctions/appels.
On avait fait cela il y a quelques années.
Voir aussi #3392.Avoir une vue claire de ce qui prend du temps dans vidjil-algo, au niveau des fonctions/appels.
On avait fait cela il y a quelques années.
Voir aussi #3392.Algo 2020.06https://gitlab.inria.fr/vidjil/vidjil/-/issues/2913Diminuer ou décaler dynamiquement, par seuil, la taille de la fenêtre2020-04-15T09:18:25+02:00Mikaël SalsonDiminuer ou décaler dynamiquement, par seuil, la taille de la fenêtreDans #2910 on manque un clone car il y a une grosse délétion dans le V, consuisant à une séquence très courte (~129nt) empêchant de bien positionner une fenêtre de 60nt.
C'est très grave puisqu'on peut manquer des clones majoritaires. U...Dans #2910 on manque un clone car il y a une grosse délétion dans le V, consuisant à une séquence très courte (~129nt) empêchant de bien positionner une fenêtre de 60nt.
C'est très grave puisqu'on peut manquer des clones majoritaires. Une solution est de décaler la fenêtre #1580 (soit en encodant directement le décalage, dans la config, mais cela signifie que c'est systématique, soit dynamiquement mais c'est compliqué).
Une autre solution simple serait de prendre une fenêtre plus petite si on n'arrive pas à placer la fenêtre de 60nt. On pourrait essayer différentes longueurs, par ordre décroissant, par seuils (60, 50, 40, 30…) et on prend la première qui passe. Cela permet d'avoir quelque chose de reproductible. Et cela éviterait de passer à côté d'un gros clone.Algo 2017.11Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1580Décaler la window dans certains cas2020-04-15T09:18:25+02:00Vidjil TeamDécaler la window dans certains casMikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de ...Mikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de certaines amorces...).
Y aurait-il des cas où on aimerait plus revenir à gauche ? Surtout si on prend un grand `-w`, 80, 100 ou plus.
(Avoir un truc flexible, en fonction de la taille de la read, semble difficile, puisqu'on veut avant tout regrouper les reads en clones...)
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3954Graines différentes pour V et J2020-03-26T12:45:56+01:00Mathieu GiraudGraines différentes pour V et JSpécialise #1169.
Pensé depuis le début avec ~"cpp-aho".
@mikael-s : "on stocke déjà un `index_load` différent" et "en IGK, 30kbp pour V et 300bp pour J, 100 fois moins !"
Voir aussi #1364.Spécialise #1169.
Pensé depuis le début avec ~"cpp-aho".
@mikael-s : "on stocke déjà un `index_load` différent" et "en IGK, 30kbp pour V et 300bp pour J, 100 fois moins !"
Voir aussi #1364.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4225Affectations manquantes avec l'option `-1`2020-03-25T12:09:53+01:00Mikaël SalsonAffectations manquantes avec l'option `-1`Comme noté dans #3954, avec l'option `-1` on se retrouve avec des affectations `_` là où on ne devrait pas.Comme noté dans #3954, avec l'option `-1` on se retrouve avec des affectations `_` là où on ne devrait pas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/915Calculer valeur entière d'un k-mer à partir de la précédente et non pas recal...2020-02-21T21:20:02+01:00Vidjil TeamCalculer valeur entière d'un k-mer à partir de la précédente et non pas recalculer from scratchnon, difficile pour spaced seeds
***
Même dans le cas d'une graine espacée, cela peut se faire en O(1), en stockant juste un buffer plein, sans les espaces, en faisant évoluer le buffer à chaque caractère, puis en appliquant le masque qu...non, difficile pour spaced seeds
***
Même dans le cas d'une graine espacée, cela peut se faire en O(1), en stockant juste un buffer plein, sans les espaces, en faisant évoluer le buffer à chaque caractère, puis en appliquant le masque qu'il faut pour avoir la valeur. On passerait de O(nk) à O(n).
***
kmerstore.h : getResults (rigolo, actuellement pas du tout la même implémentation pour Map et Array, pourquoi ?)
- buffer = (buffer << 2) && xx || yy
- kmer = buffer && zz
... mais après il reste dans kmer des trous à zéro.
Enlever ces zéros n'est pas si facile et revient, dans le cas le pire, en O(k).
Une autre solution est de laisser ces zéros, ce qui fait juste "gâcher" 4x d'espace par joker pour le ArrayKmerStore (et rien pour le MapKmerStore). Jouable, non ?
Mais seul un esprit supérieurement templatisé réussira à faire cela...
***
(et le "gâchis" est le même que celui induit par les jokers dans Aho)
***
> kmerstore.h : getResults (rigolo, actuellement pas du tout la même implémentation pour Map et Array, pourquoi ?)
eb031bf2 et f7f1690
***
branch spaced
Ne marche pas encore
Voir par exemple
sh should-to-tap.sh multi-short-affects.should_get
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2964Séquence non analysée avec la présence du gène constant2020-02-13T16:42:59+01:00Anne de SeptenvilleSéquence non analysée avec la présence du gène constantJ'ai passé dans mon dernier run, 4 patients dont le clontype a été amplifié sur cDNA (et non ADN),
Notamment celui ci, dont le clonotype n'est pas du tout reconnu par Vidjil :
https://app.vidjil.org/index.html?set=26028&config=2
La re...J'ai passé dans mon dernier run, 4 patients dont le clontype a été amplifié sur cDNA (et non ADN),
Notamment celui ci, dont le clonotype n'est pas du tout reconnu par Vidjil :
https://app.vidjil.org/index.html?set=26028&config=2
La reconnaissance du J est peut-être gênée par les mutations ?
Séquence attendue (obtenue en Sanger, et visible sans problème sur Arrest)
```
>CHA
caggtcaccttgaaggagtctggtcctgtactggttaaacccacagagaccctcacgctgacgtgcaccgtctctgggttctcactcaacagtgctagaatgggtgtgacctggatccgtcagtccccagggaaggccctggaatggcttgcacacatttcctcgaatgacgaaaaattgtatagtacatctctgaagaccaggctcaccatctccaaggacacctccagaagccaggtggtcctcaccgtgaccaacatggaccctgtggacacagccacatattactgtgcacggacacggggagtatatagttatgattctcttgagtactggggccagggagccctgatcaccgtctccgcag
```Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1273Raisons de non-segmentation : remettre à plat, documenter ?2019-11-21T12:10:16+01:00Vidjil TeamRaisons de non-segmentation : remettre à plat, documenter ?Les commits jusqu'à 41b4f07 peuvent nous faire demander si les raisons de non-segmentation sont bien rangées.
En particulier STRAND par rapport à AMBIGUOUS.
On pourra faire cela pour heuristique 1.9 ou 2.0.
***
Un read uniquement avec d...Les commits jusqu'à 41b4f07 peuvent nous faire demander si les raisons de non-segmentation sont bien rangées.
En particulier STRAND par rapport à AMBIGUOUS.
On pourra faire cela pour heuristique 1.9 ou 2.0.
***
Un read uniquement avec des J est classifié parfois en tant que #UNSEG ambiguous, ce qui n'est pas vraiment attendu, parfois en tant que too few V.
Exemple :
#UNSEG ambiguous
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+J+J+J+J+J+J+J+J+J+J+J _
Mais aussi :
#UNSEG too few V
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+J+J+J
***
Ce n'est pas trop flou, c'est clairement un bug. Peut-être lié avec l'autre potentiel de ce matin :)
***
>TRDD2*01-TRDJ1*01
CCTTCCTACACACCGATAAACTCATCTTTGGAAAAGGAACCCGTGTGACTGTGGAACCAA
#UNSEG ambiguous
_ _ _ _ _ _ _ _ _+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J
>TRDV3*01-TRDD3*01
ATCTCTCCAGTAAGGACTGAAGACAGTGCCACTTACTACTGTGCCTTTAGACTGGGGGATACG
#UNSEG ambiguous
+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _ _ _ _ _ _ _
***
En fait c'est bien à cause de 41b4f07105.
Si on détecte 10 k-mers, passe en AMBIGUOUS. Ce n'est pas très informatif, et surtout ce n'est pas souhaité si on fait derrière des réarrangements incomplets.
***
a8df78e, on n'aura plus ce bug.
Mais il faudra toujours remettre un jour les raisons de non-segmentation à plat, strand / detect.
***
Beaucoup mieux depuis 1f1f16e.
Mais une remise à plat serait toujours la bienvenue.
Autant faire cela après germlines.data et Aho-Corasick...
***
Et documenter cela.
***
Fait depuis 2015-05 et 2015-06
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2556Mettre Aho par défaut2019-03-05T08:55:46+01:00Mathieu GiraudMettre Aho par défautÉvoqué par @mikael-s pour %"Algo 2017.07".
Avant #1169, on pourrait déjà mettre Aho par défaut.
Problèmes restants sur Aho :
* [ ] #2596 (xxx meilleur que recombinaison classique)
* [x] #3404 (xxx IGHV+/IGHJ+ meilleur que IGH !)
* ...Évoqué par @mikael-s pour %"Algo 2017.07".
Avant #1169, on pourrait déjà mettre Aho par défaut.
Problèmes restants sur Aho :
* [ ] #2596 (xxx meilleur que recombinaison classique)
* [x] #3404 (xxx IGHV+/IGHJ+ meilleur que IGH !)
* [x] #2652 (VD au lieu de VDJ)
* [ ] #3402 (DJ au lieu de VDJ)
* [ ] #2595 (segmentation avec un seul k-mer, mais non bloquant je dirais)Algo 2018.12Mikaël SalsonMikaël Salson