vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2023-10-20T12:27:43+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4665Nouvelles germlines, clustérisation S22 et fenêtre décalée : k-mer commun ent...2023-10-20T12:27:43+02:00Mathieu GiraudNouvelles germlines, clustérisation S22 et fenêtre décalée : k-mer commun entre V et DDepuis https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/885#note_441064.
L'extrait d'une read de S22 (c'est pareil pour 4 autres reads) :
```
>extract-from-lcl|FLN1FA002P88J7
AGAGCCGAGGACACGGCCGTGTATTACTGTGCGAGAGATCGACATTGTAGTGGTG...Depuis https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/885#note_441064.
L'extrait d'une read de S22 (c'est pareil pour 4 autres reads) :
```
>extract-from-lcl|FLN1FA002P88J7
AGAGCCGAGGACACGGCCGTGTATTACTGTGCGAGAGATCGACATTGTAGTGGTGGTAGTTGCCGAGGCCTCTGGGGCCAGGGAACCCTGGTCACCGTCTCCTCAG
```
`vidjil-algo -r 1`, les affects (la seule chose qui change est les germlines) :
```
dev 52 + VJ 1 38 72 106 (...)+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V+V+V ? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
!885 53 + VJ 1 60 72 106 (...)+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V+V+V ?+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
```
Un `+H` (J) décale la fenêtre de 11bp, ce qui mène à un clone qui passe à 5 reads avec la nouvelle germline (avant ? 4 ?)
Avant de parler de la clustérisation, j'aimerais comprendre d'où vient ce k-mer et si l'un des deux affects est "le bon".https://gitlab.inria.fr/vidjil/vidjil/-/issues/2314Une séquence TRG en xxx2018-07-20T18:57:21+02:00Mathieu GiraudUne séquence TRG en xxxhttp://app.vidjil.org/index.html?sample_set_id=23190&config=25
Une séquence traine en `xxx` alors qu'elle est bien fine segmentée en `TRG`:
```
>TRGV10*01 4/GTTT/7 TRGJP1*01 186 nt, 1125 reads (0.064%, 1973.68% of unexpected)
AGCATG...http://app.vidjil.org/index.html?sample_set_id=23190&config=25
Une séquence traine en `xxx` alors qu'elle est bien fine segmentée en `TRG`:
```
>TRGV10*01 4/GTTT/7 TRGJP1*01 186 nt, 1125 reads (0.064%, 1973.68% of unexpected)
AGCATGGGTAAGACAAGCAACAAAGTGGAGGCAAGAAAGAATTCTCAAACTCTCACTTCAATCCTTACCATCAAGTCCGTAGAGAAAGAAGACATGGCCGTTTACTACTGTGCTGCGTCGTTGG
GGTT
TTGGTTGGTTCAAGATATTTGCTGAAGGGACTAAGCTCATAGTAACTTCGCCTGGTAA
```
cc @mikael-shttps://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/2508Vh pas trouvé, uniquement Dh-Jh2018-06-27T18:53:42+02:00Mathieu GiraudVh pas trouvé, uniquement Dh-JhAurélie ~"LIL-Lille" :
> I have a question on the results I obtain on the following sample: http://app.vidjil.org/?sample_set_id=23852&config=25
>
> Let's look on the following clones:
> >IGHD2-2*02 2/TGA/5 IGHJ5*02 362 nt, 148 52...Aurélie ~"LIL-Lille" :
> I have a question on the results I obtain on the following sample: http://app.vidjil.org/?sample_set_id=23852&config=25
>
> Let's look on the following clones:
> >IGHD2-2*02 2/TGA/5 IGHJ5*02 362 nt, 148 525 reads (10.64%, 53.45% of IGH/IGH+, 2042% of IGH+)
> GGAGTCGGGGGAGGCTTGGTCCAGCCTGGGGGTCCCTGAGACTCTCCTGTGCAGCCTCTGGATTCACCTTCAGTGACTACTACATGAGCTGGGTCCGCCAGGCTCCCGGGAAGGGGCTGGAGTGGGTAGGTTTCATTAGAAACAAAGCTAATGGTGGGACAACAGAATAGACCACGTCTGTGAAAGGCAGATTCACAATCTCAAGAGATGATTCCAAAAGCATCACCTATCTGCAAATGAACAGCCTGAGAGCCGAGGACACGGCCGTGTATCAAGGGGCATTTATTGTAGTAGTACCAGCTGCTAT
>
> ATG
> ATGGTTCGACCCCTGGGGCCAGGGAACCCTGGTCACCGTCTCCTCAGGTAAG
>
>
>
> Bonjour,
>
> Ce clone est mal nommé, il ne reconnaît pas le VH, bien présent puisque nous avons pu merger des clones qui étaient VDJ. Cela m’embête car ce clone étant majoritaire, le merge ne permet pas de corriger la séquence.
>
> Pourriez-vous y regarder et me dire pourquoi le VH n’a pas été reconnu ?
>
> Merci
>
> AurélieAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1915Graîne pour xxx2020-08-27T12:47:39+02:00Vidjil TeamGraîne pour xxxLa graîne utilisé pour xxx est plus courte que pour d'autres locus (IGH, TRA, TRB, IGH+, TRA+D, TRD+), du coup une séquence ne passant pas dans un locus normal (à cause d'erreurs ou hypermutations) pourrait passer en xxx alors que la rec...La graîne utilisé pour xxx est plus courte que pour d'autres locus (IGH, TRA, TRB, IGH+, TRA+D, TRD+), du coup une séquence ne passant pas dans un locus normal (à cause d'erreurs ou hypermutations) pourrait passer en xxx alors que la recombinaison n'a rien d'extraordinaire. Exemple ici : http://rbx.vidjil.org/browser/index.html?patient=1655&config=25
***
Bien vu. Je me demandais ce que faisait ces séquences.
Que doit-on faire ?
1) allonger la graine de xxx (ou les seuils de e-valeur) pour ne plus avoir cela
2) interdire que xxx retourne un V/J d'un autre locus
3) ou... "sauver" ces séquences et les remettre (même dans le C++) dans le locus d'origine. **Si** on a confiance dans nos calculs d'e-valeur, ce serait la bonne chose à faire : une séquence xxx qui passe est pertinente.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1400Heuristique i.0 : être capable d'inférer des germlines "inconnus"2017-07-05T09:15:56+02:00Vidjil TeamHeuristique i.0 : être capable d'inférer des germlines "inconnus"Suite à la discussion en janvier à Necker.
On voudrait segmenter des séquences... à la découverte de ce qu'on ne connaît pas. But : 100% des reads ont une explication, TOO_SHORT, ou sinon on dit ce qu'il y a dedans.
1) Cas relativement ...Suite à la discussion en janvier à Necker.
On voudrait segmenter des séquences... à la découverte de ce qu'on ne connaît pas. But : 100% des reads ont une explication, TOO_SHORT, ou sinon on dit ce qu'il y a dedans.
1) Cas relativement simple :
+V+V+V+V+V+V+V__________________________
À distinguer du cas TOO_FEW_J / trop court. Ici, c'est probablement autre chose, et on pourrait extraire une fenêtre centrée sur la fin du V
2) Et cas plus dur : idem... sans les +V. Bref, être capable de deviner le point de jonction... on se souvient de ce qui avait été fait avec David. On pourrait tout à fait rentrer cela dans le Vidjil actuel : avoir un CountSegmenter qui prédit un point de cassure... (Question subsidiaire : que donne CRAC si on lui donne un jeu de reads V(D)J ?)
***
Séquences de Prague, sur rbx, collegues/pragues/IGH-UNSEG.affects
Il y a des trop petits... mais il y a aussi d'autres choses...
***
Si on infère des choses bizarres, il faudra mettre des checks sur la representative et/ou de gros warnings partout (on est pas sûr que la fenêtre est pertinente, qu'autour c'est pareil...)
***
b9994d1 et 196acbc
Sur Pee (217, Rennes)
- -g -i : 48% (110s)
- après max12: 85%
- après sortLeftRight : 99.1% (42s, car pas de -i)
Attention, est-on sûr de ce qu'on trouve ? Les longueurs des représentatives ont l'air plutôt bonnes, mais il faudrait quelque chose pour en être plus sûr et vérifier qu'on ne clustérise pas des bouts de V.
***
http://rbx.vidjil.org/browser/?custom=1442&custom=1443&custom=1568&custom=1569&
À gauche, multi+inc, à droite, multi+xxx.
***
Changements légers ce matin, marche avec -i, pas segmenté si < 5 kmers (DETECT_THRESHOLD)
http://rbx.vidjil.org/browser/?custom=1442&custom=1585&custom=1443&custom=1586&
***
ok pour "xxx"... mais il faudrait pouvoir avoir des choses plus méchantes, en devinant des germlines (à la David ?)
***
12bcb3c: MAX1U, -4. Modèle de proba à discuter ensemble, pour l'instant c'est trop méchant.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1543bug de segmentation sur deux slaves2017-07-05T09:15:56+02:00Vidjil Teambug de segmentation sur deux slavesDepuis mes commits du 24 avril, le build est cassé... sur exactement deux slaves. Les autres fonctionnent.
ks.getSegmentationStatus() == UNSEG_TOO_FEW_J failed (testSegment.cpp:161)
# 9 ! seed TRG UNSEG too few (0) 1.000000e+00 5.2...Depuis mes commits du 24 avril, le build est cassé... sur exactement deux slaves. Les autres fonctionnent.
ks.getSegmentationStatus() == UNSEG_TOO_FEW_J failed (testSegment.cpp:161)
# 9 ! seed TRG UNSEG too few (0) 1.000000e+00 5.263273e17/1.000000e+00
+G+G+G+G+G+G+G+G+G _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Je devrais apprendre à me logguer en ssh sur les slaves pour comprendre ce qu'il se passe :)
***
C'est cadeau :
Add these lines to your .ssh/config file
Host *.ci
ProxyCommand ssh mgir001@ci-ssh.inria.fr "/usr/bin/nc `basename %h .ci` %p"
SSH command : ssh ci@bonsai-debian-squeeze.ci
Le mot de passe de l'utilisateur ci est… ci et celui de root est… password
***
Et évidemment mettre ta clé publique sur ci.inria.fr
***
merci !
Et pour devenir "Slave Admin" sur https://ci.inria.fr/project/bonsai/users, il faut que je corrompe un des Admin ?
***
done. bon we.
***
Cela fonctionne, merci et bon we !
Juste pour info, dans mon .ssh/config, comme j'utilise une "autre clé", j'ai du spécifier IdentityFile, mais pour la passerelle, en rajoutant :
Host ci-ssh.inria.fr
IdentityFile = ~/.ssh/id_dsa.xxxxxx
***
a72ef27
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1756Only V / Only J alors qu'il n'y a que du bruit2017-09-19T23:50:40+02:00Vidjil TeamOnly V / Only J alors qu'il n'y a que du bruitLe mail que j'ai envoyé à McGill m'a mis la puce à l'oreille : vraiment, leurs données RNA-Seq contiendraient des dizaines de % de reads en only V ou only J ?
rbx : ~/patients/u061-McGill/V03-372-1T_1.fq
Regardé quelques reads au début ...Le mail que j'ai envoyé à McGill m'a mis la puce à l'oreille : vraiment, leurs données RNA-Seq contiendraient des dizaines de % de reads en only V ou only J ?
rbx : ~/patients/u061-McGill/V03-372-1T_1.fq
Regardé quelques reads au début (-i -x 1000 -K -uU )... et non, on fait n'importe quoi :
>Bla
CTAGGCATGGCTCCTCTCCACAGGAAAACTCCACTCCAGTGCTCAGCTTGCACCCTGGCACAGGCCAGCAGTTGCTGGAAGTCAGACACCTGAGAAGAAC
# 1 ! seed IGK UNSEG only V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Je pensais qu'il y avait un filtre de e-value pour only V / only J...
***
5298c86.
Différence entre 2015.10.2 et 5298c86, sur V03-372-1T_1.fq
(http://rbx.vidjil.org/browser/?patient=1233&config=25, 10M reads) :
UNSEG strand -> 52957 99.5
- UNSEG too few V/J -> 7341235 97.5
- UNSEG only V -> 1660661 94.3
- UNSEG only J -> 1041862 94.7
- UNSEG ambiguous -> 898556 99.4
+ UNSEG too few V/J -> 10786960 96.9
+ UNSEG only V -> 108604 98.5
+ UNSEG only J -> 46512 99.5
+ UNSEG ambiguous -> 238 100.0
UNSEG too short w -> 1 100.0
Cette correction de bug peut justifier 2015.12 :-)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1544Exploiter les qualités des .fastq ?2019-09-16T16:58:44+02:00Vidjil TeamExploiter les qualités des .fastq ?Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof...Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof.
***
Disons que ce qu'on a vu sur les problèmes de représentative (https://www.producteev.com/workspace/t/553e1de8b1fa09d063000007) montrent plutôt qu'on s'en sort déjà bien sans regarder la qualité.
***
@nobodyhttps://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 Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2595Segmentation avec un seul k-mer avec Aho-Corasick2019-02-28T20:52:32+01:00Mikaël SalsonSegmentation avec un seul k-mer avec Aho-CorasickLa version de Vidjil avec Aho-Corasick échoue sur un test dans `chimera-fake.should-get` sur cette séquence (qui est un faux mélange de TRG/TRD) :
> TCTTCCAACTTGGAAGGGAGAACGAAGTCAGTCACCAGGCTGACTGGGTCATCTGCTGAAGCCCAGAAGGTTACTCAAGCCCAGTCAT...La version de Vidjil avec Aho-Corasick échoue sur un test dans `chimera-fake.should-get` sur cette séquence (qui est un faux mélange de TRG/TRD) :
> TCTTCCAACTTGGAAGGGAGAACGAAGTCAGTCACCAGGCTGACTGGGTCATCTGCTGAAGCCCAGAAGGTTACTCAAGCCCAGTCATCAGTATCCATGCCAGTGAGGAAAGCAGTCACC
Or Vidjil segmente cette séquence en IGK et la chaîne d'affectations ressemble à cela :
```
# 11 - VJ 1 79 108 120 seed IGK SEG_- 1.858802e-01 1.858801e-01/1.009101e-07 _ _-k ? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+K _ _ _ _ _ _ _ _ _ _ _ _-K-K-K-K _ _ _ _ _ _-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-K-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Il n'y a qu'un seul `-k`, et la e-valeur est très haute, mais ça passe tout juste. Pourquoi ?
1. L'index load est faible sur les J (0,013%), contre 1,048% auparavant (il n'y avait pas de distinction entre l'index load des V et des J).
2. La séquence est relativement courte (120nt).
3. Il a peu de séquences dans le fichier.
Bref, que faire ? On est (à peu près) contents de notre calcul de e-valeur. Avoir un index load séparé pour les V et les J semble plus pertinent. Faut-il allonger la séquence pour tricher et refaire passer la e-valeur au dessus du seuil fatidique ?Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2596[Aho] Meilleure e-valeur avec xxx qu'avec une recombinaison classique2019-03-06T09:57:28+01:00Mikaël Salson[Aho] Meilleure e-valeur avec xxx qu'avec une recombinaison classiqueSur `should-vdj-tests/BRI_multi.should-vdj.fa` (par exemple) une séquence est segmentée en xxx au lieu de l'être en TRA+D. La e-valeur en xxx est 10^-109 contre 10^-100 en TRA+D.
Pourtant l'index load du xxx est bien plus élevé (3,7% con...Sur `should-vdj-tests/BRI_multi.should-vdj.fa` (par exemple) une séquence est segmentée en xxx au lieu de l'être en TRA+D. La e-valeur en xxx est 10^-109 contre 10^-100 en TRA+D.
Pourtant l'index load du xxx est bien plus élevé (3,7% contre 0,004%).
La séquence est :
```
>TRDV2*01 3/CGGAGG/19 TRAJ48*01 [TRA+D]
TGCAAAGAACCTGGCTGTACTTAAGATACTTGCACCATCAGAGAGAGATGAAGGGTCTTACTACTGTGCCTGTGACCGGAGGGAAATTAACCTTTGGGACTGGAACAAGACTCACCATCATACCCAGTAAGTTCTTCATCCTTGGTCAGGAAATCAGCCTGCATAAGATTCTGGGGA
```Heuristique 2.0Mikaël SalsonMikaël Salsonhttps://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/2644Décaler automatiquement voire raccourcir la window quand il n'y a pas assez d...2018-01-18T00:35:54+01:00Mathieu GiraudDécaler automatiquement voire raccourcir la window quand il n'y a pas assez de place(Rendu compte lors de la minimisation #2643, mais s'applique aussi au cas général.)
N'est-il pas dommage que des séquences dont le point de jonction a été trouvé finissent en `TOO_SHORT_FOR_WINDOW` ? Dans ces cas-là, pourrait-on, au mom...(Rendu compte lors de la minimisation #2643, mais s'applique aussi au cas général.)
N'est-il pas dommage que des séquences dont le point de jonction a été trouvé finissent en `TOO_SHORT_FOR_WINDOW` ? Dans ces cas-là, pourrait-on, au moment du `getJunction()`, accepter de décaler un peu la fenêtre jusqu'au bord gauche/droit, voire la raccourcir ?
Ces reads ne serait pas groupées avec les autres... mais a priori ce serait peu problable de les mettre avec d'autres reads non liées, car toutes les fenêtres ainsi décalées viendraient de reads toutes trop courtes de la même façon.
Voir #1580 pour d'autres raisons de décalage.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2648Calcul efficace d'un minimizer : par Aho ?2017-09-18T11:07:46+02:00Mathieu GiraudCalcul efficace d'un minimizer : par Aho ?Ce qui est dans !76 pour #2643 fonctionne : `kaa.minimize(const KmerAffect &affect, int margin, int width)` retourne la position (hors de `margin` sur les bords) tel que le k-mer de longueur `width` soit minimal (maximal en fait). Idéale...Ce qui est dans !76 pour #2643 fonctionne : `kaa.minimize(const KmerAffect &affect, int margin, int width)` retourne la position (hors de `margin` sur les bords) tel que le k-mer de longueur `width` soit minimal (maximal en fait). Idéalement on n'aimerait pas avoir de paramètre `width`, juste `minimize(const KmerAffect &affect, int margin)`.
Mais le code actuel est trivial, c'est du `O(n * width)`, et on utilise `tools.dna_to_int` (qui ne sert pas ailleurs, c'était une tentative il y a longtemps..., ~"dev-dead-code" ?). Si on se met à faire cela pour chaque read reconnue par SEG_METHOD_ONE (par exemple des CDs dans du RNA-seq #1801), c'est perdu.
Il y a sûrement des moyens de faire `O(n)`... voir #915 ?
@mikael-s, ne serait-ce pas possible, de coder simplement et efficacement `minimize`? Par exemple l'état final avec `affect` telle que son *adresse mémoire* soit minimale ? Si on joue avec cela, serait-ce reproductible d'un lancer à l'autre ? Si non reproductible, stocker un autre `int` dans chaque état d'Aho sur lequel on trie ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2652Aho : Séquences segmentées VD au lieu de VJ2018-07-19T19:50:13+02:00Mikaël SalsonAho : Séquences segmentées VD au lieu de VJLa séquence IGH suivante devrait être segmentée en IGH :
```
>IGHV4-31*03 0/TCCT/1 IGHD3-22 3/AGCG/8 IGHJ4 [IGH]
AGGTGCAGTGGAGCAGTCGGGCCCAGGACTGGTGAAGCCTTCACAGACCCTGTCCCTCACCTGCACTGTCTCTGGTGGTCCATAGCAGTGGTGGTTACTACTGGAGCTGGATCCGCCAGCACCC...La séquence IGH suivante devrait être segmentée en IGH :
```
>IGHV4-31*03 0/TCCT/1 IGHD3-22 3/AGCG/8 IGHJ4 [IGH]
AGGTGCAGTGGAGCAGTCGGGCCCAGGACTGGTGAAGCCTTCACAGACCCTGTCCCTCACCTGCACTGTCTCTGGTGGTCCATAGCAGTGGTGGTTACTACTGGAGCTGGATCCGCCAGCACCCAGGGAAGGGCCTGGAGTGGATTGGGTACATCTATTACAGTGGGAGCACCTATACAACCCGTCCCTCAAGAGTCGAGTTACCATATCAGTAGACACGTCTAAGAACCAGTTCTCCCTGAAGCTGAGCTCTGTGACTGCCGCGGACACGGCCGTGTATTACTGTGCGAGAGATCCTTATTACTATGATAGTAGTGGTTATTACAGCGGACTACTGGGGCCAGGAACCTGGTCACCGTCGTCCTGCAGGTAAG
```
Mais avec Aho ce n'est pas le cas. Car dans le cas où le germline est unexpected, il y a plus de k-mers Dh (les `+V` ci-dessous) que de k-mers Jh (les `+h` ci-dessous). Du coup la e-valeur est meilleure en faisant du V-D que du V-J !
```
# 258 + VJ 1 292 299 374 seed unexpected SEG_+ 3.376699e-37 0.000000e+00/3.376699e-37
_ _ _+H _ _+G _ _ _ _ _ _ _+H+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+A _
+H ?+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V+V+V ?+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _+L _ _ _
_ _ _ _ _+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _+h _ _ _ _ _ _ _ _ _ _ _ _+K-L _ _ _ _ _ _ _ _ _ _ _ _
```
@magiraud Une idée autre que celle de pénaliser arbitrairement le unexpected ?
Et pas sûr que #1878 arrange les choses là-dessus.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2653SEG_METHOD_ONE: comment comparer aux autres SEG_METHOD_* ?2023-10-26T15:49:32+02:00Mathieu GiraudSEG_METHOD_ONE: comment comparer aux autres SEG_METHOD_* ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2654Heuristique KmerSegmenter détectant directement VDJ (SEG_METHOD_5K43)2018-07-16T07:30:18+02:00Mathieu GiraudHeuristique KmerSegmenter détectant directement VDJ (SEG_METHOD_5K43)On en avait parlé il y a des années, je n'en retrouve pas trace.
Utiliité d'un affectanalyzer permettant aussi de détecter le 4 au milieu du 5 et 3 ?
Peut-être pas impossible de rester linéaire, en sommant sur un espace à deux dimension...On en avait parlé il y a des années, je n'en retrouve pas trace.
Utiliité d'un affectanalyzer permettant aussi de détecter le 4 au milieu du 5 et 3 ?
Peut-être pas impossible de rester linéaire, en sommant sur un espace à deux dimension. Mais bon, utilité ? ~"wont-fix" ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2655Comparer des e-valeurs venant de méthodes de segmentation différentes ?2023-10-26T15:49:32+02:00Mathieu GiraudComparer des e-valeurs venant de méthodes de segmentation différentes ?Titre initial : *Ne pas* comparer des e-valeurs venant de méthodes de segmentation différentes :-)
Nous avons plusieures tâches ou bugs passés, actuels et futurs liés à la comparaison de ~"bio-e-value" entre `SEG_METHOD_*` ou germlines ...Titre initial : *Ne pas* comparer des e-valeurs venant de méthodes de segmentation différentes :-)
Nous avons plusieures tâches ou bugs passés, actuels et futurs liés à la comparaison de ~"bio-e-value" entre `SEG_METHOD_*` ou germlines différentes :
- VD/VDJ : #2652, #1878
- xxx/*: #2596, hack 5bc753eea, #2651, hack 951facdc
- ONE/* : #2653
Discussion avec @mikael-s il y a quelques jours : une p-valeur d'une séquence est la probabilité qu'elle sorte, étant donné un modèle. Mais là... on a des modèles différents, et aucune connaissance sur ces modèles. Comparer n'est donc pas pertinent.
Supposons une read honnête, V^20 D^30 J^5. Quoi que l'on pénalise, ce sera ici toujours plus beau en VD qu'en VJ. Et #1878 n'arrange pas.
Nous devons peut-être changer complètement de point de vue. Si le filtre de e-valeur est de 10^-6, et que VD et VJ passent ce filtre (1), je veux exactement avoir la réponse la plus complète : "la séquence est VJ" (voire V(D)J après `Fine`, (2)). Le fait que VD puisse être à 10^-100 et VJ à 10^-10 ne change rien au fait que la réponse complète soit vraie "avec une erreur d'au plus 10^-6" (et même 10^-10 ici). (Et... vous savez quoi ? On peut dire avec e-valeur quasi nulle que "il y a des séquences humaines dedans", mais cela n'ajouterait pas grand chose.)
(1) VD et VJ *compatibles*, comme VhDh et VhJh. S'ils ne sont pas compatibles, c'est une autre histoire, voir ci-dessous.
(2) On pourrait aussi avoir une `Kmer`-heuristique détectant V-D-J, #2654, mais pareil, rien ne dit que les e-valeurs soient comparables avec les autres.
Une proposition serait donc **d'arrêter de choisir le locus avec la meilleure e-valeur**, et d'avoir plutôt une situation évoquée dans le passée (mais jamais implémentée, ou peut-être en dur au tout début quand on a fait `IGH+`) avec un ordre partiel `SEG_METHOD_ONE < xxx (MAX_12, MAX_1U) < IGH+ < IGH`. Entre deux germlines passant le filtre de e-valeur et comparables dans l'ordre partiel, on prend la germline la plus complète. Entre deux non-comparables, on prend la meilleure e-value (3). (À voir en pratique. On définit des `stage`, 0 pour les complets, 1 pour les `+`, 2 pour `xxx`, 3 pour `ONE`... ? on utilise un `after` pour encoder la relation ?)
(3) Et encore... Si j'ai TRB et IGH qui passent tous deux à 10^-6, cela veut bien dire que, avec très forte probabilité, la séquence est ambiguë. Les mettre plutôt en `AMBIGUOUS` ?
- Cette définition est encore un chouia ambiguë: si on a `IGH+` 10^-30, `IGH` 10^-10, `TRG` 10^-10, que choisir ?
- Et qu'est-ce que cela donne pour les `TRD+` avec Dd2- ... ?
Cela peut sembler un retour en arrière par rapport à #1499/ae1ac525 (printemps 2015)... mais non: nous sommes contents de nos calculs de e-valeurs (et bien plus sûrs qu'en 2015) pour dire si une recombinaison est signifiante ou pas. Each cell counts.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2656Central region : couper en deux pour ne pas pénaliser deux fois2019-03-14T16:17:37+01:00Mathieu GiraudCentral region : couper en deux pour ne pas pénaliser deux foisDans 2e23e720, j'avais écrit :
> A more exact option could have been to use something like
> (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
> The selected option should anyway improve the estimation...Dans 2e23e720, j'avais écrit :
> A more exact option could have been to use something like
> (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
> The selected option should anyway improve the estimation in most of the cases.
Je pense que ce qui me chiffonait pour la symétrie, c'était qu'doit être invariant aux reads rev-compés. Prendre la position (first_pos_max + last_pos_max) / 2 n'est pas reproductible. Mais il suffit de dépasser d'un nucléotide quand c'est impair, et plus de soucis. On comptera dans ce cas une position deux fois, mais ce sera mieux que toute la zone centrale comptée deux fois.
Voir aussi #1878.Algo -- ImportantMathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2657SEG_METHOD_34_NOT52018-07-13T16:24:48+02:00Mathieu GiraudSEG_METHOD_34_NOT5Une possibilité (pas forcément souhaitable) pour #2655 : en cas de VD, regarder derrière s'il y a des k-mers J, et faire le calcul qu'il faut pour dire qu'il ne devrait pas en avoir.Une possibilité (pas forcément souhaitable) pour #2655 : en cas de VD, regarder derrière s'il y a des k-mers J, et faire le calcul qu'il faut pour dire qu'il ne devrait pas en avoir.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2658VD/VJ : Changer d'avis au moment du Fine2018-07-06T12:39:42+02:00Mathieu GiraudVD/VJ : Changer d'avis au moment du FineIndépendamment des discussions de #2655.
Lors de la deuxième passe, on réévalue chaque read représentative pour le meilleur locus, et on lance le Fine dessus. Mais on a le temps... on pourrait tout à fait lancer deux Fine et prendre le ...Indépendamment des discussions de #2655.
Lors de la deuxième passe, on réévalue chaque read représentative pour le meilleur locus, et on lance le Fine dessus. Mais on a le temps... on pourrait tout à fait lancer deux Fine et prendre le meilleur, l'estimation de ~"bio-e-value" étant supposée plus précise lors du Fine.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2666e-valeur de SEG_METHOD_MAX1U et index_load de AFFECT_UNKNOWN2017-09-25T10:31:56+02:00Mathieu Giraude-valeur de SEG_METHOD_MAX1U et index_load de AFFECT_UNKNOWNLe test de `chimera-fake-half.should-get` qui ne passe pas dans !79 (alors que !79 est bon dans l'esprit) révèle que les e-valeurs de `SEG_METHOD_MAX1U` sont mal calculées (et donc on en a très peu souvent).
Séquence :
```
>TRGV1*01--cg...Le test de `chimera-fake-half.should-get` qui ne passe pas dans !79 (alors que !79 est bon dans l'esprit) révèle que les e-valeurs de `SEG_METHOD_MAX1U` sont mal calculées (et donc on en a très peu souvent).
Séquence :
```
>TRGV1*01--cgcg
tcttccaacttggaagggagaacgaagtcagtcaccaggctgactgggtcatctgctgaa
cgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcg
```
Affects :
```
# 6 - VJ 1 59 88 100 seed IGK SEG_- 2.526646e+01 2.452207e+01/7.443986e-01 _ _-k ? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+K _ _ _ _ _ _ _ _ _ _ _ _-K-K-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
# 49 ! seed TRG UNSEG ambiguous 9.600000e+01 2.122587e-92/9.600000e+01+G+G+G ?+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
IGK par chance (avec !79, et encore, e-value pourrie), mais ici c'est clairement un MAX1U qui doit passer (et plus que SEG_METHOD_ONE #1724).
Voir aussi #2655.https://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/2820Détecter les primers dimers2023-06-28T18:28:32+02:00Mathieu GiraudDétecter les primers dimersMentionné par Aurélie ~"PAR-Debré" : les nouvelles amorces ~"ec-ngs" génèrent plus de dimers.
À controller.Mentionné par Aurélie ~"PAR-Debré" : les nouvelles amorces ~"ec-ngs" génèrent plus de dimers.
À controller.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/2884Mieux documenter les causes de non segmentation "UNSEG"2017-11-29T13:16:41+01:00Tatiana RocherMieux documenter les causes de non segmentation "UNSEG"Les décrire plus clairement dans la doc ou faire des bulles contextuelles au passage de la souris ?Les décrire plus clairement dans la doc ou faire des bulles contextuelles au passage de la souris ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2909Recombinaison atypique : grande insertion dans le V2018-01-19T10:04:56+01:00Mathieu GiraudRecombinaison atypique : grande insertion dans le V@Anne@Annehttps://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/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/2915Ne mettre que le upstream / amont, et pas le gène D, pour être sûr du IGH+2017-11-29T13:26:07+01:00Mathieu GiraudNe mettre que le upstream / amont, et pas le gène D, pour être sûr du IGH+Proposition baroque.Proposition baroque.https://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/1266Taille de fenêtre en IGH : cas où 50 ne suffit pas ?2018-11-20T09:18:26+01:00Vidjil TeamTaille de fenêtre en IGH : cas où 50 ne suffit pas ?La taille des fenêtres en multi-système est globale. À rajouter dans germlines et voir les implications dans windowExtractor ou la représentative.
***
On remet donc le doigt dessus.
C'est embêtant si on est amené à comparer des données p...La taille des fenêtres en multi-système est globale. À rajouter dans germlines et voir les implications dans windowExtractor ou la représentative.
***
On remet donc le doigt dessus.
C'est embêtant si on est amené à comparer des données produites par des configs différentes.
Au minimum : rajouter dans germline, pour qu'en multi IGH soit aussi à 60.
Ou sinon, grande homogénéisation, tout le monde à 40, 50, ou 60.
***
On pourrait décider de cela avant 2015.02.
Je penche pour la grande homogénéisation.
***
à décider pour 2015.02
***
ok, on voit cela pour 2015.04
***
plus tard...
***
Au fait, j'ai bien vu hier que la propagande officielle indique "50" partout :)
***
2d80348, 50 pour tout le monde.
Il n'y a "plus" que la transition server à voir, autre tâche.
***
Euh… c'est pas un peu dangereux de mettre ça sur master alors qu'on n'a pas de moyen de faire la transition ? Ça veut dire qu'il ne faut surtout pas changer la version de vidjil sur rbx
***
rbx est sur 2015.04, sur un version stable, oui il faudra faire attention à ne pas changer tout de suite... master sert à cela :)
***
au passage, master est désynchronisé avec rbx depuis déjà quelque temps , surtout avec le -e 1.0 par défaut mais aussi le -t 100
***
50bp, est-ce bien raisonnable ? Oui je sais on n'a plus ou moins tranché mais sans vraiment avoir de recul sur des données.
Mais quand je vois ça : http://rbx.vidjil.org/browser/?patient=481&config=26 (clone à 1,5% et afficher la fenêtre), si le D était un peu plus grand ou moins grignoté, ça fait un peu peur…
***
Par contre un exemple qui fait très peur, sur le même jeu de données, c'est le clone à 0,671% : on a du D, du J et un seul nucléotide dans le N.
***
Dans ce cas on pourrait passer à 60... mais cela ne fait que 5 de plus de cahque côté, on va toujours avoir des cas limite même à 60.
***
Mmmm…. on a déjà eu du mal à prendre cette décision 50 (n’oublions pas que c’est 40 en ce moment). Par contre, on pourrait imaginer un process qui met un warning sur certains clones. En sortie du FineSegmenter, on devrait savoir si on est dans un cas limite ou non.
Et ce problème est (dans certains cas) indépendant de la taille de la fenêtre : Si on a un V/J collé avec 0 zone de N, ce sera très limite même avec une fenêtre de taille 100 :-) On doit mettre un gros warning dessus, et permettre de revenir sur les reads.
***
N'oublions pas que c'est 60 en IGH pour l'instant… (4^5 = 1024).
Ce sont des cas que j'ai vus sans trop chercher, parmi les 100 clones du jeu de données que j'avais en face de moi. C'est ça qui fait peur. Évidemment il y aura toujours des cas limites, mais là je n'ai pas épluché tous nos résultats avec de l'IGH pour tomber sur LE cas limite.
***
Exemple 0481 mis dans notable.
Pour cet exemple, on est finalement sauvé (euh ? une délétion au troisième nucl de J) par ce que voit IMGT.
Mais cela n'enlève pas le problème, on doit alerter si faible spécificité de la fenêtre (tâche dédiée).
Être à 60 permet d'avoir 4^5... si on récupère bien du N sur un des côtés, ce qui est loin d'être sûr.
Maintenant, reste la question du -w par défaut.
Les utilisateurs en multi doivent avoir la même qualité que ceux en IGH seul, et la qualité doit être au top pour tout le monde.
On teste le -w 50 depuis longtemps en multi... et... les tests passent.
***
Revu une trentaine de clones des utilisateurs IGH (Florian, Eva, Jack). Aucun soucis pour le -w 50. Mais plusieurs soucis pour certaines spécificités avec zéro N qu'un -w 60 ne résoud pas.
Tranché, c'est douloureux. Je maintiens "The default value (=-w 50=) was selected to ensure a high-quality clone gathering."
Mise en prod server : si on hésite (non, il ne faut pas...), on pourra mettre -w 60 pour la config IGH.
Tâche renommé, le pb est IGH.
***
La nouvelle tâche S22 m'a fait encore plus peur... mais on est bien sur autre chose que les discussions 50/60.
***
(sur rbx, IGH est encore en -w 60, tout le reste en -w 50 par défaut, sauf les configs [old])
***
@magiraud @mikael-shttps://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/1581Tailles de fenêtres différentes selon les locus2018-04-10T12:29:07+02:00Vidjil TeamTailles de fenêtres différentes selon les locusMikaël : "pourquoi ne pas mettre la taille de la fenêtre dans Germline
et avoir des tailles différentes selon les germlines ? Je ne vois pas
pourquoi TRG et IGH (par exemple) devraient nécessairement avoir la même
taille de fenêtre."
**...Mikaël : "pourquoi ne pas mettre la taille de la fenêtre dans Germline
et avoir des tailles différentes selon les germlines ? Je ne vois pas
pourquoi TRG et IGH (par exemple) devraient nécessairement avoir la même
taille de fenêtre."
***
Ce serait un rétro-pédalage depuis le -w 50 (mais c'est possible, et plus pertinent de changer selon la germline que selon l'option multi ou pas)
Les raisons (peut-être mauvaises) qui avaient poussé à un -w unique :
- on souhaite pouvoir comparer IGH et IGH+
- et TRD avec TRD+, avec VdJa, avec TRA -> par transitivité TRA avec TRD, alors que VJ et VDJ
mais est-ce vraiment important ? deux fenêtres IGH et IGH+ n'ont de toute façon rien à voir ensemble...
***
... et si on resplite un clone, on aura des tailles de fenêtres encore différentes à l'intérieur d'un même locus...
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1604Le calcul de la e-valeur devrait prendre en compte le -t2018-04-10T12:28:09+02:00Vidjil TeamLe calcul de la e-valeur devrait prendre en compte le -tSi on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers...Si on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers V (et même x - s + 1) par exemple.
***
ok
***
Tout doit se faire dans kmerstore.h
- en entrée, les insert() reçoivent et utilisent keep_only : à stocker
- en sortie, getProbabilityAtLeastOrAbove()
***
68fef14. Quitte à prendre en compte le -t, autant être plus générique : si on n'a inséré que des choses de 200 ou moins, le calcul devrait prendre en compte ces 200.
Pour faire le changement souhaité, il faut maintenant faire quelque chose du type :
int n_max = atMostMaxSizeIndexing(length) - getS() + 1;
dans getProbabilityAtLeastOrAbove()
Mais j'ai maintenant des doutes : veut-on remplacer vraiment n par n_max dans toute cette fonction ? Est-ce que le index_load n'a pas déjà pris cela en compte ?
Bref, je te laisse voir :-)
***
Dans une séquence de longueur 200, même si on n'a inséré que des séquences de longueur 100 :
- la proba d'avoir exactement 18 k-mers est toujours la même ?
- et celle d'avoir 150 k-mers ? Elle est faible... mais pas nulle (et d'ailleurs, on trouvera des séquences chimériques avec cela). Est-ce que le but est de mettre cela à zéro ?
ou bien est-ce que cela doit être fait finalement dans affectanalyser.cpp:160 ? Qu'est-ce que cela signifie ?
***
La proba d'avoir 18 k-mers par hasard est plus élevée dans une séquence de longueur 200 que de longueur 100. De manière générale, il existe au moins une valeur t pour laquelle t k-mers dans 100nt est significatif mais pas t dans 200nt.
***
ok pour la longueur de la séquence observée, mais est-ce que cela dépend de la longueur de la séquence insérée ? (Cette dépendence ne serait-elle pas déjà dans le index_load ?)
En tout cas, si tu penses avoir la formule, vas-y :-)
***
Je pense que je ne comprends pas ce que tu veux dire :)
Par exemple pour l'instant on calcule la probabilité à gauche sur toute la longueur jusqu'à first_pos_max. Ce qui est très bien puisque cela évite de prendre en compte le N (dans lequel on ne s'attend pas à avoir de k-mers). Là c'est la même chose : on ne veut pas prendre en compte le début du V puisqu'on ne s'attend pas à avoir de k-mers dedans.
Autrement dit, entre un read qui contient 100nt de V et un read qui contient 300nt du même V, on ne devrait pas avoir une e-valeur différente (avec -t 100).
***
Après réflexion collective, un segment de 200, même avec -t 100, contient aussi un certain nb de kmers "aléatoires" dans les 100 premiers nt, qui fait que le calcul de la e-valeur serait tout de même bon (à peu près).
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1586Recombinaisons TRDD/TRAJ2017-12-04T14:55:54+01:00Vidjil TeamRecombinaisons TRDD/TRAJDans le tableau de Yann tous les gros problèmes semblent résolus sauf un : une recombinaison TRDD/TRAJ (ou même TRDD2/TRDD3/TRAJ). Elle était trouvée par chance en TRDD2/TRDD3 auparavant, mais cela ne résiste pas à la e-valeur (le TRDD3 ...Dans le tableau de Yann tous les gros problèmes semblent résolus sauf un : une recombinaison TRDD/TRAJ (ou même TRDD2/TRDD3/TRAJ). Elle était trouvée par chance en TRDD2/TRDD3 auparavant, mais cela ne résiste pas à la e-valeur (le TRDD3 est grignoté comme il est recombiné et donc il n'y a pas assez de k-mers pour passer le seuil). Du coup on ne trouve plus un clone qu'on trouvait auparavant (mais qu'on classait mal).
Met-on cela dans le germline VdJa ? Sauf qu'il s'appelle VdJa Et là on est sur du DdJa… Sauf que le VdJa c'est du VDJ et là on cherche du DJ.
***
Ici il n'y est plus : http://rbx.vidjil.org/browser/index.html?patient=443&config=25 mais là il y était : http://rbx.vidjil.org/browser/index.html?patient=443&config=11
***
J'imagine que ce sera D avec upstream ?
***
Dans TRD+, on a regroupé plusieurs cas sur le locus TRD.
On pourrait donc regrouper plusieurs cas sur le locus TRA/TRD dans VdJa.
(quitte à renommer, TRA/D (aïe, cinq caractères) ? TRA+ ? On peut mettre déjà dans VdJa, et réfléchir ensuite.)
IMGT appelle cela "Human TRA/TRD locus" : http://www.imgt.org/LocusView/docs/humanTRATRDlocus.pl
***
Pour le TRDD_upstream… pourquoi pas ou en DD2-01, ça dépend de ce qui peut être recombiné.
***
euh... est-ce bien notable/0443-lil-LEQ--DdJa.fa ?
Je ne m'y retrouve pas.
***
ea66e02 pour la gestion TRDD/TRAJ et 07cb337 pour les tests
***
Marqué comme fait.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1549Utiliser pour de vrai les séquences upstream/downstream2017-12-04T14:55:54+01:00Vidjil TeamUtiliser pour de vrai les séquences upstream/downstreamIl y a des données d'Alice avec un D5-J5 qui a 12 délétions → il en reste 8.
Il faut mettre à jour les germlines (sur Vidjil-data), et mettre à jour les tests et le germline.cpp qui utilise certaines séquences.
***
Fait pour DH-JH (9e16...Il y a des données d'Alice avec un D5-J5 qui a 12 délétions → il en reste 8.
Il faut mettre à jour les germlines (sur Vidjil-data), et mettre à jour les tests et le germline.cpp qui utilise certaines séquences.
***
Fait pour DH-JH (9e16fee5). Met-on les J downstream pour tout le monde ?
***
fait pour plusieurs germlines...
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1687Classes des Ig en RNA-Seq2017-12-04T14:55:59+01:00Vidjil TeamClasses des Ig en RNA-SeqOn ne va pas devenir un outil générique de mapping...
... néanmoins, est-ce que cela ne vaudrait pas le coup de détecter qui pourraient arriver en RNA-Seq ? (voire en capture, cela dépend du protocole)
Par exemple au moins les CD3, CD4...On ne va pas devenir un outil générique de mapping...
... néanmoins, est-ce que cela ne vaudrait pas le coup de détecter qui pourraient arriver en RNA-Seq ? (voire en capture, cela dépend du protocole)
Par exemple au moins les CD3, CD4, CD8, CD19, CD45RA/CD45RO... ou d'autres...
***
Et les régions constantes pour détecter la classe d'Ig
https://en.wikipedia.org/wiki/Immunoglobulin_class_switching
***
Sarah, 26 oct. 2015 :
> Je voudrais savoir s’il est possible de connaitre la chaine lourde utilisée (IgM ou autre) à partir des analyses faites sur vidjil ?
***
Dans IMGT/GENE-DB, on a :
1 4 IGHA1
3 11 IGHA2
4 18 IGHE
4 18 IGHG1
6 28 IGHG2
19 130 IGHG3
4 15 IGHG4
1 6 IGHGP
3 18 IGHM
Lecture: IGHM, 3 alleles / C-GENE-UNIT, (IGHM*01, *02, *03), mais au total 18 exons (selon les classes, CH1-4, H1-2, M1-2, entre 35 et 400 nt).
***
Attention ! IGHD*01 et IGHD*02 sont des chaînes lourdes constantes IgD, au contraire des gènes habituels IGHD1-1*01 & co.
***
Class switching : mentionné par Cristina Jiminez lors de son talk ESLHO
***
ping
***
Classes : Sarah est extrêmement intéressée.
La pseudo-germline IgJC (mail du 30 octobre, et branche ighc, rebasée à l'instant) lui convient parfaitement ("cela évitera de refaire à Rennes 150 PCRs" :-). Bref, mettre la détection des classes avant notre audio du 25 février.
***
(autres choses que les classes: bougé dans nouvelle tâche)
***
Config 37, avec /home/vidjil/custom-germlines/germlines-classes.data
+ branche ighc (pas utilisée pour l'instant, juste pour vérifier que tout passe, sauf à la marge -2/-4). Lancé sur une dizaine de fichiers de Sarah, on lui fera coucou lundi.
***
@nobody @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1673Valeur de -m par défaut pas très claire2017-12-04T14:55:59+01:00Vidjil TeamValeur de -m par défaut pas très claireDoc: "Note that it is even possible to set `-m -10`
(meaning that V and J could overlap 10 bp). This is the default for VJ recombinations."
En fait c'est le cas... sauf en cas de `-g germline`, ou c'est 0 pour tous.
On retrouve l...Doc: "Note that it is even possible to set `-m -10`
(meaning that V and J could overlap 10 bp). This is the default for VJ recombinations."
En fait c'est le cas... sauf en cas de `-g germline`, ou c'est 0 pour tous.
On retrouve la même ambiguité que ce qu'on avait pour les fenêtres.
Solution : si on a envie de conserver des réglages différents, les mettre dans "parameters" de germline.data.
***
@magiraud @mikael-sAlgo 2017.07https://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/2968Classes pour les méthodes de segmentation2022-02-01T10:30:14+01:00Mathieu GiraudClasses pour les méthodes de segmentationDiscuté avec @mikael-s il y a déjà un certain temps : "segment.cpp a plein de `if`, on commence a ne plus y voir grand chose."Discuté avec @mikael-s il y a déjà un certain temps : "segment.cpp a plein de `if`, on commence a ne plus y voir grand chose."Algo 2022.04Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2985Améliorer la fonction de hash2020-02-21T21:18:24+01:00Mathieu GiraudAméliorer la fonction de hash@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/76#note_68968 :
> Généralement la minimisation ne se fait pas sur l'ordre lexico (car cela favorise AAAA…, ou des régions de faible complexité riches en A, qui ne sont pas ...@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/76#note_68968 :
> Généralement la minimisation ne se fait pas sur l'ordre lexico (car cela favorise AAAA…, ou des régions de faible complexité riches en A, qui ne sont pas les séquences ADN les plus spécifiques), mais en utilisant une fonction de hash.Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2987Shorter / shifted w : autoriser de plus grands shifts, mais jusqu'à où ?2018-06-27T18:53:30+02:00Mathieu GiraudShorter / shifted w : autoriser de plus grands shifts, mais jusqu'à où ?Suite à #2913/#1580.
Si je ne trompe pas, le shift peut être d'au plus `-5`/`+5`, tandis que le short peut aller beaucoup plus loin. Autant cela ne me gène pas de raccourcir quand on n'a pas le choix (reads courtes des deux côtés), auta...Suite à #2913/#1580.
Si je ne trompe pas, le shift peut être d'au plus `-5`/`+5`, tandis que le short peut aller beaucoup plus loin. Autant cela ne me gène pas de raccourcir quand on n'a pas le choix (reads courtes des deux côtés), autant je pense qu'on pourrait bénéficier de plus de contenu à gauche quand on le peut.
Spontanément, j'aimerais mettre :
- les shifts testés à `{-1, 1, -2, 2, -3, 3, -4, 4}`, ou au moins `{-1, 1, -2, 2}`
- et/ou une valeur de `DEFAULT_WINDOW_SHIFT` à `10` ou `15`.
Je ne sais pas si on peut arriver à quelque chose de plus rationel. En tout cas :
- un `w50/-10` serait mieux qu'un `w45/-5`
- un `w50/-20` serait mieux qu'un `w35/-5` (?)
- par contre on ne doit pas faire `w50/-30` à la place d'un `w25/-5` qui serait sous le `MINIMAL_WINDOW_LENGTH`
Pour info, les shifts sur `stanford-w100`:
```
913 w100/-5
197 w95/-5
163 w90/-5
63 w85/-5
29 w80/-5
2 w75/-5
1 w60/-5
```Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2993SEG_METHOD_543C : ne pas prendre en compte C dans la p-valeur du J2018-07-16T07:30:18+02:00Mathieu GiraudSEG_METHOD_543C : ne pas prendre en compte C dans la p-valeur du JPour résoudre #2964, discussion avec @mikael-s
- stocker dans les index les gènes constants (36 KB en IGH)
- point central: lorsqu'on a `VVV_DD_JJJJ_CCCC`, ne pas prendre en compte la zone `CCCC` pour la p-valeur du J
- puis éventu...Pour résoudre #2964, discussion avec @mikael-s
- stocker dans les index les gènes constants (36 KB en IGH)
- point central: lorsqu'on a `VVV_DD_JJJJ_CCCC`, ne pas prendre en compte la zone `CCCC` pour la p-valeur du J
- puis éventuellement #2994/#2995
Si les gènes constants sont trop gros, un pis-aller serait de ne pas considérer, dans `VVV_DD_JJJJ______`, la zone vide à droite du J. Mais c'est potentiellement dangereux.
Fait-on d'un même coup quelque chose `SEG_METHOD_C543C`, configurable ? Ou on a le temps de voir venir ?
Demande en tout cas d'abord #2968.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2996SEG_METHOD_ONE et revcomp2018-07-13T16:08:46+02:00Mathieu GiraudSEG_METHOD_ONE et revcompPour l'instant le revcomp n'est pas géré ?
- évoqué avec @mikael-s : le faire au niveau du hash de minimisation ?
- peut-être plus robuste de considérer les k-mers de l'index... à moins que ce ne soit déjà fait ? `reversed = (nb_strand...Pour l'instant le revcomp n'est pas géré ?
- évoqué avec @mikael-s : le faire au niveau du hash de minimisation ?
- peut-être plus robuste de considérer les k-mers de l'index... à moins que ce ne soit déjà fait ? `reversed = (nb_strand[0] > nb_strand[1])` est aussi calculé pour `SEG_METHOD_ONE`... est-ce pris en compte ?Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3146UNSEG only J curieux sur une affectation particulière2018-07-12T18:26:07+02:00Mathieu GiraudUNSEG only J curieux sur une affectation particulièreSéquence de #3145 (ici je ne parle pas de la séquence, uniquement de ~"cpp-heuristic").
On est en DJ, mais bon, on a deux affectations `+b` et `+B`.
Avant :
```
# 119 ! seed TRB+ UNSEG ambiguous 1.023222e-110 1.116486e-116/1.023221...Séquence de #3145 (ici je ne parle pas de la séquence, uniquement de ~"cpp-heuristic").
On est en DJ, mais bon, on a deux affectations `+b` et `+B`.
Avant :
```
# 119 ! seed TRB+ UNSEG ambiguous 1.023222e-110 1.116486e-116/1.023221e-110 _ _ _ _ _ _ _ _ _ _+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Vu l'affectation, `ambiguous` est la bonne réponse.
Avec !148 (mais ma question ne concerne pas !148) :
```
# 175 ! seed TRB+ UNSEG only J/3' 1.500000e+10 1.500000e+10/0.000000e+00 _ _ _ _ _ _ _ _ _ _+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b _ _ _ _ _ _+b _ _ _ _ _ _+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B+B _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b+b _ _ _ _ _ _+b _ _ _ _ _ _+b _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Je ne comprends pas pourquoi on a désormais `UNSEG only J/3'`. @mikael-s ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3296L'heuristique n'est pas symétrique lorsqu'il y a cheuvauchement entre affecta...2018-07-12T18:26:07+02:00Mikaël SalsonL'heuristique n'est pas symétrique lorsqu'il y a cheuvauchement entre affectations before et after.Dans !148 un test sur les locus échoue mais ce n'est pas imputable à la MR (voir le job en question : https://gitlab.inria.fr/vidjil/vidjil/-/jobs/117114).
La séquence n'est pas segmentée dans le sens + mais elle est segmentée en xxx da...Dans !148 un test sur les locus échoue mais ce n'est pas imputable à la MR (voir le job en question : https://gitlab.inria.fr/vidjil/vidjil/-/jobs/117114).
La séquence n'est pas segmentée dans le sens + mais elle est segmentée en xxx dans le sens -, ce qui n'est pas forcément choquant. En revanche ce qui est choquant c'est que la séquence ne soit pas segmentée de la même manière dans les deux sens.
Ce type de cas se produit lorsqu'il y a chevauchement entre la fin d'une affectation `before` et le début d'une affectation `after` alors qu'on a atteint la valeur maximale (celle qui sert à déterminer le point de jonction). On a alors un plateau de valeurs maximales.
Le problème c'est que dans un sens les affectations `before` rencontrées sur ce plateau seront comptées comme « à gauche ». Ensuite le ratio entre le nombre à gauche et le nombre à droite risque d'être trop élevé et risque de provoquer une absence de segmentation.Algo 2018.08Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3357Détection de séquences VJ particulières2018-08-30T17:47:05+02:00Mikaël SalsonDétection de séquences VJ particulièresPour #2232, mais cela peut aussi être dans d'autres situations comme avec des dimers d'amorces, on a des clones qui ressortent et qui ne sont pas significatifs.
On aimerait leur mettre des warnings (#2247).
Une solution est de coder en...Pour #2232, mais cela peut aussi être dans d'autres situations comme avec des dimers d'amorces, on a des clones qui ressortent et qui ne sont pas significatifs.
On aimerait leur mettre des warnings (#2247).
Une solution est de coder en dur la valeur des recombinaisons et de lever un warning lorsqu'on rencontre cette valeur-là. Une autre solution serait de stocker les séquences elle-mêmes et de détecter les fenêtres dans ces séquences. Toutes les séquences partageant cette fenêtre seront clusterisées avec ce qui nous permet ensuite de faire ce qu'on veut.
Cela éviterait de stocker des choses plus ou moins robustes en dur.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3370Une séquence passe en unexpected au lieu d'IGH2018-07-13T16:08:46+02:00Mikaël SalsonUne séquence passe en unexpected au lieu d'IGHCe n'est pas extrêmement choquant vue la séquence.
Il s'agit de la séquence `#1347 vh2` de `gosh-igh.should-vdj.fa`. Elle contient un réarrangement VDJ normal mais à la fin elle a aussi du V dans le sens négatif.
Auparavant la séquence...Ce n'est pas extrêmement choquant vue la séquence.
Il s'agit de la séquence `#1347 vh2` de `gosh-igh.should-vdj.fa`. Elle contient un réarrangement VDJ normal mais à la fin elle a aussi du V dans le sens négatif.
Auparavant la séquence était vue comme une séquence VDJ normale mais avec la mise à jour des germlines, on a plus de k-mers reconnus comme V- à la fin de la séquence ce qui donne une meilleure e-valeur à la recombinaison inattendue par rapport à la VDJ classique.
Voici les affectations :
```
_ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _
_ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H
+H+H+H+H+H+H+H+H+H _ _+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _+h _ _ _ _ _ _+h+h+h
+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
```
Est-on choqué que ce soit unexpected ou non ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3376SEG_METHOD_123: Détecter les recombinaisons à trois, même si elles sont vues ...2018-07-16T19:33:46+02:00Mathieu GiraudSEG_METHOD_123: Détecter les recombinaisons à trois, même si elles sont vues comme VJ normalEn généralisant #3370.
Les séquences avec trois affectations (suffisament présentes) ABC, où ABC n'est pas un VDJ attendu, devraient être affichées comme unexpected... même si le AB, le AC ou le BC peuvent faire qu'elles soient vues com...En généralisant #3370.
Les séquences avec trois affectations (suffisament présentes) ABC, où ABC n'est pas un VDJ attendu, devraient être affichées comme unexpected... même si le AB, le AC ou le BC peuvent faire qu'elles soient vues comme VJ "normal". Ce sont en effet des séquences très particulières (artefact ? bio ?) et on doit attirer l'attention dessus.
Une nouvelle `SEG_METHOD_123` ? Nécessite #2968 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3385Liste des `SEG_METHOD_*`2021-02-10T20:17:07+01:00Mathieu GiraudListe des `SEG_METHOD_*`Sans parler d'algo trop précis ni de technique (#3377, #2968, #2655)...
Quelque part un inventaire de situations bios.
- (no implémenté) `_ZERO`: Rien de connu `(_)`, mais significativement rien (`_` suffisament long, ce n'est pas exa...Sans parler d'algo trop précis ni de technique (#3377, #2968, #2655)...
Quelque part un inventaire de situations bios.
- (no implémenté) `_ZERO`: Rien de connu `(_)`, mais significativement rien (`_` suffisament long, ce n'est pas exactement comme `UNSEG_TOO_FEW_ZERO`
- `_ONE`: Colinéaire génome `(*, 1, *)` (dans cet esprit `(1)` serait souhaitable ?).
- `_53`: Recombinaison VJ, ou autre,`(5, *, 3)`.
- Notons qu'il n'y a pas de `*` sur le côté, ce qui a nécessité J+down #3008
- Cela suggère d'ailleurs (non implémenté) `_543C` #2993
- Le `*` pose #2656 #1878
- `_12`: Recombinaison inattendue xxx, `(1, *, 2)`, cas particulier de `(5, *, 3)`.
- `_1U`: Recombinaison inattendue / translocation xxx, `(1, _)`, avec `_` "sufisament long"
- `_543`: Recombinaison VDJ `(5, *, 4+, *, 3)` Le `4+` est regardé uniquement par le FineSegmenter. Il est optionnel.
- (non implémenté) `_5K43`: Recombinaison VDJ `(5, *, 4+, *, 3)` Le `4+` (ou déjà un `4?`) serait aussi considéré par le KmerSegmenter #2654
- (non implémenté) `_u543d`: Recombinaison VDJ `(up, 5, *, 4+, *, 3, down)` avec up/down stream indexé séparément #XXXX (et aussi #2138)
- (non implémenté) `_123`: Cas complexes `(*, 1, *, 2, *, 3, *)` #3376https://gitlab.inria.fr/vidjil/vidjil/-/issues/3386Indexer séparément, mais à la suite, les up/down-stream2018-07-16T07:31:14+02:00Mathieu GiraudIndexer séparément, mais à la suite, les up/down-streamNous aimons le up/down-stream. Nous avons fait #3008 pour J+down, et, précédemment, la même chose Dd2/Dd3.
Mais idéalement, on devrait distinguer des situations comme `JJJJJdddd`, `JJJJJCCCCC`, `JJJJJ----`. Et, avec des reads non-longu...Nous aimons le up/down-stream. Nous avons fait #3008 pour J+down, et, précédemment, la même chose Dd2/Dd3.
Mais idéalement, on devrait distinguer des situations comme `JJJJJdddd`, `JJJJJCCCCC`, `JJJJJ----`. Et, avec des reads non-longues, `JJJJJdddddCCCC` ne devrait pas arriver.
Certes, avoir d'un côté `J.fa` et de l'autre `J+down.fa` fournit une solution, idem pour Dd2/Dd3, couplé avec des entrées dans `germline.h` différentes (et des méthodes de segmentation différentes), mais on sent la recopie d'informations. Et même en situation "normale" `JJJJJdddd`, on aimerait #3147, mais là cela relève plutôt du FineSegmenter.
Serait-ce possible d'avoir un mécanisme où l'on indexe directement `(J + down)`, avec un kmer `down` déclenché
dès le premier nucléotide de `down` ? Avec Aho, c'est peut-être encore plus simple à implémenter ?
Cela demanderait aussi d'adapter les méthodes de segmentation... ou possiblement #3377.
Ping #2138.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3388Agrandir la taille des graines pour limiter les faux positifs2019-11-23T06:51:30+01:00Mikaël SalsonAgrandir la taille des graines pour limiter les faux positifsDans vdj#693 on se rend compte que certains faux positifs peuvent gêner la segmentation. Ces faux positifs sont dus à une taille de graine faible en TRA+D (c'est un `-k 9`).
Historiquement on a cette petite taille car les TRDD sont cour...Dans vdj#693 on se rend compte que certains faux positifs peuvent gêner la segmentation. Ces faux positifs sont dus à une taille de graine faible en TRA+D (c'est un `-k 9`).
Historiquement on a cette petite taille car les TRDD sont courts. Mais maintenant qu'on utilise les régions amont et aval cette raison n'a plus de sens.
Il serait bon de remonter cette valeur à `-s 10s`, voire plus, sans forcément attendre #1364.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3584Germline unexpected : comment remonter à la bonne germline ?2024-03-27T16:43:37+01:00Mikaël SalsonGermline unexpected : comment remonter à la bonne germline ?La fonction `Germline::override_rep5_rep3_from_labels` permet normalement de faire cela. Elle est utilisée lorsqu'on est en unexpected afin d'aligner la séquence contre les bons répertoires.
Les répertoires corrects sont trouvés grâce a...La fonction `Germline::override_rep5_rep3_from_labels` permet normalement de faire cela. Elle est utilisée lorsqu'on est en unexpected afin d'aligner la séquence contre les bons répertoires.
Les répertoires corrects sont trouvés grâce aux KmerAffect. Mais… ces KmerAffect sont les mêmes pour un germline complet et incomplet (le shortcut est par exemple `H` en complet et `h` en incomplet) :
```c++
affect_5 = string(1, toupper(shortcut)) + "-" + code + "V";
affect_4 = string(1, 14 + shortcut) + "-" + code + "D";
affect_3 = string(1, tolower(shortcut)) + "-" + code + "J";
```
On pourrait se dire que ce n'est pas grave et qu'on va mettre des KmerAffect différents pour les germlines complets et incomplets… sauf que non. Si on fait cela la partie commune des germlines complets et incomplets (souvent les gènes J) seraient considérés comme ambigus car appartenant à des germlines différents.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3726AFFECT_UNKNOWN à la fin des affectations avec Aho et probas2019-02-12T14:36:35+01:00Mathieu GiraudAFFECT_UNKNOWN à la fin des affectations avec Aho et probasDepuis !78, tant qu'on a un automate par germline avec des graines fixes, on a `k` affectations `_` à la fin.
Est-ce que cela pourrait fausser nos calculs de p-valeur sur les J ? @mikael\-s : "peut-être, mais l'index load sur les J a te...Depuis !78, tant qu'on a un automate par germline avec des graines fixes, on a `k` affectations `_` à la fin.
Est-ce que cela pourrait fausser nos calculs de p-valeur sur les J ? @mikael\-s : "peut-être, mais l'index load sur les J a tellement baissé qu'on ne le verrait probablement pas". À voir en tout cas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3727Utilisation de getS() ou de la graîne avec Aho-Corasick2019-02-28T20:52:32+01:00Mikaël SalsonUtilisation de getS() ou de la graîne avec Aho-CorasickDans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a u...Dans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a un automate par germline et les graînes ne sont pas encore différenciées selon le gène. Mais cela pourrait poser problème plus tard (ou à d'autres endroits du code), notamment avec #1169.Heuristique 2.0https://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/3981On trouve un clone sur très peu d'identité.2019-09-16T16:58:44+02:00Thonier FlorianOn trouve un clone sur très peu d'identité.Suite à des demandes d'éclaircissement, je regarde pourquoi des clones n'ont pas d'identification VDJ. Je prends les séquences bruts de ce clone par l'identifiant, puis lance vidjil dessus avec `-K` pour voir l'affectation.
Je me rends...Suite à des demandes d'éclaircissement, je regarde pourquoi des clones n'ont pas d'identification VDJ. Je prends les séquences bruts de ce clone par l'identifiant, puis lance vidjil dessus avec `-K` pour voir l'affectation.
Je me rends alors compte que nous prédisons un clone, alors que sur 95nt, nous n'avons que 12 matchs de V au début de la séquence, et 6 matchs de J en fin de séquence, les 80nt intermédiaires étant vides.
De plus, comme nous avons des matchs à 100% sur ces portions, la evalue est assez élevé, à 1.78e-15 et 5e-21.
Le clone concerné est le premier de ce sample : https://app.vidjil.org/?set=33551&config=2&clone=41
```
>seq_identifie_vidjil
GAGACCCTGTCCCTCACCTGCGCTCCTGCGAGACCAGATATAAAACTAGCTGCCAACCCAGCCTGTGGCCAGGTCACCGTCTCCTCAGGTCCT
# 18 + VJ 1 24 72 93 seed IGH SEG_+ 2.087323e-16 4.085299e-22/2.087319e-16+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Je pense que l'on est dans un cas limite, et on ne devrait probablement pas retourner de clone la dessus.
J'ai cherché une issue qui s'y rapporterait. Je ne sais pas si cela à un lien avec #1964, mais le fine pourrait déjà permettre de faire un filtre plus précis non ?
ping @magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4056Séquences non recombinées mais KmerSegmentées à tort ?2019-11-23T06:51:30+01:00Mathieu GiraudSéquences non recombinées mais KmerSegmentées à tort ?Deux échantillons a priori indépendants: http://app.vidjil.org/index.html?custom=67009&custom=67033&clone=4
Partagent un `D7-27-0/92/0-J1` (bien taggué depuis #2232), mais aussi deux clones en IGK et IGL, en plus non FineSegmentés. Sera...Deux échantillons a priori indépendants: http://app.vidjil.org/index.html?custom=67009&custom=67033&clone=4
Partagent un `D7-27-0/92/0-J1` (bien taggué depuis #2232), mais aussi deux clones en IGK et IGL, en plus non FineSegmentés. Serait-ce des cas similaires à du D7-27 / J1 ?
Ping #1664
cc @flothoni @duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4188Retirer les séquences de faible complexité des germlines ?2022-02-17T18:36:48+01:00Mathieu GiraudRetirer les séquences de faible complexité des germlines ?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Algo 2022.04https://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/4226Graines différentes pour V et J : usage2020-04-23T19:24:33+02:00Mathieu GiraudGraines différentes pour V et J : usageAprès #3954/!634.
Attend-on une remise à plat globale des graines #1364 et/ou le seul index pour tous #1169, ou déjà essaie-t-on de mettre dès maintenant quelques J plus petits ? Autre chose ?Après #3954/!634.
Attend-on une remise à plat globale des graines #1364 et/ou le seul index pour tous #1169, ou déjà essaie-t-on de mettre dès maintenant quelques J plus petits ? Autre chose ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/1490P-value / E-value du segmenter (nb de k-mers)2016-11-29T14:37:01+01:00Vidjil TeamP-value / E-value du segmenter (nb de k-mers)merci Mikaël !
***
Comparaison entre multi+inc et multi+inc+e-val (1e-6) :
http://rbx.vidjil.org/browser/?custom=1846&custom=2065&
Il n'y a que 67 reads segmentés en moins
***
Sur le jeu de Patrick : http://rbx.vidjil.org/browser/?custo...merci Mikaël !
***
Comparaison entre multi+inc et multi+inc+e-val (1e-6) :
http://rbx.vidjil.org/browser/?custom=1846&custom=2065&
Il n'y a que 67 reads segmentés en moins
***
Sur le jeu de Patrick : http://rbx.vidjil.org/browser/?custom=2063&custom=1988&custom=2064&custom=1989&
Les séquences qui disparaissent avec le 1e-6 s'alignent toutes de manière contigue sur le génome sur toute la longueur de la représentative, d'après Ensembl.
En faisant la même chose avec les séquences communes aux deux configs, on a quelques surprises. Il y a encore des alignements contigus sur le génome. La raison : des gènes J non recombinés. On a plein de J à droite et juste un V à gauche (par hasard). Ça passe haut la main la e-valeur (et c'est normal).
Donc il faut bien faire une e-valeur à droite et à gauche, mais pour être plus strict en fait (une e-valeur juste sur le nombre d'affectations dans la partie gauche (sans distinguer V et J) et même chose sur la partie droite ?).
***
La probabilité est calculée sur toute la longueur de la séquence (sauf les derniers nucléotides) mais on ne peut pas avoir de k-mers non plus au niveau de la jonction… Faut-il corriger cela ? (facile : en supposant que le nombre d'insertions est nul, dur : en ayant un modèle sur le nombre d'insertions, qui dépend du locus…)
***
J'ai lancé le jeu de données de Larisa en multi+inc et multi+inc+e-val → seule différence un clone TRG (le seul, le reste est du TRB) mis de côté par la e-value. Plutôt positif donc.
***
On va dire que cette tâche est terminée, merci !
***
@magiraud @mikael-shttps://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/872Longueur des reads d'un clone (distribution des longueurs par fenêtre) : Stat...2016-11-29T14:28:36+01:00Vidjil TeamLongueur des reads d'un clone (distribution des longueurs par fenêtre) : Stats/BinReads- moyenne, médiane ? distribution ?
- pour les représentatives, jeux d'entrées... ?
- objet générique (à la bucket ?)
***
L'objet existe : c'est core/stats.cpp.
On pourrait le compléter (ou, mieux, le sous-classer) pour faire les stats ...- moyenne, médiane ? distribution ?
- pour les représentatives, jeux d'entrées... ?
- objet générique (à la bucket ?)
***
L'objet existe : c'est core/stats.cpp.
On pourrait le compléter (ou, mieux, le sous-classer) pour faire les stats voulues, déjà un histogramme.
***
Tiens, une vieille tâche qui traînait :)
***
On aimerait dans Stats récupérer aussi un histogramme... mais c'est une fonctionnalité de BinReadStorage.
Bref, ne faudrait-il pas virer stats.cpp et utiliser directement BinReadStorage pour faire des stats ? (en ayant une sous-classe qui ne stocke pas les reads, mais juste l'info de longueur).
(Attention, stats sert à faire des moyennes de longueur de reads, mais aussi d'autres choses, mais cela devrait être générique)
***
Je suis pas sûr, mais j'essaie de me lancer dessus…
***
e9a7b7c7..272347d
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1304Réarrangements incomplets2016-11-29T14:34:29+01:00Vidjil TeamRéarrangements incompletsPatient MAQ : en lançant Vidjil en ligne de commande ./vidjil -V germline/IGK-INTRON.fa -J germline/IGK-KDE.fa -c clones data.fastq on trouve un clone en Intron-KDE qui ressort fortement (35987 reads)
***
Pour le patient MAQ en DD2/DD3 :...Patient MAQ : en lançant Vidjil en ligne de commande ./vidjil -V germline/IGK-INTRON.fa -J germline/IGK-KDE.fa -c clones data.fastq on trouve un clone en Intron-KDE qui ressort fortement (35987 reads)
***
Pour le patient MAQ en DD2/DD3 : rien. Mais ça vient des germlines. Le DD2 fait 9nt et on utilise une graine qui s'étend sur 11. Il faudrait récupérer la séquence en amont du DD2 et en aval du DD3.
***
|13+0=13| |rev-compl|
actgggggatacgcacagtgctacaaaacctacagagacctgtac
En utilisant ces séquences-là (en local) on a un clone à 44584 reads.
***
|
***
|9+0=9| |rev-compl|
tatactgatgtgtttcattgtgccttcctac
et cette séquence-là pour le DD3 :
>M22152|TRDD3*01|Homo sapiens|F|D-REGION|214..226|13 nt|1|
***
|
***
Sur bioinfo-inria on a cette séquence-là pour le DD2 :
>M22153|TRDD2*01|Homo sapiens|F|D-REGION|34..42|9 nt|1|
***
Pour récupérer automatiquement les séquences amonts on peut peut-être utiliser l'API du NCBI (pour le faire automatiquement). Sinon on peut les stocker quelque part :)
***
Pour TRDD2*01 :
http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=nuccore&id=M22153&rettype=fasta&retmode=text&to=42
Pour TRDD3*01 :
http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=nuccore&id=M22152&rettype=fasta&retmode=text&from=214&to=258
***
b43f867 pour récupérer les fichiers avec les séquences amont/aval
et cffcd74, 7aaa26f pour gérer les réarrangements incomplets (merci Mathieu)
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/871distribution "+" /"-" par fenêtre2016-11-29T14:28:35+01:00Vidjil Teamdistribution "+" /"-" par fenêtre-récupérer l'information dans le core
-la stocker dans le json
-afficher dans le browser
***
@Duez-récupérer l'information dans le core
-la stocker dans le json
-afficher dans le browser
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/916Bit-parallelism everywhere in the heuristics2016-11-30T20:37:20+01:00Vidjil TeamBit-parallelism everywhere in the heuristicshahaha
***
@nobodyhahaha
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/917Zéro malloc/free dans le kmer segmenter (itérateur getResults())2016-11-29T14:29:13+01:00Vidjil TeamZéro malloc/free dans le kmer segmenter (itérateur getResults())pas de strings :
- soit directement 0/1/2/3 à la sortie de OnLineFasta
- soit, plus simple, juste l'itérateur dans KmerStore . getResults()
***
Implémenté dans branche "getResults".
Passe les tests... mais voir commentaire de 8870b35, ...pas de strings :
- soit directement 0/1/2/3 à la sortie de OnLineFasta
- soit, plus simple, juste l'itérateur dans KmerStore . getResults()
***
Implémenté dans branche "getResults".
Passe les tests... mais voir commentaire de 8870b35, c'est curieux.
***
Sur 14-07-Nijmegen/all.fastq, uniquement la segmentation :
getResults real 0m38.008s user 0m29.394s
master real 1m8.989s user 1m0.036s
Même nombre de SEG. Par contre, de très légères différences dans les causes de UNSEG. Pour une même affection des reads sont dans un cas toofewV et dans l'autre toofewJ.
Extrait de 14-07-Nijmegen/diff-master-getResults :
>CEBEW:01362:00030
ACGTTTGATCTCCAC
-#UNSEG too few J
+#UNSEG too few V
_ _ _-J
(...)
>CEBEW:01551:00111
ACGTTTTGATCTCCACCT
-#UNSEG too few V
+#UNSEG too few J
_ _ _ _-J _ _
***
toujours sur 14-07-Nijmegen/all.fastq, pour comparaison :
release-2014.03 real 1m9.651s user 1m0.456s
(curieusement, on a perdu 4% de segmentées entre release-2014.03 et master ?)
***
Dans la version release-2014.03 on a des segmentations comme celle-ci :
CEBEW:00023:00065 - VJ 0 94 120 157 seed
Alors que delta_max vaut 20 (et 120 - 94 > 20 je crois)
***
wc -l
0
***
wc -l
47677
awk '$0~/^>/ && $6-$5 > 20' out-speed-master/segmented.vdj.fa
***
Ce qu'on peut vérifier comme cela :
awk '$0~/^>/ && $6-$5 > 20' out-speed-2014.03/segmented.vdj.fa
***
ok
***
Il semble, pour une raison que j'ignore, que le delta_max vaille 50 en dépit de ce qui est affiché sur la sortie standard :
# k = 11, w = 40, delta = [-10,20]
Voici la répartition des valeurs des delta observées dans le fichier .vdj.fa pour 2014.03 :
2 -10
631 -9
120 -8
50 -7
160 -6
56 -5
97 -4
106 -3
191 -2
549 -1
59829 0
58104 1
74169 2
130098 3
89321 4
20963 5
138043 6
29126 7
22434 8
105227 9
59138 10
15288 11
5760 12
13950 13
55996 14
3978 15
2197 16
3954 17
3083 18
10562 19
5324 20
1730 21
1612 22
1326 23
1225 24
7504 25
25796 26
1501 27
1080 28
675 29
790 30
426 31
349 32
622 33
421 34
352 35
337 36
357 37
250 38
217 39
122 40
131 41
113 42
167 43
114 44
106 45
83 46
80 47
49 48
79 49
63 50
Il serait peut-être pertinent de mettre un delta_max qui dépende du système (l'enzyme responsable des insertions n'a pas la même activité sur tous les systèmes)
***
814f8cbff :-)
Le 50 était codé en dur avant.
***
@magiraudhttps://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/919segmented.vdj.fa : ne pas le produire quand on en a pas besoin ?2016-11-29T14:29:14+01:00Vidjil Teamsegmented.vdj.fa : ne pas le produire quand on en a pas besoin ?5df371c1
Sur mon portable, on gagne 20 à 30% lorsque cela segmente beaucoup :
./vidjil -G germline/TRG -U ~/vdj/data/runs/13-09/Leu+7_BCD.fastq
./vidjil -G germline/TRG ~/vdj/data/runs/13-09/Leu+7_BCD.fastq
Cela fait bizarre de ...5df371c1
Sur mon portable, on gagne 20 à 30% lorsque cela segmente beaucoup :
./vidjil -G germline/TRG -U ~/vdj/data/runs/13-09/Leu+7_BCD.fastq
./vidjil -G germline/TRG ~/vdj/data/runs/13-09/Leu+7_BCD.fastq
Cela fait bizarre de supprimer l'ancienne sortie principale de Vidjil :)
***
@magiraudhttps://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/930Algo multi-systèmes 1.5 : intégrer un objet Germline2016-11-29T14:29:34+01:00Vidjil TeamAlgo multi-systèmes 1.5 : intégrer un objet Germline- graines de taille variable ? (tricher sur remplissage)
***
voir aussi "germlines.txt"
***
Séparé en deux, voir aussi "Algo multi-systèmes avec index unique"
***
objet Germline: before, 4, after, delta_min/max/cost, index, seed_size
***...- graines de taille variable ? (tricher sur remplissage)
***
voir aussi "germlines.txt"
***
Séparé en deux, voir aussi "Algo multi-systèmes avec index unique"
***
objet Germline: before, 4, after, delta_min/max/cost, index, seed_size
***
branch "germlines"
Marc : il nous faut un parser de .json :
- maison ?
- ou utilise-t-on https://github.com/miloyip/rapidjson (ou autre), et donc en remplaçant core/json.cpp ?
***
parse depuis germline.data -> dans autre tâche
***
CMD_GERMLINES: 7bd4fc0
***
#931, #932, #933, #934, #935, #936, #937, #938, #939, #940
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/931définir l'objet Germline, MultiGermline2016-11-29T14:29:34+01:00Vidjil Teamdéfinir l'objet Germline, MultiGermline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/932à parser depuis germline.data2016-11-29T14:29:34+01:00Vidjil Teamà parser depuis germline.data
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/933AffectAnalyzer prend un MultiGermline, coeur de l'heuristique2016-11-29T14:29:34+01:00Vidjil TeamAffectAnalyzer prend un MultiGermline, coeur de l'heuristique
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/934AffectAnalyzer renvoie l'info du Germline choisi2016-11-29T14:29:34+01:00Vidjil TeamAffectAnalyzer renvoie l'info du Germline choisi
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/935FineSegmenter considère le bon Germline2016-11-29T14:29:34+01:00Vidjil TeamFineSegmenter considère le bon Germline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/936FineSegmenter prend un Germline2016-11-29T14:29:34+01:00Vidjil TeamFineSegmenter prend un Germline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/937MultiGermline passé de vidjil.cpp à segmenter.cpp2016-11-29T14:29:34+01:00Vidjil TeamMultiGermline passé de vidjil.cpp à segmenter.cpp
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/938réparer les tests unitaires :)2016-11-29T14:29:34+01:00Vidjil Teamréparer les tests unitaires :)
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/939Le Germline choisi est transféré à vidjil.cpp2016-11-29T14:29:34+01:00Vidjil TeamLe Germline choisi est transféré à vidjil.cpp
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/940faire aussi CMD_GERMLINES avec le MultiGermline2016-11-29T14:29:34+01:00Vidjil Teamfaire aussi CMD_GERMLINES avec le MultiGermline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/942utiliser position Cys pour recaler la window2021-10-21T19:06:31+02:00Vidjil Teamutiliser position Cys pour recaler la windowà voir...
- si au coeur de l'heuristique, peut ralentir beaucoup
- si à la fin, on ne connait plus le contexte (sauf si on stocke 42-44 au lieu de 40)
***
@nobodyà voir...
- si au coeur de l'heuristique, peut ralentir beaucoup
- si à la fin, on ne connait plus le contexte (sauf si on stocke 42-44 au lieu de 40)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/976Séquences segmentées mais fenêtres non trouvées (J trop court)2018-11-20T09:33:12+01:00Vidjil TeamSéquences segmentées mais fenêtres non trouvées (J trop court)Il y a un biais sur les séquences pour lesquelles on ne trouve pas les fenêtres et on peut donc passer à côté de certains clones.
***
Solutions possibles :
– raccourcir la fenêtre
– décaler la fenêtre vers la gauche (tout le temps, ou p...Il y a un biais sur les séquences pour lesquelles on ne trouve pas les fenêtres et on peut donc passer à côté de certains clones.
***
Solutions possibles :
– raccourcir la fenêtre
– décaler la fenêtre vers la gauche (tout le temps, ou ponctuellement si on ne trouve pas de fenêtre)
***
Danger si on fait cela tout le temps (création de plein de fenêtes shiftées, rend plus complexe clustérisation manuelle ou auto). Pourquoi pas en option.
En tout cas, au moins bien dire à l'utilisateur.
***
Pour moi, ce n'est pas un bug, mais de mauvaises données du séquenceur. Lien "qualité", le dire à l'utilisateur. À rediscuter à froid dans quelque temps.
***
label control-bio: c'est un truc à surveiller de qualité
***
#977
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/977diagnostic sur toutes nos séquences2018-11-20T09:33:19+01:00Vidjil Teamdiagnostic sur toutes nos séquences
***
#976
***
#976https://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/979merger affect_heuristic / online_affect2016-11-29T14:30:09+01:00Vidjil Teammerger affect_heuristic / online_affect(indépendant de getResult ?)
***
attendre 2014-09 ? ce serait plus joli, mais cela segmente vraiment beaucoup plus, donc peut-être ne pas attendre
***
vitesse ok avec online_affect
***
#980
***
@magiraud @mikael-s(indépendant de getResult ?)
***
attendre 2014-09 ? ce serait plus joli, mais cela segmente vraiment beaucoup plus, donc peut-être ne pas attendre
***
vitesse ok avec online_affect
***
#980
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/980revérifier la vitesse (une fois qu'on aura déjà viré FineSegmenter), tests TR...2016-11-29T14:30:09+01:00Vidjil Teamrevérifier la vitesse (une fois qu'on aura déjà viré FineSegmenter), tests TRG : bof, finalement pas la peine
***
#979
***
#979https://gitlab.inria.fr/vidjil/vidjil/-/issues/981alertes à l'utilisateur en fonction de certaines raisons de non-segmentation2018-11-20T09:34:53+01:00Vidjil Teamalertes à l'utilisateur en fonction de certaines raisons de non-segmentation
***
@nobody
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/996k-mers interdits, distance 12021-04-06T14:59:34+02:00Vidjil Teamk-mers interdits, distance 1Ping. Une des plus anciennes tâches ouvertes (2014).
***
@nobodyPing. Une des plus anciennes tâches ouvertes (2014).
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1168Algo multi-systèmes 1.5 : heuristique choisir le bon système en premier2016-11-29T14:32:41+01:00Vidjil TeamAlgo multi-systèmes 1.5 : heuristique choisir le bon système en premierTransformé dans la tâche optimisation germlines.data
***
@magiraud @mikael-sTransformé dans la tâche optimisation germlines.data
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1229N, autres nucléotides étendus2020-02-21T21:20:02+01:00Vidjil TeamN, autres nucléotides étenduscore/tools.cpp:complement_nucleotide(66-76) pourrait faire croire que l'on gère d'autres nucléotides que A, C, G, T. Il n'en est évidemment rien :
- KmerStore::get() ne renvoie qu'un seul kmer
- et même dans dynprog, Cost::substitution...core/tools.cpp:complement_nucleotide(66-76) pourrait faire croire que l'on gère d'autres nucléotides que A, C, G, T. Il n'en est évidemment rien :
- KmerStore::get() ne renvoie qu'un seul kmer
- et même dans dynprog, Cost::substitution fait seulement (a == b)
Si on y tient :
- autoriser des caractères étendus dans les reads > trop complexe à gérer, risque de ralentir
(****mais que se passe t-il actuellement ? si N ? il faudrait être clair***)
- autoriser des caractères étendus dans les germlines > pas plus simple, mais pour le coup cela ne ralentirait pas
Bofbof. Utiilité ?
***
- en sortie : voir "representative"
***
l'automate rendrait certaines choses possibles (en le faisant grossir, certes)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1265Erreur d'affectation en multi-système2016-11-29T14:33:59+01:00Vidjil TeamErreur d'affectation en multi-systèmeSur certains patients (par exemple Leu en multi-système virtuel), on a un clone en IGL. Il devrait être séquencé en TRG mais la séquence est chimérique : plein de V, puis des J puis à nouveau des V. Elle est classée en tant que too few J...Sur certains patients (par exemple Leu en multi-système virtuel), on a un clone en IGL. Il devrait être séquencé en TRG mais la séquence est chimérique : plein de V, puis des J puis à nouveau des V. Elle est classée en tant que too few J. Elle devrait être notée ambigue/chimérique : ce qui signifierait que le germline est bon, mais qu'on ne peut rien faire. Il n'y a donc pas à continuer à chercher une affectation avec un autre germline.
***
a9b4ecc et a8d2c87
***
> diff /mnt/result/tmp/out-00053[48]/*.vidjil.log
- ==> segmented 1452687 reads (58%)
+ ==> segmented 1421376 reads (56.8%)
La différence vient bien de AMBIGUOUS :
- UNSEG ambiguous -> 1950 193.4
+ UNSEG ambiguous -> 327571 189.4
Mais... il reste toujours du IGL (moins) :
- IGL -> 47730 194.1
+ IGL -> 17081 191.9
(et quelques pouillèmes d'autres systèmes)
***
Youpi. 41b4f07
Le problème ne venait pas que TOO_FEW_J/V. Mais aussi STRAND, DELTA_MIN/MAX...
> diff /mnt/result/tmp/out-0005[34]4//000*.vidjil.log
- ==> segmented 1452687 reads (58%)
+ ==> segmented 1400617 reads (55.9%)
TRG -> 320591 194.8
- IGH -> 1081421 319.8
- TRA -> 45 186.7
- TRB -> 1602 197.2
- TRD -> 991 196.9
- IGK -> 307 185.9
- IGL -> 47730 194.1
+ IGH -> 1078450 319.7 *** on en a perdu un peu, ok ***
+ TRA -> 39 185.2
+ TRB -> 217 193.0
+ TRD -> 914 193.3
+ IGK -> 220 185.7
+ IGL -> 186 172.3 *** youpi ****
Plus de IGL (ou à peine, en tout cas rien dans le top 100).
Vérifié les 10 premiers clones à la main, les résultats sont conservés.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1272Algo multi-système 1.9, faire passer les tests, k-mers ambigus2016-11-29T14:34:04+01:00Vidjil TeamAlgo multi-système 1.9, faire passer les tests, k-mers ambigusIl n'y a finalement très peu de tests en multi-système.
Faire un fichier avec des reads devant être segmenté un peu partout.
***
Branche multi, b5fa7e8, le test est fait... reste à le faire passer :)
Solutions possibles :
- monter DE...Il n'y a finalement très peu de tests en multi-système.
Faire un fichier avec des reads devant être segmenté un peu partout.
***
Branche multi, b5fa7e8, le test est fait... reste à le faire passer :)
Solutions possibles :
- monter DETECT_THRESHOLD
- graines plus longues
- k-mots communs interdits : une manière simple serait de faire une fonction IKmerStore::remove (ou annihilate, ou ...) qui supprime de l'index les k-mers du fasta donné.Sur l'index TRG, on appellerait remove(IGH), remove(IGK)...
***
On voit cela plus tard, peut-être en janvier, avec k-mers communs et index commun ou pas.
***
Solution proposée :
- k-mots communs interdits : une manière simple serait de faire une fonction IKmerStore::remove (ou annihilate, ou ...) qui supprime de l'index les k-mers du fasta donné.Sur l'index TRG, on appellerait remove(IGH), remove(IGK)...
- (et idéalement, l'avoir aussi à distance 1)
1) C'est relativement facile à faire
2) Cela permet, dans notre code actuel, d'être quasiment fonctionnellement équivalent à ce qu'on sera quand on aura au début du seul index/automate.
- Fonctionnellement, car on sera toujours beaucoup plus long.
- et 'au début', car après l'automate permettrait de partir dans des graines bien plus différentes par V/J
***
@magiraud @mikael-shttps://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/1399Calcul de la strand : améliorer, supprimer ?2016-11-29T14:35:47+01:00Vidjil TeamCalcul de la strand : améliorer, supprimer ?segment.cpp:206 : strand = affect_strand(it.affect);
1) Le calcul de la strand prend ici en compte *toutes* les affectations, même si il y a d'autres choses dans l'index considéré (ce n'est pas le cas actuellement, mais cela peut l'êtr...segment.cpp:206 : strand = affect_strand(it.affect);
1) Le calcul de la strand prend ici en compte *toutes* les affectations, même si il y a d'autres choses dans l'index considéré (ce n'est pas le cas actuellement, mais cela peut l'être avec use_index et ce le sera pour l'automate). Il ne devrait regarder que affect_5 et affect_3, c'est potentiellement un bug.
2) On pourrait même supprimer ce calcul, TRG/strand+ TRG/strand- n'étant que deux germlines différentes. (Si on le fait dès maintenant, il faudra lancer le KmerAffectAnalyser(*(germline->index), sequence) au bon moment pour ne pas répliquer les calculs).
***
Tiens, on en parle aussi ici.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1437Spécificité / P-value / E-value d'une recombinaison2019-09-16T16:58:45+02:00Vidjil TeamSpécificité / P-value / E-value d'une recombinaisonPrend en compte nb de délétions, mutations V/J, N... Normalement cela devrait se voir dans les scores de FineSegmentation.
Détecter ces probabilités depuis nos jeux de données (mais cela suppose d'avoir des segmentations VDJ de référe...Prend en compte nb de délétions, mutations V/J, N... Normalement cela devrait se voir dans les scores de FineSegmentation.
Détecter ces probabilités depuis nos jeux de données (mais cela suppose d'avoir des segmentations VDJ de référence...)
Lien avec génération aléatoire.
Faire cela dans notre coin ? Mettre quelqu'un dans la boucle ? (Laurent ?)
***
De manière empirique, pas nécessairement besoin de segmentations VDJ de réf. Ne peut-on pas le faire directement depuis les fenêtres ? On sait où est censé se terminer le V et commencer le J. Et donc on peut retrouver si on trouve une fenêtre à distance 0 ou 1.
Et si on va sur la génération aléatoire, le problème est la probabilité qu'on affecte à des délétions, insertions (et cela dépend des chaînes et des récepteurs, la dTd et la bouffeuse de nucléotides ne sont pas aussi actives partout). Ou alors on part de nos données, mais là pour le coup on a besoin de segmentations VDJ de références.
***
On en parle donc un jour avec Laurent. Voir quand.
***
On a donc maintenant une e-valeur d'une découpe left/right, mais la question reste toujours ouverte pour une recomb VDJ, à partir d'exemples, d'estimer les paramètres. On en avait aussi parlé avec Nikos.
***
(copié depuis tâche "Taille de fenêtre en multi-système") Si on a un V/J collé avec 0 zone de N, ce sera très limite même avec une fenêtre de taille 100 :-) On doit mettre un gros warning dessus, et permettre de revenir sur les reads.
***
Remonté, car l'heuristique peut regrouper des choses curieuses si la fenêtre n'est pas spécifique. (mais bon, contrôle par le coverage ?). Devient légèrement différent : quelle est la P/E-valeur d'une fenêtre ?
- compter les N (après Fine Segmenter)
- un bidule dans le FineSegmenter qui compte en plus les mutations de la fenêtre
- ... ou bien un truc magique à base de k-mers (y compris des D) ?
(Voir par exemple notable/0481)
***
euh... on maintenant a un warning si faible e-valeur ?
toujours d'actualité ?
***
Cela a été fait très sérieusement par Thierry Mora et Aleksandra Walczak
-> Quantifying lymphocyte receptor diversity
http://arxiv.org/abs/1604.00487
***
Et il y a un article qui utilise cela pour calculer la p-value de clones identifiés au diag : http://www.nature.com.sci-hub.cc/bmt/journal/vaop/ncurrent/full/bmt2016148a.html « Reliability of immune receptor rearrangements as genetic markers for minimal residual disease monitoring »
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1493P-value / E-value du segmenter (nb de k-mers gauche + droite)2016-11-29T14:37:03+01:00Vidjil TeamP-value / E-value du segmenter (nb de k-mers gauche + droite)C'est clairement ce qu'il nous faut.
Cela permettrait d'aller essayer de nouvelles germlines bizarres, des translocations, le MAX12...
Pour simplifier, supposons que le point de segmentation est fixé.
Version simple : e-valeur d'avoir ...C'est clairement ce qu'il nous faut.
Cela permettrait d'aller essayer de nouvelles germlines bizarres, des translocations, le MAX12...
Pour simplifier, supposons que le point de segmentation est fixé.
Version simple : e-valeur d'avoir le nb de V à gauche, et le nb de J à droite. Juste deux appels à ce qui existe déjà. Cela permettra déjà d'enlever les cas où il y a un pauvre V tout seul qui traîne.
Version mieux : On se rapproche de la e-valeur d'une recombinaison. A gauche, on regarde aussi le nb de J, et il ne doit pas être gros. (mais finalement, notre heuristique pour trouver le point de seg garantit déjà qu'il n'y a pas trop de J à gauche).
Dans les deux cas, on pourrait avoir le index_load pour V et J différents, mais, bon, on peut prendre le même dans un premier temps. (et dans les deux cas, on pourrait itérer sur le point de seg pour avoir une formule exacte ? euh, pas sûr)
***
34068e0, version simple. À un moment, j'ai pensé combiner gauche et droite, mais cela ne marche tout simplement pas (on peut avoir 1e-60 à droite, et du bruit à gauche).
***
+ e17174a
***
@magiraud @mikael-s