vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-05-22T17:09:00+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2011Ne pas lancer fuse quand le nombre de samples est trop important ?2017-05-22T17:09:00+02:00Vidjil TeamNe pas lancer fuse quand le nombre de samples est trop important ?Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : u...Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : un fuse sur 100 fichiers prend du temps).
De plus le fuse est lancé autant de fois qu'il appartient à de sample sets (donc au moins 2, non ?).
***
753e78c : On ne garde que les 16 premiers. C'est peut-être un peu brutal de faire cela au niveau de fuse.py, mais bon, cela renvoie tout de même un .vidjil pour une visualisation sur les premiers échantillons.
***
Ça me paraît un peu rapide. On n'a pas vraiment de solution pour « degrade gracefully ».
Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers ? Comment on fait pour avoir les autres ? Le custom fuse ne permet pas de sauvegarder les analyses.
Côté serveur il faudrait avertir les utilisateurs qu'ils ne verront que 16 fichiers.
Il y a des utilisateurs avec plus de 16 fichiers, et ça peut faire sens : http://rbx.vidjil.org/browser/index.html?patient=790&config=25
Le problème est surtout avec les runs ou avec Kiel qui met plein d'échantillons différents dans un même patient. Les clones n'ont rien à voir d'un échantillon à l'autre et donc on se retrouve avec des dizaines de milliers de clones dans le fichier. Une autre solution peut être de réduire le top lorsque le nombre de fichier augmente.
***
D'autant plus que l'utilisateur qui nous pause problème à ce sujet n'utilise pas le fuse automatique mais plutôt le custom_fuse, non ? Ne pourrait-ton pas simplement avoir des configs qui fusent et d'autres non ?
***
Oui, effectivement ça serait une solution simple de proposer à Kiel une config sans fuse (on sait faire ça ?).
***
Je pense qu'il y a un bout de code à changer pour que le run accepte de ne pas fuse, mais oui je pense que c'est possible.
***
Oui, le coup de la config en plus, pourquoi pas !
Ou même... la config par défaut pourrit faire 16 fichiers au plus, et on a une config spéciale si quelques gens veulent avoir beaucoup de points.
> « degrade gracefully ».
> Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers
C'est une bonne question. Mais que cela soit oui ou non, c'est un "degrade gracefully" si on montre 16 points... et si on dit qu'on a une autre config si vraiment on veut avoir d'autre chose.
Enfin, quitte à avoir une autre config, on pourrait aussi régler plus finement les paramètres du fuse (top et autres).
***
Ça me semble plus simple de demander à Kiel d'utiliser une config sans fuse, plutôt que de mettre en place le nécessaire pour avertir les utilisateurs que quand il y a plus de X fichiers ils ne verront pas tous les résultats et qu'ils doivent lancer avec une autre config (en espérant qu'il y ait une config correspondante avec un fuse infini).
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant), j'ai envie de savoir si j'ai de la conta entre mes 20 fichiers pas entre 16 fichiers plus ou moins choisis aléatoirement (dont l'ordre dépendra de l'upload).
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante (et même pas besoin de demander à Kiel d'utiliser une autre config, on peut mais ça n'est pas indispensable).
***
> plutôt que de mettre en place le nécessaire pour avertir les utilisateurs
Je ne suis pas d'accord sur ce point, c'est très simple avec les notifications. Cela permet d'avoir, par défaut, un comportement correct pour la majorité des utilisateurs, et de les inciter à utiliser correctement les patients. (Et s'ils leur manquent quelque chose, c'est facile de rajouter une config pour un user, pour des bonnes raisons). Je préfère être sûr, dès maintenant, que tous les utilisateurs font ce qu'il faut (et traiter au cas par cas quelques cas comme Kiel) plutôt que de retomber dans quelques mois sur un autre utilisateur qui fera pareil.
> Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant)
Oui, tout à fait ! 16 est un exemple, cela peut être 32 ou 42 :-) Dans tous les cas, au-delà de 8-10 simples, on devrait cacher sur le graphe (cf une autre tâche). Et encore plus si on fait des SampleSets : peut-être que quelqu'un aura un SampleSet de 100/200 patients correspondant à un truc particulier... (Mais lance-t-on les mêmes configs dans tous les SampleSet ? Ce n'est pas obligé.)
> En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante
Oui, c'est aussi possible, par exemple (1000 / #samples)... mais on a déjà du mal à expliquer ce qu'est notre top, alors là cela va être encore plus dur. Ou alors, 1000 tant que #samples < 8, puis ensuite cela descend.
***
Par défaut, met-on le -f dans fuse.py à 0 et on fait une config pour Kiel où le -f est à 1 (ou X) ?
***
Kiel vient d'ajouter une centaine de fichiers → –10 Go
***
@magiraud @RyanHerb @mikael-sWeb 2017.05Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2891Upload de plusieurs fichiers .fasta via un .zip / .csv2023-03-28T16:10:53+02:00Mathieu GiraudUpload de plusieurs fichiers .fasta via un .zip / .csvTâche originelle dans #1362
PAN a envoyé un .zip avec 4 fichiers dedans. Et ça on ne sait pas faire. Il faudrait « juste » décompresser l'archive et itérer sur tous les fichiers et les remplir tous avec les mêmes propriétés.
***
Oui, c...Tâche originelle dans #1362
PAN a envoyé un .zip avec 4 fichiers dedans. Et ça on ne sait pas faire. Il faudrait « juste » décompresser l'archive et itérer sur tous les fichiers et les remplir tous avec les mêmes propriétés.
***
Oui, cela simplifierait beaucoup certains usages... mais ce n'est pas si évident à faire :
- le "sampling date" peut ne pas être le même (mais on pourrait faire une passe manuelle ensuite)
- et surtout, si on décompresse, il faut le faire dans environnement sécurisé pour que cela ne mette pas le bazar dans nos fichiers
- et éduquer les utilisateurs pour que le .zip soit uniquement des fichier fasta (pas un fichier .txt ou je ne sais quoi en plus)...
En mode production MRD, ce n'est pas forcément nécessaire (un point à la fois).
***
Mentionné par nos amis du NHS.
Pour eux, ce serait même *différents patients* ? Au passage, c'est vrai que c'est plus réaliste. En production, on a le(s) run(s) de la semaine, avec du diag, et des MRDs de patients existants
***
Vraiment pas facile...
Début de réflexion : on uploade une archive, cela ajoute les fichiers, on arrive sur un tableau avec la liste des fichiers et des controles pour ajouter au patient qu'on veut ?
On suppose par contre que producer / sequencer sont le même pour tous...
Mais primers, non.
Pb: tant que le .zip n'est pas arrivé, on ne peut pas afficher le tableau.
Bof / bof...
Il faudrait expliciter le scénario avec nos users pour voir ce qu'ils veulent vraiment.
***
Est-ce vraiment un problème de ne pas voir le tableau ? De toute façon on voit l'upload en cours dans le widget.
***
Remis au goût du jour pour Lyon ?
***
Après le R1+R2, il faudra voir si on remet cela au goût du jour.
Heinrik a exactement le problème d'uploader régulièrement >20 fichiers, il faudrait un moyen de le faire plus rapidement.
À voir comment cela pourrait marcher avec le R1+R2.
***
Discuté lors de la Rando 2016.
Pas prioritaire. L'idée pour les prochains mois est déjà d'utiliser les "runs", de voir si nos utilisateurs aiment cela.
***
Ping.
Henrik est revenu à la charge. La solution la plus simple est un upload de plusieurs fichiers pour *un même* patient. À mon avis on peut bidouiller un truc côté Javascript, à voir si c'est souhaitable (récupère tous les fichiers et les envoie 1 par 1 ou 2 par 2 au contrôleur).
***
@nobody
cc @RyanHerbWeb 2023.10https://gitlab.inria.fr/vidjil/vidjil/-/issues/1589API des controlleurs : documenter2023-06-29T10:23:44+02:00Vidjil TeamAPI des controlleurs : documenterPour que Martin puisse faire ce qu'il veut, il faudrait documenter quelques controlleurs.Pour que Martin puisse faire ce qu'il veut, il faudrait documenter quelques controlleurs.Web 2023.10https://gitlab.inria.fr/vidjil/vidjil/-/issues/2020Clone majoritaire qui disparait avec un nombre plus important de samples2019-08-20T10:34:34+02:00Vidjil TeamClone majoritaire qui disparait avec un nombre plus important de samplesExemple : Dans le deuxième il y a un clone très clair en TRG qui disparait dans le premier cas
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&custom=16753&custom=16762&custom=16771&custom=16780&
http:...Exemple : Dans le deuxième il y a un clone très clair en TRG qui disparait dans le premier cas
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&custom=16753&custom=16762&custom=16771&custom=16780&
http://rbx.vidjil.org/browser/?custom=16705&custom=16717&custom=16729&custom=16741&
***
Cela semble dépendant de l'ordre. Essayé en local : selon les fichiers mis en premier les résultats obtenus ne sont pas les mêmes…
***
C'est ma faute : 0d40d04c7975403b691781b50eafef9efb1dced5
***
Je ne suis pas sûr de comprendre, merci en tout cas d'avoir trouvé.
Proposition : dans l'urgence, reverter simplement ce commit plutôt que de chercher à corriger. Puis changer une batterie de tests et changer le fonctionnement de fuse.py tranquillement.
***
Moi non plus je ne comprends pas.
***
Ah, c'est plus embêtant... Peux-tu mettre un test quelque part, même très informel, où on voit ce qui ne va pas ?
***
Commit réverté, utilisateur prévenu;
***
Merci ! Est-ce que cela ne vaudrait pas le coup de faire une notification sur le serveur pour tous ?
***
La mise à jour de prod-server sur rbx n'a été faite que hier et depuis il n'y a que Kiel qui a utilisé le fuse (ou lancé des jobs), du coup je ne pense pas que ce soit utile.
***
ok, parfait
***
@Duez @RyanHerb @mikael-s @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2542Clones qui n'apparaissent pas dans un compare samples2021-11-16T17:32:37+01:00Mikaël SalsonClones qui n'apparaissent pas dans un compare samples~"KIE-Kiel" nous remonte un problème où les clones n'apparaissent pas dans des compare samples (par exemple ici : http://app.vidjil.org/?custom=26292&custom=26293&custom=26294&custom=26295 en se connectant avec l'utilisateur 27).
Je n'a...~"KIE-Kiel" nous remonte un problème où les clones n'apparaissent pas dans des compare samples (par exemple ici : http://app.vidjil.org/?custom=26292&custom=26293&custom=26294&custom=26295 en se connectant avec l'utilisateur 27).
Je n'arrive pas à reproduire ce problème. Quelqu'un l'a ?
cc @flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2119Pas d'assigation VDJ lorsqu'il y a de grosses délétions2024-01-31T17:25:11+01:00Mikaël SalsonPas d'assigation VDJ lorsqu'il y a de grosses délétionsVoici [un exemple](http://app.vidjil.org/?patient=4601&config=25) où il y a 2 ou 3 centaines de nucléotides délétés dans le V. Le FIneSegmenter échoue à proposer une solution. Il me semblait qu'on avait déjà une issue sur le sujet, mais ...Voici [un exemple](http://app.vidjil.org/?patient=4601&config=25) où il y a 2 ou 3 centaines de nucléotides délétés dans le V. Le FIneSegmenter échoue à proposer une solution. Il me semblait qu'on avait déjà une issue sur le sujet, mais je ne l'ai pas retrouvée (lorsqu'à Lille on avait un patient dans une situation comparable). IgBlast trouve sans problème des solutions pour le V (avec 19 nucléotides dans le V c'est un peu juste pour déterminer duquel il s'agit), le D et le J.
Serait-ce dû à des optimisations pour ne chercher que sur la diagonale ? Peut-on la désactiver si on ne trouve pas de segmentation ?
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1362Upload de plusieurs fichiers via des formulaires web2018-03-21T19:04:38+01:00Vidjil TeamUpload de plusieurs fichiers via des formulaires webTâche spécialisée depuis la tâche originale déplacée dans #2891.
Tâche spécialisée depuis la tâche originale déplacée dans #2891.
Web 2018.01Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1008Nommer des séquences d'intérêt (super utile pour pool de patients, pour stand...2021-11-19T11:06:57+01:00Vidjil TeamNommer des séquences d'intérêt (super utile pour pool de patients, pour standards, pour clones connus)
***
#1007
***
#1007https://gitlab.inria.fr/vidjil/vidjil/-/issues/2031Pré-sélectionner un .analysis (standards connus, ...)2019-04-02T11:33:00+02:00Vidjil TeamPré-sélectionner un .analysis (standards connus, ...)On en avait parlé il y a déjà très longtemps (c'était même une fonctionnalité prévue avec Marc au tout début) : le "import analysis" est fantastique, permet par exemple de pré-charger une analyse avec des spikes ou autre chose.
Revenu ...On en avait parlé il y a déjà très longtemps (c'était même une fonctionnalité prévue avec Marc au tout début) : le "import analysis" est fantastique, permet par exemple de pré-charger une analyse avec des spikes ou autre chose.
Revenu au goût du jour par une demande explicite de Michaela :
====
Dear Mathieu and Mikael,
as you probably know, we in Kiel are now extensively using Vidjil for the analysis of our routine marker screening data.
We now want to start using spike-ins, because it is necessary for correction of targets representation.
Would it please be possible that we upload the sequences of spike-ins into vidjil and these will be always marked (eg. with diferrent colour), so that we can easily distinguish spike-in sequences from patients' sequences?
Thank you very much for your answer and have a nice weekend,
Michaela
====
Réponse de Mathieu :
=== Preparation, only once
1) Create a « patient » with the name « Spikes » (or what you want).
2) Upload there a Fasta file containing only the spikes (this could be an artificial Fasta file with only a few sequences)
3) Run it (with the same config that you use)
4) Once the run is completed, on the results, color what you want. Moreover, we advise to name the spike clones with a more meaningful label such as « Spike A » (in the list, double-click on the name of the clone). Note that the original name is still accessible, both on the status bar and on the information panel on each clone.
5) Click on « import/export → export analysis ». This will download a very small file that you can store on your computer, renaming it to something like « spikes.analysis »
=== Usage
Each time you have a new patient/sample, once the run is completed
6) Click on « import/export → import analysis » and select the file « spikes.analysis » from your computer. This will color the spikes. This step should be done *before* any other work on the sample, as it may reset some work done.
7) As usual, work on the sample, possibly merging / tagging some clones
8) Then « save patient » will save both the imported spikes and your work on the sample
In the future, we would like to improve this procedure to avoid step 6), but it would require some development.
***
Bref, serait-il possible de faire cela de manière plus intégrée ?
- un "import analysis" qui prenne directement un fichier sur le serveur ?
- un réglage dans la config ou ailleurs qui applique un .analysis dès le fuse ? (euh, les fused ne sont pas les .analysis !)
Liste déroulante quelque part des analysis disponibles ? Ceux qui sont marqués d'une certaine manière ?
Enfin, est-ce que "import analysis" fait bien un reset de tout ? Ou bien un merge ?
***
Autre application possible : tagger certains recombinaisons publiques, et tagger la non-recombinaison Dh7-J (on a parlé de Dh7 à la réunion Inca aujourd'hui)
***
Avec la méthode actuelle, attention au contexte dans lequel le fichier .analysis est généré. S'il contient trop d'informations, cela écraserait celles du sampleset dans lequel il est importé. cf. https://www.producteev.com/workspace/t/58221473b2fa094c7500000d
***
@magiraud