vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-07-30T20:49:08+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3795Pertinence du format .vdj.fa et documentation2020-07-30T20:49:08+02:00Mathieu GiraudPertinence du format .vdj.fa et documentationLa ~doc du ~cpp a une grande partie, plutôt historique, sur `.vdj`. (Elle est certes après celle sur AIRR... mais par contre le `.vidjil` n'est pas décrit dans cette doc.)
Est-ce que ces infos sur `.vdj` sont toujours à jour ? Je doute ...La ~doc du ~cpp a une grande partie, plutôt historique, sur `.vdj`. (Elle est certes après celle sur AIRR... mais par contre le `.vidjil` n'est pas décrit dans cette doc.)
Est-ce que ces infos sur `.vdj` sont toujours à jour ? Je doute de leur pertinence vu, d'un côté, le `.vidjil`, et, de l'autre, le AIRR. Nous n'avons maintenant pas vraiment envie que des bioinfos construisent des pipelines en s'appuyant dessus, non ?
Supprimer cela ? Le réduire fortement ?Algo 2020.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3785Combo -FaW obsolète2019-03-12T14:08:29+01:00Mathieu GiraudCombo -FaW obsolèteC'est une conséquence malheureuse de !434 (peut-être la plus pénible sur l'ensemble des tests changés): la combo `-FaW` devient `--out-reads --label-filter --label`... c'est lourd (et même si on mettait `--filter` au lieu de `--label-fil...C'est une conséquence malheureuse de !434 (peut-être la plus pénible sur l'ensemble des tests changés): la combo `-FaW` devient `--out-reads --label-filter --label`... c'est lourd (et même si on mettait `--filter` au lieu de `--label-filter`).
Voir #3305, et la combo est aussi mentionnée ou utilisée dans `vidjil-algo.md` et dans `task.py` pour #1469.
On pourrait faire aussi un raccourci pour ces trois options, mais je ne suis pas sûr que cela aide à la compréhension de l'ensemble. Bref tant pis ?Algo 2018.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/3772-c designations2019-03-06T11:44:04+01:00Mathieu Giraud-c designations```
-c COMMAND command
clones locus detection, window extraction, clone clustering (default command, most efficient, all outputs)
windows locus detection, window extraction
segment ...```
-c COMMAND command
clones locus detection, window extraction, clone clustering (default command, most efficient, all outputs)
windows locus detection, window extraction
segment detailed V(D)J designation (not recommended)
germlines statistics on k-mers in different germlines
```
Remplace-t-on `segment` par ce qui suit ?
```
designate detailed V(D)J designation, without prior clustering (not as efficient)
```
Et l'avertissement :
```
* WARNING: vidjil-algo was run with '-c segment' option
* vidjil-algo efficientl extracts windows overlapping the CDR3
* to cluster reads into clones ('-c clones').
* Computing accurate V(D)J designations for many sequences ('-c segment' or large '-z' values)
* is slow and should be done only on small datasets or for testing purposes.
* More information is provided in the 'doc/vidjil-algo.md' file.
```
Avant-dernière ligne, à la place :
```
* is not as efficient as the default '-c clones' command
```
Et on enlève "should be done only on small datasets or for testing purposes" ?
Voir aussi #3295.Algo 2018.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/3770Documenter les besoins mémoire de vidjil-algo2024-02-05T15:37:43+01:00Mathieu GiraudDocumenter les besoins mémoire de vidjil-algoDepuis https://gitlab.inria.fr/vidjil/vidjil/issues/3652#note_179079.
Ajouter les CD, du même ordre de grandeur que les IGHV (100 kbp), pourrait mettre à plat certaines machines sur ~"dev\-ci"... alors que le même job s'éxécute en 2 sec...Depuis https://gitlab.inria.fr/vidjil/vidjil/issues/3652#note_179079.
Ajouter les CD, du même ordre de grandeur que les IGHV (100 kbp), pourrait mettre à plat certaines machines sur ~"dev\-ci"... alors que le même job s'éxécute en 2 secondes sur un portable. Est-ce parce que les CD ont une structure particulière (beaucoup plus de k-mers que les IGH dans leur ensemble, donc plus de ~"cpp\-mem") ? Il suffit qu'on passe au-dessus d'une limite et on swappe.
Indépendamment des CD, cela pose la question de l'efficacité et de ce qu'on conseille comme machines.
`server.md` indique :
> vidjil-algo typically uses approx. 1.2GB of RAM to run on a 1GB `.fastq` and will take approx. 5+ minutes.
> Therefore in order to process requests from a single user with a few samples,
> any standard multi-core processor with 2GB RAM will be enough.
Est-ce à mettre à jour après !78 ? Ces infos devraient être aussi dans `vidjil-algo.md`.
Enfin, si on conseille 2GB de RAM et si nos slaves ont 1GB de RAM, c'est tout à notre honneur, on teste dans des conditions plus difficiles... mais est-ce que ~"tests\-speed" serait amélioré avec des slaves qui auraient tous 2GB ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3719Tutoriel : ajouter les choses spécifiques à la CLL2019-03-15T09:33:34+01:00Mikaël SalsonTutoriel : ajouter les choses spécifiques à la CLLOn a des fonctionnalités plus spécifiques à la CLL, elles devraient apparaître dans le tutoriel. Voire avoir une partie plus LAL et une partie plus CLL ?On a des fonctionnalités plus spécifiques à la CLL, elles devraient apparaître dans le tutoriel. Voire avoir une partie plus LAL et une partie plus CLL ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3568AIRR : documenter2018-10-24T16:16:47+02:00Mathieu GiraudAIRR : documenter> @flothoni, #3457 :
> Je pense que si l'on adopte ce format, on pourrait reprendre directement ce tableau
Oui, bonne idée. On mettra dans notre ~doc au moins les champs qu'on utilise et le sens qu'on y met, pas besoin de s'étendre s...> @flothoni, #3457 :
> Je pense que si l'on adopte ce format, on pourrait reprendre directement ce tableau
Oui, bonne idée. On mettra dans notre ~doc au moins les champs qu'on utilise et le sens qu'on y met, pas besoin de s'étendre sur ceux qu'on n'utilise pas.Algo 2018.09https://gitlab.inria.fr/vidjil/vidjil/-/issues/3474Remplir les profils / descriptions sur DockerHub, nettoyer2018-10-15T17:44:55+02:00Mathieu GiraudRemplir les profils / descriptions sur DockerHub, nettoyerhttps://hub.docker.com/r/vidjil/
Pas urgent, en tout cas bien moins que #3175.https://hub.docker.com/r/vidjil/
Pas urgent, en tout cas bien moins que #3175.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3445serveur delocalisé; problème à l'installation; job coincés en queue2021-02-09T17:27:33+01:00Thonier Florianserveur delocalisé; problème à l'installation; job coincés en queueUn utilisateur souhaite installer localement le serveur.
Ils font face à un souci dans l’installation puisque toutes leurs analyses restent en `queue`. A distance, il y a malheureusement beaucoup de source d'erreurs possibles, et je ne ...Un utilisateur souhaite installer localement le serveur.
Ils font face à un souci dans l’installation puisque toutes leurs analyses restent en `queue`. A distance, il y a malheureusement beaucoup de source d'erreurs possibles, et je ne suis pas trop au point sur l'aspect serveur.
Cela me fait penser à vdj#631. Je vais leur demander si ils sont passé par la version docker ou non. Mais dans ce cas, l'erreur de vdj#631 devrait être corrigé sur la dernière version non ?
Dans le cas contraire, qu'elles sont les informatiions qui peuvent nous aider ? les logs du serveur, de l'app vidjil ?
cc: @RyanHerb @mikael\-s @magiraud
PS: voici leur mail explicatif:
>Thanks for providing this support email. We managed to install Vidjil
locally, initiated a database, created an admin user and a couple of
ordinary users. But we are facing problems:
>- when the ordinary users log in, create a patient and load a sample, the
"config" drop down list is empty; the admin's "config" list shows more
options, namely: TRG, multi+inc+xxx, multi+inc, multi, IGH,
default+extract_reads
>- even the admin user, when we select "multi+inc+xxx" in the "config"
list, cannot run the analysis. They apparently get stuck in the QUEUED
mode forever.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3413Vocabulaire vidjil-algo Kmer/Fine2020-06-11T22:18:26+02:00Mathieu GiraudVocabulaire vidjil-algo Kmer/Fine@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/245#note_108065
> Il y a _analyze_ qui est utilisé dans deux sens : pour l'heuristique et pour la désignation VDJ. Je trouve que ça n'aide pas à la compréhension.
Mille f...@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/245#note_108065
> Il y a _analyze_ qui est utilisé dans deux sens : pour l'heuristique et pour la désignation VDJ. Je trouve que ça n'aide pas à la compréhension.
Mille fois oui !!! On est souvent embêté, pour l'instant c'était "full analysis" ou "further analysis" pour `Fine` et effectivement c'est confus.
> Je pense qu'il faudrait parler de VDJ designation ou VDJ assignment dans le 2è cas et donc dans les options ne pas avoir du `analysis` partout.
Pourquoi pas ! C'est bien "assignment" et pas "assignation".
Il faudrait avoir un verbe et un nom commun. Cela donnerait, avec d'autres possibilités :
- "V(D)J genes designation" / "to design V(D)J genes" (verbe bof ?)
- "V(D)J genes assignment" / "to assign V(D)J genes"
- ~~"V(D)J genes labeling" / "to label V(D)J genes"~~ -> conflit avec "labeled sequences"
- ~~"V(D)J genes tagging" / "to tag V(D)J genes"~~ -> conflit avec "tag" dans client
- "V(D)J genes identification" / "to identify V(D)J gene"
- autres ?
(cc @RyanHerb : y a-t-il des expressions qui font bizarre en anglais (en américain plutôt :-)) ?)
Pendant qu'on y est, pourrait-on être encore plus précis sur la première phase et utiliser par exemple "recombination detection" / "to detect recombinations" (modulo #1724, hihihi) ? Ce qui permettrait de garder "analysis" / "analyzed reads" pour le process global.
Une fois décidé, cela s'appliquera
- [ ] aux noms des options !245
- [ ] `doc/vidjil-algo.md`
- [ ] quelques messages dans `vidjil.cpp`
- [ ] dans le client, voir s'il y a des choses
- [ ] com, site web
- [ ] slides de présentation
(Au passage, j'ai encore changé des "segment" la semaine dernière :-)Algo 2020.06https://gitlab.inria.fr/vidjil/vidjil/-/issues/3368Réparer Vidjil-deploy-doc2020-08-27T11:32:01+02:00Mikaël SalsonRéparer Vidjil-deploy-docSuite à !202. Il faut mettre à jour le job Jenkins `Vidjil-deploy-doc` et installer le nécessaire sur le slave.Suite à !202. Il faut mettre à jour le job Jenkins `Vidjil-deploy-doc` et installer le nécessaire sur le slave.Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3364Vérifier tous les liens de la doc, internes comme externe2020-01-22T10:42:10+01:00Mathieu GiraudVérifier tous les liens de la doc, internes comme externeVoir #3349... mais aussi les liens externes : on a encore des liens sur `rby` !
Faire un script et le mettre en CI.
Plus simple à faire sur le résultat (build *.html).
Il y a sûrement des outils qui existent, sinon quelques lignes de p...Voir #3349... mais aussi les liens externes : on a encore des liens sur `rby` !
Faire un script et le mettre en CI.
Plus simple à faire sur le résultat (build *.html).
Il y a sûrement des outils qui existent, sinon quelques lignes de python feront bien l'affaire.Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3350Faire un artefact avec la doc .html et le déployer2019-12-04T22:30:17+01:00Mathieu GiraudFaire un artefact avec la doc .html et le déployerDemande aussi de finir la doc .md pour client #3348 #3349.Demande aussi de finir la doc .md pour client #3348 #3349.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3348doc en .md : org-babel-tangle.py pour les tests browser2018-07-12T15:12:19+02:00Mathieu Girauddoc en .md : org-babel-tangle.py pour les tests browserExtrait de #3004 : Adapter [org-babel-tangle.py](/vidjil/vidjil/blob/dev/tools/org-babel-tangle.py) au MarkdownExtrait de #3004 : Adapter [org-babel-tangle.py](/vidjil/vidjil/blob/dev/tools/org-babel-tangle.py) au MarkdownMathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3295Options : bikeshedding noms longs, suppression de certains noms courts2019-03-12T11:53:57+01:00Mathieu GiraudOptions : bikeshedding noms longs, suppression de certains noms courtsÀ faire après !105. Forte charge émotionnelle, avec 49 options :-)
- noms longs partout ou pas ? Peut-être `-V` n'a pas besoin de nom court. Mais c'est presque un élément de `doc`, ce n'est pas impossible qu'on aie à la fois `-g, --ger...À faire après !105. Forte charge émotionnelle, avec 49 options :-)
- noms longs partout ou pas ? Peut-être `-V` n'a pas besoin de nom court. Mais c'est presque un élément de `doc`, ce n'est pas impossible qu'on aie à la fois `-g, --germline` et `-3, --cdr3`.
- supprimer certains noms courts ? Évidemment pas ceux auquel on est habitués... Mais pourquoi pas pour les options obsures.Algo 2018.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/3175Documenter le processus de A à Z pour déployer sur un serveur sous Docker2018-10-16T11:11:39+02:00Mikaël SalsonDocumenter le processus de A à Z pour déployer sur un serveur sous DockerOn a de la doc concernant la construction des paquets ou l'utilisation de Docker. Mais il manque un pas à pas complet qui permette de savoir comment mettre à jour (ou installer) un serveur avec Docker. Cette doc pourra évidemment faire ...On a de la doc concernant la construction des paquets ou l'utilisation de Docker. Mais il manque un pas à pas complet qui permette de savoir comment mettre à jour (ou installer) un serveur avec Docker. Cette doc pourra évidemment faire référence à ce qui existe déjà.
Pour avoir une idée de ce qu'il peut manquer comme information (voir https://gitlab.inria.fr/vidjil/vdj/issues/644#note_84839)Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3088Pear et/ou le scheduler tombe en echec lors du dump2023-05-23T15:50:12+02:00Thonier FlorianPear et/ou le scheduler tombe en echec lors du dumpUn utilisateur essaye de faire un merge de fichiers relativement gros (4Go) en preprocess. Après deux tentatives, on retrouve un échec avec une erreur lors de la phase dump.
Voici le log retourné:
```
Traceback (most recent call last):...Un utilisateur essaye de faire un merge de fichiers relativement gros (4Go) en preprocess. Après deux tentatives, on retrouve un échec avec une erreur lors de la phase dump.
Voici le log retourné:
```
Traceback (most recent call last):
File "/home/vidjil-ci/git/prod/prod-server/server/web2py/gluon/scheduler.py", line 501, in executor
result = dumps(_function(*args, **vars))
File "applications/vidjil/models/task.py", line 734, in run_pre_process
(stdoutdata, stderrdata) = p.communicate()
File "/usr/lib/python2.7/subprocess.py", line 796, in communicate
self.wait()
File "/usr/lib/python2.7/subprocess.py", line 1376, in wait
pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
File "/usr/lib/python2.7/subprocess.py", line 476, in _eintr_retry_call
return func(*args)
File "/home/vidjil-ci/git/prod/prod-server/server/web2py/gluon/scheduler.py", line 901, in <lambda>
signal.signal(signal.SIGTERM, lambda signum, stack_frame: sys.exit(1))
SystemExit: 1
```
Je pense qu'il s'agit d'une erreur de surcharge dans la mémoire, mais je ne peux pas accéder à vda pour voir les logs (connexion au chu), et les logs dispo depuis l'interface sont trop récents.
A vérifier lorsque je peux accéder au serveur.
En tout cas je ne suis pas certain qu'il s'agisse d'un bug à proprement parler si cela vient de la mémoire.
cc @magiraud @mikael-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3037Compléter la documentation sur Docker2018-10-16T11:11:38+02:00Mikaël SalsonCompléter la documentation sur DockerSi on n'est pas habitué de Docker, il semble y avoir certaines étapes qui sont implicites dans [doc/dev.org](doc/dev.org) (en particulier par rapport à l'installation et l'utilisation de `docker-compose`.Si on n'est pas habitué de Docker, il semble y avoir certaines étapes qui sont implicites dans [doc/dev.org](doc/dev.org) (en particulier par rapport à l'installation et l'utilisation de `docker-compose`.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3029Client : afficher les warnings, se servir éventuellement du code2018-02-20T19:46:10+01:00Mathieu GiraudClient : afficher les warnings, se servir éventuellement du codeOriginellement dans https://gitlab.inria.fr/vidjil/vidjil/issues/2247#note_65739 :
> Le ~client pourrait
>
> - afficher le message en `:hover` (!139), mais aussi getHTMLInfo et autres
> - lier sur de l'aide #1945/#2745, l'identifiant a...Originellement dans https://gitlab.inria.fr/vidjil/vidjil/issues/2247#note_65739 :
> Le ~client pourrait
>
> - afficher le message en `:hover` (!139), mais aussi getHTMLInfo et autres
> - lier sur de l'aide #1945/#2745, l'identifiant aidant à cela
> - voire faire un truc plus futé sur certains warnings -> mvouaisMathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3015Support de gcc 7.3 ?2018-06-21T17:46:46+02:00Mathieu GiraudSupport de gcc 7.3 ?`doc/algo.org:` Vidjil-algo will not work with a =g++= 7.0 or above.
On devrait avoir au moins 7.2 vu #2615.
Est-ce que 7.3 fonctionne ?`doc/algo.org:` Vidjil-algo will not work with a =g++= 7.0 or above.
On devrait avoir au moins 7.2 vu #2615.
Est-ce que 7.3 fonctionne ?Algo 2018.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3011Short / shifted window : re-rendre cohérent le message sur stdout2018-01-29T20:08:49+01:00Mathieu GiraudShort / shifted window : re-rendre cohérent le message sur stdoutSuite à !141, le message historique sur stdout `found 11835 100-windows in 13152 reads` (provient au moins de 2013.07 !) est parfois inexact: ce ne sont pas que des 100-windows.
Ne mettre que le nombre de window non raccourcies ? (bof...Suite à !141, le message historique sur stdout `found 11835 100-windows in 13152 reads` (provient au moins de 2013.07 !) est parfois inexact: ce ne sont pas que des 100-windows.
Ne mettre que le nombre de window non raccourcies ? (bof).
Retirer "100-" ? Mettre une autre formulation ?Algo 2017.11Mathieu GiraudMathieu Giraud