vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-04-16T16:17:49+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2023Merge reads et .fasta2018-04-16T16:17:49+02:00Vidjil TeamMerge reads et .fastaÉchange entre Shun et Mikaël :
> The read merging failed because you provided FASTA files. When merging reads, you should provide FASTQ files only. We should specify that limitation more clearly. You cannot provide FASTA files if you wa...Échange entre Shun et Mikaël :
> The read merging failed because you provided FASTA files. When merging reads, you should provide FASTQ files only. We should specify that limitation more clearly. You cannot provide FASTA files if you want to merge the reads.
On devrait pouvoir utiliser le merge même avec des .fasta (quitte à faire un .fastq bidon). En attendant, j'ai renommé la config pre-process en "Merge paired-end reads (+R2) [only .fastq / .fastq.gz files]".
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2022Tester l'affichage des "smaller clones"2017-11-18T12:31:19+01:00Vidjil TeamTester l'affichage des "smaller clones"Ex ici : http://rbx.vidjil.org/browser/index.html?patient=4011&config=25
Plus de smaller clones dans la liste des clones. Où sont-ils passés ?
***
Cela vient de 2095ef3152, je ne sais pas encore pourquoi.
***
7525317c2
***
Ce serait bien...Ex ici : http://rbx.vidjil.org/browser/index.html?patient=4011&config=25
Plus de smaller clones dans la liste des clones. Où sont-ils passés ?
***
Cela vient de 2095ef3152, je ne sais pas encore pourquoi.
***
7525317c2
***
Ce serait bien de faire un test fonctionnel : vérifier qu'un clone virtuel "smaller clones" apparait dans la liste, mais pas dans le scatterplot.
(Cela dit, un jour on aura des clones "virtuels" qui iront aussi dans le scatterplot, ceux rajoutés manuellement...)
***
a11c031 (le commit montre la simplicité des tests Watir ;))
Cela va casser les tests à cause de https://producteev.com/workspace/t/58220195b0fa09ce7e000000
***
@nobody @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2021Sauvegarde de l'analyse ne fonctionne pas2017-07-05T09:15:55+02:00Vidjil TeamSauvegarde de l'analyse ne fonctionne pasNotification mise ;)
Je suis dessus pour ~40min
***
Notification mise ;)
Je suis dessus pour ~40min
***
Sur dev.vidjil.org, j'ai modifié un self.m.samples.ids en self.m.samples.id dans databse.js, ligne 720 et ça fonctionne.
Mais ce n'es...Notification mise ;)
Je suis dessus pour ~40min
***
Notification mise ;)
Je suis dessus pour ~40min
***
Sur dev.vidjil.org, j'ai modifié un self.m.samples.ids en self.m.samples.id dans databse.js, ligne 720 et ça fonctionne.
Mais ce n'est pas une ligne modifiée récemment, donc ce n'est pas ça qui doit causer la nouveauté du problème.
Je n'arrive pas à trouver où ces ID sont définis dans le .js ni si quelquechose a récemment été modifié dans ce sens. Marc, Ryan une idée ?
Je ne suis plus dessus, vous avez la main ;)
***
Sur dev.vidjil.org, j'ai modifié un self.m.samples.ids en self.m.samples.id dans databse.js, ligne 720 et ça fonctionne.
Mais ce n'est pas une ligne modifiée récemment, donc ce n'est pas ça qui doit causer la nouveauté du problème.
Je n'arrive pas à trouver où ces ID sont définis dans le .js ni si quelquechose a récemment été modifié dans ce sens. Marc, Ryan une idée ?
Je ne suis plus dessus, vous avez la main ;)
***
C'est bien cette modification qui allait bien. Ou du moins c'était la plus simple. Le code de get_data (default.py) avec changé en octobre, donc quand j'ai mis prod-server à jour avec dev, le save_analysis. J'aurais pu remettre le bon champ "ids" dans le get_data mais il y avait plus de lignes à changer (au moins le double !).
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2020Clone majoritaire qui disparait avec un nombre plus important de samples2019-08-20T10:34:34+02:00Vidjil TeamClone majoritaire qui disparait avec un nombre plus important de samplesExemple : Dans le deuxième il y a un clone très clair en TRG qui disparait dans le premier cas
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&custom=16753&custom=16762&custom=16771&custom=16780&
http:...Exemple : Dans le deuxième il y a un clone très clair en TRG qui disparait dans le premier cas
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&custom=16753&custom=16762&custom=16771&custom=16780&
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&
***
Cela semble dépendant de l'ordre. Essayé en local : selon les fichiers mis en premier les résultats obtenus ne sont pas les mêmes…
***
C'est ma faute : 0d40d04c7975403b691781b50eafef9efb1dced5
***
Je ne suis pas sûr de comprendre, merci en tout cas d'avoir trouvé.
Proposition : dans l'urgence, reverter simplement ce commit plutôt que de chercher à corriger. Puis changer une batterie de tests et changer le fonctionnement de fuse.py tranquillement.
***
Moi non plus je ne comprends pas.
***
Ah, c'est plus embêtant... Peux-tu mettre un test quelque part, même très informel, où on voit ce qui ne va pas ?
***
Commit réverté, utilisateur prévenu;
***
Merci ! Est-ce que cela ne vaudrait pas le coup de faire une notification sur le serveur pour tous ?
***
La mise à jour de prod-server sur rbx n'a été faite que hier et depuis il n'y a que Kiel qui a utilisé le fuse (ou lancé des jobs), du coup je ne pense pas que ce soit utile.
***
ok, parfait
***
@Duez @RyanHerb @mikael-s @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2018L'alignement multiple ne se fait pas nécessairement par rapport à la première...2016-11-29T14:43:17+01:00Vidjil TeamL'alignement multiple ne se fait pas nécessairement par rapport à la première séquencecf. mail d'Aurélie 24/10 8h55
***
2998886
***
@mikael-scf. mail d'Aurélie 24/10 8h55
***
2998886
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2017Lorsqu'on affiche les données d'un run, les courbes sont affichées (et séparé...2022-06-20T12:07:06+02:00Vidjil TeamLorsqu'on affiche les données d'un run, les courbes sont affichées (et séparées) par dateCe n'est probablement pas pertinent pour un run (où plusieurs choses sans rapport peuvent être mélangées). Exemple ici : http://rbx.vidjil.org/browser/?sample_set_id=16349&config=25
***
@nobodyCe n'est probablement pas pertinent pour un run (où plusieurs choses sans rapport peuvent être mélangées). Exemple ici : http://rbx.vidjil.org/browser/?sample_set_id=16349&config=25
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2016Charger des fichiers BAM2017-07-07T15:46:09+02:00Vidjil TeamCharger des fichiers BAMLes fichiers BAM sont directement générés par les séquenceurs Ion apparemment, cela éviterait de passer par le FASTQ. Le fichier BAM est une version compressée du fichier SAM. Il vaut mieux passer par une bibliothèque externe pour les li...Les fichiers BAM sont directement générés par les séquenceurs Ion apparemment, cela éviterait de passer par le FASTQ. Le fichier BAM est une version compressée du fichier SAM. Il vaut mieux passer par une bibliothèque externe pour les lire… Il existe par exemple htslib mais elle fait plein d'autres choses https://github.com/samtools/htslib (il y en a probablement d'autres)
***
@magiraud @mikael-sAlgo 2017.07Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2015Compresser les fichiers .vidjil et .fused2023-03-28T16:09:20+02:00Vidjil TeamCompresser les fichiers .vidjil et .fusedLes fichiers prennent de la place sur disque mais se compressent très bien. Un gros fichier fused de 150Mo (Kiel inside) se compresse à environ 5 Mo avec gzip.
Cela nous permettrait d'économiser pas mal d'espace disque. Sur le réseau on ...Les fichiers prennent de la place sur disque mais se compressent très bien. Un gros fichier fused de 150Mo (Kiel inside) se compresse à environ 5 Mo avec gzip.
Cela nous permettrait d'économiser pas mal d'espace disque. Sur le réseau on ne devrait rien gagner puisque normalement les connexions sont déjà gzippées.
Je me souviens que ça avait été discuté à une époque avec Marc qui avait dit que ce n'était pas un problème. À voir comment. Peut-on décompresser côté client ? Faut-il décompresser côté serveur ? Peut-on avoir en parallèle des fichiers gzippés et d'autres non ?
***
Une autre manière de le voir : les sauvegardes de /mnt/result/results prennent à l'heure actuelle 14G alors que les données sur disque utilisent plus de 100G.
***
Très bonne idée, idéalement il faudrait que le client puisse de manière transparente prendre un .vidjil ou un .vidjil.gz.
(Mais ce n'est pas si urgent, on arrive à libérer de la place, /results est petit comparé à d'autres choses.)
***
@RyanHerb @DuezWeb 2023.10https://gitlab.inria.fr/vidjil/vidjil/-/issues/2014Le merge semble ne pas fonctionner2016-11-29T14:43:14+01:00Vidjil TeamLe merge semble ne pas fonctionnerEn réalité il fonctionne, mais les bulles ne disparaissent pas et la liste affiche un – alors que le clone est « replié », ce qui donne l'impression que le merge ne fonctionne pas.
***
75e01801 c'était pour réparer les tests fonctionnels...En réalité il fonctionne, mais les bulles ne disparaissent pas et la liste affiche un – alors que le clone est « replié », ce qui donne l'impression que le merge ne fonctionne pas.
***
75e01801 c'était pour réparer les tests fonctionnels.
***
Oui mais ça ne le corrige pas dans le bon sens ;) Le clic sur le bouton merge ne provoque pas une « fusion » des bulles, ce qui est un peu contre-intuitif.
***
Le commit mentionné était à l'origine du problème, je l'ai revert, donc le merge fonctionne à nouveau, mais le test qui était réparé par le commit est de nouveau en erreur.
***
merci, super !
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2013Un mauvais commit traine dans dev, à rebaser2017-02-01T18:48:35+01:00Vidjil TeamUn mauvais commit traine dans dev, à rebaser1bba34fa35 (XXXX choses qui trainaient dans ~/git/prod-server/ XXX) s'est (encore) retrouvé sur dev :-)
***
@magiraud @RyanHerb @mikael-s1bba34fa35 (XXXX choses qui trainaient dans ~/git/prod-server/ XXX) s'est (encore) retrouvé sur dev :-)
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2012should-to-tap.sh / should-vdi-to-tap.py : option verbose, -v/-vv ?2022-06-20T18:12:36+02:00Vidjil Teamshould-to-tap.sh / should-vdi-to-tap.py : option verbose, -v/-vv ?Il m'arrive très souvent, pour enquêter sur un test, d'aller voir le .log pour retrouver la commande vidjil et la lancer, éventuellement modifiée.
Avec should-to-tap.sh, on voit la commande lancée. Ce serait bien d'avoir une option dans...Il m'arrive très souvent, pour enquêter sur un test, d'aller voir le .log pour retrouver la commande vidjil et la lancer, éventuellement modifiée.
Avec should-to-tap.sh, on voit la commande lancée. Ce serait bien d'avoir une option dans should-vdj-to-tap.py pour voir cela ou de le mettre par défaut (mais encombre la sortie)
Et ce serait bien, pour les deux, d'avoir une option pour voir directement le log. Je pinaille, peut-être est-ce du confort juste pour moi.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2011Ne pas lancer fuse quand le nombre de samples est trop important ?2017-05-22T17:09:00+02:00Vidjil TeamNe pas lancer fuse quand le nombre de samples est trop important ?Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : u...Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : un fuse sur 100 fichiers prend du temps).
De plus le fuse est lancé autant de fois qu'il appartient à de sample sets (donc au moins 2, non ?).
***
753e78c : On ne garde que les 16 premiers. C'est peut-être un peu brutal de faire cela au niveau de fuse.py, mais bon, cela renvoie tout de même un .vidjil pour une visualisation sur les premiers échantillons.
***
Ça me paraît un peu rapide. On n'a pas vraiment de solution pour « degrade gracefully ».
Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers ? Comment on fait pour avoir les autres ? Le custom fuse ne permet pas de sauvegarder les analyses.
Côté serveur il faudrait avertir les utilisateurs qu'ils ne verront que 16 fichiers.
Il y a des utilisateurs avec plus de 16 fichiers, et ça peut faire sens : http://rbx.vidjil.org/browser/index.html?patient=790&config=25
Le problème est surtout avec les runs ou avec Kiel qui met plein d'échantillons différents dans un même patient. Les clones n'ont rien à voir d'un échantillon à l'autre et donc on se retrouve avec des dizaines de milliers de clones dans le fichier. Une autre solution peut être de réduire le top lorsque le nombre de fichier augmente.
***
D'autant plus que l'utilisateur qui nous pause problème à ce sujet n'utilise pas le fuse automatique mais plutôt le custom_fuse, non ? Ne pourrait-ton pas simplement avoir des configs qui fusent et d'autres non ?
***
Oui, effectivement ça serait une solution simple de proposer à Kiel une config sans fuse (on sait faire ça ?).
***
Je pense qu'il y a un bout de code à changer pour que le run accepte de ne pas fuse, mais oui je pense que c'est possible.
***
Oui, le coup de la config en plus, pourquoi pas !
Ou même... la config par défaut pourrit faire 16 fichiers au plus, et on a une config spéciale si quelques gens veulent avoir beaucoup de points.
> « degrade gracefully ».
> Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers
C'est une bonne question. Mais que cela soit oui ou non, c'est un "degrade gracefully" si on montre 16 points... et si on dit qu'on a une autre config si vraiment on veut avoir d'autre chose.
Enfin, quitte à avoir une autre config, on pourrait aussi régler plus finement les paramètres du fuse (top et autres).
***
Ça me semble plus simple de demander à Kiel d'utiliser une config sans fuse, plutôt que de mettre en place le nécessaire pour avertir les utilisateurs que quand il y a plus de X fichiers ils ne verront pas tous les résultats et qu'ils doivent lancer avec une autre config (en espérant qu'il y ait une config correspondante avec un fuse infini).
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant), j'ai envie de savoir si j'ai de la conta entre mes 20 fichiers pas entre 16 fichiers plus ou moins choisis aléatoirement (dont l'ordre dépendra de l'upload).
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante (et même pas besoin de demander à Kiel d'utiliser une autre config, on peut mais ça n'est pas indispensable).
***
> plutôt que de mettre en place le nécessaire pour avertir les utilisateurs
Je ne suis pas d'accord sur ce point, c'est très simple avec les notifications. Cela permet d'avoir, par défaut, un comportement correct pour la majorité des utilisateurs, et de les inciter à utiliser correctement les patients. (Et s'ils leur manquent quelque chose, c'est facile de rajouter une config pour un user, pour des bonnes raisons). Je préfère être sûr, dès maintenant, que tous les utilisateurs font ce qu'il faut (et traiter au cas par cas quelques cas comme Kiel) plutôt que de retomber dans quelques mois sur un autre utilisateur qui fera pareil.
> Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant)
Oui, tout à fait ! 16 est un exemple, cela peut être 32 ou 42 :-) Dans tous les cas, au-delà de 8-10 simples, on devrait cacher sur le graphe (cf une autre tâche). Et encore plus si on fait des SampleSets : peut-être que quelqu'un aura un SampleSet de 100/200 patients correspondant à un truc particulier... (Mais lance-t-on les mêmes configs dans tous les SampleSet ? Ce n'est pas obligé.)
> En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante
Oui, c'est aussi possible, par exemple (1000 / #samples)... mais on a déjà du mal à expliquer ce qu'est notre top, alors là cela va être encore plus dur. Ou alors, 1000 tant que #samples < 8, puis ensuite cela descend.
***
Par défaut, met-on le -f dans fuse.py à 0 et on fait une config pour Kiel où le -f est à 1 (ou X) ?
***
Kiel vient d'ajouter une centaine de fichiers → –10 Go
***
@magiraud @RyanHerb @mikael-sWeb 2017.05Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2010Erreur lors de l'annulation d'upload2016-12-13T17:46:24+01:00Vidjil TeamErreur lors de l'annulation d'uploadLorsque j'annule un upload en cours sur dev, j'ai l'erreur suivante dans la console :
TypeError: db.warning is not a function
db.warning("upload canceled - " + this.queue[id].filename)
Et l'upload n'est pas annulé.
***
@RyanHerbLorsque j'annule un upload en cours sur dev, j'ai l'erreur suivante dans la console :
TypeError: db.warning is not a function
db.warning("upload canceled - " + this.queue[id].filename)
Et l'upload n'est pas annulé.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2009CSS/JS manquant pour l'admin de dev.vidjil.org2016-11-29T14:43:10+01:00Vidjil TeamCSS/JS manquant pour l'admin de dev.vidjil.orgL'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le pass...L'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le passage au https qui a cassé le css de l'interface admin
***
Et c'est réparé
***
Merci :)
Pour l'historique, quel était le problème ?
***
la règle 'static' de http que j'ai migrée en https. En fait les css de admin passaient déjà en https et le nouveau routage introduisait une erreur
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2008Redirection de / vers /browser en HTTPS2016-11-29T14:43:09+01:00Vidjil TeamRedirection de / vers /browser en HTTPSEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2007Empêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espac...2020-01-08T17:39:47+01:00Vidjil TeamEmpêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espace disqueOn sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on...On sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on ne se retrouve jamais avec un disque plein et pas avec des jobs en failed parce qu'il n'y a plus d'espace disque.
Par contre, prévoir de spammer les admins dès que la limite est atteinte pour qu'ils fassent quelque chose (en générant un ticket web2py ?)
***
C'est en prod. On a une limite en pourcentage qui se fixe dans defs.py. Actuellement réglé sur 1%. La limite est commune pour toutes les partitions mais la vérification est spécifique (donc il peut s'avérer que l'upload soit bloqué, mais pas les runs
***
Merci Ryan.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2006ECMAScript v6 ? Version du DOM ?2022-06-10T12:00:56+02:00Vidjil TeamECMAScript v6 ? Version du DOM ?83a112a, Mikael:
segmenter.js: includes() method is a bit new
(…) It is part of the ECMAScript 2016 standard while indexOf is part of the
ECMAScript 5.1 standard (2011).
De la même manière que notre code C++ est du C++11 (et pa...83a112a, Mikael:
segmenter.js: includes() method is a bit new
(…) It is part of the ECMAScript 2016 standard while indexOf is part of the
ECMAScript 5.1 standard (2011).
De la même manière que notre code C++ est du C++11 (et pas du C++14), nous devrions décider quelle version d’ECMAScript nous utilisons.
Et peut-on le forcer dans les tests unitaires / fonctionnels ?
Cela nous aiderait peut-être à répondre à #1077.
***
Le phantomjs sur Jenkins n'étant pas très à jour, du javascript 2016 ne passera pas dessus (c'est ce qui m'est arrivé)
Mais ça ne répond pas vraiment aux questions…
***
@magiraud @RyanHerb @mikael-s @DuezWeb 2018.01https://gitlab.inria.fr/vidjil/vidjil/-/issues/2005Après un compare sample, le scatterplot n'est pas initialisé2017-05-22T15:26:06+02:00Vidjil TeamAprès un compare sample, le scatterplot n'est pas initialiséExemple ici : http://rbx.vidjil.org/browser/?custom=5611&custom=777&
Je n'ai que ? comme label du scatterplot. Il faut appuyer sur g pour que le scatterplot se mette en mode TRG.
***
@RyanHerb @Duez @magiraud Exemple ici : http://rbx.vidjil.org/browser/?custom=5611&custom=777&
Je n'ai que ? comme label du scatterplot. Il faut appuyer sur g pour que le scatterplot se mette en mode TRG.
***
@RyanHerb @Duez @magiraud Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2004igBlast ne fonctionne plus2016-11-29T14:43:07+01:00Vidjil TeamigBlast ne fonctionne plusAucun souci pour moi, sur ma machine ou sur rbx. Plus d'info ?
Pour info j'ai poussé hier une modif qui met IgBlast en HTTPS (car le NCBI passe en HTTPS). Serait-ce lié ?
***
Curieux. Hier cela m'était arrivé sous Safari. Ré-essayé à l'i...Aucun souci pour moi, sur ma machine ou sur rbx. Plus d'info ?
Pour info j'ai poussé hier une modif qui met IgBlast en HTTPS (car le NCBI passe en HTTPS). Serait-ce lié ?
***
Curieux. Hier cela m'était arrivé sous Safari. Ré-essayé à l'instant, sur rbx et depuis Firefox sans cache, et même error. Screenshot joint. Par contre, cela fonctionne sans soucis si je vais sur la page d'IgBlast et que je soumets des séquences.
Est-ce depuis l'université de Thessalonique serait blacklistée d'une certaine manière ? Ou est-ce ma machine qui est curieuse en ce moment ?
***
Tu sembles en HTTP, et donc ce que j'ai poussé hier soir (uniquement sur dev pour l'instant) devrait corriger ton problème (c'était un des tests fonctionnels cassés, d'ailleurs). Essaie avec le browser en local. Comme c'est une modif dans un fichier JS il faut éventuellement rafraichir ton cache.
En allant sur la page d'IgBlast la redirection vers HTTPS se fait bien (je ne sais pas pourquoi elle ne se fait pas avec la requête POST).
***
Oui, c'est cela, cela fonctionne ! Au temps pour moi, je n'avais pas vu ce coup d'HTTPS.
***
@magiraud @Duezhttps://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 -- Important