vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-07-05T09:15:56+02:00https://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/2250Que signifie une e-valeur de 1 ?2017-03-14T17:48:13+01:00Mathieu GiraudQue signifie une e-valeur de 1 ?@mikael-s, à propos de #2230 :
> Un des problèmes vient du fait qu'une e-valeur de 1 n'est pas délirante quand on a 100 séquences, mais si on en a qu'une (comme dans les should-vdj) ce n'est pas la même histoire (mais ce n'est pas le seu...@mikael-s, à propos de #2230 :
> Un des problèmes vient du fait qu'une e-valeur de 1 n'est pas délirante quand on a 100 séquences, mais si on en a qu'une (comme dans les should-vdj) ce n'est pas la même histoire (mais ce n'est pas le seul problème).
J'ai eu un soucis similaire pour #2107, qui a mené à 3f023b73 : vu que c'est désormais uniquement le test de e-valeur qui mène à `UNSEG_ONLY_V/J`, des séquences vont être désormais segmentée avec une e-valeur de 1 alors qu'elles ne l'étaient pas avant (il y a avait `DETECT_THRESHOLD`). Pas de soucis dès qu'on a le multiplieur.
Faudrait-il mettre la e-valeur par défaut à 0.01 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2167Mieux construire la pseudo-germline xxx en ne prenant pas les doublons2017-02-04T12:26:33+01:00Mathieu GiraudMieux construire la pseudo-germline xxx en ne prenant pas les doublonsOn devrait initialiser `xxx` avec tous les répertoires disponibles (voir aussi #2168), mais faire en sorte qu'on ne prenne qu'une fois chaque fichier (sinon on génère des `AFFECT_AMBIGUOUS`, voir !6 et c7a85b67).On devrait initialiser `xxx` avec tous les répertoires disponibles (voir aussi #2168), mais faire en sorte qu'on ne prenne qu'une fois chaque fichier (sinon on génère des `AFFECT_AMBIGUOUS`, voir !6 et c7a85b67).Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1760Une séquence ambiguë à tort ? -42017-02-04T10:11:36+01:00Vidjil TeamUne séquence ambiguë à tort ? -4Hier, tu as dit à un moment "c'est bizarre que cette séquence soit ambigüe".
Tu te souviens de laquelle c'était ?
***
C'est quand tu faisais un -4 (sur les données de Florian ?), en xxx la séquence passait en unknown alors qu'il y avait ...Hier, tu as dit à un moment "c'est bizarre que cette séquence soit ambigüe".
Tu te souviens de laquelle c'était ?
***
C'est quand tu faisais un -4 (sur les données de Florian ?), en xxx la séquence passait en unknown alors qu'il y avait pas mal de delta à la fin qui était bien reconnu
***
Ah, ok, si c'est -4 c'est expérimental :-)
***
Euh… pourquoi le calcul de l'ambigu différerait entre le -4 et le reste ?
***
C'est une bonne question.
***
J’ai comparé 0ce12ff et 783d0b1 (diff: changements de la semaine dernière, plus de reads en ambiguous)
/vidjil -g germline/ -i -K ~/notable/data_translocation.fasta
Une séquence passe de only V en too few V/J, et c’est mieux ainsi.
Bref, pas de soucis avec les dernières modifs.
Avec -4, pas encore tout compris ce qu’il se passe, mais rien d’urgent de ce côté, on verra cela en janvier.
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1936Véracité des causes de non segmentation (et implications du -t ou -2)2016-12-06T10:22:13+01:00Vidjil TeamVéracité des causes de non segmentation (et implications du -t ou -2)Les causes de non segmentation varient grandement en fonction des paramètres utilisés, ce qui induit en erreur.
Par exemple sur des données de LLC, ajouter un -t 0 (par défaut -t 100), conduit à considérer le V dans toute sa longueur et ...Les causes de non segmentation varient grandement en fonction des paramètres utilisés, ce qui induit en erreur.
Par exemple sur des données de LLC, ajouter un -t 0 (par défaut -t 100), conduit à considérer le V dans toute sa longueur et donc le UNSEG too few V/J passe de ~10^5 à ~10^3, les séquences passant en fait en « UNSEG only V/5' ». Cela amène d'ailleurs à se poser la question de la pertinence de -t 100 : il y a des séquences qui contiennent vraiment du V mais dont on pense qu'elles n'en ont pas à cause du -t 100.
Par ailleurs sur ces mêmes données, utiliser un -2 fait passer une très grosse partie des séquences de « UNSEG only V/5' » à « UNSEG only J/3' » pour une raison que je n'explique pas.
Les données en question : patient 1803 et 1806 (Lille).
***
@magiraud @mikael-shttps://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/1592segmenter.h/c: rationaliser les attributs d'information2016-11-29T14:38:19+01:00Vidjil Teamsegmenter.h/c: rationaliser les attributs d'informationdans le Kmer et le FineSegmenter, on stocke différentes chaînes d'information :
info, info_extra, code, code_short, code_light
puis on s'en sert à des degrés divers sur la sortie standard et dans le .vidjil.
Voir aussi finishSegmentati...dans le Kmer et le FineSegmenter, on stocke différentes chaînes d'information :
info, info_extra, code, code_short, code_light
puis on s'en sert à des degrés divers sur la sortie standard et dans le .vidjil.
Voir aussi finishSegmentation() et getInfoLine().
Voir si tout cela ne pourraît pas être simplifié.
***
@nobodyhttps://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-s