vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-03-03T10:46:21+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4174original_names ne peut pas être correctement renseigné avec des fichiers AIRR2020-03-03T10:46:21+01:00Mikaël Salsonoriginal_names ne peut pas être correctement renseigné avec des fichiers AIRRDans `default.py` on fait le lien entre le `original_names` d'un fichier et le sample auquel il correspond dans le sample set.
Sauf que pour les fichiers AIRR on ne peut pas avoir l'information du `original_names`. Tout ce qu'on peut re...Dans `default.py` on fait le lien entre le `original_names` d'un fichier et le sample auquel il correspond dans le sample set.
Sauf que pour les fichiers AIRR on ne peut pas avoir l'information du `original_names`. Tout ce qu'on peut renseigner, c'est au moment où on fait le `fuse.py`, on peut renseigner le nom du `results_file`. Pour cela on peut créer un autre champ (du genre `original_results_name`) qui stockerait cette information dans le fichier fused.
Ensuite dans la fonction de `get_data` de `default.py`, il faudrait un autre dictionnaire similaire à `query2` mais dont les clés soient les `results_file` de la BDD (qui sont déjà récupérés par la requête précédente).
Nécessaire pour #3591.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4182Points décalés dans le rapport2020-02-26T16:19:25+01:00Mathieu GiraudPoints décalés dans le rapportLes points du rapport sont parfois décalés.
![rapport](/uploads/e3b6b9643944b0dd71bdf92e17a29b47/rapport.jpg)
cc @flothoniLes points du rapport sont parfois décalés.
![rapport](/uploads/e3b6b9643944b0dd71bdf92e17a29b47/rapport.jpg)
cc @flothonimarc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4202Clones dans .analysis (et pas dans .vidjil): ne créer de nouveau locus que si...2020-02-25T19:37:07+01:00Mathieu GiraudClones dans .analysis (et pas dans .vidjil): ne créer de nouveau locus que si reads existe et est > 0 ?
Pour compléter !602 :
> éventuellement ne créer le clone que si le nombre de reads est > 0, mais il faudrait être sûr que cela ne gène pas les créations manuelles de clones
Évoqué avec @flothoni, ~"priority-1-low". Après #2603.
Pour compléter !602 :
> éventuellement ne créer le clone que si le nombre de reads est > 0, mais il faudrait être sûr que cela ne gène pas les créations manuelles de clones
Évoqué avec @flothoni, ~"priority-1-low". Après #2603.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2603Affichage des clone ajoutés2020-02-25T19:36:29+01:00Mathieu GiraudAffichage des clone ajoutésNathalie ~"LIL-Lille" : "il faudra bien identifier les clones virtuels #1921, qu'on ne les confonde pas et qu'on s'en souvienne lors d'une prochaine visite".
Voir aussi #2212.
Afficher ces clones en carré (pivoté de 45°) dans le scatte...Nathalie ~"LIL-Lille" : "il faudra bien identifier les clones virtuels #1921, qu'on ne les confonde pas et qu'on s'en souvienne lors d'une prochaine visite".
Voir aussi #2212.
Afficher ces clones en carré (pivoté de 45°) dans le scatterplot ? Comment les mettre dans les autres vues ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4026Distributions et graphe2020-02-25T19:30:47+01:00Mathieu GiraudDistributions et grapheDéjà évoqué il y a quelques jours avec @flothoni et @mikael-s.
Actuellement on les affiche tous (car pas de top), illisible. Et même on les affiche *tous* (si 3 distributions, somme plus grosse)
- 1) en afficher aucun, simple
- 2) af...Déjà évoqué il y a quelques jours avec @flothoni et @mikael-s.
Actuellement on les affiche tous (car pas de top), illisible. Et même on les affiche *tous* (si 3 distributions, somme plus grosse)
- 1) en afficher aucun, simple
- 2) afficher la somme: plus complexe ? Et même trompeur: un trait qui relierait deux points ne montrerait pas nécessairement les mêmes clones. Probablement juste un *point gris* sera quand même informatif
Bref, pour l'instant solution simple, en attendant de discuter à l'intérêt de la solution 2.https://gitlab.inria.fr/vidjil/vidjil/-/issues/988Dégradé gris léger "résolution d'affichage" pour chaque sample2020-02-25T19:30:46+01:00Vidjil TeamDégradé gris léger "résolution d'affichage" pour chaque sampleAfficher une zone grise se terminant au plus bas du clone « top » (dépendant donc du nb de clones affichés).
(Et donc on comprend mieux comment fonctionne le slider : tout clone qui est à un point en dehors de ces zones grises est affic...Afficher une zone grise se terminant au plus bas du clone « top » (dépendant donc du nb de clones affichés).
(Et donc on comprend mieux comment fonctionne le slider : tout clone qui est à un point en dehors de ces zones grises est affiché.)
***
Priorité remontée (question Alice de Rennes)
***
Celle-là est moins facile. On t'expliquera demain.
***
Ping aussi : comment faire cela si le top est par système ? #1382
***
@Cyanael @RyanHerb @flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3850Pouvoir exporter des clones au format AIRR depuis l'interface2020-02-25T15:39:07+01:00Thonier FlorianPouvoir exporter des clones au format AIRR depuis l'interfaceJe pense que c'est faisable en modifiant/adaptant la fonction export au format csv.
Au passage, dans ce cas, peut-on en profiter pour inclure des infos supplémentaires comme les tags des clones ? Afficher le nombre normalisé ? autre ?Je pense que c'est faisable en modifiant/adaptant la fonction export au format csv.
Au passage, dans ce cas, peut-on en profiter pour inclure des infos supplémentaires comme les tags des clones ? Afficher le nombre normalisé ? autre ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/1229N, autres nucléotides étendus2020-02-21T21:20:02+01:00Vidjil TeamN, autres nucléotides étenduscore/tools.cpp:complement_nucleotide(66-76) pourrait faire croire que l'on gère d'autres nucléotides que A, C, G, T. Il n'en est évidemment rien :
- KmerStore::get() ne renvoie qu'un seul kmer
- et même dans dynprog, Cost::substitution...core/tools.cpp:complement_nucleotide(66-76) pourrait faire croire que l'on gère d'autres nucléotides que A, C, G, T. Il n'en est évidemment rien :
- KmerStore::get() ne renvoie qu'un seul kmer
- et même dans dynprog, Cost::substitution fait seulement (a == b)
Si on y tient :
- autoriser des caractères étendus dans les reads > trop complexe à gérer, risque de ralentir
(****mais que se passe t-il actuellement ? si N ? il faudrait être clair***)
- autoriser des caractères étendus dans les germlines > pas plus simple, mais pour le coup cela ne ralentirait pas
Bofbof. Utiilité ?
***
- en sortie : voir "representative"
***
l'automate rendrait certaines choses possibles (en le faisant grossir, certes)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3218Supprimer les k-mers non significatifs ?2020-02-21T21:19:30+01:00Mathieu GiraudSupprimer les k-mers non significatifs ?(Juste une réflexion peut-être non pertinente, à voir uniquement si le temps du filtrage reste significatif après #3217.)
Sur IGHV (347 gènes), en prenant des k-mers de taille 5:
- 1031 k-mers différents, dont
- 36 k-mers qui appar...(Juste une réflexion peut-être non pertinente, à voir uniquement si le temps du filtrage reste significatif après #3217.)
Sur IGHV (347 gènes), en prenant des k-mers de taille 5:
- 1031 k-mers différents, dont
- 36 k-mers qui apparaissent dans >= 300 des gènes.
- environ 500 k-mers qui apparaissent dans >= 50 des gènes
Cela fait beaucoup de k-mers qui apparaissent très souvent (et qui vont "charger" l'automate, le match ne serait-il pas en `O(zn)`, où `z` est le nombre moyen d'affectations par k-mer) ?
On verra quand on aura le temps exact du filtrage (sans suppression) pour #3190 et après #3217, mais est-ce que ces 36 kmers apparaissant trop souvent apportent vraiment du signal dans le filtrage ? (Ils peuvent certes amener un signal négatif, on pourrait à la limite stocker cette info.)
cc @mikael\-s @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2985Améliorer la fonction de hash2020-02-21T21:18:24+01:00Mathieu GiraudAméliorer la fonction de hash@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/76#note_68968 :
> Généralement la minimisation ne se fait pas sur l'ordre lexico (car cela favorise AAAA…, ou des régions de faible complexité riches en A, qui ne sont pas ...@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/76#note_68968 :
> Généralement la minimisation ne se fait pas sur l'ordre lexico (car cela favorise AAAA…, ou des régions de faible complexité riches en A, qui ne sont pas les séquences ADN les plus spécifiques), mais en utilisant une fonction de hash.Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4198Chevauchement up/downstream : diviser par 2 ?2020-02-21T09:51:40+01:00Mathieu GiraudChevauchement up/downstream : diviser par 2 ?
Depuis #3133 et https://gitlab.inria.fr/vidjil/vidjil/merge_requests/606/diffs?commit_id=52aa017c75c30eee8bd826ccaaaca63fac495885#aebf9c17d51c0c1fbadd922e57cf2143bcc70201_143_162 :
> Should we divide by 2 the length so that we don't ha...
Depuis #3133 et https://gitlab.inria.fr/vidjil/vidjil/merge_requests/606/diffs?commit_id=52aa017c75c30eee8bd826ccaaaca63fac495885#aebf9c17d51c0c1fbadd922e57cf2143bcc70201_143_162 :
> Should we divide by 2 the length so that we don't have overlaps between up and downstream?
Effectivement, depuis !606 les `up` et `down` contiennent tous les deux la séquence, enfin, quand l'espace est de taille minimale à l'intérieur d'un locus (d'ailleurs, est-ce régulier ou pas ?).
Si on chargeait cela simultanément, cela ferait des `ambiguous` et limiterait l'intérêt d'avoir prolongé... mais bon, on ne les charge pas simultanément. Bref ~"wont-fix" ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4196Scatterplots "plutôt carrés" ?2020-02-20T17:53:24+01:00Mathieu GiraudScatterplots "plutôt carrés" ?En discutant sur #4195, on a refait le constat que nos vues ~"client-grid", ~"client-bar" (et ~"client-graph") sont plutôt pensées "rectangulaires". On a habituellement un ratio x:y de 4:1 à 3:1, rarement vers 2:1 (sauf quand on fait bo...En discutant sur #4195, on a refait le constat que nos vues ~"client-grid", ~"client-bar" (et ~"client-graph") sont plutôt pensées "rectangulaires". On a habituellement un ratio x:y de 4:1 à 3:1, rarement vers 2:1 (sauf quand on fait bouger le séparateur) ou moins. Le choix des axes V/J par défaut va dans ce sens (très peu de J).
Pourrait-on afficher des ~"client-grid" 1:1 (voire 1:1,5) ? A priori rien ne l'empêche (et @duez: "quand elle existe, la barre de locus pourrait être horizontale"). Certaines combinaisons d'axes devraient déjà faire quelque chose de joli (similarity, compare, ...).
À voir si il faudra trouver un joli `sp2` par défaut pour le panel C de #4195. Rien d'urgent pour l'instant.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4152only/except pour remplacer feature-a ?2020-02-20T16:36:27+01:00Mathieu Giraudonly/except pour remplacer feature-a ?Cas particulier de #3588, viendra une fois qu'on aura du recul déjà sur #4148.
De quoi `feature-a` doit dépendre ? Je vois déjà:
```yaml
only:
changes:
- algo/**/*
- doc/vidjil-algo.md # les tangles
- germline/g...Cas particulier de #3588, viendra une fois qu'on aura du recul déjà sur #4148.
De quoi `feature-a` doit dépendre ? Je vois déjà:
```yaml
only:
changes:
- algo/**/*
- doc/vidjil-algo.md # les tangles
- germline/germline_id
- germline/*.g
- tools/**/* # on pourrait être plus précis
```
Les `**/*` ailleurs que dans `algo/` peuvent être problématiques, le soucis est qu'on risque de lancer souvent pour rien #3397 (mais c'est très bien si on détecte ainsi des problèmes).
À l'inverse, même si on ne couvre pas 100% (et c'est déjà le cas actuellement, ou on "oublie" de nommer correctement une branche à certains moments), normalement on a un pipeline hebdomadaire sur `dev` qui teste tout, il faudra veiller à ce qu'il soit bien conservé.
Bref, a priori quelques fichiers `germline/`, plutôt que `germline/**/*` (le but est bien de pouvoir travailler sur une `feature-g` indépendamment de l'algo)
Quelque part cela fait réfléchir à nos dépendances (et à #1491 :).2020-04-02https://gitlab.inria.fr/vidjil/vidjil/-/issues/4192Les clones bougent à chaque clic2020-02-20T16:19:05+01:00Mikaël SalsonLes clones bougent à chaque clicDepuis D3V5 (?) les clones bougent beaucoup plus à chaque clic sur un clone.
Voici un exemple maintenant (sur [L3](http://app.vidjil.org/?set=25736&config=25)).
Notez comme le paquet de clones TRG à droite bouge beaucoup alors que je cl...Depuis D3V5 (?) les clones bougent beaucoup plus à chaque clic sur un clone.
Voici un exemple maintenant (sur [L3](http://app.vidjil.org/?set=25736&config=25)).
Notez comme le paquet de clones TRG à droite bouge beaucoup alors que je clique sur un autre clone.
![vidjil2](/uploads/17d53c760f25d8cb0c5fe75343084f4b/vidjil2.ogv)
Et la situation l'année dernière, plus stable :
![vidjil1](/uploads/cf82756c7a9118828b1eb4585a640625/vidjil1.ogv)marc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2924deploy-docker // installation et mise à jour Docker sur un serveur de prod2020-02-20T11:43:12+01:00Mathieu Girauddeploy-docker // installation et mise à jour Docker sur un serveur de prodStage manuel, en fin de pipeline, après #2940.
Pour l'instant déjà le ~client.
cc @RyanHerbStage manuel, en fin de pipeline, après #2940.
Pour l'instant déjà le ~client.
cc @RyanHerbprod-server-lilRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4189Le timeout des jobs ne semble pas correspondre au temps déclaré2020-02-18T16:06:04+01:00Thonier FlorianLe timeout des jobs ne semble pas correspondre au temps déclaréEn testant une config un peu longue, je suis tombé sur un timeout.
Pour rappel, ce temps est défini dans defs.py
```
TASK_TIMEOUT = 2 * 60 * 60
```
Dans le cas de `vdb`, on avait rallongé le temps à 5h (je viens de vérifier). Or, le la...En testant une config un peu longue, je suis tombé sur un timeout.
Pour rappel, ce temps est défini dans defs.py
```
TASK_TIMEOUT = 2 * 60 * 60
```
Dans le cas de `vdb`, on avait rallongé le temps à 5h (je viens de vérifier). Or, le lancement c'est fait à 10h46, et il n'est pas encore 15h46...
Il est utilisé dans le `task.py`, lors d'un ajout
```
task = scheduler.queue_task("pre_process", args, repeats = 1, timeout = defs.TASK_TIMEOUT)
```
Est-on certain que ce paramètre est bien pris en compte dans le docker ? je ne vois pour l'heure pas d'autres raison.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4185La présence du gène constant après le J pourrait rendre une séquence non anal...2020-02-13T17:20:55+01:00Mathieu GiraudLa présence du gène constant après le J pourrait rendre une séquence non analyséeLe cas particulier #2964 a été résolu par ~"cpp-aho". Mais le problème pourrait apparaître dans d'autres situations.
@mikael-s : "surtout pour ~"bio-rnaseq", en effet ~"bio-capture" implique J+downstream, donc moins marqué."Le cas particulier #2964 a été résolu par ~"cpp-aho". Mais le problème pourrait apparaître dans d'autres situations.
@mikael-s : "surtout pour ~"bio-rnaseq", en effet ~"bio-capture" implique J+downstream, donc moins marqué."https://gitlab.inria.fr/vidjil/vidjil/-/issues/4179Rupture de l'axe des Y / broken Y-axis2020-02-12T16:48:49+01:00Mathieu GiraudRupture de l'axe des Y / broken Y-axisDiscuté avec @mikael-s et @duez : devrait-on couper l'axe des Y pour voir un fond polyclonal sous un clone majoritaire (au lieu de la technique habituelle avec ~"client-filter") ?
Le soucis est qu'on veut toujours voir "l'écrasement". P...Discuté avec @mikael-s et @duez : devrait-on couper l'axe des Y pour voir un fond polyclonal sous un clone majoritaire (au lieu de la technique habituelle avec ~"client-filter") ?
Le soucis est qu'on veut toujours voir "l'écrasement". Par exemple, si le clone 1 est > 3-4 fois le clone 2, couper l'axe pour qu'il soit toujours au moins 2x plus gros que le clone 2. Ces cas peuvent cependant être très fréquents pour des échantillons de diag.
(Au passage, pas exactement sur le même sujet, https://www.data-to-viz.com/caveat/cut_y_axis.html)
@duez : "si on fait un truc automatique, il faudra avoir une préférence pour l'enlever"https://gitlab.inria.fr/vidjil/vidjil/-/issues/4177Courbes un peu plus angulées mais pas comme avant2020-02-12T16:40:31+01:00Mathieu GiraudCourbes un peu plus angulées mais pas comme avantVu avec @duez et @mikael-s: depuis !581, les courbes sont très smooth.
Possible qu'elles soient un tout petit plus anguleuses ?
Ou à terme, une préférence "smooth: off/on" ?Vu avec @duez et @mikael-s: depuis !581, les courbes sont très smooth.
Possible qu'elles soient un tout petit plus anguleuses ?
Ou à terme, une préférence "smooth: off/on" ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4176Filtrer des clones en sélectionnant un span sur un dégradé de couleur2020-02-12T16:38:33+01:00Mathieu GiraudFiltrer des clones en sélectionnant un span sur un dégradé de couleurÉvoqué avec @duez
Cas particulier de #2059 et #2370, bonus, rien d'urgentÉvoqué avec @duez
Cas particulier de #2059 et #2370, bonus, rien d'urgent