vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:38:27+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1602Sauvegarder les changements de germline et gènes dans le fichier .analysis2016-11-29T14:38:27+01:00Vidjil TeamSauvegarder les changements de germline et gènes dans le fichier .analysisLorsque les tâches « changer les gènes V/D/J d'un clone », « changer le germline d'un clone » seront faites il faudra conserver les modifications dans le fichier .analysis pour les rejouer lors du rechargement du fichier.
***
=== save
mo...Lorsque les tâches « changer les gènes V/D/J d'un clone », « changer le germline d'un clone » seront faites il faudra conserver les modifications dans le fichier .analysis pour les rejouer lors du rechargement du fichier.
***
=== save
model_loader: strAnalysis()
=== load
model_loader: parseJsonAnalysis() -> appelle initClones(), puiis model:
===> applyAnalysis() (devrait être renommé applyCloneAnalysis)
***
=== save
model_loader: strAnalysis() : fait; utilisation de la var manuallyChanged pour identifier les clones concernés.
***
Si c'est bon, tu peux fermer la tâche :-)
***
@flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1593Format de germlines/*.g pas suffisamment souple2020-08-21T13:25:47+02:00Vidjil TeamFormat de germlines/*.g pas suffisamment soupleDans germlines.data on a deux entrées pour TRA+D mais en fait l'une va écraser l'autre. D'autre part on a TRD+ qui est défini comme :
"5": ["TRDV.fa", "TRDD2-01.fa"],
"3": ["TRDJ.fa", "TRDD3-01.fa"]
mais cela inclut le...Dans germlines.data on a deux entrées pour TRA+D mais en fait l'une va écraser l'autre. D'autre part on a TRD+ qui est défini comme :
"5": ["TRDV.fa", "TRDD2-01.fa"],
"3": ["TRDJ.fa", "TRDD3-01.fa"]
mais cela inclut le réarrangement TRDV/TRDJ qui doit être géré par ailleurs (avec un TRDD au milieu).
Bref on veut définir plusieurs listes de gènes "5", "4" et "3" au sein d'une même entrée.
"possible_recombinations": {
{ "5" : ["TRDV.fa"], "3" : ["TRDD3-01fa"]},
{ "5" : ["TRDD2-01.fa"], "3" : ["TRDD3-01.fa", "TRDJ.fa"]},
etc.
}
***
Si on le fait, cela évitera de plus de répéter les shortcut/color/description (et "recombinations" suffira)
Mais cela veut dire que tout le monde a les même "parameters". C'est loin d'être évident entre un Dd2-Dd3 et un Vd-Dd2 (même si le up/downstream aide).
***
On pourrait aussi enlever le "follows", cela avait un sens avant dans l'algo, plus maintenant.
Ou alors le renommer en un truc type "family" ou "locus".
***
d935001.
On verra plus tard pour question de "parameters"
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1561.vidjil : pouvoir stocker plusieurs gènes D2020-12-11T13:11:20+01:00Vidjil Team.vidjil : pouvoir stocker plusieurs gènes DLe fichier .vidjil ne permet de stocker qu'un gène 5', « 4' » et 3'. On pourrait en avoir plusieurs (c'est au moins vrai pour le « 4' », mais tant qu'à le gérer pour celui-là autant le faire pour les autres aussi). Ça veut dire avoir des...Le fichier .vidjil ne permet de stocker qu'un gène 5', « 4' » et 3'. On pourrait en avoir plusieurs (c'est au moins vrai pour le « 4' », mais tant qu'à le gérer pour celui-là autant le faire pour les autres aussi). Ça veut dire avoir des listes pour "5", "4" et "3" ( avec les "start" et "end" à l'intérieur) ?
D'ailleurs le nombre de délétions n'est jamais stocké explicitement dans un champ à part : il apparaît dans le nom de la segmentation mais c'est tout. Une occasion pour l'ajouter ?
***
évoqué vendredi dernier. Pas facile, faire du 4b (et éventuellement 4c ?)
***
@nobodyhttps://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/1528Positions dans les séquences commençant à 12021-10-21T19:00:56+02:00Vidjil TeamPositions dans les séquences commençant à 1À plusieurs endroits, on fait débuter la position par 0.
- bornes dans représentative
- infos de segmentation VJ
(Y-a-t-il un endroit où on fait commencer par 1 ?)
Vérifier que la pratique est 1 (que fait IMGT, que fait IgBlast...À plusieurs endroits, on fait débuter la position par 0.
- bornes dans représentative
- infos de segmentation VJ
(Y-a-t-il un endroit où on fait commencer par 1 ?)
Vérifier que la pratique est 1 (que fait IMGT, que fait IgBlast ?).
Et regarder un peu partout dans notre code... :(
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1473Axes génériques, depuis .json (coverage, evalue...)2021-07-12T16:09:41+02:00Vidjil TeamAxes génériques, depuis .json (coverage, evalue...)Être capable d'afficher n'importe quelle donnée passée dans le .json.
Notons que l'auto-découverte (comme pour le segmenter) peut ne pas être toujours très robuste et faire du bruit dans certains cas. Une solution acceptable pourrait êt...Être capable d'afficher n'importe quelle donnée passée dans le .json.
Notons que l'auto-découverte (comme pour le segmenter) peut ne pas être toujours très robuste et faire du bruit dans certains cas. Une solution acceptable pourrait être de demander à l'utilisateur de fournir une liste "axis" indiquant les axes à considérer (et en profiter pour demander le type entier / flottant / ..., ce qui peut être difficile à deviner).
***
Après réflexion, oui, il faudrait vraiment un mécanisme générique pour qu'on puisse spécifier quels axes on veut et ce qu'ils signifient (et on peut en profiter pour passer une chaîne d'aide) :
En ce moment, on aimerait pouvoir afficher
_coverage, en float, entre 0 et 1, "Coverage of the representative"
seg._evalue, en float, en échelle log, "E-value (number of k-mers)"
***
ping
***
Revenu au goût du jour le mois dernier avec "productive".
"Axes" veut dire x, y, et aussi couleur.
***
@nobodyRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1431Galaxy2023-03-02T08:42:20+01:00Vidjil TeamGalaxy?
***
il faut juste que je les recontacte... Rotterdam, pas de nouvelle. Je baisse.
***
@magiraud?
***
il faut juste que je les recontacte... Rotterdam, pas de nouvelle. Je baisse.
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1372traduire en AA2017-11-23T15:57:29+01:00Vidjil Teamtraduire en AA
***
#1369
***
#1369https://gitlab.inria.fr/vidjil/vidjil/-/issues/1371détecter Cys, Phe/Trp, "vers le bon endroit" (pas trop loin de la window)2016-11-29T14:35:26+01:00Vidjil Teamdétecter Cys, Phe/Trp, "vers le bon endroit" (pas trop loin de la window)
***
#1369
***
#1369https://gitlab.inria.fr/vidjil/vidjil/-/issues/1370export du C++ vers le fichier .vidjil (comme pour "seg" ?)2016-11-29T14:35:26+01:00Vidjil Teamexport du C++ vers le fichier .vidjil (comme pour "seg" ?)
***
#1369
***
#1369https://gitlab.inria.fr/vidjil/vidjil/-/issues/1369c++: détection CDR3: Cys, Phe/Trp + séquence en AA2019-10-23T07:37:53+02:00Vidjil Teamc++: détection CDR3: Cys, Phe/Trp + séquence en AAOn aurait pu tout faire en .js, mais le but est d'avoir les infos dans le .vidjil et être aussi capable d'afficher d'autres méthodes de détection de CDR3 (Nikos ou autres).
Tout cela sera appelé à la fin, en même temps que le FineSegmen...On aurait pu tout faire en .js, mais le but est d'avoir les infos dans le .vidjil et être aussi capable d'afficher d'autres méthodes de détection de CDR3 (Nikos ou autres).
Tout cela sera appelé à la fin, en même temps que le FineSegmenter (et cela pourrait même être après le fuse, mais bon...)
***
Marc, peux-tu pousser ce que tu as fait, sur une branche séparée ? Merci.
***
merci Marc. On doit maintenant regarder (comparer miTCR ?) (IMGT ?)
Faire des should_get à partir de certaines séquences ?
On voit cela au cours du mois de mars.
***
Voir le script cdr3_detection/cdr3Finder.py fait par Florian dans la branche cdr3.
Il faudra un jour mettre tout ou partie de cela dans le C++, tout en gardant une certaine vitesse.
***
à faire, important... en avril ?
***
Pour mémoire, échange de mail avec Florian :
Le 25 févr. 2016 à 15:28, Florian Thonier <florian.thonier@inserm.fr> a écrit :
>> # Run search of cys104 & his position
>> theotical_cys104 = dataGerm[clone["seg"].get("5", 0)][312-LEN_CYS104:312].replace(".","").upper() # fix better len for cys ?
>> clone = betterFinder(portion5, borne5, theotical_cys104, clone)
> 312 : d’où vient cette valeur ? Est-ce la position exacte/approchée où on doit trouver la Cys104 dans les séquences gappées ? Ou bien la position exacte est 312 - 15 ? (et est-ce que cela marche pour tous les locus ?)
La position exacte du cys104 est de 310 à 312.
Je pars des séquences gappées pour positionné la CYS. Sans les gaps, les séquences sont de taille très diverses, et je ne peux donc plus le positionner exactement.
Normalement, le principe des gap fourni par IMGT est justement d'être extrêmement correct sur cette portion, quelques soit le locus. J'en ai regardé de visu quelques unes pour vérifier à l'époque, ils ont des erreurs sur d'autres portions où des corrections manuels pourraient probablement être apportée.
> Et avec le replace(".",""), tu n’as plus les gaps ensuite ? (Est-ce que c’était important d’avoir les gaps au départ ?)
theotical_cys104 est donc un motif de taille 15, que tu recherches de manière exacte ou approchée
Je le recherche de manière approché, en autorisant des petites modifs. De souvenir, c'est un partie un peu bancale. Je calcul un score d’occurrence en essayant de tenir compte de possible insert ou mismatch. si le score est inférieur à 12 ou 9 nt d’occurrence sur 15 ou 12 de séquence, je ne poursuit pas. (a vérifier)
C'est la partie à améliorer. Le souci, c'est que les séquences des clones , dans cette portion et dans des cas extrêmes, peuvent parfois inclure des modifications qui empêchent la détection du pattern.
Il y aurait sûrement un meilleurs moyen d'approcher le pattern.
> cysStart = cys[len(cys)-3:]
cysStart est le début de theoretical_cys104 (mais est-ce la Cys104 ou juste le début du motif de taille 15 ?)
On obtient par cette manip le codon de la cys 104 théorique de ce segment. Il existe deux codons possible pour la cys (TGT et TGC).
====
>> #looking for trp/phe codons in CDR3 seq
>> admisibleSeq = [r"FG[A-Z]G", r"WG[A-Z]G", r"^FG"]
> D’où viennent exactement ces patterns ? Le dernier n’est-il pas beaucoup plus tolérant que tous les autres ? (ah oui, il est en dernier ?)
C'est patterns revenaient dans deux publications d'analyse de répertoire reposant sur la détection du CDR3. Etant majoritaires mais pas non plus exactes, j'ai inclut en plus le dernier. Comme tu l'as fait remarquer, il est en dernier; il y a un break qui arrête la recherche au premier pattern trouvé. Il est donc pris en compte que dans le cas ou les deux premier échouent.
***
Branche cdr3-c++.
Le coeur est 0aae0cf : la JUNCTION est ce qui va de la Cys104 à la Phe118/Trp118 :
- Repris les séquences gappées V
- Autant faire aussi des séquences gappées J, alignées sur les motifs dont parle Florian. IMGT ne les propose pas, on le fait donc (c2b0dfc)
On utilise l'alignement déjà fait dans align_against_collection. Pour l'instant, c'est simple : si on a 3 délétions à la fin du V, on considère que la position de référence de la Cys104 est 3 nucléotides plus à droite. Bref, on ne prend pas en compte d'autres indels qui pourraient arriver. Ce calcul pourrait être amélioré en récupérant la position exacte de l'alignement.
Il y a donc des cas où cela marche et des cas non (mais ou on devrait avoir la bonne longueur à +/- 1, voire 2, mais donc mauvaise prédiction de prédictif), voir les derniers commits de tests. Pour la release 2016.03 (qui doit avoir lieu cette semaine), on fera encore quelques adaptations, mais cette détection sera toujours marquée comme "expérimentale".
Florian, pourrais-tu regarder ce que cela donne ? Cela serait particulièrement utile que tu lance sur tes données ou sur les données de test en comparant ton script et en regardant les cas où il y a des différences. Attention, il faut faire "make get-all-data" dans germline pour récupérer/créer les fichiers gappés.
***
Branche cdr3-c++ mise à jour → c’est bon, on identifie maintenant la position de Cys104 et Phe118/Trp118 précisément dans la matrice de programmation dynamique (505c29d). Normalement on devrait maintenant trouver la bonne chose dans quasiment tous les cas.
(Dernier détail : IMGT va mettre certaines séquences comme "non-productives" car il y a des stop à l'extérieur du CDR3. Le "p" ou "u" calculé par Vidjil se limite à l'intérieur du CDR3.)
***
Je reviens après avoir fait un petit tour dans les résultats.
Premier point : ça marche super bien !
J'ai toutefois deux ou trois points.
- Les autres plate-formes incluent dans leur CDR3 les codons de la cys et de la phe/trp. Je pense que pour coller au mieux niveau interopérabilité, il faudrait aussi les inclure.
- Sinon, je pense qu'il y a en effet un problème au niveau de la position start. Le bug vient de savoir si la position de début est inclusive ou exclusive, mais cela provoque par exemple un mauvais positionnement du CDR3 dans l'interface web du CDR3.
- Le dernier point, c'est de savoir si vidjil doit chercher ou non les codons stop aussi en amont/aval. Certes, le CDR3 est fonctionnel, mais la séquence ne le sera peut-être pas. Soit il faut une double feature stop-cdr3 et stop-sequence, soit une seule qui prenne en compte les deux possibilités. Toutes les séquences que j'ai trouvées non conformes le sont à cause de ce point. En amont, ce serait relativement simple; en aval, je ne sais pas quelle est la limite avant qu'un codon stop soit handicapant lors de la traduction.
***
merci Florian pour tes remarques et ton travail là-dessus ! Je vais pousser bientôt tout cela dans dev.
1) Oui. Tu as raison, d'un côté, on doit donner ce que tout le monde attend... mais, de l'autre, on doit respecter les définitions IMGT. On va donc mettre les *deux* infos dans le json, cdr3 et junction, et chacun choisit ce qu'il veut.
2) A priori toutes les positions sont inclusives, normalement le c++ respecte cela. Après, on peut changer le côté browser pour qu'il respecte mieux, je vais enquêter
3) Disons que, pour l'instant, on ne dit que si le CDR3 est productif, pas plus. Le problème pour s'étendre "plus loin" est tout le problème du calcul de la séquence représentative. On peut avoir des reads d'un clone qui sont productifs, d'autre non. Bref, on mettra une tâche pour cela, mais on verra ultérieurement, à une prochaine release. Merci de garder tes séquences discordantes quelque part, on en aura bientôt besoin.
***
merci encore Florian ! C'est mergé.
***
#1370, #1371, #1372
***
@mikael-s @Duez @flothoni @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1244versions 2014.10 et .09 : deux limites différentes2016-11-29T14:33:41+01:00Vidjil Teamversions 2014.10 et .09 : deux limites différentesdescendu, on arrive à vivre avec
***
@Duezdescendu, on arrive à vivre avec
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1173Nouveau format .data : discuter, implémenter, réparer les unit tests :)2016-11-29T14:32:45+01:00Vidjil TeamNouveau format .data : discuter, implémenter, réparer les unit tests :)Branche "data"
Pourquoi haute priorité ?
Avant de faire une migration de tout le monde vers rbx.vidjil.org (et donc de tout relancer), on a intérêt a avoir un .data aussi stable (et pensé pour le multi-germline qui arrive).
***
DL au 15...Branche "data"
Pourquoi haute priorité ?
Avant de faire une migration de tout le monde vers rbx.vidjil.org (et donc de tout relancer), on a intérêt a avoir un .data aussi stable (et pensé pour le multi-germline qui arrive).
***
DL au 15/10 → pour ensuite envoyer la doc à Jack
***
@magiraud @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1158Message d'erreur si chargement .data ne marche pas2020-12-11T12:57:30+01:00Vidjil TeamMessage d'erreur si chargement .data ne marche pasFilip : "I've tried to import my vidjil.data file to the new version of browser but
it seems to be broken. It doesn't import any data when I click on start
button."
Peut-être qu'il n'a pas la bonne version du .data, mais un message d'er...Filip : "I've tried to import my vidjil.data file to the new version of browser but
it seems to be broken. It doesn't import any data when I click on start
button."
Peut-être qu'il n'a pas la bonne version du .data, mais un message d'erreur serait le bienvenu :-) Un catchall de toutes les exceptions qui peuvent arriver à ce niveau ?
***
Peut-être que cela marche avec le bug corrigé aujourd'hui dans 7b4029582
Vérifier que le truc est bien bétonné.
***
Il y a un cas rigolo où cela ne marche toujours pas, si on met un fichier analysis à la place de data, hihihi.
Evidemment, on peut faire des tests en plus, mais il y aura toujours le cas où un fichier malformé pourra faire bugguer une partie. Bref, un catch de toutes les exceptions me semble une bonne solution, au moins pour indiquer "Parse failed."
***
J'insiste, c'est primordial, surtout quand on est en train de changer le format .data...
-> un catch de toutes les exceptions me semble une bonne solution, au moins pour indiquer "Parse failed."
***
y compris "see result TRG"
***
descendu, on n'a plus eu de problème récemment
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1081Utiliser le nouveau format .analysis2016-11-29T14:31:34+01:00Vidjil TeamUtiliser le nouveau format .analysissur branche à part
***
La semaine prochaine? On essaie déjà de mettre en prod le server avant
***
- s'assurer que les fichiers sur bx.vidjil.org sont au nouveau format
- message d'erreur si le fichier est à l'ancien format
***
le format...sur branche à part
***
La semaine prochaine? On essaie déjà de mettre en prod le server avant
***
- s'assurer que les fichiers sur bx.vidjil.org sont au nouveau format
- message d'erreur si le fichier est à l'ancien format
***
le format analysis '2014.09' est ok
TODO : supprimer le fallback '2014.02'
***
Euh... je ne vois plus les fichiers analysis d'avant (testé pour Van Cel, Lec Lec...)
Est-ce parce que le parser 2014.02 ne marche plus trop ?
Uncaught TypeError: Cannot read property 'length' of undefined model.js:694
***
fallback '2014.02' retiré
les fichiers analysis sur la db sont tous au format '2014.09'
***
Désolé d'insister, mais je ne vois toujours pas les .analysis (Van Cel par exemple)
(Safari: TypeError: 'undefined' is not an object (evaluating 'c.length'))
***
Mikaël, est-ce que cela marche pour toi ?
***
Ah, cela commence à fonctionner. C'est de ma faute, je n'avais pas tout rafraîchi ?
On fera ensemble une passe sur les patients mardi
***
Que fait-on pour les fichiers existants sur bioinfo.lifl.fr ? Est-ce qu'on reste avec ces vieux fichiers (ce qui va nous poser problème un jour ou l'autre) ? Ou est-ce qu'on les convertit et si oui comment ?
Par exemple pour le run de Necker qui a tourné avec une version récente de Vidjil, sauf que bioinfo n'a pas la dernière version du browser. Si je passe à la dernière version du browser, je casse tout pour les autres utilisateurs… (qui ont des vieux fichiers)
***
Proposition :
- on ne casse pas bioinfo, on le laisse à la vieille version, jusqu'à ce que tout nos utilisateurs soient migrés vers rbx.
Et donc pour Necker, deux solutions :
- on relance le run avec la vieille version (branche vidjil.org)
- un jour, on les met sur le serveur
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1048Stats sur le jeu complet dans le fichier .vidjil / smaller clones2019-10-29T14:38:34+01:00Vidjil TeamStats sur le jeu complet dans le fichier .vidjil / smaller clonesReparlé plusieurs fois lors des dernières semaines.
Quels stats seraient intéressantes, sur tous les clones (pas seulement les FineSegmentés) ? Distribution des longueurs (on l'a, mais un peu brut), autres ?
(distribution V/J/CDR3/... de...Reparlé plusieurs fois lors des dernières semaines.
Quels stats seraient intéressantes, sur tous les clones (pas seulement les FineSegmentés) ? Distribution des longueurs (on l'a, mais un peu brut), autres ?
(distribution V/J/CDR3/... demanderait de faire plus de FineSegmenter)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5Interacting with RepSeq software2019-04-03T07:49:46+02:00Mathieu GiraudInteracting with RepSeq softwareWe develop the web application (both client and server) to be independent from the Vidjil algorithm. We try to include or to link several software to pre-process, process, or post-process RepSeq data. We both use and propose APIs to work...We develop the web application (both client and server) to be independent from the Vidjil algorithm. We try to include or to link several software to pre-process, process, or post-process RepSeq data. We both use and propose APIs to work within a ecosystem of RepSeq software. We contribute to open formats to exchange RepSeq data.