vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-10-05T19:18:20+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3452Comment lancer les calculs pour avoir les données pour les widgets ?2018-10-05T19:18:20+02:00Mathieu GiraudComment lancer les calculs pour avoir les données pour les widgets ?Voir #3407.
Constat : on ne peut pas tout recalculer, en tout cas pour des grosses données agrégées.
Pistes évoquées avec @mikael\-s et @RyanHerb :
- 1. vidjil-algo pourrait remplir des choses. Pourquoi pas (et peut-être que certain...Voir #3407.
Constat : on ne peut pas tout recalculer, en tout cas pour des grosses données agrégées.
Pistes évoquées avec @mikael\-s et @RyanHerb :
- 1. vidjil-algo pourrait remplir des choses. Pourquoi pas (et peut-être que certains infos ne sont sortables que dans l'algo), mais cela ne serait pas systématique
- 2a. **task.py, après vidjil, pourrait lancer un autre script .py qui modifierait le `.vidjil` en ajoutant ce qu'il faut.**
- 2b. Ou bien... dans le fichier fuse.
- 3. ou bien faire un fichier supplémentaire `.vidjil-extra`, là encore créé par task.py
- 3a. en DB (mais très peu motivé pour modifier le schéma de la DB pour quelque chose comme cela)
- 3b. léger, à la `out-xxxxxx/` (et si le fichier n'est pas là, tant pis, on n'affiche pas ou on recalcule)Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3450Modulariser .gitlab-ci.yml2021-02-23T11:54:48+01:00Mathieu GiraudModulariser .gitlab-ci.ymlDepuis #1491 :
> le `.gitlab-ci.yml` actuel est un gros mélange...
Vu https://gitlab.com/gitlab-org/gitlab-ce/issues/42861#note_99630939, on va pouvoir bientôt modulariser `.gitlab-ci.yml`, ce qui a la fois améliorera la situation act...Depuis #1491 :
> le `.gitlab-ci.yml` actuel est un gros mélange...
Vu https://gitlab.com/gitlab-org/gitlab-ce/issues/42861#note_99630939, on va pouvoir bientôt modulariser `.gitlab-ci.yml`, ce qui a la fois améliorera la situation actuelle (qu'on est susceptibles de garder encore un certain temps) et aussi préparera une éventuelle séparation #1491.
À faire dans la feature sera disponible dans ~"dev\-gitlab".https://gitlab.inria.fr/vidjil/vidjil/-/issues/3440repetition d'un warning de clone présent sur plusieurs sample : simplifier, f...2020-12-04T14:10:31+01:00Thonier Florianrepetition d'un warning de clone présent sur plusieurs sample : simplifier, factoriserCas ici: https://app.vidjil.org/browser/?set=28565&config=25
On peux voir qu'un clone a un warning `w61: non recombiné...`. Mais comme le clone est présent sur chaque sample, on a une répétion de celui-ci de multiple fois, au survol de ...Cas ici: https://app.vidjil.org/browser/?set=28565&config=25
On peux voir qu'un clone a un warning `w61: non recombiné...`. Mais comme le clone est présent sur chaque sample, on a une répétion de celui-ci de multiple fois, au survol de l’icône, ou bien aussi lors de l'affichage détaillé du clone.
Je ne sais pas si tous les warning devrait être concerné, mais une tel répétition dans ce cas présent est inutile.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3430Les tests watir sur segmenter_page ne fonctionnent plus2018-09-12T08:24:23+02:00Mathieu GiraudLes tests watir sur segmenter_page ne fonctionnent plusAu moins sur `dev` dans 68fd3a7.Au moins sur `dev` dans 68fd3a7.Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3399Tests sur des navigateurs récents2022-03-23T13:49:30+01:00Mikaël SalsonTests sur des navigateurs récentsDiscuté avec @RyanHerb : nos tests Watir tournent sous de (plus en plus) vieilles versions de Firefox.
La raison : un changement du côté de Watir dans la façon de se connecter au navigateur (ou quelque chose du genre). En tout cas les vi...Discuté avec @RyanHerb : nos tests Watir tournent sous de (plus en plus) vieilles versions de Firefox.
La raison : un changement du côté de Watir dans la façon de se connecter au navigateur (ou quelque chose du genre). En tout cas les vieilles versions de Watir n'arrient pas à causer avec un nouveau Firefox et inversement, les nouvelles versions de Watir n'arrivent pas à causer avec d'anciens Firefox.
Actuellement les tests navigateurs tournent sous Firefox 32 (première version mentionnée dans `doc/user.md`) et Firefox 45 (dernière version à être gérée par les anciennes versions de Watir).
Cette version date de 2 ans, ce qui n'est pas la nuit des temps, mais il serait bon aussi de se tester contre des versions plus récentes.
Le problème est qu'on n'a pas envie d'arrêter de tester d'anciennes versions de Firefox. Il faut donc deux versions de Watir, avec deux environnements Ruby. C'est possible. Il faut s'assurer par contre que le code est retro-compatible entre les deux versions de Watir, car maintenir deux versions des tests ne me semble pas souhaitable.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3393BinReadStorage : n'utiliser des bins que lorsque c'est nécessaire2018-08-07T09:05:54+02:00Mikaël SalsonBinReadStorage : n'utiliser des bins que lorsque c'est nécessaire#3392 a mis en évidence que l'espace mémoire est dominé par l'utilisation des bins, au moins lorsque le jeu de données n'est pas clonal (et donc que le nombre de fenêtres est proche du nombre de reads). De manière plus générale on peut p...#3392 a mis en évidence que l'espace mémoire est dominé par l'utilisation des bins, au moins lorsque le jeu de données n'est pas clonal (et donc que le nombre de fenêtres est proche du nombre de reads). De manière plus générale on peut penser que ce sera le cas tant que le nombre de fenêtres n'est pas plus un ordre de grandeur en dessous du nombre de reads.
À l'initialisation d'un `BinReadStorage` (instancié pour chaque clone) on fait :
```c++
if (no_list)
bins = NULL;
else
bins = new list<Sequence>[nb_bins+1];
score_bins = new double[nb_bins+1];
nb_scores = new size_t[nb_bins+1];
```
À lui seul ce bloc représente près de 500 Mo alloués, sur 1,2Go au total.
Le nombre de bins par défaut est défini dans `windowExtractor.h` :
```c
#define NB_BINS_CLONES 10
```
On a donc 11 bins par défaut. Et on construit donc des tableaux de 11 listes, 11 `double` et 11 `size_t`.
Sauf que typiquement sur ce jeu de données la plupart des clones n'auront qu'un read et donc la grande majorité des bins seront vides.
De plus les bins ne sont utiles qu'à partir du moment où on ne peut pas garder tous les reads d'un clone, c'est-à-dire quand la limite de `DEFAULT_MAX_AUDITIONED` (2000) est franchie. Donc dans la très grande majorité des cas les bins ne servent à rien à part gaspiller de l'espace mémoire.
Il faudrait donc mettre en place le stockage par bins quand le nombre de reads du clone dépasse `getMaxNbReadsStored`. Ce sera un peu plus coûteux en temps car il faudra redispatcher les reads dans des bins, mais ça devrait rester minime, même sur des échantillons fortement clonaux.Algo 2018.09Cyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3392Profilage de l'espace mémoire utilisé par Vidjil-algo2020-04-29T12:50:19+02:00Mikaël SalsonProfilage de l'espace mémoire utilisé par Vidjil-algoOn se pose des questions sur l'espace mémoire qu'on pourrait gagner dans l'algo (#3389) mais en fait on ne sait pas vraiment où est dépensé l'espace mémoire.
#2120 nous montre un exemple où, hors pic de la fin d'exécution, on arrive à e...On se pose des questions sur l'espace mémoire qu'on pourrait gagner dans l'algo (#3389) mais en fait on ne sait pas vraiment où est dépensé l'espace mémoire.
#2120 nous montre un exemple où, hors pic de la fin d'exécution, on arrive à environ 1,5 Go. Or on a 1M de reads, on trouve des fenêtres dans 500k d'entre eux. On stocke des informations relatives uniquement à ces 500k reads.
Ces reads ont une longueur moyenne de 260bp. Dans #3389 on a listé les différents champs stockés pour les reads. En voyant large on doit arriver à 1ko par read. Cela nous ferait 500 Mo. Il manque environ 1Go. Qu'est-ce que je loupe d'important ?
Il y a bien des informations stockées par rapport au statut de la segmentation, aux longueurs moyennes, mais ça me semble assez négligeable à côté des reads.
Si on n'est pas capable de déterminer l'origine du Go manquant, cela signifie qu'on a besoin d'un profilage de la mémoire utilisée par le programme pour mieux situer les axes d'amélioration.https://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/3381top par système dans vidjil-algo2024-02-01T16:01:57+01:00Mathieu Giraudtop par système dans vidjil-algoDepuis #1382.
Faire un `-z` (ping #3295) par système.Depuis #1382.
Faire un `-z` (ping #3295) par système.Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/3366CI ne lance pas shouldlocus2018-07-12T19:01:19+02:00Mikaël SalsonCI ne lance pas shouldlocusLes tests sur les locus ne sont actuellement pas lancés.
Or des tests peuvent échouer en `shouldlocus` et pas en `shouldvdj`Les tests sur les locus ne sont actuellement pas lancés.
Or des tests peuvent échouer en `shouldlocus` et pas en `shouldvdj`Algo 2018.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3356genes et up/down-stream : vérifier qu'on tombe au bon endroit par rapport à *012018-10-17T11:50:31+02:00Mathieu Giraudgenes et up/down-stream : vérifier qu'on tombe au bon endroit par rapport à *01Depuis !182 :
> > plus généralement, vérifier que cela qu'on extrait du chromosome comprend bien ce qu'on avait dans le gène ?
> Pas encore fait, c'est bien cela ?
`get_updownstream_sequences()` ou d'autres choses autour pourraient v...Depuis !182 :
> > plus généralement, vérifier que cela qu'on extrait du chromosome comprend bien ce qu'on avait dans le gène ?
> Pas encore fait, c'est bien cela ?
`get_updownstream_sequences()` ou d'autres choses autour pourraient vérifier que ce que l'on a dans le génome correspond à notre séquence (ou presque, voir aussi #3301).Algo 2018.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3353should-vdj-to-tap.py --retry2018-07-10T16:46:56+02:00Mathieu Giraudshould-vdj-to-tap.py --retryDe la même manière qu'on a `should.py --retry`, on devrait avoir quelque chose pour relancer uniquement les tests loupés.De la même manière qu'on a `should.py --retry`, on devrait avoir quelque chose pour relancer uniquement les tests loupés.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3325Mutations silencieuses (ou pas) : afficher les codons `get_codons`2018-09-28T12:21:46+02:00Mathieu GiraudMutations silencieuses (ou pas) : afficher les codons `get_codons`Voir #2056.
Lorsqu'une mutation est indiquée comme silencieuse au milieu du V, on n'a pas grand chose pour bien estimer ce qu'il se passe. On pourrait
- afficher la sortie de `get_codons` sur la séquence référence par des traits fins ...Voir #2056.
Lorsqu'une mutation est indiquée comme silencieuse au milieu du V, on n'a pas grand chose pour bien estimer ce qu'il se passe. On pourrait
- afficher la sortie de `get_codons` sur la séquence référence par des traits fins (comme ceux qui séparent V/N).
- voire avoir la possibilité d'afficher la séquence en AA ? #2140 (mais bug #3326)CLL-2018-septembrehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3275Gaps affine pour deletion_end pour de très grandes délétions2021-04-01T17:37:10+02:00Mathieu GiraudGaps affine pour deletion_end pour de très grandes délétionsLié à #3165.
Il serait apparament simple de changer la fonction qui utilise `deletion_end` :
`if (mode == LocalEndWithSomeDeletions) tbest += cost.deletion_end*(n-j); `
Faudrait-il un gap affine (ou même autre chose) pour permettre ...Lié à #3165.
Il serait apparament simple de changer la fonction qui utilise `deletion_end` :
`if (mode == LocalEndWithSomeDeletions) tbest += cost.deletion_end*(n-j); `
Faudrait-il un gap affine (ou même autre chose) pour permettre de très grandes délétions ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3270Utiliser NO_LIMIT_VALUE plutôt que UINT_MAX dans filter.h/filter.cpp2018-06-13T15:45:33+02:00Mathieu GiraudUtiliser NO_LIMIT_VALUE plutôt que UINT_MAX dans filter.h/filter.cppUn détail : nous n'avons pas l'habitude d'utiliser des comparaisons avec `UINT_MAX`, mais plutôt de faire un test explicite avec `NO_LIMIT_VALUE` (voir les occurrences de `NO_LIMIT_VALUE` dans `core/*.cpp`).
(Cela simplifiera en plus #3...Un détail : nous n'avons pas l'habitude d'utiliser des comparaisons avec `UINT_MAX`, mais plutôt de faire un test explicite avec `NO_LIMIT_VALUE` (voir les occurrences de `NO_LIMIT_VALUE` dans `core/*.cpp`).
(Cela simplifiera en plus #3264.)merge-filterCyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3268-Z all : ne pas construire l'automate2018-06-13T15:45:33+02:00Mathieu Giraud-Z all : ne pas construire l'automateLorsqu'on désactive l'automate, on ne devrait pas construire l'automate.
Ce n'est pas le cas pour l'instant pour les résultats de #3260 (mais c'était intéressant pour voir le temps de construction de l'automate). En temps normal, si on n...Lorsqu'on désactive l'automate, on ne devrait pas construire l'automate.
Ce n'est pas le cas pour l'instant pour les résultats de #3260 (mais c'était intéressant pour voir le temps de construction de l'automate). En temps normal, si on ne veut pas d'heuristique, on ne veut pas prendre du temps / de la mémoire avec l'automate.merge-filterCyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3264Option -Z pour le "N" du filtrage par automate2018-06-13T15:45:34+02:00Mathieu GiraudOption -Z pour le "N" du filtrage par automateFaire une option `-Z nb` (en ce moment on a peu d'options dispos, ping #2732) pour spécifier en ligne de commande le N à utiliser. Cela demandera sûrement de passer cette valeur à travers quelques fonctions.
Dans l'optique d'un merge pr...Faire une option `-Z nb` (en ce moment on a peu d'options dispos, ping #2732) pour spécifier en ligne de commande le N à utiliser. Cela demandera sûrement de passer cette valeur à travers quelques fonctions.
Dans l'optique d'un merge prochain, la valeur par défaut sera pour l'instant `-Z all` (voir `NO_LIMIT` / `NO_LIMIT_VALUE` dans `vidjil.cpp`).merge-filterCyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3250Décaler les valeurs ascii des K-mers AMBIGUOUS et UNKNOWN2018-07-02T13:36:43+02:00Cyprien BoréeDécaler les valeurs ascii des K-mers AMBIGUOUS et UNKNOWNMettre les caractères ascii des K-mers AMBIGUOUS et UNKNOWN à des valeurs supérieures à 127.Mettre les caractères ascii des K-mers AMBIGUOUS et UNKNOWN à des valeurs supérieures à 127.Cyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3246Attribuer la même couleur à tous les clones sélectionnés2018-06-04T10:08:04+02:00Mikaël SalsonAttribuer la même couleur à tous les clones sélectionnésUne demande de ~"LIL\-Immuno" est de pouvoir mettre de côté les clones non productifs. Une manière un peu générique de faire cela est de tous les sélectionner (ce qui est simple, puisqu'on a un axe pour cela), ensuite de leur attribuer u...Une demande de ~"LIL\-Immuno" est de pouvoir mettre de côté les clones non productifs. Une manière un peu générique de faire cela est de tous les sélectionner (ce qui est simple, puisqu'on a un axe pour cela), ensuite de leur attribuer une couleur et de cacher cette couleur. Problème : on ne peut pas attribuer directement la même couleur à tous les clones sélectionnés.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3201Tests unitaires serveur sur le multi-upload2021-10-15T09:38:08+02:00Mikaël SalsonTests unitaires serveur sur le multi-uploadIl n'y a actuellement pas de tests unitaires sur le multi-upload, notamment pour vérifier que les fichiers sont affectés au bon sample set (cf. #3199).
Cela serait nécessaire.Il n'y a actuellement pas de tests unitaires sur le multi-upload, notamment pour vérifier que les fichiers sont affectés au bon sample set (cf. #3199).
Cela serait nécessaire.Ryan HerbertRyan Herbert