vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-12-04T14:55:59+01:00https://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/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/1606Supprimer delta_max (et delta_min ?)2016-11-29T14:38:30+01:00Vidjil TeamSupprimer delta_max (et delta_min ?)Ils ne sont probablement pas souhaitables pour le KmerSegmenter, mais pour le FineSegmenter ?
***
Ah, oui, il y a le Fine derrière. (Cela est lié avec tâche "ne pas Finesegmenter si ce n'est pas joli", titre de mémoire, bref avoir une e-...Ils ne sont probablement pas souhaitables pour le KmerSegmenter, mais pour le FineSegmenter ?
***
Ah, oui, il y a le Fine derrière. (Cela est lié avec tâche "ne pas Finesegmenter si ce n'est pas joli", titre de mémoire, bref avoir une e-value pour le Fine.
On peut déjà le supprimer pour le Kmer.
***
Je serais partant de ne garder que le delta_min pour le Fine. Si on a KmerSegmenté avec de grosses insertions, c'est bizarre d'empêcher le Fine de trouver le bon alignement.
***
oui, ok (mais peut-être que le Fine actuel ne va pas bien se comporter, on verra...)
***
fait il y a un certain temps...
***
@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/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/1579k-mers communs entre IGHV et IGHD2021-03-17T23:19:38+01:00Vidjil Teamk-mers communs entre IGHV et IGHDMikaël, à propos d'IGH : "Une partie du problème vient du fait que deux gènes D ont des k-mers partagés avec des gènes V. Cela peut être vérifié facilement :
./vidjil -G germline/IGH -K germline/IGHD.fa
Du coup cela décale la fenêtre ver...Mikaël, à propos d'IGH : "Une partie du problème vient du fait que deux gènes D ont des k-mers partagés avec des gènes V. Cela peut être vérifié facilement :
./vidjil -G germline/IGH -K germline/IGHD.fa
Du coup cela décale la fenêtre vers la droite et on a une moins bonne
spécificité."
La sotie en question :
>J00234|IGHD2-15*01|Homo
AGGATATTGTAGTGGTGGTAGCTGCTACTCC
_ _ _ _ _ _ _ _+X+X _ _ _ _ _ _ _ _ _
>X93616|IGHD3-22*01|Homo
GTATTACTATGATAGTAGTGGTTATTACTAC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+X _ _
***
- modifier notre graine d'IGH pour que cela n'arrive pas ?
- prendre en compte le répertoire D pour marquer certains k-mers de V et de J ambigus ? (Finalement, jusqu'à maintenant le rep D ne sert pas du tout pour le KmerSegmenter !)
- décaler la window pour compenser ?
***
J'avais oublié, mais ton merge de voodooj me l'a rappelé : le -t 100 solutionne cela : « Interestingly with -w 100, the number of foud windows is much larger because now the window is better centered around the junction. ». Par chance les k-mers partagés avec les gènes D ne sont pas dans les 100 derniers nucléotides des V.
***
la chance est avec nous :-)
La solution 2 "prendre en compte le répertoire D pour marquer certains k-mers de V et de J ambigus" me semble tout de même raisonnable et robuste.
***
On n'était pas si chanceux que cela, même avec le -t 100 :
../../vidjil -y 0 -s '#####-#####' -K -G ../../germline/IGH -u ../../data/common-D-V.fa
+X+X+X+X+X+X+X+X+X+X _ _ _ _ _ _ _ _ _+X _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+x+x+x+x+x+x+x+x+x+x
en insérant aussi les D :
+X+X+X+X+X+X+X+X+X+X _ _ _ _ _ _ _ _ _ ?+f+f+f+f+f+f _ _ _ _ _ _ _ _ _ _+x+x+x+x+x+x+x+x+x+x
ok, c'est une graine non-standard.
***
c23b5d2
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1570Merger voodooj, option '-t'2016-11-29T14:38:03+01:00Vidjil TeamMerger voodooj, option '-t'J'étais en train de faire le CHANGELOG quand je me suis demandé "mais où donc est le -t" :-) ?
J'ai donc rebasé voodooj sur master.
Il manque juste le commit 37d77d1, tests à vérifier / remerger.
Si on le veut pour la release, il faut m...J'étais en train de faire le CHANGELOG quand je me suis demandé "mais où donc est le -t" :-) ?
J'ai donc rebasé voodooj sur master.
Il manque juste le commit 37d77d1, tests à vérifier / remerger.
Si on le veut pour la release, il faut merger...
***
6184ddb, mergé mais pas par défaut. Comme pour e-valeur le mois dernier : on fait les changements juste après la release.
***
d317535.
Il reste à regarder un test, mais c'est secondaire.
***
@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/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/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/1499Mise en prod de l'evalue (printemps 2015)2017-09-20T08:48:13+02:00Vidjil TeamMise en prod de l'evalue (printemps 2015) - mettre une e-valeur par défaut
- dans le multi, comparer les `KmerSegmenter` par leur e-value
- prise en compte de la longueur de la séquence
ae1ac52
- mettre une e-valeur par défaut
- dans le multi, comparer les `KmerSegmenter` par leur e-value
- prise en compte de la longueur de la séquence
ae1ac52
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1495avoir une version plus heuristique de nb_sequences_in_fasta2016-11-29T14:37:05+01:00Vidjil Teamavoir une version plus heuristique de nb_sequences_in_fasta
***
#1494
***
#1494https://gitlab.inria.fr/vidjil/vidjil/-/issues/1494E-value, multiplier par le nombre de reads2016-11-29T14:37:05+01:00Vidjil TeamE-value, multiplier par le nombre de readsOn multiplie déjà par le nombre de germlines... je suis très tenté de multiplier par le nombre de reads.
L'effet du paramètre dépendra alors de la taille, mais on pourra fixer quelque chose comme -e 1 ou -e 0.01 par défaut. C'est plus ou...On multiplie déjà par le nombre de germlines... je suis très tenté de multiplier par le nombre de reads.
L'effet du paramètre dépendra alors de la taille, mais on pourra fixer quelque chose comme -e 1 ou -e 0.01 par défaut. C'est plus ou moins ce qui se passe pour BLAST.
(Cela permettra aussi de faire passer des tests limites sur une séquence, mais c'est une autre histoire, et on pourra très bien tester à très faible e-valeur si c'est notre souhait.)
***
ok, à faire en appelant nb_sequences_in_fasta (ou une meilleure version)
***
#1495
***
@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-shttps://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/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/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/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-s