vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:38:43+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1625Dans le browser, cluster by ne fonctionne plus2016-11-29T14:38:43+01:00Vidjil TeamDans le browser, cluster by ne fonctionne plusPar exemple ici : http://rbx.vidjil.org/browser/index.html?patient=724&config=2
TypeError: m.clone(...).getV is not a function
TypeError: this.m.clusters[this.index] is undefined
TypeError: this.clusters[i] is undefined
***
> 366f6a323
...Par exemple ici : http://rbx.vidjil.org/browser/index.html?patient=724&config=2
TypeError: m.clone(...).getV is not a function
TypeError: this.m.clusters[this.index] is undefined
TypeError: this.clusters[i] is undefined
***
> 366f6a323
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1624export anaylsis : fichier sans le nom du patient/fichier original2021-10-21T17:41:09+02:00Vidjil Teamexport anaylsis : fichier sans le nom du patient/fichier originalBug non reproductible.
***
Lors de l'export de fichiers .analysis, celui-ci ne porte pas de nom de patient et s'enregistre sous ".analysis".
origine inconnue
***
@nobodyBug non reproductible.
***
Lors de l'export de fichiers .analysis, celui-ci ne porte pas de nom de patient et s'enregistre sous ".analysis".
origine inconnue
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1623bug lors d'un chargement file.analysis2016-11-29T14:38:42+01:00Vidjil Teambug lors d'un chargement file.analysisLe graphique chargé par défaut est coupé à la moitié.
Le bug se resout si l'on redimensionne la fenêtre.
***
corrigé depuis un moment, c'était un problème d'ordre de chargement dans require.js
***
@nobodyLe graphique chargé par défaut est coupé à la moitié.
Le bug se resout si l'on redimensionne la fenêtre.
***
corrigé depuis un moment, c'était un problème d'ordre de chargement dans require.js
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1621freebsd, pb avec Makefile, gmake ?2016-11-29T14:38:40+01:00Vidjil Teamfreebsd, pb avec Makefile, gmake ?Il n'y a plus que freebsd qui ne passe pas. Apparament utiliser gmake solutionnerait, mais est-ce que cela vient d'un changement récent sur freebsd ? Peut-être la mise à jour de freebsd ?
***
Je vois qu'il y a déjà "alias make=gmake" dan...Il n'y a plus que freebsd qui ne passe pas. Apparament utiliser gmake solutionnerait, mais est-ce que cela vient d'un changement récent sur freebsd ? Peut-être la mise à jour de freebsd ?
***
Je vois qu'il y a déjà "alias make=gmake" dans la config
***
oui, mais le alias ne marche pas sur Jenkins, j'avais effectivement bidouillé un truc (genre un lien symbolique bourrin entre make et gmake) qui a dû sauter avec la mise à jour. Je peux peut-être essayer de faire un truc plus robuste…
***
fef236d il suffit de passer ensuite MAKE=gmake quand on lance le make
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1619Bug 20150604, une séquence de S22 non segmentée sur certaines archis2016-11-29T14:38:39+01:00Vidjil TeamBug 20150604, une séquence de S22 non segmentée sur certaines archisÉvidemment, cela bloque la release... mais c'est rigolo, c'était non testé avant :-)
Les affects sont les même, mais, sur CentOS, on a "too few V inf inf"
Un calcul d'e-valeur qui se passe mal ?
***
Le souci vient de l'index_load, mal...Évidemment, cela bloque la release... mais c'est rigolo, c'était non testé avant :-)
Les affects sont les même, mais, sur CentOS, on a "too few V inf inf"
Un calcul d'e-valeur qui se passe mal ?
***
Le souci vient de l'index_load, mal calculé.
***
33188375.
Au passage, j'ai vérifié qu'il n'y a pas d'autre (1 << k) dans le code.
Les seuls autres shifts sont dans tools.h/cpp et ne sont pas dangereux.
***
et je ne sais pas si c'est bien de le faire, mais le "git push" depuis un slave CI fonctionne très bien :-)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1615Utilité du TIMEOUT ?2018-03-28T10:29:12+02:00Vidjil TeamUtilité du TIMEOUT ?Discuté hier avec Marc, à l'occasion d'un TIMEOUT sur un job de M. Diop (à 16:45)
Vidjil a duré 2h05... s'est bien terminé (derniers fichiers écrits à 16:50). Bref, on ne dirait pas que le TIMEOUT tue les fils, mais juste libère le work...Discuté hier avec Marc, à l'occasion d'un TIMEOUT sur un job de M. Diop (à 16:45)
Vidjil a duré 2h05... s'est bien terminé (derniers fichiers écrits à 16:50). Bref, on ne dirait pas que le TIMEOUT tue les fils, mais juste libère le worker (et donc ici n'a pas lancé le fuse à la suite).
-> le plus logique serait de tuer les fils
-> ou, sinon, ... enlever le TIMEOUT....
(au passage, il vaut 4 heures désormaix sur rbx)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1609Revoir la liste dans germline.js2021-11-08T16:16:22+01:00Vidjil TeamRevoir la liste dans germline.jsApparitions impromptues de différents TRD dans d'autres germlines.
***
Merci Florian pour la tâche :)
N'hésite pas à nous mettre en followers au moins. Ça nous permet d'être au courant de la création de la tâche et de son évolution.
***
...Apparitions impromptues de différents TRD dans d'autres germlines.
***
Merci Florian pour la tâche :)
N'hésite pas à nous mettre en followers au moins. Ça nous permet d'être au courant de la création de la tâche et de son évolution.
***
@nobody @mikael-s @Duez @magiraudhttps://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/1603top n'affiche pas le nombre de clones attendu2016-11-29T14:38:28+01:00Vidjil Teamtop n'affiche pas le nombre de clones attenduExemple : http://rbx.vidjil.org/browser/index.html?patient=609&config=2
Si on diminue le nombre de clones au minimum (top 5), au diag on a seulement deux clones affichés (mais le fichier .vidjil est correct et dans les top 5 on a bien 5 ...Exemple : http://rbx.vidjil.org/browser/index.html?patient=609&config=2
Si on diminue le nombre de clones au minimum (top 5), au diag on a seulement deux clones affichés (mais le fichier .vidjil est correct et dans les top 5 on a bien 5 clones pour chacun des points de suivi).
Cela ne semble pas être un problème du fuse.py mais de la visu.
***
Euh, pas reproductible ? (Ou l'exemple a changé ?) L'exemple a plein de clones mergés, c'est dur d'y voir clair, mais au Diag on voit bien plein de clones.
***
Au 4è point, on a que deux clones majoritaires et trois clones au total (en mettant le filter à 5).
***
ok
***
J'insiste : au 4è point, après un "reset user clones" et un top à 5, je vois bien... 5 clones, le dernier faisant 1.442%.
***
Ah oui… le reset user clones. On va dire que c'est bon alors.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1597Nombre de délétions incorrects dans le J et (surtout) incohérent avec celui d...2016-11-29T14:38:23+01:00Vidjil TeamNombre de délétions incorrects dans le J et (surtout) incohérent avec celui du gène D90776df (sur bonsai)
***
notable/0298, à comprendre, cela devrait fonctionner avec les changements récents
***
60a1562. On faisait n'importe quoi sur les jonctions J/D depuis... toujours (février 2013, dccec03).
***
@magiraud90776df (sur bonsai)
***
notable/0298, à comprendre, cela devrait fonctionner avec les changements récents
***
60a1562. On faisait n'importe quoi sur les jonctions J/D depuis... toujours (février 2013, dccec03).
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1596L'estimation du nombre de séquences est fausse pour un .gz2020-08-27T12:44:14+02:00Vidjil TeamL'estimation du nombre de séquences est fausse pour un .gzDans `bioreader.cpp`, dans `approx_nb_sequences_in_file(string f)`:
`float ratio = (float) filesize(f.c_str()) / (float) sequences->getPos();`
On ne prend pas en compte le cas où c'est compressé, bref la valeur est fausse à un facteur...Dans `bioreader.cpp`, dans `approx_nb_sequences_in_file(string f)`:
`float ratio = (float) filesize(f.c_str()) / (float) sequences->getPos();`
On ne prend pas en compte le cas où c'est compressé, bref la valeur est fausse à un facteur environ 4.
Mais bon, vu que cela sert pour la e-valeur, on n'est pas à un demi-ordre de grandeur près...
***
- voir si un igzstream permet de savoir où l'on est, en position compressée
- ou voir si on peut avoir accès à la taille décompressée de tout le fichier
- ou multiplier par 4 quand c'est un .gz
***
Évoqué de nouveau vendredi dernier. En plus fasta.gz et fastq.gz ne donnent pas les mêmes biais.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1595Un test ne passe pas chez Ping2016-11-29T14:38:22+01:00Vidjil TeamUn test ne passe pas chez Pingpython ../../tools/format_json.py -1
n'est pas allée jusqu'au bout. Pb de sync ? parenthésage ?
***
On dirait que la sortie standard de
!LAUNCH: ../../vidjil -z 0 -G ../../germline/IGH -w 60 -r 5 -b data ../../data/Stanford_S22.fasta ...python ../../tools/format_json.py -1
n'est pas allée jusqu'au bout. Pb de sync ? parenthésage ?
***
On dirait que la sortie standard de
!LAUNCH: ../../vidjil -z 0 -G ../../germline/IGH -w 60 -r 5 -b data ../../data/Stanford_S22.fasta ; cat out/data.vidjil
***
C'était donc un pb de version python
***
@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/1576Pas de représentative pour les séquences étiquetées2017-07-05T09:15:56+02:00Vidjil TeamPas de représentative pour les séquences étiquetéesstanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la conditio...stanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la condition de mettre -r 1.
En tout cas, c'est un bug.
***
f3cab65
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1573Coverage plus que douteux sur certains jeux de données2021-04-08T19:03:56+02:00Vidjil TeamCoverage plus que douteux sur certains jeux de donnéesSur les 20 premiers clones de Stanford S22, avec -w 60, près de la moitié ont un coverage <= 65%.
Et plusieurs sont à <= 55%.
***
Et avec -w 100, ce n'est pas vraiment mieux.
N'est-ce que des hypermutations somatiques, ou est-ce plus gr...Sur les 20 premiers clones de Stanford S22, avec -w 60, près de la moitié ont un coverage <= 65%.
Et plusieurs sont à <= 55%.
***
Et avec -w 100, ce n'est pas vraiment mieux.
N'est-ce que des hypermutations somatiques, ou est-ce plus grave ?
***
Titre changé : cela ne concerne pas que S22.
Autre exemple de jeux de données avec des coverages très douteux :
http://rbx.vidjil.org/browser/index.html?patient=786&config=26
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1565Les affect values ne sont pas alignées avec la séquence dans le segmenteur2021-04-08T08:30:17+02:00Vidjil TeamLes affect values ne sont pas alignées avec la séquence dans le segmenteurPar exemple ici http://rbx.vidjil.org/browser/?patient=481&config=26 et aller voir les affectations pour le clone à 1,5%
***
Je me sens fautif :)
***
Mais alors assigne-toi la tâche, pour soulager ta peine :)
***
ah oui, je me sens très ...Par exemple ici http://rbx.vidjil.org/browser/?patient=481&config=26 et aller voir les affectations pour le clone à 1,5%
***
Je me sens fautif :)
***
Mais alors assigne-toi la tâche, pour soulager ta peine :)
***
ah oui, je me sens très soulagé :)
***
à voir en novembre, avec IMGT/CSV
***
-> François nov/déc
***
François va regarder très bientôt.
***
@magiraud @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1564Longueur des reads d'un clone, prendre tous les reads en compte2016-11-29T14:37:58+01:00Vidjil TeamLongueur des reads d'un clone, prendre tous les reads en compteLa longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en ...La longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en être très loin).
Problème : on peut avoir des chimères, et elles vont se trouver parmi les premières séquences considérées. Par exemple, la fameuse séquence de Yann (patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11 clone TRDV1*01 -5/0/-3 TRDD2*01 -1/0/-7 TRAJ29*01), sur ma machine j'ai une représentative de 257 bp (58% of 438 bp). On pourrait se dire : c'est moche. En fait non.
On va dans le tableau de Yann et la taille en électrophorèse est 255 !
Bilan : il faudrait calculer la taille sur les reads stockés. Le BinReadStorage peut donner l'info (il peut même donner l'info pour tous les reads et pas seulement pour ceux qu'il stocke).
Maintenant qu'on propose le coverage comme un axe d'analyse en disant que c'est une bonne mesure de la qualité, c'est assez critique comme problème.
***
De mémoire, n'est-ce pas sur l'ensemble des 2000 premiers reads ? Est-ce que ce 2000 ne devrait pas atténuer les quelques chimères au début ? Est-ce que cela signifie, pour la séquence de Yann, que de nombreux reads chimériques sont là ?
Cela dit, même si c'est le cas, quand on a beaucoup de reads, les 2000 premiers peuvent faire sens "les plus gros"... Mais les résultats donc ne sont plus cohérents entre un gros clone 20 000 reads et un petit 2 000.
Donc tu as sans doute raison, il faudra faire cette moyenne sur *tous les reads*. Mais alors la coverage pourra être bien au-dessus de 1.00, s'il y a des petits reads...
***
Ben non, c'est pas sur les 2000 premiers… j'ai regardé dans le code. Tu avais mis le calcul de la longueur dans la boucle qui calcule la représentative. Mais pour le calcul de la représentative je ne parcours pas tous les reads. Je m'arrête au read qui m'a donné la meilleure représentative + stability_limit (30 par défaut).
***
Argh.
***
(Et j'ai donc mal répondu à Yann tout à l'heure.)
Et oui, ce serait bien de le faire sur l'ensemble des reads via BinReadStorage.
Idéalement instancier un objet Stats par BinReadStorage, cela permettra d'avoir plus que la longueur si un jour Stats fait mieux (la distribution par exemple)
***
Notons que le "av. len" dans les infos du run est lui bien calculé, sur toutes les reads (windowExtractor.cpp:57)
***
38cbe4d
Finalement le Stats est instancié dans windows.cpp : stats_by_windows, de la même manière que germline_by_windows, status_by_windows et seqs_by_windows.
(On devrait faire du ménage là-dedans, et bouger tous ces trucs dans le BinReads ?)
J'ai bien vu qu'il y avait aussi des calculs de longueur dans BinReads, on aurait pu le faire avec (voir tâche Stats / BinReads), mais je maîtrisais mieux l'autre côté :-)
***
Il y a quelque chose qu'on n'utilise pas assez dans producteev c'est le « in progress ». Avant d'aller manger j'avais un code qui faisait ça (en passant par BinReadStorage), mais qui ne compilait pas encore. Ni moi, ni toi n'avons utilisé le « in progress », d'où le doublon.
***
oui, tout à fait.
***
désolé...
***
@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/1551Impossible d'afficher la fenêtre d'information à l'intérieur d'un cluster2017-04-06T18:25:10+02:00Vidjil TeamImpossible d'afficher la fenêtre d'information à l'intérieur d'un cluster
***
@Duez
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1550selected locus est initialisé avec le nombre de segmented reads2016-11-29T14:37:48+01:00Vidjil Teamselected locus est initialisé avec le nombre de segmented readsAlors qu'en fait la somme des reads segmentés sur les locus montrés ne fait pas forcément le nombre total de reads segmentés (il peut y avoir des systèmes non montrés avec des clones n'apparaissant pas dans le top 100).
Pour voir le bu...Alors qu'en fait la somme des reads segmentés sur les locus montrés ne fait pas forcément le nombre total de reads segmentés (il peut y avoir des systèmes non montrés avec des clones n'apparaissant pas dans le top 100).
Pour voir le bug : désélectionner des locus et en ré-sélectionner.
***
et de plus, si on déselectionne tout et resélectionne tout, le selected est... supérieur au nombre de segmented reads
http://rbx.vidjil.org/browser/index.html?patient=444&config=11
***
Apparemment ce n'est plus reproductible.
L'exemple précédent était très vieux.
Plus de soucis : http://rbx.vidjil.org/browser/index.html?patient=444&config=25
J'ai bien l'impression que, maintenant, à l'init, la somme est directement le segmented reads. Mikaël, tu confirmes ?
***
Oui ça semble bon. Marqué terminé.
***
@magiraud @mikael-s