vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-06-27T18:53:42+02:00https://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/1879Seuil pour les D, e-valeur2020-10-14T11:25:55+02:00Vidjil TeamSeuil pour les D, e-valeurVW16: deux écoles.
* 4nt (Hélène ~"PAR-Debré" ), pour éviter de faire un primer qui tombe dedans
* 8nt (c'est bien cela ?), (Frédéric ~"Paris-Pitié" , "vieux papiers")
Et nous, on a dit "euh, 5nt". Sommes-nous confiant dans notre c...VW16: deux écoles.
* 4nt (Hélène ~"PAR-Debré" ), pour éviter de faire un primer qui tombe dedans
* 8nt (c'est bien cela ?), (Frédéric ~"Paris-Pitié" , "vieux papiers")
Et nous, on a dit "euh, 5nt". Sommes-nous confiant dans notre calcul de e-valeur pour les D ?
***
Oui c'est bien cela. Le seuil de 8nt correspond à un seuil immuno pour avoir un D qui ait du sens.
***
segment.cpp, FineSegmenter::FineSegmentD
`float evalue_D = multiplier * (r-l) * germline->rep_4.totalSize() * segment_cost.toPValue(box_DD->score[0].first);`
Ouf, `(r-l) `est bien la taille de la zone considérée.
Calcul à priori correct... sauf qu'il dépend de` .toPValue`, donc de `K` et `lambda` qui sont fixés à la légère (mais qui ne devraient pas changer l'ordre de grandeur)
***
Depuis 2016.08, on peut jouer avec `-E`.
Avec e6ffb91, on a perdu 6 séquences de .should-vdj VDDJ.
Retravailler là-dessus, voir s'il faut des seuils différents pour premier D et D suivants, peut-être retravailler sur le score et/ou K/lambda.
***
ping, voir "Configuration trop stringeante sur la recherche du D" #2002
***
@magiraud @mikael-sAlgo -- ImportantThonier FlorianThonier Florianhttps://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/2750Blinder les tests sur les options2018-06-27T19:29:36+02:00Mathieu GiraudBlinder les tests sur les optionsAvant de faire #2732, il faudrait s'assurer que nos tests couvrent le plus d'options possibles, pour éviter des choses type #2748, ou pire sur une option réellement utilisée.
Voir aussi #1696.Avant de faire #2732, il faudrait s'assurer que nos tests couvrent le plus d'options possibles, pour éviter des choses type #2748, ou pire sur une option réellement utilisée.
Voir aussi #1696.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2825Coût du FineSegmenter : est-on trop généreux avec les mismatches ?2018-06-26T10:41:27+02:00Mikaël SalsonCoût du FineSegmenter : est-on trop généreux avec les mismatches ?Il y a certains cas où le nombre de mismatches, proches d'une extrémité semble important par rapport au nombre de matches.Il y a certains cas où le nombre de mismatches, proches d'une extrémité semble important par rapport au nombre de matches.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2967Clone chimère2018-06-26T10:40:27+02:00Anne de SeptenvilleClone chimèrePatient DES, clones attendus attendus : V3-15 J6 et V3-21 J5
https://app.vidjil.org/index.html?set=26067&config=2
Problème pour le clone V3-21 J5 :
Vidjil semble créer une sorte de clone étant une combinaison des 2 attendus.
Pour...Patient DES, clones attendus attendus : V3-15 J6 et V3-21 J5
https://app.vidjil.org/index.html?set=26067&config=2
Problème pour le clone V3-21 J5 :
Vidjil semble créer une sorte de clone étant une combinaison des 2 attendus.
Pourtant Arrest n'a pas de problème particulier avec cet échantillon.Algo -- Importanthttps://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/3019similarity.cgi n'est pas testé2020-05-26T10:45:34+02:00Mathieu Giraudsimilarity.cgi n'est pas testéVu en faisant #3012.Vu en faisant #3012.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3021Avoir un fichier qui teste tous les warnings ou presque2018-06-26T10:40:27+02:00Mathieu GiraudAvoir un fichier qui teste tous les warnings ou presque#2247
Pour l’instant les warnings sont dans des should-get différents. Pourquoi pas, mais ce serait intéressant d’avoir aussi un fichier qui donnerait plusieurs clones avec chacun un warning différent, un peu dans l'esprit de `Demo-X5`....#2247
Pour l’instant les warnings sont dans des should-get différents. Pourquoi pas, mais ce serait intéressant d’avoir aussi un fichier qui donnerait plusieurs clones avec chacun un warning différent, un peu dans l'esprit de `Demo-X5`. Cela ferait une bonne ~doc pour ces wanrings.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3022Mettre à jour Demo-X52019-03-06T08:52:26+01:00Mathieu GiraudMettre à jour Demo-X5Aurait-on des systèmes / recombinaisons particulières qui mériteraient d'être dans `Demo-X5` ?Aurait-on des systèmes / recombinaisons particulières qui mériteraient d'être dans `Demo-X5` ?Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3027Sortir partiellement vidjil-h-examples.should-get vers un nouveau stage de test2018-06-26T10:41:01+02:00Mathieu GiraudSortir partiellement vidjil-h-examples.should-get vers un nouveau stage de testDepuis ee762649 / f7c71ba pour #2635, les tests mettent 7 minutes de plus pour se lancer deux fois sur LIL-L4.
J'avais mis dans un premier temps `-x 10000` pour que cela soit plus rapide, mais le but est bien de montrer dans l'aide des...Depuis ee762649 / f7c71ba pour #2635, les tests mettent 7 minutes de plus pour se lancer deux fois sur LIL-L4.
J'avais mis dans un premier temps `-x 10000` pour que cela soit plus rapide, mais le but est bien de montrer dans l'aide des commandes utiles en situation réelle.
Cela pourrait encore s'empirer si on en met dans `doc/algo.org` (ce qui est souhaitable).
Pour %"Algo 2017.11" cela peut aller, mais pour la suite (et surtout pour notre ~"dev-ci" régulière), il faudrait sortir ces choses longues vers un stage appelé rarement comme valgrind.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3028La quatorzième séquence de X5 est en BUG, court DD2 non trouvé2020-05-20T16:18:52+02:00Mathieu GiraudLa quatorzième séquence de X5 est en BUG, court DD2 non trouvéTagguée depuis 5469353/348ba98, mais elle doit être en bug depuis longtemps.
`TRDV1*01 5//3 TRDD2*01 1//7 TRAJ29*01`, found instead `TRDV1*01 5/TCCTA/7 TRAJ29*01`
Vérifier cela (et peut-être on en parle déjà dans une autre issue ?). Ét...Tagguée depuis 5469353/348ba98, mais elle doit être en bug depuis longtemps.
`TRDV1*01 5//3 TRDD2*01 1//7 TRAJ29*01`, found instead `TRDV1*01 5/TCCTA/7 TRAJ29*01`
Vérifier cela (et peut-être on en parle déjà dans une autre issue ?). Étant donné que c'est notre jeu de démo principal, que ce soit sur `app` ou dans `demo/`, cette séquence mérite qu'on y prette attention :-)Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3165Ikaros : les séquences communiquées sont trop longues, voir ce qu'il faut garder2020-05-20T16:25:46+02:00Mikaël SalsonIkaros : les séquences communiquées sont trop longues, voir ce qu'il faut garderLa région 3'UTR communiquée par ~"PAR-Debré" est grande (près de 800nt) et il est impossible qu'un read couvre toute la région (plus un autre intron).
Cela pose des problèmes d'analyse (#3066), à cause du grand nombre de délétions, des ...La région 3'UTR communiquée par ~"PAR-Debré" est grande (près de 800nt) et il est impossible qu'un read couvre toute la région (plus un autre intron).
Cela pose des problèmes d'analyse (#3066), à cause du grand nombre de délétions, des séquences moins pertinentes peuvent-être préférées.
Même si idéalement ça serait mieux de garder toute la séquence on peut prévoir de n'en garder qu'une partie ou de la couper en plusieurs morceaux.
D'après les documents de ~"PAR-Debré" il y a souvent un point de cassure pas très loin de la fin du 3'UTR (autour d'une centaine de nt) et les exemples qu'ils nous ont donné correspondent à ce point de cassure. Dans leur document il y a un autre point de cassure beaucoup plus lointain dans le 3'UTR qui ne peut jamais être atteint par un read en ayant une amorce à la fin du 3'UTR.
Et en fait la question se pose également pour l'intron 1 et l'intron 1 var (entre 600 et 700nt de long).
Ça serait bien de voir avec ~"PAR-Debré" ce qu'il en est : peut-on on couper en plusieurs morceaux ? ne garder qu'une partie des séquences ? y a-t-il d'autres points de cassure qui sont possibles ?Algo -- ImportantThonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3214La recherche de recombinaisons inattendues n'utilise pas les version +up et +...2020-05-20T16:21:42+02:00Mikaël SalsonLa recherche de recombinaisons inattendues n'utilise pas les version +up et +down des germlinesDans un problème remonté par Aurélie (cf. https://serveur-vidjil.chrul.net/browser/index.html?set=32653&config=25) on a un réarrangement `+TRDV2 -TRDD2` ce qui devrait être trouvé comme étant unexpected. Sauf que, pour les unexpected, on...Dans un problème remonté par Aurélie (cf. https://serveur-vidjil.chrul.net/browser/index.html?set=32653&config=25) on a un réarrangement `+TRDV2 -TRDD2` ce qui devrait être trouvé comme étant unexpected. Sauf que, pour les unexpected, on n'utilise pas les parties amont et aval des gènes. Du coup il n'y a pas assez de signal pour détecter le TRDD2 (surtout qu'il n'y a que la partie intronique !).
Il faudrait donc les intégrer à la recherche de recombinaison unexepected. Dans ce cas j'imagine qu'il ne faudra prendre que les versions amont ou aval et pas du tout les versions restreintes aux gènes pour éviter des conflits (ce qui conduirait à des ambiguous).Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3229Nomenclature ERG2020-05-20T16:40:19+02:00Mathieu GiraudNomenclature ERGMême question que #3165 pour ERG: d'où vient la nomenclature `ERG-2F` ?
`ERG-R(3'5') ERG-Init-R` : il va s'arrêter à l'espace.
-> plutôt `ÈRG-Init-R`et `ERG-Seq-R` ? D'où viennent ces nomenclatures ?
Peut-on enlever les `(5'3')` parto...Même question que #3165 pour ERG: d'où vient la nomenclature `ERG-2F` ?
`ERG-R(3'5') ERG-Init-R` : il va s'arrêter à l'espace.
-> plutôt `ÈRG-Init-R`et `ERG-Seq-R` ? D'où viennent ces nomenclatures ?
Peut-on enlever les `(5'3')` partout : `ERG-2F`... ?
cc @flothoniAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3365should-vdj-to-tap ne vérifie pas correctement le locus2020-05-20T16:40:35+02:00Mikaël Salsonshould-vdj-to-tap ne vérifie pas correctement le locusDans `should-vdj-tests/igh-vdj.should-vdj.fa` le 3è test passe pour le locus alors qu'il n'est pas correct (IGH+ trouvé au lieu de IGH).
```
#(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 (IGHJ4*01, IGHJ4*02) [IGH] BUG
>1 100 101 12...Dans `should-vdj-tests/igh-vdj.should-vdj.fa` le 3è test passe pour le locus alors qu'il n'est pas correct (IGH+ trouvé au lieu de IGH).
```
#(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 (IGHJ4*01, IGHJ4*02) [IGH] BUG
>1 100 101 121 seed IGH+ SEG_+ 2.180678e-23 4.130931e-61/2.180678e-23
```Algo -- Importanthttps://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/4036Taille des .vidjil en -y all2021-04-06T11:17:00+02:00Mathieu GiraudTaille des .vidjil en -y allvdj#921
Sur LIL-L3-1 :
- .fastq.gz 330M
- .vidjil habituel, `-z 100`, 51M
- .vidjil `-y all`, **395M**
- .vidjil après ~"server-fuse", 200k
Pour 1 clone en `-y all` sans `-z`, il y a... `1.9 ko` dans le `.vidjil` ! En plus de `se...vdj#921
Sur LIL-L3-1 :
- .fastq.gz 330M
- .vidjil habituel, `-z 100`, 51M
- .vidjil `-y all`, **395M**
- .vidjil après ~"server-fuse", 200k
Pour 1 clone en `-y all` sans `-z`, il y a... `1.9 ko` dans le `.vidjil` ! En plus de `sequence`, on a `quality`, `affectSigns`, `affectValues`... Beaucoup pour quelque chose qui va juste être un +1 dans une distribution...
- Calculer certaines distributions dans ~cpp ? Faisable, mais pas très générique, et demande ensuite des changements dans ~"server-fuse" pour lire les distributions
- Limiter au maximum ces sorties (voir aussi #3911) ? Par exemple, au-delà du `-z`, ne mettre que l'`id` et la `sequence`. Relativement simple, devrait réduire déjà la taille d'un facteur 3-4.
- Ne rien faire, tant pis pour la place, de toute façon cela se compresse bien ?
- Ne rien faire, car de toute façon le but est un jour de faire `-z all`, et on aura encore plus de choses ? (voire AIRR pour tout ?)
```
{
"_average_read_length": [
377.0
],
"_coverage": [
1.0
],
"_coverage_info": [
"377 bp (100% of 377.0 bp)"
],
"germline": "IGH",
"id": "AAAAAGTGGGAACTACTTCGGGCGGCGCCCCACCTAGGCTACTGGGGGCC",
"reads": [
1
],
"seg": {
"affectSigns": {
"seq": "+++++++ + +++++++++++++++++++++++++++++++++++++ + + ++++++++++++++ +++ + +++++++++++++++++++++++ + ++++ + ++ + + +++++++++++++++++++++++ + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++ ",
"start": 1,
"stop": 377
},
"affectValues": {
"seq": "HHHHHHH______H______HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH___H__H___HHHHHHHHHHHHHH?HHH______H____HHHHHHHHHHHHHHHHHHHHHHH_________H?HHHH________________H______HH______H_________________H______HHHHHHHHHHHHHHHHHHHHHHH______H______HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH_________________________________________________________________hhhhhhhhhhhhhhh_____________",
"start": 1,
"stop": 377
},
"evalue": {
"val": "2.012178e-46"
},
"evalue_left": {
"val": "0.000000e+00"
},
"evalue_right": {
"val": "2.012178e-46"
},
"quality": {
"seq": "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!::::*:999+85883446878/--'-----'334933-36;665999+95!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!",
"start": 1,
"stop": 377
}
},
```
cc @flothoni @duezAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1020Multi-threader les parties critiques de vidjil.cpp2021-04-27T17:14:08+02:00Vidjil TeamMulti-threader les parties critiques de vidjil.cppNotons que cela ne changera pas le temps quand on envoie plusieurs fichiers (voire un "relaunch all"), comme il y a déjà les workers...
... mais ce sera très utile pour le lancement au coup par coup sur nos machines
***
Ping Wu (London):...Notons que cela ne changera pas le temps quand on envoie plusieurs fichiers (voire un "relaunch all"), comme il y a déjà les workers...
... mais ce sera très utile pour le lancement au coup par coup sur nos machines
***
Ping Wu (London): "Does vidjil programme support multiple-core run? I am looking ways to speed things up, as It still takes a couple of hours when running something like (...) on our cluster."
***
@nobodyAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1878Prise en compte de la central région pour la p-valeur : mauvaise idée pour ch...2020-12-04T12:07:46+01:00Vidjil TeamPrise en compte de la central région pour la p-valeur : mauvaise idée pour choix du meilleur locusSur l'exemple ci-dessous (IgJC/IgVC souris,), c'est le IgVC qui devrait moralement passer : le V est beaucoup plus beau (1e-110) que le J (1e-38). *Mais* le fait d'avoir pris la "central region" pour la e-valeur (2e23e720) donne finaleme...Sur l'exemple ci-dessous (IgJC/IgVC souris,), c'est le IgVC qui devrait moralement passer : le V est beaucoup plus beau (1e-110) que le J (1e-38). *Mais* le fait d'avoir pris la "central region" pour la e-valeur (2e23e720) donne finalement une plus mauvaise e-valeur pour le segment droit (C) et finalement pour IgVC.
Je suis prêt à parier qu'on retrouve la même chose sur certains DhJh / VDJ IGH humain.
```
>6
ACATTTGGGAAGGACTGACTCTCTGAGGAGACGGTGACCGTGGTCCCTGTGCCCCAGACATCGAAGTACCACCGTAATCCCCTCCTTCGAGCACAGTAGTATGTGGCAGTATCTGCAGTGTCCACACTGGTGATCTTGAGGAATACCTGGTTTCTGGAGGTATCCTTGGAGATTGTGAGCCGGCTCTTCAGGGATGGGTTATAGCGCTTGTCATCATCCCAGTAAATGTGTGCCAGCCACTCCAGACCCTTTCCTGAAGGCTGACGAATCCAGCTCACACCCATACCAGAAGTGCTCAGTGAAAACCCAGAGAAAGAACAAGTCAGACTGAGGGTCTGGGAGGACTGCAATATCCCAGGGCCAGACTCTTTCAGAGTAACCTGGGACAGGACATATGCAGGGACAATCAGCAGCAGGAATGAGGAAGTA
# 32 - VJ 0 405 407 428 seed IgJC SEG_- 9.531439e-38 7.491827e-38/2.039612e-38-c-c-c-c-c-c-c-c-c-c-c _ _ _ _ _ _ _ _ _ _ _-C-C-C-C _ _ _ _-C-C-C-C-C-C-C _ _ _ _ _ _-C _ _ _ _ _ _-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (...)
# 81 - VJ 0 339 406 428 seed IgVC SEG_- 2.634030e-23 2.634030e-23/3.652017e-110-c-c-c-c-c-c-c-c-c-c-c _ _ _ _ _ _ _ _ _ _ _-Q-Q-Q-Q _ _ _ _-Q-Q-Q-Q-Q-Q-Q _ _ _ _ _ _-Q _ _ _ _ _ _-Q-Q-Q-Q-Q-Q-Q-Q-Q _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _-C _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (...)
#>6 - VJ 0 405 407 428 seed IgJC SEG_- 9.531439e-38 7.491827e-38/2.039612e-38
```
***
Que faire ? Arrêter la central région si on rencontre un k-mer "4" ? plusieurs k-mers "4" ?
***
Pas sûr de comprendre le problème. N'est-il pas censé y avoir une région centrale aussi ? Pourquoi y a-t-il trois types d'affectation dans la séquence du bas (`-c`, `-Q`, `-C`) ?
***
En bas, c'est `5`=`V`=`-C`, `4`=`J`=`-Q`, `3`=`isotypes`=`-c`.
Ne pas oublier que les k-mers 4 sont dans l'index.
Mais bon, reformulation plus simple : le problème est le choix entre VDJ et DJ :
```
VVVVVV-------DDDDDD-------JJJJJJJ donc 33333(-----44444-----)5555
DDDDDD-------JJJJJJJ donc 33333(-----)5555
```
La zone centrale, entre parenthèses, est plus grande en haut qu'en bas, d'où une moins bonne e-valeur pour la région J en haut par rapport à en bas.
***
test 69ea8e6
***
ping
***
Choses en cours dans hotfix_evalue_incomplete_germline
Voir aussi aho et xxx (pénalité qui était implicite avant) ?
***
À voir d'ici 2016.09
***
Il y a eu le hack pour 2016.09.
À revoir tranquillement pour la prochaine releaseAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2003Le résultat de la segmentation change selon le contexte2019-11-23T05:29:48+01:00Vidjil TeamLe résultat de la segmentation change selon le contexteExemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutati...Exemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutation. Or si on exporte ces séquences et qu'on fait tourner le -c segment ou, même, Vidjil avec les mêmes options que sur le serveur (et même avec le vidjil présent sur le serveur)... on ne trouve pas la même segmentation.
Voir le test 88c6e92
***
N'y aurait-il pas un test de e-valeur pour le D qui dépende du nombre de reads ? (dans le test on passe de 2D trouvés avec un seul read, contre 0 D trouvé avec 11 reads)
***
> N'y aurait-il pas un test de e-valeur pour le D qui dépende du nombre de reads ?
Oui... et je pense bien que ce n'est pas un bug, mais une feature (introduite par e6ffb91). C'est précisément pour cela qu'est fait la E-value, non ? On fait strictement la même chose pour la FineSegmentation V/J ("multiplier" dans FineSegmenter()).
Le multiplier est
- nb_reads_for_evalue pour -c segment (pour V/J comme pour D)
- sort_clones.size() pour -c clones (Aïe, je me rends compte qu'il n'y est pas pour V/J, vidjil.cpp:1413 !!!)
Ce multiplier dit bien le nombre de segmentation que l'on fait, bref ce qu'il faut pour transformer la p-valeur en e-valeur.
Après, peut-être que le calcul des p-valeurs du D est trop stringent (voir tâche réouverte).
***
Et on a même une dépendance encore plus vicieuse que celle au nombre de reads : passer de -z 100 à -z 1000 peut faire dé-segmenter une séquence... C'est la vie. Voir si IgBlast a aussi ce type de comportement.
***
Pourquoi le multiplier devrait-il être le nombre de clones plutôt que le nombre de séquences réellement segmentées ?
***
Qu'on n'ait pas les mêmes résultats entre 10M de reads (fine segmentés) et 10 reads, je comprends bien : on change de plusieurs ordres de grandeur. Mais qu'on n'ait pas les mêmes résultats entre 1 read, 6 reads et 11 reads, j'ai plus de mal. Peut-être est-ce juste un problème de seuil de E-valeur
***
> Mais qu'on n'ait pas les mêmes résultats entre 1 read, 6 reads et 11 reads, j'ai plus de mal
Tout à fait, il faut comprendre ce qu'il se passe, et il y a peut-être des bugs
> Pourquoi le multiplier devrait-il être le nombre de clones plutôt que le nombre de séquences réellement segmentées ?
Oui, l'estimation actuelle est trop stricte. Est-ce que cela devrait être un max entre sort_clones.size() et max_clones ?
***
>Oui, l'estimation actuelle est trop stricte. Est-ce que cela devrait être un max entre sort_clones.size() et max_clones ?
J'aurais dit un min ;) Ce qui importe c'est le nombre de séquences qu'on va réellement segmenter.
***
Oui, tout à fait, un min !
J'étais plus en forme hier soir (cela m'a étonné d'ailleurs, c'était après 3 verres, ce a quoi je ne suis pas habitué :-)
***
@magiraud @mikael-sAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2249Trop de délétions dans les D : longueur négative2018-06-26T10:41:01+02:00Mikaël SalsonTrop de délétions dans les D : longueur négativeQuand on monte la e-valeur pour la FineSegmentation du D on peut se retrouver avec des D tellement courts qu'ils peuvent être de longueur négative.
Quand on monte la e-valeur pour la FineSegmentation du D on peut se retrouver avec des D tellement courts qu'ils peuvent être de longueur négative.
Algo -- Important