vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:39:37+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1699Générer des .fa.gz pour les gros get_reads2016-11-29T14:39:37+01:00Vidjil TeamGénérer des .fa.gz pour les gros get_readsMais quand on commence, on ne sait pas encore si c'est gros ou pas.
Une option en command-line ?
***
@mikael-sMais quand on commence, on ne sait pas encore si c'est gros ou pas.
Une option en command-line ?
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1680Export fasta: afficher d'une certaine manière les bases enlevées sur la germline2021-08-27T11:06:14+02:00Vidjil TeamExport fasta: afficher d'une certaine manière les bases enlevées sur la germlinepar exemple, si /-4 KDE :
>KDE...
ggagCCCTACAAGT
Minuscules : simple. (mais pb convention ?)
Couleur, parenthèses, italique ? peu .fa - compatible
Remarque de Tatiana : que faire si plusieurs séquences ? Afficher les V/J plusieurs foi...par exemple, si /-4 KDE :
>KDE...
ggagCCCTACAAGT
Minuscules : simple. (mais pb convention ?)
Couleur, parenthèses, italique ? peu .fa - compatible
Remarque de Tatiana : que faire si plusieurs séquences ? Afficher les V/J plusieurs fois ? Faire une option ?
à réfléchir avant de s'y lancer
***
On aurait aussi pu faire un équivalent de junction analyser:
atcgatcgatcgtagcatcatc
atcgAtcaAAA
TATTatcatc
... mais non, il faut résister à l'envie, le but est que le segmenter avec l'affichage des germline fasse cela.
Bref, on se limite pour cette tâche à un truc simple, qui garde la compatibilité avec un .fa
***
Discuté aussi vendredi dernier.
On pourrait aller vers deux exports :
1) Un export fasta brut, comme actuellement (avec en particulier les V/D/J à la fin, groupés). Utilisation bioinfo derrière.
2) Un export avec alignement du read contre germline V/D/J, avec espaces / tiret, et majuscules/minuscules dans les germlines V/D/J pour mutations. Éventuellement avec des infos de score, e-value... Et même avec couleurs (on se rapproche du rapport...), mais en restant basé texte pour copie facile.
Le 2) est très tentant, mais fera peut-être doublon avec le segmenter ? Pas si sûr, et ce serait très agréable d'avoir cela pour nous aider à faire les .should-vdj et discuter ensemble de segmentation. D'ailleurs, même une fois que le segmenter fera ce qu'on veut, une fonctionnaité d'export du segmenter sera la bienvenue !
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1676Séparateurs milliers/décimal2022-06-20T18:16:57+02:00Vidjil TeamSéparateurs milliers/décimalActuellement nous sommes incohérents :
- séparateur décimal : "." (car javascript)
- mais model.js: toStringThousands : séparateur milliers " "
Cela me fait mal au coeur à mettre "," comme séparateur de milliers, mais ce serait plus...Actuellement nous sommes incohérents :
- séparateur décimal : "." (car javascript)
- mais model.js: toStringThousands : séparateur milliers " "
Cela me fait mal au coeur à mettre "," comme séparateur de milliers, mais ce serait plus cohérent à court terme
Et on peut faire une vrai i18n un jour.
***
J'ai essayé le "," comme séparateur de milliers, argh, l'européen continental que je suis n'aime pas :
segmented 519,680 reads (89.39%)
2 clones, 1,212,434 reads
Bref, je préfère mettre pour l'instant cela sous le tapis... on verra si les Anglais s'en aperçoivent un jour :)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1665minifier JS ?2017-11-29T13:56:18+01:00Vidjil Teamminifier JS ?https://github.com/mishoo/UglifyJS2 ? Autre chose ?
Utiliité ? (comme on a besoin de MB pour télécharger les .vidjil, est-ce que cela vaut le coup de compresser un peu les .js ?)
***
@Duezhttps://github.com/mishoo/UglifyJS2 ? Autre chose ?
Utiliité ? (comme on a besoin de MB pour télécharger les .vidjil, est-ce que cela vaut le coup de compresser un peu les .js ?)
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1650Convention_de_codage ou ConventionDeCodage ?2019-12-02T18:12:51+01:00Vidjil TeamConvention_de_codage ou ConventionDeCodage ?
***
@magiraud @mikael-s
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1620Vidjil-all-slaves directement après coverage ?2019-03-05T14:42:50+01:00Vidjil TeamVidjil-all-slaves directement après coverage ?Vidjil-coverage dure 4 min
valgrind-unit dure > 20 min
On doit donc souvent attendre ~ 25 minutes avant d'avoir des bugs (ou des résolutions) dans all-slaves.
Ne faudrait-il pas lancer all-slaves directement après coverage (quitte à su...Vidjil-coverage dure 4 min
valgrind-unit dure > 20 min
On doit donc souvent attendre ~ 25 minutes avant d'avoir des bugs (ou des résolutions) dans all-slaves.
Ne faudrait-il pas lancer all-slaves directement après coverage (quitte à supprimer valgrind-unit, puisque valgrind est inclus dans all-slaves) ?
***
Vidjil-coverage lance déjà les tests. Ils passent sur meccano alors qu'ils ne passent pas sur all slaves, c'est pas de chance. Mais le rôle de valgrind-unit est de faire une première passe de valgrind sur les tests unitaires pour voir s'il n'y a pas de problème dessus avant de lancer ces tests unitaires avec valgrind sur *tous* les slaves (pour éviter d'avoir tous les slaves qui râlent en même temps, c'est même toi qui l'avait demandé).
Dans ce cas les tests semblent passer sous debian (c'est pour ça que ça franchit successivement coverage et valgrind-unit sans souci) mais foire sur le all-slaves.
Supprimer valgrind-unit n'améliorerait pas la situation actuelle mais obligerait à lancer les tests sur tous les slaves même quand il y a un problème basique impactant tous les slaves. Ici le problème n'impacte pas tous les slaves, donc on ne voit pas l'intérêt de valgrind-unit…
***
ok. Effectivement, la dépendance unit > all-slaves-unit est justifée.
Pour boucler la boucle, on pourrait avoir:
coverage (meccano) 4' > all-slaves (sans unit) 4' > unit 20' > all-slaves (avec unit) 20 '
mais cela en fait un de plus...
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1607Des e-valeurs sont supérieures à 12023-03-01T17:05:07+01:00Vidjil TeamDes e-valeurs sont supérieures à 1Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé....Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé... à voir si on peut le refaire sur un autre fichier, et surtout sur la nouvelle version. En attendant, la séquence en question est dans notable, et elle donne une e-valeur correcte seule.
***
Ici on en a aussi : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2 : e-valeur de 568 pour le clone en J3
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1604Le calcul de la e-valeur devrait prendre en compte le -t2018-04-10T12:28:09+02:00Vidjil TeamLe calcul de la e-valeur devrait prendre en compte le -tSi on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers...Si on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers V (et même x - s + 1) par exemple.
***
ok
***
Tout doit se faire dans kmerstore.h
- en entrée, les insert() reçoivent et utilisent keep_only : à stocker
- en sortie, getProbabilityAtLeastOrAbove()
***
68fef14. Quitte à prendre en compte le -t, autant être plus générique : si on n'a inséré que des choses de 200 ou moins, le calcul devrait prendre en compte ces 200.
Pour faire le changement souhaité, il faut maintenant faire quelque chose du type :
int n_max = atMostMaxSizeIndexing(length) - getS() + 1;
dans getProbabilityAtLeastOrAbove()
Mais j'ai maintenant des doutes : veut-on remplacer vraiment n par n_max dans toute cette fonction ? Est-ce que le index_load n'a pas déjà pris cela en compte ?
Bref, je te laisse voir :-)
***
Dans une séquence de longueur 200, même si on n'a inséré que des séquences de longueur 100 :
- la proba d'avoir exactement 18 k-mers est toujours la même ?
- et celle d'avoir 150 k-mers ? Elle est faible... mais pas nulle (et d'ailleurs, on trouvera des séquences chimériques avec cela). Est-ce que le but est de mettre cela à zéro ?
ou bien est-ce que cela doit être fait finalement dans affectanalyser.cpp:160 ? Qu'est-ce que cela signifie ?
***
La proba d'avoir 18 k-mers par hasard est plus élevée dans une séquence de longueur 200 que de longueur 100. De manière générale, il existe au moins une valeur t pour laquelle t k-mers dans 100nt est significatif mais pas t dans 200nt.
***
ok pour la longueur de la séquence observée, mais est-ce que cela dépend de la longueur de la séquence insérée ? (Cette dépendence ne serait-elle pas déjà dans le index_load ?)
En tout cas, si tu penses avoir la formule, vas-y :-)
***
Je pense que je ne comprends pas ce que tu veux dire :)
Par exemple pour l'instant on calcule la probabilité à gauche sur toute la longueur jusqu'à first_pos_max. Ce qui est très bien puisque cela évite de prendre en compte le N (dans lequel on ne s'attend pas à avoir de k-mers). Là c'est la même chose : on ne veut pas prendre en compte le début du V puisqu'on ne s'attend pas à avoir de k-mers dedans.
Autrement dit, entre un read qui contient 100nt de V et un read qui contient 300nt du même V, on ne devrait pas avoir une e-valeur différente (avec -t 100).
***
Après réflexion collective, un segment de 200, même avec -t 100, contient aussi un certain nb de kmers "aléatoires" dans les 100 premiers nt, qui fait que le calcul de la e-valeur serait tout de même bon (à peu près).
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1591server/apache2_install.sh2020-12-11T13:15:15+01:00Vidjil Teamserver/apache2_install.shContrairement à server/ngnix_install.sh, server/apache2_install.sh n'a pas été mis a jour depuis très longtemps. Est-ce encore fonctionnel ? Garder ou supprimer ?
***
@nobodyContrairement à server/ngnix_install.sh, server/apache2_install.sh n'a pas été mis a jour depuis très longtemps. Est-ce encore fonctionnel ? Garder ou supprimer ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1583Makefile: ne pas regénérer vidjil et align.cgi quand pas besoin2016-11-29T14:38:13+01:00Vidjil TeamMakefile: ne pas regénérer vidjil et align.cgi quand pas besoinMême sans rien modifier, un make refait toujours vidjil et align.cgi
- vidjil.o: c'est à cause de git-version.h, qui est toujours regénéré même si cela n'a pas changé
- align.cgi : je ne sais aps
***
ab1e8ea: git-version.h.
Il reste le...Même sans rien modifier, un make refait toujours vidjil et align.cgi
- vidjil.o: c'est à cause de git-version.h, qui est toujours regénéré même si cela n'a pas changé
- align.cgi : je ne sais aps
***
ab1e8ea: git-version.h.
Il reste les exécutables vidjil et align.cgi
***
e04751b et 9f3e2d8
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1568Nettoyage des fausses dates2018-11-20T09:10:55+01:00Vidjil TeamNettoyage des fausses datesIl faudrait supprimer / demander à nos utilisateurs de supprimer les dates pipo.
***
@magiraud @mikael-sIl faudrait supprimer / demander à nos utilisateurs de supprimer les dates pipo.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1556Méta-données : technique de séquençage2023-03-02T09:42:32+01:00Vidjil TeamMéta-données : technique de séquençageDNA-seq, RNA-seq, Capture, PCR, nested PCR... (plusieurs choix possibles...)
***
Ping. ADT, Aurélien ?
***
@magiraud @mikael-sDNA-seq, RNA-seq, Capture, PCR, nested PCR... (plusieurs choix possibles...)
***
Ping. ADT, Aurélien ?
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1544Exploiter les qualités des .fastq ?2019-09-16T16:58:44+02:00Vidjil TeamExploiter les qualités des .fastq ?Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof...Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof.
***
Disons que ce qu'on a vu sur les problèmes de représentative (https://www.producteev.com/workspace/t/553e1de8b1fa09d063000007) montrent plutôt qu'on s'en sort déjà bien sans regarder la qualité.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1529should_get : * est parfois shell-étendu2016-11-29T14:37:30+01:00Vidjil Teamshould_get : * est parfois shell-étendu$ ok
1: bla.* 0
$ fait une extension (shell) du .*
1: bla .* 0
est-ce normal ?
***
Tu l'as corrigé par 83167c9 ?
***
Oui, d'ailleurs c'était une extension uniquement dans l'output (ça n'impactait pas la regex).
***
@mikael-s$ ok
1: bla.* 0
$ fait une extension (shell) du .*
1: bla .* 0
est-ce normal ?
***
Tu l'as corrigé par 83167c9 ?
***
Oui, d'ailleurs c'était une extension uniquement dans l'output (ça n'impactait pas la regex).
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1516Color by locus2016-11-29T14:37:21+01:00Vidjil TeamColor by locusMarc, dans 1fcc4967, tu avais commenté "color by locus". Y-avait-il une raison particulière ?
Je l'ai remis, et cela a l'air de bien fonctionner.
***
et aussi cluster ? à voir
***
On va dire que c'est bon
***
@DuezMarc, dans 1fcc4967, tu avais commenté "color by locus". Y-avait-il une raison particulière ?
Je l'ai remis, et cela a l'air de bien fonctionner.
***
et aussi cluster ? à voir
***
On va dire que c'est bon
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1515SortMeVDJ : extraction/tri de reads suivant les locus2021-01-19T10:27:12+01:00Vidjil TeamSortMeVDJ : extraction/tri de reads suivant les locusCommande -c sort pour trier les reads, même non segmentés, suivant les différents locus. Est-ce que ce serait utile ?
Peut-être avec des seuils (IGH pour ceux qui ont significativement plus de k-mers IGH que d'autres).
Ou utiliser tout ...Commande -c sort pour trier les reads, même non segmentés, suivant les différents locus. Est-ce que ce serait utile ?
Peut-être avec des seuils (IGH pour ceux qui ont significativement plus de k-mers IGH que d'autres).
Ou utiliser tout simplement SortMeRNA ?
***
Et le filtre capture comme le filtre IMGT ne sont pas si loins...
***
FS a battu cette nuit un record : 1.97 GB, 22 M reads, pour... 3 reads segmentées
http://rbx.vidjil.org/browser/?patient=606&config=2
***
(lien avec place sur le serveur, virer tout sauf les séquences qui ont un peu de k-mers VDJ)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1496Valgrind: avoir la raison d'un build loupé dans le mail2020-12-11T13:06:01+01:00Vidjil TeamValgrind: avoir la raison d'un build loupé dans le mailC'est à eux qu'il faut demander : https://wiki.jenkins-ci.org/display/JENKINS/Valgrind+Plugin
***
@mikael-sC'est à eux qu'il faut demander : https://wiki.jenkins-ci.org/display/JENKINS/Valgrind+Plugin
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1475Récupérer des données par FTP/HTTP ou autre2017-11-22T12:48:32+01:00Vidjil TeamRécupérer des données par FTP/HTTP ou autreOn en parlait il y a très longtemps : on pourrait, au lieu d'uploader, donner une URL à télécharger. Cela pourrait revenir au goût du jour avec ceux qui ont des très grosses données : une transmission directe de leur serveur au notre ser...On en parlait il y a très longtemps : on pourrait, au lieu d'uploader, donner une URL à télécharger. Cela pourrait revenir au goût du jour avec ceux qui ont des très grosses données : une transmission directe de leur serveur au notre serait plus efficace qu'un upload browser.
Mais... peut-être que finalement on ne souhaite pas faciliter tant que cela l'import de fichiers de 10 GB ! Le wont-fix me tente :-)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1466/reports2020-08-27T11:38:45+02:00Vidjil Team/reportsMikael:
Je veux bien mais le répertoire reports/ n'existe pas ce qui fait foirer
le build Vidjil-valgrind
(https://ci.inria.fr/bonsai/job/Vidjil-Valgrind/10/console).
Et pourquoi ne mettre que les fichiers valgrind ? et pas les tap ? (...Mikael:
Je veux bien mais le répertoire reports/ n'existe pas ce qui fait foirer
le build Vidjil-valgrind
(https://ci.inria.fr/bonsai/job/Vidjil-Valgrind/10/console).
Et pourquoi ne mettre que les fichiers valgrind ? et pas les tap ? (mais
dans ce cas il faut probablement modifier la config des jobs sur Jenkins).
***
Mathieu : on a déjà unit_gcovr, should_gcovr et cppcheck qui remplissent reports (avec du xml). (Pour un éventuelle utilisation de sonar #3858, c'est bien si on sait où tout aller chercher.)
.tap : pourquoi pas (should_get, should-vdj, browser unit ?)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1448Séparation serveurs : app (html/js) // vda2017-11-22T12:48:32+01:00Vidjil TeamSéparation serveurs : app (html/js) // vdaFaudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le b...Faudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le browser
Juste une réflexion, on ne va pas se lancer là-dedans pour l'instant ! Et en plus, en production, ce n'est même pas dit que nos pb d'efficacité soient si importants, typiquement dans un hôpital il y aura 1 ou 2 utilisateurs, pas 100 simultanés :)
***
@nobody