vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-02-06T08:21:58+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4731Mettre à jour (encore) les germlines2024-02-06T08:21:58+01:00Mathieu GiraudMettre à jour (encore) les germlinesAprès !885, on pourra tenter de reprendre la dernière germline (sur !885, c'est 2021-01-25). Peu de [modifications](http://www.imgt.org/IMGTgenedbdoc/dataupdates.html) sur Homo Sapiens, mais autant être à jour, actuellement on est chaud ...Après !885, on pourra tenter de reprendre la dernière germline (sur !885, c'est 2021-01-25). Peu de [modifications](http://www.imgt.org/IMGTgenedbdoc/dataupdates.html) sur Homo Sapiens, mais autant être à jour, actuellement on est chaud sur les modifications que cela peut impliquer (mais je ne le fais pas maintenant sur !885 car cela peut remettre le bazar partout).
Cela se fera probablement en même temps/après !478 et cochonAlgo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4702Productivité et pseudo-gènes2024-02-23T10:32:17+01:00Mathieu GiraudProductivité et pseudo-gènes
ERIC #2443 mentionne explicitement **functional** IGHV gene. Mais il y a un certain nombre de pseudo-gènes dans nos germlines (et il y en aura encore plus après !885). Est-ce que ces séquences sont gappées ? A-t-on eu déjà des cas ou d...
ERIC #2443 mentionne explicitement **functional** IGHV gene. Mais il y a un certain nombre de pseudo-gènes dans nos germlines (et il y en aura encore plus après !885). Est-ce que ces séquences sont gappées ? A-t-on eu déjà des cas ou des discordances avec des pseudo-gènes ?
On devrait probablement vérifier cela, ce qui impliquer de parser un peu plus les headers... et/ou, dans `split-germlines.py`, extraire deux fichiers différents, les gènes et les pseudos ?
Y a-t-il un lien avec #3654 ?Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4678Reproductibilité valgrind_functional / gzip2024-02-06T07:47:44+01:00Mathieu GiraudReproductibilité valgrind_functional / gzip
Voir https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/884#note_460619
Actuellement on a `allow_failure: true` pour #4460, mais à terme ce serait bien de ne plus l'avoir
Comprendre ce qui loupe. Éventuellement récupérer cela avec...
Voir https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/884#note_460619
Actuellement on a `allow_failure: true` pour #4460, mais à terme ce serait bien de ne plus l'avoir
Comprendre ce qui loupe. Éventuellement récupérer cela avec should pour qu'un test du par exemple à un timeout soit simplement marqué `skip` et qu'on puisse se focaliser sur les vrais problèmes décelés par `valgrind`.Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4346http://www.vidjil.org/releases/vidjil-algo-latest.tar.gz2022-03-16T11:25:53+01:00Mathieu Giraudhttp://www.vidjil.org/releases/vidjil-algo-latest.tar.gz
Sur www.vidjil.org/releases, les `-latest` dataient de 2019.05. Je les ai modifié à la main, mais mettre cela dans ~"dev-cd".
Sur www.vidjil.org/releases, les `-latest` dataient de 2019.05. Je les ai modifié à la main, mais mettre cela dans ~"dev-cd".Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4320Uniquement des slaves Docker2024-01-18T10:13:29+01:00Mathieu GiraudUniquement des slaves DockerQuestion plus large que #4273 : est-ce faisable et souhaitable d'arriver à un point où toute la ~"dev-ci" serait dockerisée, y compris les jobs de déploiement, d'environnement de review, et autres ? Le jour où on aura cela, pourrons-nous...Question plus large que #4273 : est-ce faisable et souhaitable d'arriver à un point où toute la ~"dev-ci" serait dockerisée, y compris les jobs de déploiement, d'environnement de review, et autres ? Le jour où on aura cela, pourrons-nous "en un claquement de doigts" éteindre nos slaves (par exemple `meccano`, ou bien `vdc`) et en utiliser ailleurs sans presque avoir à se logguer sur le slave ?
Par rapport à #4273, cela suppose d'avoir des clés de déploiement stockées dans ~"dev-gitlab" (ce qui déjà un peu le cas) ? D'autres points ?Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4315Ne pas avoir de tests unitaires dépendant de serveurs externes, ou les repous...2024-01-18T10:13:20+01:00Mathieu GiraudNe pas avoir de tests unitaires dépendant de serveurs externes, ou les repousser à la finDeux tests unitaires client (sur 701) nécessitent un appel au ~"server-cgi" align.
Hack temporaire dans !713 pour pouvoir avoir le reste du ~"dev-ci" cette semaine.
On pourrait supprimer l'appel externe en mockant quelque chose dans `s...Deux tests unitaires client (sur 701) nécessitent un appel au ~"server-cgi" align.
Hack temporaire dans !713 pour pouvoir avoir le reste du ~"dev-ci" cette semaine.
On pourrait supprimer l'appel externe en mockant quelque chose dans `segment.align()`.
Ou on décide de garder ces tests, et ce serait bien de les déplacer vers la fin des pipelines ~"dev-ci", juste avant `test_functional_external`.Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4273Algo: Uniquement des tests Docker ?2024-02-01T06:03:39+01:00Mathieu GiraudAlgo: Uniquement des tests Docker ?Pour continuer sur la lancée de !612 et d'autres chsoes, ne faudrait-il pas que *tous* les tests passent par Docker, pour limiter la configuration manuelle de slaves et rendre cela plus reproductible ? vdj#660
Mais est-ce souhaitable ? ...Pour continuer sur la lancée de !612 et d'autres chsoes, ne faudrait-il pas que *tous* les tests passent par Docker, pour limiter la configuration manuelle de slaves et rendre cela plus reproductible ? vdj#660
Mais est-ce souhaitable ? En particulier si on passe tout sous Docker, même avec des images/distributions différentes, émule-t-on bien des architectures différentes ?
Et évidemment #3397.Algo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4215Gitlab-CI : supprimer le before_script (ne télécharger des données que si c'e...2024-01-18T10:30:25+01:00Mikaël SalsonGitlab-CI : supprimer le before_script (ne télécharger des données que si c'est utile)On a dans le `.gitlab-ci.yml` un `before_script` qui est donc lancé avant **chaque** job. Or cela implique le téléchargement d'un certain nombre de données (par exemple #3597) qui ne sont pas indispensables à chaque job.
Il faudrait sup...On a dans le `.gitlab-ci.yml` un `before_script` qui est donc lancé avant **chaque** job. Or cela implique le téléchargement d'un certain nombre de données (par exemple #3597) qui ne sont pas indispensables à chaque job.
Il faudrait supprimer ce before_script (qui ne fait plus sens vu le nombre de jobs qu'on a maintenant) et réintégrer les commandes nécessaires dans les jobs qui en ont besoin.
Voir aussi https://gitlab.inria.fr/vidjil/vidjil/issues/3397#note_311859Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4197.gitlab-ci.yml : faire marcher only:changes avec probablement only:merge_requ...2024-01-18T10:53:29+01:00Thonier Florian.gitlab-ci.yml : faire marcher only:changes avec probablement only:merge_requestsSuite de #4148.
https://docs.gitlab.com/ee/ci/yaml/#using-onlychanges-without-pipelines-for-merge-requests
Après !585/!586:
> Je viens de pousser depuis hier des modifs sur 3 MR pour lesquelles j'ai rapatrié le dev.
>
> Je m'aperçois...Suite de #4148.
https://docs.gitlab.com/ee/ci/yaml/#using-onlychanges-without-pipelines-for-merge-requests
Après !585/!586:
> Je viens de pousser depuis hier des modifs sur 3 MR pour lesquelles j'ai rapatrié le dev.
>
> Je m'aperçois que ces MR n’exécutent pas correctement les tests. Je viens de trouver qu'il y a eu un ajout de fichier `gitlab-ci.yml` dans la doc, dont les stages correspondent aux 2 stages qui sont maintenant testé sur les MR vidjil!565 et vidjil!564.
Reverté par !608/!609Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4188Retirer les séquences de faible complexité des germlines ?2022-02-17T18:36:48+01:00Mathieu GiraudRetirer les séquences de faible complexité des germlines ?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4036Taille des .vidjil en -y all2021-04-06T11:17:00+02:00Mathieu GiraudTaille des .vidjil en -y allvdj#921
Sur LIL-L3-1 :
- .fastq.gz 330M
- .vidjil habituel, `-z 100`, 51M
- .vidjil `-y all`, **395M**
- .vidjil après ~"server-fuse", 200k
Pour 1 clone en `-y all` sans `-z`, il y a... `1.9 ko` dans le `.vidjil` ! En plus de `se...vdj#921
Sur LIL-L3-1 :
- .fastq.gz 330M
- .vidjil habituel, `-z 100`, 51M
- .vidjil `-y all`, **395M**
- .vidjil après ~"server-fuse", 200k
Pour 1 clone en `-y all` sans `-z`, il y a... `1.9 ko` dans le `.vidjil` ! En plus de `sequence`, on a `quality`, `affectSigns`, `affectValues`... Beaucoup pour quelque chose qui va juste être un +1 dans une distribution...
- Calculer certaines distributions dans ~cpp ? Faisable, mais pas très générique, et demande ensuite des changements dans ~"server-fuse" pour lire les distributions
- Limiter au maximum ces sorties (voir aussi #3911) ? Par exemple, au-delà du `-z`, ne mettre que l'`id` et la `sequence`. Relativement simple, devrait réduire déjà la taille d'un facteur 3-4.
- Ne rien faire, tant pis pour la place, de toute façon cela se compresse bien ?
- Ne rien faire, car de toute façon le but est un jour de faire `-z all`, et on aura encore plus de choses ? (voire AIRR pour tout ?)
```
{
"_average_read_length": [
377.0
],
"_coverage": [
1.0
],
"_coverage_info": [
"377 bp (100% of 377.0 bp)"
],
"germline": "IGH",
"id": "AAAAAGTGGGAACTACTTCGGGCGGCGCCCCACCTAGGCTACTGGGGGCC",
"reads": [
1
],
"seg": {
"affectSigns": {
"seq": "+++++++ + +++++++++++++++++++++++++++++++++++++ + + ++++++++++++++ +++ + +++++++++++++++++++++++ + ++++ + ++ + + +++++++++++++++++++++++ + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++ ",
"start": 1,
"stop": 377
},
"affectValues": {
"seq": "HHHHHHH______H______HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH___H__H___HHHHHHHHHHHHHH?HHH______H____HHHHHHHHHHHHHHHHHHHHHHH_________H?HHHH________________H______HH______H_________________H______HHHHHHHHHHHHHHHHHHHHHHH______H______HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH_________________________________________________________________hhhhhhhhhhhhhhh_____________",
"start": 1,
"stop": 377
},
"evalue": {
"val": "2.012178e-46"
},
"evalue_left": {
"val": "0.000000e+00"
},
"evalue_right": {
"val": "2.012178e-46"
},
"quality": {
"seq": "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!::::*:999+85883446878/--'-----'334933-36;665999+95!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!",
"start": 1,
"stop": 377
}
},
```
cc @flothoni @duezAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3727Utilisation de getS() ou de la graîne avec Aho-Corasick2019-02-28T20:52:32+01:00Mikaël SalsonUtilisation de getS() ou de la graîne avec Aho-CorasickDans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a u...Dans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a un automate par germline et les graînes ne sont pas encore différenciées selon le gène. Mais cela pourrait poser problème plus tard (ou à d'autres endroits du code), notamment avec #1169.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3589Termiinal web sur les environnements Docker2024-01-18T11:02:30+01:00Mathieu GiraudTermiinal web sur les environnements DockerDispo depuis 11.4 :
https://docs.gitlab.com/ee/ci/interactive_web_terminal/
Pourrait être intéressant pour débugguer des tests qui ne passent pas.
cc @RyanHerbDispo depuis 11.4 :
https://docs.gitlab.com/ee/ci/interactive_web_terminal/
Pourrait être intéressant pour débugguer des tests qui ne passent pas.
cc @RyanHerbDev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3588.gitlab-ci.yml : utiliser only/except pour ne lancer certains tests que lors ...2024-01-18T11:02:41+01:00Mathieu Giraud.gitlab-ci.yml : utiliser only/except pour ne lancer certains tests que lors de certaines modifications ?(Probablement un doublon, je n'arrive pas retrouver l'issue d'origine.)
Possible depuis 11.4, déployé sur gitlab.inria.
https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#run-jobs-codeonlycodecodeexceptcode-for-modifications-on-...(Probablement un doublon, je n'arrive pas retrouver l'issue d'origine.)
Possible depuis 11.4, déployé sur gitlab.inria.
https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#run-jobs-codeonlycodecodeexceptcode-for-modifications-on-a-path-or-fileDev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3584Germline unexpected : comment remonter à la bonne germline ?2024-03-27T16:43:37+01:00Mikaël SalsonGermline unexpected : comment remonter à la bonne germline ?La fonction `Germline::override_rep5_rep3_from_labels` permet normalement de faire cela. Elle est utilisée lorsqu'on est en unexpected afin d'aligner la séquence contre les bons répertoires.
Les répertoires corrects sont trouvés grâce a...La fonction `Germline::override_rep5_rep3_from_labels` permet normalement de faire cela. Elle est utilisée lorsqu'on est en unexpected afin d'aligner la séquence contre les bons répertoires.
Les répertoires corrects sont trouvés grâce aux KmerAffect. Mais… ces KmerAffect sont les mêmes pour un germline complet et incomplet (le shortcut est par exemple `H` en complet et `h` en incomplet) :
```c++
affect_5 = string(1, toupper(shortcut)) + "-" + code + "V";
affect_4 = string(1, 14 + shortcut) + "-" + code + "D";
affect_3 = string(1, tolower(shortcut)) + "-" + code + "J";
```
On pourrait se dire que ce n'est pas grave et qu'on va mettre des KmerAffect différents pour les germlines complets et incomplets… sauf que non. Si on fait cela la partie commune des germlines complets et incomplets (souvent les gènes J) seraient considérés comme ambigus car appartenant à des germlines différents.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3501Aho : retirer les hack2024-03-26T12:09:05+01:00Mikaël SalsonAho : retirer les hack5bc753eeae et 5ccd2ec7345bc753eeae et 5ccd2ec734Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3402Aho : segmentation en DJ au lieu de VDJ2018-10-03T15:57:05+02:00Mikaël SalsonAho : segmentation en DJ au lieu de VDJSur le test simple `should-vdj-tests/igh-vdj.should-vdj.fa` on segmente en DJ au lieu de segmenter en VDJ.
```
>(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 IGHJ4*01 [IGH]
agcctacatggagctgaggagcctgagatctgacgacacggccgtgtattactgtgcga...Sur le test simple `should-vdj-tests/igh-vdj.should-vdj.fa` on segmente en DJ au lieu de segmenter en VDJ.
```
>(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 IGHJ4*01 [IGH]
agcctacatggagctgaggagcctgagatctgacgacacggccgtgtattactgtgcgagaga
gtattatgattacgtttgggggagttatgcttatacc
actactttgactactggggccaaggaaccctggtcaccgtctcctcag
```
En IGH :
```
IGH SEG_+ 1.339458e-30 2.318227e-129/1.339458e-30+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
```
En IGH+ :
```
IGH+ SEG_+ 1.329853e-39 8.909570e-83/1.329853e-39 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
```
Cela passe en IGH+ à cause du J, qui a pourtant autant d'affectations dans les deux cas. Mais la différence c'est que la fenêtre est plus proche du J en IGH+ qu'en IGH. La e-valeur est donc calculée sur une zone moins grande pour le J en IGH+ qu'en IGH, la e-valeur est donc moins élevée en IGH+ et IGH+ gagne.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3397Coûts environnementaux et économiques de CI (et dev)2024-02-16T10:00:05+01:00Mathieu GiraudCoûts environnementaux et économiques de CI (et dev)Depuis #2723 :
> est-il raisonnable (coûts environnementaux, économiques, dépendance sur un serveur externe, etc.) de télécharger p.ex. 1Go de données à chaque pipeline ?
Et #2881 arrive...
Plus généralement, quelle sont ces coûts sur...Depuis #2723 :
> est-il raisonnable (coûts environnementaux, économiques, dépendance sur un serveur externe, etc.) de télécharger p.ex. 1Go de données à chaque pipeline ?
Et #2881 arrive...
Plus généralement, quelle sont ces coûts sur l'ensemble de notre process de CI, qui doit faire surtout beaucoup de CPU ? Est-ce que ces coûts sont négligeables ou non devant les gains de productivité / robustesse avec un bon pipeline de CI ?Dev-cihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3388Agrandir la taille des graines pour limiter les faux positifs2019-11-23T06:51:30+01:00Mikaël SalsonAgrandir la taille des graines pour limiter les faux positifsDans vdj#693 on se rend compte que certains faux positifs peuvent gêner la segmentation. Ces faux positifs sont dus à une taille de graine faible en TRA+D (c'est un `-k 9`).
Historiquement on a cette petite taille car les TRDD sont cour...Dans vdj#693 on se rend compte que certains faux positifs peuvent gêner la segmentation. Ces faux positifs sont dus à une taille de graine faible en TRA+D (c'est un `-k 9`).
Historiquement on a cette petite taille car les TRDD sont courts. Mais maintenant qu'on utilise les régions amont et aval cette raison n'a plus de sens.
Il serait bon de remonter cette valeur à `-s 10s`, voire plus, sans forcément attendre #1364.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3365should-vdj-to-tap ne vérifie pas correctement le locus2020-05-20T16:40:35+02:00Mikaël Salsonshould-vdj-to-tap ne vérifie pas correctement le locusDans `should-vdj-tests/igh-vdj.should-vdj.fa` le 3è test passe pour le locus alors qu'il n'est pas correct (IGH+ trouvé au lieu de IGH).
```
#(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 (IGHJ4*01, IGHJ4*02) [IGH] BUG
>1 100 101 12...Dans `should-vdj-tests/igh-vdj.should-vdj.fa` le 3è test passe pour le locus alors qu'il n'est pas correct (IGH+ trouvé au lieu de IGH).
```
#(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 (IGHJ4*01, IGHJ4*02) [IGH] BUG
>1 100 101 121 seed IGH+ SEG_+ 2.180678e-23 4.130931e-61/2.180678e-23
```Algo -- Important