vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-03-25T12:09:53+01:00https://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/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/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/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/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/1779xxx problème dans le nommage de certains clones2017-02-04T10:12:16+01:00Vidjil Teamxxx problème dans le nommage de certains cloneshttp://rbx.vidjil.org/browser/?patient=1347&config=25
Nom de la séquence : Unexpected -/home/vidjil/vidjil-release//germline//TRBV.fa /+/home/vidjil/vidjil-release//germline//IGHV.fa
***
d65a9c9 : c'était une feature, ou bien j'étais bou...http://rbx.vidjil.org/browser/?patient=1347&config=25
Nom de la séquence : Unexpected -/home/vidjil/vidjil-release//germline//TRBV.fa /+/home/vidjil/vidjil-release//germline//IGHV.fa
***
d65a9c9 : c'était une feature, ou bien j'étais bourré ?
Disons que, en ligne de commande, ce sera souvent " Unexpected germline/TRBV.fa", ce qui peut être souhaitable, en particulier si on a "mouse/TRBV.fa" ou bien "new-germline/TRBV.fa".
Ici, c'est illisible parce que le chemin est absolu. Est-ce que cela pourrait être géré plutôt par le browser ? Comme tu veux, c'est vrai que ce n'est pas joli actuellement.
Si on veut changer cela dans le C++, il suffit de faire ce qu'on veut lignes 707 et 709 de segment.cpp. Il y a bien une fonction basename quelque part ?
***
ae31aba
***
@magiraudhttps://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/1674FineSegmenter donne UNSEG < delta_min sur des belles séquences -> supprimer d...2017-11-24T10:04:37+01:00Vidjil TeamFineSegmenter donne UNSEG < delta_min sur des belles séquences -> supprimer delta_min
@flothoni : J'ai quelques séquences qui sont retrouvées dasn vidjil mais qui n'ont pas de noms définis.
En investigants un peu sur celles-ci (via imgt-quest), il semblerait que vidjil n'ai pas assez d'informations pour discriminer les ...
@flothoni : J'ai quelques séquences qui sont retrouvées dasn vidjil mais qui n'ont pas de noms définis.
En investigants un peu sur celles-ci (via imgt-quest), il semblerait que vidjil n'ai pas assez d'informations pour discriminer les segments, en general entre les alleles.
J'ai essayé de jouer sur la eval pour discriminer grossièrement, mais ça ne marche pas non plus.
Je ne sais aps si vous avez déjà eu le cas ou non.
Du coup, il faudrait que vidjil retourne au moins le nom du seg, même si il ne peut pas discriminer l'allele quand ceux qu'il identifie son similaires.
Vous voyez une autre raison ou méthode pour "recupérer" ces séquences ?
Ps , les fichiers vidjil sont en pj.
@magiraud : L'algo parfois segmente certaines séquences par l'heuristique des k-mers (`SEG_+`/`SEG_-`) mais n'arrive pas à faire la désignation V(D)J (ce qu'on appelle le "FineSegmenter"), par exemple si les séquences sont vraiment bizarres (et dans ce cas on garde quand même la séquence dans le .vidjil, un clone est identifié, mais on ne sait pas le désigner)
... mais ici c'est clairement un bug, ce sont des beaux réarrangements.
`algo/tests/bugs/bug20150909.fa`
@magiraud : c5c781e. On enlève le test, tout se passe bien.
(Les séquences ont d'autres bugs, autre tâche)
@magiraud @mikael-s @flothoniAlgo 2017.07https://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/1580Décaler la window dans certains cas2020-04-15T09:18:25+02:00Vidjil TeamDécaler la window dans certains casMikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de ...Mikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de certaines amorces...).
Y aurait-il des cas où on aimerait plus revenir à gauche ? Surtout si on prend un grand `-w`, 80, 100 ou plus.
(Avoir un truc flexible, en fonction de la taille de la read, semble difficile, puisqu'on veut avant tout regrouper les reads en clones...)
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1552Une représentative, plusieurs clones2016-11-29T14:37:49+01:00Vidjil TeamUne représentative, plusieurs clonesCe sont des exemples donnés par Yann, par exemple sur ce patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11
Le cas a été clusterisé par Yann, mais il suffit d'aller en TRD (il y a un seul clone). Ce clone correspond ...Ce sont des exemples donnés par Yann, par exemple sur ce patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11
Le cas a été clusterisé par Yann, mais il suffit d'aller en TRD (il y a un seul clone). Ce clone correspond à un cluster de deux clones, l'un en VdJa et l'autre en TRD.
On ne voit plus ce cas-là avec la e-valeur, mais c'est peut-être pour une raison différente…
***
Cas ici aussi (même procédé pour le repérer) http://rbx.vidjil.org/browser/index.html?patient=169&config=11
ou encore ici (gros clone en TRD+ avec du Vd2/Dd3 repéré sans le Ja29) : http://rbx.vidjil.org/browser/index.html?patient=167&config=11 → on n'a plus le fichier de séquences
***
impressionnant, joli bug en effet
***
commit 07adde3
> Author: Mikael Salson <mikael.salson@univ-lille1.fr>
> kmerstore.h: Insert properly the revcomp kmers with unsymmetrical seeds.
> If the seed is not symmetrical (as with TRA and VdJa), we can't just reverse the seed.
> We need to take back the original substring, reverse it and then take the seed.
Impressionnant que cela ait passé tous les tests jusqu'à maintenant !
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1548Problème de D7-J1 en complémentaire2017-03-09T10:21:19+01:00Vidjil TeamProblème de D7-J1 en complémentaireSéquence D7-J1 trouvée en IGH (et pas IGH+) quand elle est en complémentaire ?
Le problème vient peut-être de leur protocole de séquençage qui n'est pas équivalent dans les deux sens (du coup on ne se retrouve pas avec les mêmes séquen...Séquence D7-J1 trouvée en IGH (et pas IGH+) quand elle est en complémentaire ?
Le problème vient peut-être de leur protocole de séquençage qui n'est pas équivalent dans les deux sens (du coup on ne se retrouve pas avec les mêmes séquences en aval et en amont et on pourrait détecter des trucs qui ressemblent à du V). Avec la e-valeur, je ne pense pas que ça passe.
À tester…
***
Probablement un problème similaire à 1 clone, 2 représentatives. Test ajouté, passe.
***
@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/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/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/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/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/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/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/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.
***
@magiraud