vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2023-03-28T16:10:53+02:00https://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/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/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
***
@magiraudhttps://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
***
#1007