vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-02-06T16:58:36+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4069Afficher les index de diversité en statistiques patient/run/set2024-02-06T16:58:36+01:00Mathieu GiraudAfficher les index de diversité en statistiques patient/run/setDemande de @Anne, initialement dans #4038 :
> Est-ce que ça serait possible d'avoir un bouton sur la page du run ou du set ? Qui donnerait cette valeur pour tous les patients du run/set. Ce serait super d'avoir un tableau récapitulatif ...Demande de @Anne, initialement dans #4038 :
> Est-ce que ça serait possible d'avoir un bouton sur la page du run ou du set ? Qui donnerait cette valeur pour tous les patients du run/set. Ce serait super d'avoir un tableau récapitulatif avec ces infos, ainsi que le % de reads appariés et le % de reads abalysés.
Voir #3171, #3496... toute la partie sur les ~"server-qc-stats" fait partie d'un point qui va être traité par @RyanHerb, entre janvier et mars 2020.Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/3539Export CSV de stats / qualité2024-01-18T15:28:01+01:00Mathieu GiraudExport CSV de stats / qualitéSuggestion de @Anne : pouvoir obtenir un export csv d'un run, sur tous les fihciers qui le compose
cc @RyanHerbSuggestion de @Anne : pouvoir obtenir un export csv d'un run, sur tous les fihciers qui le compose
cc @RyanHerbWeb 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/3171Statistiques multi-samples et contrôle de qualité run/sample, plan de bataille2024-03-29T15:43:11+01:00Mathieu GiraudStatistiques multi-samples et contrôle de qualité run/sample, plan de batailleDiscuté avec @flothoni et @mikael-s suite à ~"ec-ngs" à Lille. Le point le plus revenu dans les échanges, on s'y met en mai-juin de notre côté.
**Prérequis, pipeline de base**
- contrôleur préparant des métadonnées + ensemble de `.vid...Discuté avec @flothoni et @mikael-s suite à ~"ec-ngs" à Lille. Le point le plus revenu dans les échanges, on s'y met en mai-juin de notre côté.
**Prérequis, pipeline de base**
- contrôleur préparant des métadonnées + ensemble de `.vidjil` #3041
- qui récupère des infos des `.vidjil` #3172 (donc #2240)
- puis vue générique #2235 (app-stats: autre chose, plutôt explorer distributions V/J)
Premier but: commencer déjà par infos présentes dans `.vidjil`, typiquement *nombre de reads segmentées* et *clone principal avec son abondance*.
**Puis**
- (Jouable) Plus d'infos dans le `.vidjil`, mieux structurées, déjà depuis vidjil-algo
- les `UNSEG` triés #3049
- warnings par clone / sample #3086 #3060. Documenter, en faire de nouveaux
- (Jouable) vue spécifique #2875, spécialise #2235 pour QC, contrôles
- ~"!-hard" plus fort que #2875, profil par type de manipulation (sequenceur, données, ..) ou utilisateur #3168
- Présence des primers #3152 #1253
- ~"!-hard" (modification db) Pré-process #3154 (déjà PEAR #3054)Web 2024.04CHESNIN ClementCHESNIN Clementhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2379Appels à Blast et IgBlast avec d'autres espèces que l'humain2024-01-19T18:38:21+01:00Mathieu GiraudAppels à Blast et IgBlast avec d'autres espèces que l'humainDepuis XXXX, les appels à IMGT incluent l'espèce (fonctionne au moins pour la souris).
Il faudrait faire la même chose pour Blast et IgBlast, et/ou inactiver ces boutons.Depuis XXXX, les appels à IMGT incluent l'espèce (fonctionne au moins pour la souris).
Il faudrait faire la même chose pour Blast et IgBlast, et/ou inactiver ces boutons.Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/2358task.py: Mécanisme flexible pour lancer des traitements annexes non-bloquants2024-01-19T18:31:51+01:00Mathieu Giraudtask.py: Mécanisme flexible pour lancer des traitements annexes non-bloquants@mikael-s, à propos de #1744, pense que :
- Marc a fait un mécanisme plutôt générique pour lancer via `task.py` des traitements en utilisant les scheduler, avec retour asynchrone.
- Cela pourrait être utilisé pour #1469.
Et cela po...@mikael-s, à propos de #1744, pense que :
- Marc a fait un mécanisme plutôt générique pour lancer via `task.py` des traitements en utilisant les scheduler, avec retour asynchrone.
- Cela pourrait être utilisé pour #1469.
Et cela pourrait aussi servir à d'autres choses (Et pour "Compare patients", #1508, qu'est-ce qui avait été trouvé ?).
Bref, à partir des choses faites par Marc, pourrait-on avoir un mécanisme générique pour ce type de choses (avec un truc générique dans ~"server-task.py", et un autre dans ~client) ?
cc @RyanHerbWeb 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/2241Titre des samples lors de la comparaison de différentes analyses d'un même fi...2024-01-19T18:30:10+01:00Mikaël SalsonTitre des samples lors de la comparaison de différentes analyses d'un même fichier (compare samples)Lorsqu'on compare des résultats d'un même sample lancés à différentes époques (on compare donc l'évolution de Vidjil), les noms des samples dans le client ne sont pas du tout clairs… puisqu'il s'agit toujours du même.
Il faudrait donc m...Lorsqu'on compare des résultats d'un même sample lancés à différentes époques (on compare donc l'évolution de Vidjil), les noms des samples dans le client ne sont pas du tout clairs… puisqu'il s'agit toujours du même.
Il faudrait donc modifier temporairement les noms des samples pour y mettre une notion de date.
cc @magiraud @RyanHerbWeb 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/2125Afficher l'organisme dans le client2024-01-19T18:49:19+01:00Mathieu GiraudAfficher l'organisme dans le clientAprès #1987, on pourra afficher l'organisme quelque part dans le client. Mais où donc ?
@mikael-sAprès #1987, on pourra afficher l'organisme quelque part dans le client. Mais où donc ?
@mikael-sWeb 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/1382top par système : fuse.py2024-01-22T15:24:43+01:00Vidjil Teamtop par système : fuse.pySuite à la réunion du CBP et la discussion dans le métro, ce serait bien de récupérer plus de séquences par systèmes.
- une solution serait d'avoir, dans fuse, un `--top-by-system`, par exemple à 30, qui laisse passer (en plus du top 100...Suite à la réunion du CBP et la discussion dans le métro, ce serait bien de récupérer plus de séquences par systèmes.
- une solution serait d'avoir, dans fuse, un `--top-by-system`, par exemple à 30, qui laisse passer (en plus du top 100) les 30 tops par système *à condition* que le système apparaisse dans le top 100 normal.
- mais cela demande aussi, dans le c++, de faire en sorte que ce top 30 soit segmenté. Pas ultra-prévu pour, à voir.
- ~~ou bien on en profite pour chambouler l'ensemble et lancer une partie du c++ (FineSegmenter, et bientôt CDR3/AA) après le fuse.~~ non
Bref, ce n'est pas si facile. Aussi une crainte : que cela ramène des choses trop basses, de bruit comparables à d'autres clones qu'on affiche pas car caché par de plus gros clones.
À réfléchir ensemble, attendre retour du CBP de début février. (En attendant, solution simple est de relancer sur autre config,)
***
Demandé aussi par Rennes : top 100 + top 10 par système ?
***
Mais attention, certains systèmes où on n'a pas grand chose on va ramener des clones très faibles…
***
On mettra des gros warnings pour les trop faibles globaux
***
Voir le mail à McGill d'aujourd'hui... En RNA-Seq, ils ont (peut-être) du TR, mais caché par un Ig beaucoup plus gros :
```
reads clones
IGH -> 49714 100.0 5930 0.119
IGK -> 214250 100.0 8250 0.039
IGL -> 67030 100.0 4375 0.065
TRA -> 796 100.0 442 0.555
TRB -> 1158 100.0 586 0.506
TRD -> 61 100.0 43 0.705
TRG -> 126 100.0 80 0.635
```
Mais il y a toujours la question du bruit.
***
Évoqué lors du VW16
***
Ping : on est peut-être sur le point de modifier le fuse, penser aussi au top par système (ou au top 1000 + 100 par système)Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5244Does `RUNNING` really means `RUNNING`?2024-03-20T15:35:38+01:00Mikaël SalsonDoes `RUNNING` really means `RUNNING`?I currently see that 33 processes have the status `RUNNING`. However on the server I only see 4 ongoing processes.
In that case the `RUNNING` status may be misleading.I currently see that 33 processes have the status `RUNNING`. However on the server I only see 4 ongoing processes.
In that case the `RUNNING` status may be misleading.Web hotfix 2024.01CHESNIN ClementCHESNIN Clementhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5241Avoir une gestion plus fine/rigoureuse du succès/échec des should-vdj2024-02-06T09:56:14+01:00Mathieu GiraudAvoir une gestion plus fine/rigoureuse du succès/échec des should-vdj
Actuellement, on ne vérifie que le nombre de failed.
Ce n'est pas génial, si on a un +1/-1 qui s'équilibrent.
À voir comment on utilise les BUG/TODO: on a probablement quasiment déjà le mécanisme pour écrire en dur que certains tests n...
Actuellement, on ne vérifie que le nombre de failed.
Ce n'est pas génial, si on a un +1/-1 qui s'équilibrent.
À voir comment on utilise les BUG/TODO: on a probablement quasiment déjà le mécanisme pour écrire en dur que certains tests ne passent pas, pour pouvoir suivre tout changement de comportement.Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5238Regex "ou" dans should-to-tap.py2024-02-07T19:18:15+01:00Mathieu GiraudRegex "ou" dans should-to-tap.pyDepuis !1412 et le passage en python3 :
```
python should-vdj-to-tap.py -v should-vdj-tests/0000-nck-TRD.should-vdj.fa
```
Le `TRDV1 (5/AC/0 TRDD2 3/CGTGT/0, 5/AC/0 TRDD2 5/TCCCGTGT/0, 5/14/0) TRDJ1*01` ne passe plus. La manière dont...Depuis !1412 et le passage en python3 :
```
python should-vdj-to-tap.py -v should-vdj-tests/0000-nck-TRD.should-vdj.fa
```
Le `TRDV1 (5/AC/0 TRDD2 3/CGTGT/0, 5/AC/0 TRDD2 5/TCCCGTGT/0, 5/14/0) TRDJ1*01` ne passe plus. La manière dont on construit les regex me semble obscure.
a0b75bf3e dans !1412 contourne cela en simplifiant le test, mais ce serait mieux de comprendre ce qu'il se passe et d'avoir un traitement robuste de ces regex, bref de refaire marcher cela en revertant a0b75bf3e.Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5237Don't take into account upstream or downstream regions for the start/end posi...2024-02-02T09:52:32+01:00Mikaël SalsonDon't take into account upstream or downstream regions for the start/end positions of the geneWe use upstream of downstream sequences to improve the sensitivity for small genes, however they are added to the reference as a normal sequence. They should be differentiated in order to provide the correct start/end positions of the ge...We use upstream of downstream sequences to improve the sensitivity for small genes, however they are added to the reference as a normal sequence. They should be differentiated in order to provide the correct start/end positions of the gene (that don't have to take into account upstream or downstream sequence).
See an example of such an issue here #5235Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5222Get rid of python2.7 for the algorithm and switch to Python32024-02-07T19:18:15+01:00Mikaël SalsonGet rid of python2.7 for the algorithm and switch to Python3This is becoming a limiting factor at least for the CI but probably for the distribution of Vidjil-algo (at least for the accompanying scripts).
Just specifying python2 everywhere is not enough: python2 cannot be installed easily anymore...This is becoming a limiting factor at least for the CI but probably for the distribution of Vidjil-algo (at least for the accompanying scripts).
Just specifying python2 everywhere is not enough: python2 cannot be installed easily anymore on recent distributions.
We need to convert:
* [ ] Scripts in `germline/` #5031 !1414
* [ ] fuse.py #4455 (!1221 ?)
* [ ] `should-vdj-to-tap.py` !1412
* [ ] `repseq_vdj.py` !1412
(and potentially others)Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5198Speed up cypress ci jobs2024-01-18T10:12:44+01:00THONIER FlorianSpeed up cypress ci jobs* [ ] improve docker build of testing images
* [ ] reduce time of starting of server
* [ ] Pull cypress image at the same time that other images* [ ] improve docker build of testing images
* [ ] reduce time of starting of server
* [ ] Pull cypress image at the same time that other imagesDev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5197CI; gain some time by using some pre-updated image server/client2024-02-07T14:19:38+01:00THONIER FlorianCI; gain some time by using some pre-updated image server/clientI was thinking to a way to increase our time of CI.
Major part of the build time is taken by apt-get update & installation of third-party softwares as a base image before pull vidjil content.
We could probably split our Dockerfile as...I was thinking to a way to increase our time of CI.
Major part of the build time is taken by apt-get update & installation of third-party softwares as a base image before pull vidjil content.
We could probably split our Dockerfile as base/top image that we will be able to speed up build time.
Problem is that if we change content of dockerfile, we will have error. We could probably use branch name to take that into account.
* build a first image for that, push it as vidjil/vidjil-{client/server}:latest-base
* have a new branche type `docker` that will launch a job to build a new base image and propagate it to his derived CI jobs to ensure that everything work well
* Other branch will use default latest-base image
* When merge in dev, we could [detect a change in file](https://forum.gitlab.com/t/how-to-trigger-a-job-when-specific-files-have-changed-at-any-commit-in-the-branch/89945) to launch jobs to build latest-base images.
... Something like that I think...Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5129Provide information when marked_pos (CDR3) is not found2024-02-01T06:04:02+01:00Mikaël SalsonProvide information when marked_pos (CDR3) is not foundIt may happen that we don't find the CDR3 because there are too many deletions either in the V or the J genes that go beyond the marked_pos.
In such a case the CDR3 will not be found and no reason will be provided for that.
More generall...It may happen that we don't find the CDR3 because there are too many deletions either in the V or the J genes that go beyond the marked_pos.
In such a case the CDR3 will not be found and no reason will be provided for that.
More generally if the marked_pos is not set in the germline, the user doesn't have that information. The user can only see that no CDR3 was found with no reason given for that (which is not the case for productivity).
We should give some information about it.
Here is an example where the marked_pos is deleted (appears in position 277/290 of the V gene but we have 16 deletions in the V).
```
GCTGTCATCTCTCAAAAGCCAAGCAGGGATATCTGTCAACGTGGAACCTCCCTGACGATCCAGTGTCAAGTCGATAGCCAAGTCACCATGATGTTCTGGTACCGTCAGCAACCTGGACAGAGCCTGACACTGATCGCAACTGCAAATCAGGGCTCTGAGGCCACATATGAGAGTGGATTTGTCATTGACAAGTTTCCCATCAGCCGCCCAAACCTAACATTCTCAACTCTGACTGTGAGCAACATGAGCCCTGAAGACAGCAGCATAAATCCCCTTGGGGGTCCCTATAATTCACCCCTCCACTTTGGGAACGGGACCAGGCTCACTGTGACAGGTATGGGGGCTCCACTCTTGACTCGGGGGTGCCTGGGTTTGACTG
```Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4985Mettre à jour vidjil-alpha2024-02-01T06:07:44+01:00Mathieu GiraudMettre à jour vidjil-alphavidjil-alpha est notre solution pour le [pre-filtering](https://www.vidjil.org/doc/workflow/#pre-filtering-of-large-datasets), et on l'a maintenant releasé il y a plus d'un an, avec deux releases depuis de vijdil-algo.
J'ai vérifié dans...vidjil-alpha est notre solution pour le [pre-filtering](https://www.vidjil.org/doc/workflow/#pre-filtering-of-large-datasets), et on l'a maintenant releasé il y a plus d'un an, avec deux releases depuis de vijdil-algo.
J'ai vérifié dans le CHANGELOG, pour l'instant rien de critique n'a été mis depuis, mais bon, il y a eu du refactor (des germlines), d'autres sont à venir (!1129), bref cela vaudrait probablement le coup de ne pas trop diverger.
Rebaser ou remerger la bonne MR (c'est d'ailleurs !410 ou !881 ?) et republier un vidjil-alpha à jour ?
cc @mikael-sAlgo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4821Passer nos tests locaux via le gitlab-runer2024-01-18T10:14:37+01:00Thonier FlorianPasser nos tests locaux via le gitlab-runerThe following discussion from !979 should be addressed:
- [ ] @flothoni started a [discussion](https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/979#note_542898): (+3 comments)
> J'abandonne ce point tant que le gitlab-runner ne ...The following discussion from !979 should be addressed:
- [ ] @flothoni started a [discussion](https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/979#note_542898): (+3 comments)
> J'abandonne ce point tant que le gitlab-runner ne fonctionnera pas mieux en local. Pour rappel, nous devons faire face à 3 problèmes rédhibitoire pour le moment avec cette approche:
>
>* Le runner est incapable de faire des includes
>* On ne peut pas faire de récupération sur les artefacts
>* Si on veut lancer un test, il faut que les changements soient comités. Ça oblige a jongler avec le git sur les moindre lignes que nous manipulons en cours de dev.
On pourra revenir dessus si on jour le runner local évolue, mais ça ne semble pas être une des priorités de gitlab.
CC @magiraud @mikael-s @duezDev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4804Simplification du job de CI sur les tests serveurs2024-01-18T12:13:32+01:00Mikaël SalsonSimplification du job de CI sur les tests serveurs@duez et @flothoni ont discuté ensemble de la construction des images Docker pour les tests serveurs. C'est inutilement coûteux pour des changements minimes. Dans le cas général, il n'y a pas de modification du Docker (ou des configurati...@duez et @flothoni ont discuté ensemble de la construction des images Docker pour les tests serveurs. C'est inutilement coûteux pour des changements minimes. Dans le cas général, il n'y a pas de modification du Docker (ou des configurations associées), il n'est donc pas utile de tout reconstruire.
Il est aussi question d'utiliser des fichiers override pour la configuration Docker (sur ce point, voir !614).
J'ai par contre un peu de mal à voir ce qui se passe quand on pousse des modifs dans le répertoire `docker/`. On pourrait donc avoir un nom de branche à part pour générer une nouvelle image, mais quel est ensuite le statut de l'image construite ? Devient-elle directement après merge la nouvelle image par défaut ? Est-ce que ça ne pourrait pas poser des problèmes de compatibilité avec les autres branches en cours ?Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4748Pouvoir invalider "manuellement" quelques k-mers2023-10-20T12:27:43+02:00Mathieu GiraudPouvoir invalider "manuellement" quelques k-mersDepuis #4665 :
> au final, c'est bien une séquence de 12nt présente dans le D et le V, mais nos graines de D ne l'ont pas vue... et donc cela apparaît abusivement comme V. C'est à se demander si on ne pourrait avoir quelque chose de "ma...Depuis #4665 :
> au final, c'est bien une séquence de 12nt présente dans le D et le V, mais nos graines de D ne l'ont pas vue... et donc cela apparaît abusivement comme V. C'est à se demander si on ne pourrait avoir quelque chose de "manuel" pour "invalider" certaines séquences comme celles-là (en pratique, il suffirait de rajouter un "faux D" suffisament long).
>
> Et #996 ?
On pourrait détecter (manuellement, déjà au moins celui de #4665, ou automatiquement #1364) que certains k-mers sont "dangereux" car partagés ou presque et les invalider.Algo 2022.04Mathieu GiraudMathieu Giraud