vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-06-11T11:26:37+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1996Afficher certaines séquences particulières, même en-dessous du -t2020-06-11T11:26:37+02:00Vidjil TeamAfficher certaines séquences particulières, même en-dessous du -tLorsque des séquences d'intérêt sont en dessous du -t 100 de fuse.py on veut qu'elles finissent malgré tout dans le fichier final. Quelle solution retenir ?
* Les passer explicitement en paramètre du fuse.py ? Pas très simple pour notre...Lorsque des séquences d'intérêt sont en dessous du -t 100 de fuse.py on veut qu'elles finissent malgré tout dans le fichier final. Quelle solution retenir ?
* Les passer explicitement en paramètre du fuse.py ? Pas très simple pour notre serveur de faire ça
* Avoir un champ dans le fichier .vidjil qui dise au fuse.py « prends-moi » ? Les champs correspondants aux clones sont assez descriptifs. Là on ajouterait un champ purement « computationnel ». Ça polluerait un peu le fuse…
***
Le champ dans le `.vidjil` pourrrait être un "label", qui ne serait pas forcément oui/non mais pourrait ajouter de la sémantique (comme on faisait il y a longtemps avec l'option "-l"). C'est donc descriptif. (On a déjà "name", qu'on utilise pas comme cela.)
Dans un premier temps, fuse.py pourrait tout simplement garder les séquences avec label. Dans un deuxième, fuse pourrait avoir des paramètres pour spécifiquement garder/ignorer certains labels.
***
Au fait, dans #1007, un vieux commentaire disait :
> "un flag faisant qu'il prend le nom des fichiers fasta comme "name" dans le `.vidjil` (et sort `top: 0`, ou, mieux, un nouveau flag ?)"
On peut effectivement déjà forcer avec `top: 0`. Utiliser "name" ne me semble pas une bonne idée maintenant.
***
Forcer le top : bof, on perd l'info.
Je pense que la situation était différente dans l'autre tâche puisqu'il n' s'agit pas de séquences appartenant réellement au jeu de données. Ce qui n'est pas notre cas ici.
***
nouvelle option `--label` (édité, ancienneemnt `-W`) + d332792 : on a le `label`
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1995Export Krona pour la visualisation du répertoire2021-11-19T11:06:56+01:00Vidjil TeamExport Krona pour la visualisation du répertoireun exemple de visualisation pratique (et dynamique) pour le répertoire.
Les krona permettent de zoomer et d'approfondir la visualisation.
Possibilité de la proposé en export à partir de vidjil.
PS: inclut depuis peu par arrest (contin...un exemple de visualisation pratique (et dynamique) pour le répertoire.
Les krona permettent de zoomer et d'approfondir la visualisation.
Possibilité de la proposé en export à partir de vidjil.
PS: inclut depuis peu par arrest (continuité utilisateur ? ).
***
@flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1994app/analyze: contact pour séquences avec souci2017-04-11T04:40:00+02:00Vidjil Teamapp/analyze: contact pour séquences avec souciMikaël : Et à côté de chaque segmentation on pourrait avoir une petit icone pour demander aux utilisateurs s'ils sont satisfaits de la segmentation proposée. Dans le cas contraire on leur demande ce qu'ils s'attendaient à avoir et on gén...Mikaël : Et à côté de chaque segmentation on pourrait avoir une petit icone pour demander aux utilisateurs s'ils sont satisfaits de la segmentation proposée. Dans le cas contraire on leur demande ce qu'ils s'attendaient à avoir et on génère un should-vdj automatiquement :)
En attendant, on pourrait faire comme ce que Tatiana a fait pour l'appli principale, qui se contente de prendre toute la sortie et d'ouvrir un mail.
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1993vidjil/segmenter: utiliser le .vidjil2017-04-11T04:37:31+02:00Vidjil Teamvidjil/segmenter: utiliser le .vidjil-c segment sort désormais un .vidjil.
Afficher un segmenteur du browser ? Autre chose ?
***
@nobody-c segment sort désormais un .vidjil.
Afficher un segmenteur du browser ? Autre chose ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1992app/analyze: exposer/documenter une API2023-03-28T16:21:00+02:00Vidjil Teamapp/analyze: exposer/documenter une APIShugay et d'autres seraient contents de pouvoir utiliser cela.
(Mais attention, pour l'instant bloquant pour le reste du serveur ?)
***
@nobodyShugay et d'autres seraient contents de pouvoir utiliser cela.
(Mais attention, pour l'instant bloquant pour le reste du serveur ?)
***
@nobodyWeb 2022.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/1991Release 2016.092016-11-29T14:42:58+01:00Vidjil TeamRelease 2016.09- la première release avec aho (pour l'instant silencieux ou pas ?)
- max_similarity 20
- pb de représentative : à voir sérieusement, hotfix et autres
À faire au pire avant EC-NGS, donc jeudi prochain
De plus, cela fait *très* longte...- la première release avec aho (pour l'instant silencieux ou pas ?)
- max_similarity 20
- pb de représentative : à voir sérieusement, hotfix et autres
À faire au pire avant EC-NGS, donc jeudi prochain
De plus, cela fait *très* longtemps qu'on a pas communiqué/spammé tous les utilisateurs (pas fait cet été, finalement).
***
- aho : n'a pas été mergé complètement. Un merge maintenant fait pas mal de conflits
***
aho : désolé, c'est moi qui juste après 2016.08 n'a pas fait de pull incluant ton dernier boulot.
-> branche sans-aho, rebasée sur 2016.08 en enlevant juste le merge loupé.
et... aho se merge quasi-parfaitement dessus !
Proposition : on travaille sur sans-aho, on release 2016.09, puis on merge proprement aho.
***
(on pourrait même merger directement aho sur sans-aho... mais cela risque de rajouter des choses à controller pour la release de jeudi prochain ou d'avant, à voir)
***
Ok.
Il faut aussi intégrer/modifier/améliorer hotfix_evalue_incomplete_germline
***
sans-aho : Il y a 0cb9a9f, 9bac43b et 4fc1c8c qui ont un lien avec Aho. Je les avais mis dans dev, car après le merge. Cela casse les tests, qu'en fait-on ?
***
Rebasé à l'instant sans-aho en enlevant ces trois commits + poussé les trois commits sur aho.
***
+ fait la même opération pour les deux commits "chimera.should-get: We segment again on IGL by chance" et "chimera.should-get: We expect just one sequence to be ambiguous"
(à chaque fois je fais rebase -i master)
***
Il ne manque plus que
- DDJ ?
- improve_representative_sans-aho (si cela passe) ?
***
-improve-representative_sans-aho passe
- DDJ argh… je savais bien que j'avais un autre truc, ça doit être bon je vérifie.
***
Chez moi sans-aho (synchro avec origin/sans-aho, pas de modifs en plus) ne passe pas avec les shouldvdj (170 tests échoués au lieu de 168…). Je fais comment pour trouver le coupable ? ;)
***
1) Tu passes EXPECTED à 85 pour que les tests passent
2) Tu fais un "make snapshot_diff", et tu regardes en particulier le début (out/should-vdj.log)
***
Non, il y a beaucoup mieux maintenant :
Sans rien toucher, faire "make snapshot_diff_current", cela fait un shapshot du truc en cours (pas forcément réussi, donc) puis un diff avec le dernier snapshot réussi
***
Il ne reste donc que DDJ :-)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1990Supprimer le calcul de matrice de similarité dans l'algo2020-05-26T10:45:33+02:00Vidjil TeamSupprimer le calcul de matrice de similarité dans l'algoMikaël :
Dans 830ad222 on est passé de max_clones (en général 100) comparés à sort_clones.size() qui, me semble-t-il, contient la liste de tous les clones.
Mathieu :
Oui, exactement. La raison de 830ad222 était que certains utilisateurs...Mikaël :
Dans 830ad222 on est passé de max_clones (en général 100) comparés à sort_clones.size() qui, me semble-t-il, contient la liste de tous les clones.
Mathieu :
Oui, exactement. La raison de 830ad222 était que certains utilisateurs lancent -z 10000 (ou plus), et cela faisait vraiment exploser la taille.
Notons que, avant, on avait toujours 100 clones, même quand il y en avait moins...
Mikaël:
(…) D'ailleurs a priori le calcul fait dans Vidjil n'est plus utile. On pourrait le virer.
Mathieu:
Je l’ai tout de suite remis à 20. C’est probablement de la faiblesse (au lieu de l’enlever), mais cela ira pour l’instant.
***
-> si pas de regret, on le supprime à la release qui suivra 2016.10
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1989Un pre-process en timeout apparaît toujours running2019-02-28T12:40:31+01:00Vidjil TeamUn pre-process en timeout apparaît toujours runningLorsqu'un pre-process est timeout, l'interface web affiche toujours le process comme en cours (avec la petite icone qui tourne). Et on ne peut pas le relancer (mais pour ça cf. #1960 )
***
@nobodyLorsqu'un pre-process est timeout, l'interface web affiche toujours le process comme en cours (avec la petite icone qui tourne). Et on ne peut pas le relancer (mais pour ça cf. #1960 )
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1988Configs qui apparaissent en double (dans les résultats)2020-12-19T13:36:32+01:00Vidjil TeamConfigs qui apparaissent en double (dans les résultats)Par exemple : patients 3561, 3562 ou 3606 (allez voir la fiche info). Il y a en bas à droite des liens en double pointant avec les résultats d'une même config
***
Non seulement les configs apparaissent en double, mais il y a deux entrées...Par exemple : patients 3561, 3562 ou 3606 (allez voir la fiche info). Il y a en bas à droite des liens en double pointant avec les résultats d'une même config
***
Non seulement les configs apparaissent en double, mais il y a deux entrées dans fused_file et celle qui est mise à jour par de futurs fuse n'est pas la même que celle affichée.
Le problème sous-jasent existe encore, mais l'impacte pour l'utilisateur devrait maintenant être nul.
hotfix: a46b11007c0af4d3182a54
***
Un moyen de créer de telles configs est de bégayer de la souris. Il suffit de cliquer deux fois rapidement sur run et deux runs sont lancés sur le serveur, à peu près au même moment. Pour peu que le fuse ne soit pas immédiat on aura deux fuse lancés et du coup deux entrées dans la DB. Cela a été fait (volontairement) sur dev sur le patient 1321.
Mais ça n'explique pas pourquoi ce problème serait apparu seulement en août… S'il s'agit bien de l'origine du problème, il aurait dû être présent avant.
***
On a une championne avec des configs en triple ! Patient 3764
***
@nobody @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1987Ajouter l'organisme dans le fichier .vidjil2017-02-02T12:39:25+01:00Vidjil TeamAjouter l'organisme dans le fichier .vidjilUn fichier .vidjil donne le locus mais pas l'espèce. Impossible alors de savoir si un fichier avec un germline IGH provient d'un humain ou d'une souris.
***
@nobodyUn fichier .vidjil donne le locus mais pas l'espèce. Impossible alors de savoir si un fichier avec un germline IGH provient d'un humain ou d'une souris.
***
@nobodyAlgo 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1986Affichage des logs du serveur web2023-06-28T16:37:56+02:00Vidjil TeamAffichage des logs du serveur webDans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs V...Dans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs Vidjil, des logs du serveur web, du serveur web lui-même et des droits affectés au fichier.
Au passage j'aurais bien ajouté une vérification dans showlog pour que showlog ne montre que les logs de Vidjil (et donc empêche de se balader où on veut dans l'arborescence).
Bref je retirerais bien ces deux liens.
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1985Requêtes incessantes à scheduler_task et scheduler_worker2017-12-19T09:46:45+01:00Vidjil TeamRequêtes incessantes à scheduler_task et scheduler_workerIl s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a pl...Il s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a plusieurs requêtes par seconde ayant un lien avec les workers et les schedulers alors qu'aucun process n'est queued ou assigned.
Il s'agit de requête du genre :
SELECT scheduler_task.id, scheduler_task.application_name, scheduler_task.task_name, scheduler_task.group_name, scheduler_task.status, scheduler_task.function_name, scheduler_task.uuid, scheduler_task.args, scheduler_task.vars, scheduler_task.enabled, scheduler_task.start_time, scheduler_task.next_run_time, scheduler_task.stop_time, scheduler_task.repeats, scheduler_task.retry_failed, scheduler_task.period, scheduler_task.prevent_drift, scheduler_task.timeout, scheduler_task.sync_output, scheduler_task.times_run, scheduler_task.times_failed, scheduler_task.last_run_time, scheduler_task.assigned_worker_name FROM scheduler_task WHERE ((scheduler_task.assigned_worker_name = 'rbx.vidjil.org#26682') AND (scheduler_task.status = 'ASSIGNED')) ORDER BY scheduler_task.next_run_time LIMIT 1 OFFSET 0
et
SELECT scheduler_worker.id, scheduler_worker.worker_name, scheduler_worker.first_heartbeat, scheduler_worker.last_heartbeat, scheduler_worker.status, scheduler_worker.is_ticker, scheduler_worker.group_names, scheduler_worker.worker_stats FROM scheduler_worker WHERE (scheduler_worker.worker_name = 'rbx.vidjil.org#9626')
Les (anciennes) requêtes sont loggées dans /var/log/mysql/mysql_general.log. J'ai désactivé le log pour ne pas saturer le disque. Pour réactiver, il faut aller dans /etc/mysql/my.cnf, chercher general, décommenter les deux lignes en lien avec general_log et redémarrer le serveur mysql.
***
Dev et test ont maintenant un Heartbeat de 10 secondes, rbx un Heartbeat de 3 secondes (inchangé), la charge de la bdd semble être réduite.
***
On est effectivement passés à environ 3,1 requêtes par seconde, ce qui semble cohérent.
D'après les valeurs que tu donnes, en l'espace de 30 secondes on va avoir 3 heartbeats de chaque worker de dev et de test (soit au total 3 heartbeats * 3 workers * 2 serveurs = 18 heartbeats) et on va en avoir 10 pour rbx ( * 3 workers, soit 30 heartbeats). On arrive à 48 heartbeats en 30 secondes, soit environ 1,6 par seconde. Chaque heartbeat semble générer 2 requêtes, ce qui donne 3,2 requêtes par seconde. On tombe pas loin de ce que j'ai mesuré.
On pourrait diminuer encore du côté de dev et test, mais au final ça ne changerait pas grand chose puisque maintenant c'est rbx qui fait le plus de heartbeats.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1984Le -c segment devrait sortir un .vidjil2016-11-29T14:42:53+01:00Vidjil TeamLe -c segment devrait sortir un .vidjilSouhait de Mikaël, en particulier pour que app.vidjil.org/vidjil/segmenter puisse embarquer un segment.js
***
ffebf9a
***
@magiraud @mikael-s @DuezSouhait de Mikaël, en particulier pour que app.vidjil.org/vidjil/segmenter puisse embarquer un segment.js
***
ffebf9a
***
@magiraud @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1983SampleSets : controlleurs génériques2017-05-19T14:56:23+02:00Vidjil TeamSampleSets : controlleurs génériquesCe serait agréable de pouvoir utiliser des SampleSet génériques (tout en gardant les vues patients et runs).
***
Au programme de la visite de Ryan à Bristol ?
***
@RyanHerb @DuezCe serait agréable de pouvoir utiliser des SampleSet génériques (tout en gardant les vues patients et runs).
***
Au programme de la visite de Ryan à Bristol ?
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1982Décalage des informations sous la séquence dans le segmenter2021-04-08T08:29:33+02:00Vidjil TeamDécalage des informations sous la séquence dans le segmenterSur ma machine sous FF j'ai un décalage des informations dans le segmenteur (par exemple avec la qualité ou les affectValues), cf. copie d'écran. Ce décalage est beaucoup plus modéré sous Chromium (environ 1 nucléotide).
***
@nobodySur ma machine sous FF j'ai un décalage des informations dans le segmenteur (par exemple avec la qualité ou les affectValues), cf. copie d'écran. Ce décalage est beaucoup plus modéré sous Chromium (environ 1 nucléotide).
***
@nobodyRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1981Le left-container a une largeur qui n'est pas toujours la même2018-04-16T15:48:23+02:00Vidjil TeamLe left-container a une largeur qui n'est pas toujours la mêmeSur ce patient, la largeur réelle du left-container est de 475px : http://rbx.vidjil.org/browser/index.html?patient=3508&config=25
alors que sur cet autre patient, la taille réelle est de 503px : http://rbx.vidjil.org/browser/?patient=32...Sur ce patient, la largeur réelle du left-container est de 475px : http://rbx.vidjil.org/browser/index.html?patient=3508&config=25
alors que sur cet autre patient, la taille réelle est de 503px : http://rbx.vidjil.org/browser/?patient=3220&config=35
Pourtant les règles CSS disent 475px. Qui comprend le problème ?
***
Je dirais l'ellipsis. Sans le ellipsis le nom du sample est cassé deux caractères plus tôt. Donc les caractères plus le '...' du ellipsis ~= 28px ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1980Titre de la page HTML parfois faux ?2018-04-16T15:49:37+02:00Vidjil TeamTitre de la page HTML parfois faux ?(Aurélie ?) Dans compare patients / dans runs ? À vérifier.
***
@nobody(Aurélie ?) Dans compare patients / dans runs ? À vérifier.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1979Titre du rapport exporté faux quand "compare patients" et runs2018-04-16T15:49:37+02:00Vidjil TeamTitre du rapport exporté faux quand "compare patients" et runsAurélie : On voit le titre du dernier patient.
***
Confirmé.
***
1. Ouvrir un patient
2. Faire « open patient list »
3. Compare patients
4. Sélectionner des patients (autres)
5. Export report (monitor). Le titre est celui du pati...Aurélie : On voit le titre du dernier patient.
***
Confirmé.
***
1. Ouvrir un patient
2. Faire « open patient list »
3. Compare patients
4. Sélectionner des patients (autres)
5. Export report (monitor). Le titre est celui du patient ouvert au 1.
***
Idem pour les runs : il n'affiche pas le nom du run mais le nom du dernier patient ouvert.
(this.m.patient_name dans export.js, rempli directement par ce que renvoie le serveur)
***
@Duez @magiraud @RyanHerb Web 2017.03Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1978Pouvoir fixer la fenêtre du segmenter avec beaucoup de séquences2017-01-18T12:50:44+01:00Vidjil TeamPouvoir fixer la fenêtre du segmenter avec beaucoup de séquencesAurélie bosse souvent à 15-20 séquences et "cela n’arrête pas de bouger" (en particulier parce que la fenêtre de tag est en haut).
Elle voudrait pouvoir fixer la fenêtre.
C'est vrai que, dès qu'on travaille avec plein de séquences, le r...Aurélie bosse souvent à 15-20 séquences et "cela n’arrête pas de bouger" (en particulier parce que la fenêtre de tag est en haut).
Elle voudrait pouvoir fixer la fenêtre.
C'est vrai que, dès qu'on travaille avec plein de séquences, le redimensionnement automatique est vite fatiguant.
***
J'avais cru que cela avait été fait dans les précédentes semaines, mais non, le comportement y est toujours, sur dev en tout cas. Marc, as-tu fait cela ou c'était juste un projet ?
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1977maintenir le « color by » en changeant de patient2016-11-29T14:42:49+01:00Vidjil Teammaintenir le « color by » en changeant de patientdemande d'Aurélie. Mikaël, c'est bon ?
***
06b78fb
***
@mikael-sdemande d'Aurélie. Mikaël, c'est bon ?
***
06b78fb
***
@mikael-s