vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:34:04+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1272Algo multi-système 1.9, faire passer les tests, k-mers ambigus2016-11-29T14:34:04+01:00Vidjil TeamAlgo multi-système 1.9, faire passer les tests, k-mers ambigusIl n'y a finalement très peu de tests en multi-système.
Faire un fichier avec des reads devant être segmenté un peu partout.
***
Branche multi, b5fa7e8, le test est fait... reste à le faire passer :)
Solutions possibles :
- monter DE...Il n'y a finalement très peu de tests en multi-système.
Faire un fichier avec des reads devant être segmenté un peu partout.
***
Branche multi, b5fa7e8, le test est fait... reste à le faire passer :)
Solutions possibles :
- monter DETECT_THRESHOLD
- graines plus longues
- k-mots communs interdits : une manière simple serait de faire une fonction IKmerStore::remove (ou annihilate, ou ...) qui supprime de l'index les k-mers du fasta donné.Sur l'index TRG, on appellerait remove(IGH), remove(IGK)...
***
On voit cela plus tard, peut-être en janvier, avec k-mers communs et index commun ou pas.
***
Solution proposée :
- k-mots communs interdits : une manière simple serait de faire une fonction IKmerStore::remove (ou annihilate, ou ...) qui supprime de l'index les k-mers du fasta donné.Sur l'index TRG, on appellerait remove(IGH), remove(IGK)...
- (et idéalement, l'avoir aussi à distance 1)
1) C'est relativement facile à faire
2) Cela permet, dans notre code actuel, d'être quasiment fonctionnellement équivalent à ce qu'on sera quand on aura au début du seul index/automate.
- Fonctionnellement, car on sera toujours beaucoup plus long.
- et 'au début', car après l'automate permettrait de partir dans des graines bien plus différentes par V/J
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1266Taille de fenêtre en IGH : cas où 50 ne suffit pas ?2018-11-20T09:18:26+01:00Vidjil TeamTaille de fenêtre en IGH : cas où 50 ne suffit pas ?La taille des fenêtres en multi-système est globale. À rajouter dans germlines et voir les implications dans windowExtractor ou la représentative.
***
On remet donc le doigt dessus.
C'est embêtant si on est amené à comparer des données p...La taille des fenêtres en multi-système est globale. À rajouter dans germlines et voir les implications dans windowExtractor ou la représentative.
***
On remet donc le doigt dessus.
C'est embêtant si on est amené à comparer des données produites par des configs différentes.
Au minimum : rajouter dans germline, pour qu'en multi IGH soit aussi à 60.
Ou sinon, grande homogénéisation, tout le monde à 40, 50, ou 60.
***
On pourrait décider de cela avant 2015.02.
Je penche pour la grande homogénéisation.
***
à décider pour 2015.02
***
ok, on voit cela pour 2015.04
***
plus tard...
***
Au fait, j'ai bien vu hier que la propagande officielle indique "50" partout :)
***
2d80348, 50 pour tout le monde.
Il n'y a "plus" que la transition server à voir, autre tâche.
***
Euh… c'est pas un peu dangereux de mettre ça sur master alors qu'on n'a pas de moyen de faire la transition ? Ça veut dire qu'il ne faut surtout pas changer la version de vidjil sur rbx
***
rbx est sur 2015.04, sur un version stable, oui il faudra faire attention à ne pas changer tout de suite... master sert à cela :)
***
au passage, master est désynchronisé avec rbx depuis déjà quelque temps , surtout avec le -e 1.0 par défaut mais aussi le -t 100
***
50bp, est-ce bien raisonnable ? Oui je sais on n'a plus ou moins tranché mais sans vraiment avoir de recul sur des données.
Mais quand je vois ça : http://rbx.vidjil.org/browser/?patient=481&config=26 (clone à 1,5% et afficher la fenêtre), si le D était un peu plus grand ou moins grignoté, ça fait un peu peur…
***
Par contre un exemple qui fait très peur, sur le même jeu de données, c'est le clone à 0,671% : on a du D, du J et un seul nucléotide dans le N.
***
Dans ce cas on pourrait passer à 60... mais cela ne fait que 5 de plus de cahque côté, on va toujours avoir des cas limite même à 60.
***
Mmmm…. on a déjà eu du mal à prendre cette décision 50 (n’oublions pas que c’est 40 en ce moment). Par contre, on pourrait imaginer un process qui met un warning sur certains clones. En sortie du FineSegmenter, on devrait savoir si on est dans un cas limite ou non.
Et ce problème est (dans certains cas) indépendant de la taille de la fenêtre : Si on a un V/J collé avec 0 zone de N, ce sera très limite même avec une fenêtre de taille 100 :-) On doit mettre un gros warning dessus, et permettre de revenir sur les reads.
***
N'oublions pas que c'est 60 en IGH pour l'instant… (4^5 = 1024).
Ce sont des cas que j'ai vus sans trop chercher, parmi les 100 clones du jeu de données que j'avais en face de moi. C'est ça qui fait peur. Évidemment il y aura toujours des cas limites, mais là je n'ai pas épluché tous nos résultats avec de l'IGH pour tomber sur LE cas limite.
***
Exemple 0481 mis dans notable.
Pour cet exemple, on est finalement sauvé (euh ? une délétion au troisième nucl de J) par ce que voit IMGT.
Mais cela n'enlève pas le problème, on doit alerter si faible spécificité de la fenêtre (tâche dédiée).
Être à 60 permet d'avoir 4^5... si on récupère bien du N sur un des côtés, ce qui est loin d'être sûr.
Maintenant, reste la question du -w par défaut.
Les utilisateurs en multi doivent avoir la même qualité que ceux en IGH seul, et la qualité doit être au top pour tout le monde.
On teste le -w 50 depuis longtemps en multi... et... les tests passent.
***
Revu une trentaine de clones des utilisateurs IGH (Florian, Eva, Jack). Aucun soucis pour le -w 50. Mais plusieurs soucis pour certaines spécificités avec zéro N qu'un -w 60 ne résoud pas.
Tranché, c'est douloureux. Je maintiens "The default value (=-w 50=) was selected to ensure a high-quality clone gathering."
Mise en prod server : si on hésite (non, il ne faut pas...), on pourra mettre -w 60 pour la config IGH.
Tâche renommé, le pb est IGH.
***
La nouvelle tâche S22 m'a fait encore plus peur... mais on est bien sur autre chose que les discussions 50/60.
***
(sur rbx, IGH est encore en -w 60, tout le reste en -w 50 par défaut, sauf les configs [old])
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/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/1168Algo multi-systèmes 1.5 : heuristique choisir le bon système en premier2016-11-29T14:32:41+01:00Vidjil TeamAlgo multi-systèmes 1.5 : heuristique choisir le bon système en premierTransformé dans la tâche optimisation germlines.data
***
@magiraud @mikael-sTransformé dans la tâche optimisation germlines.data
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/981alertes à l'utilisateur en fonction de certaines raisons de non-segmentation2018-11-20T09:34:53+01:00Vidjil Teamalertes à l'utilisateur en fonction de certaines raisons de non-segmentation
***
@nobody
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/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/978segmenter.cpp: séparer UNSEG_strand en deux cas (vraiment pas beaucoup d'affe...2021-03-31T17:26:04+02:00Vidjil Teamsegmenter.cpp: séparer UNSEG_strand en deux cas (vraiment pas beaucoup d'affect ou pas)On voit souvent du STRAND (mail Manuel, mais aussi d'autres)... et peut-être que cela ne veut pas dire grand chose. Et c'est un de nos premiers tests.
- séparer en deux cas : c'est le minimum
- et, même, je me demande quelle est main...On voit souvent du STRAND (mail Manuel, mais aussi d'autres)... et peut-être que cela ne veut pas dire grand chose. Et c'est un de nos premiers tests.
- séparer en deux cas : c'est le minimum
- et, même, je me demande quelle est maintenant la pertinence de la détection de strand (et le RATIO_STRAND à 5 semble gros). Comme on a une e-valeur, ne devrait-on pas faire les deux côtés et prendre la meilleure ?
***
73178e8
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/977diagnostic sur toutes nos séquences2018-11-20T09:33:19+01:00Vidjil Teamdiagnostic sur toutes nos séquences
***
#976
***
#976https://gitlab.inria.fr/vidjil/vidjil/-/issues/976Séquences segmentées mais fenêtres non trouvées (J trop court)2018-11-20T09:33:12+01:00Vidjil TeamSéquences segmentées mais fenêtres non trouvées (J trop court)Il y a un biais sur les séquences pour lesquelles on ne trouve pas les fenêtres et on peut donc passer à côté de certains clones.
***
Solutions possibles :
– raccourcir la fenêtre
– décaler la fenêtre vers la gauche (tout le temps, ou p...Il y a un biais sur les séquences pour lesquelles on ne trouve pas les fenêtres et on peut donc passer à côté de certains clones.
***
Solutions possibles :
– raccourcir la fenêtre
– décaler la fenêtre vers la gauche (tout le temps, ou ponctuellement si on ne trouve pas de fenêtre)
***
Danger si on fait cela tout le temps (création de plein de fenêtes shiftées, rend plus complexe clustérisation manuelle ou auto). Pourquoi pas en option.
En tout cas, au moins bien dire à l'utilisateur.
***
Pour moi, ce n'est pas un bug, mais de mauvaises données du séquenceur. Lien "qualité", le dire à l'utilisateur. À rediscuter à froid dans quelque temps.
***
label control-bio: c'est un truc à surveiller de qualité
***
#977
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/940faire aussi CMD_GERMLINES avec le MultiGermline2016-11-29T14:29:34+01:00Vidjil Teamfaire aussi CMD_GERMLINES avec le MultiGermline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/939Le Germline choisi est transféré à vidjil.cpp2016-11-29T14:29:34+01:00Vidjil TeamLe Germline choisi est transféré à vidjil.cpp
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/938réparer les tests unitaires :)2016-11-29T14:29:34+01:00Vidjil Teamréparer les tests unitaires :)
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/937MultiGermline passé de vidjil.cpp à segmenter.cpp2016-11-29T14:29:34+01:00Vidjil TeamMultiGermline passé de vidjil.cpp à segmenter.cpp
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/936FineSegmenter prend un Germline2016-11-29T14:29:34+01:00Vidjil TeamFineSegmenter prend un Germline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/935FineSegmenter considère le bon Germline2016-11-29T14:29:34+01:00Vidjil TeamFineSegmenter considère le bon Germline
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/934AffectAnalyzer renvoie l'info du Germline choisi2016-11-29T14:29:34+01:00Vidjil TeamAffectAnalyzer renvoie l'info du Germline choisi
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/933AffectAnalyzer prend un MultiGermline, coeur de l'heuristique2016-11-29T14:29:34+01:00Vidjil TeamAffectAnalyzer prend un MultiGermline, coeur de l'heuristique
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/932à parser depuis germline.data2016-11-29T14:29:34+01:00Vidjil Teamà parser depuis germline.data
***
#930
***
#930https://gitlab.inria.fr/vidjil/vidjil/-/issues/931définir l'objet Germline, MultiGermline2016-11-29T14:29:34+01:00Vidjil Teamdéfinir l'objet Germline, MultiGermline
***
#930
***
#930