vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:35:49+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1402algo/tools: align.cpp2016-11-29T14:35:49+01:00Vidjil Teamalgo/tools: align.cppEn cours de modif, pour tester dynprog
***
@magiraudEn cours de modif, pour tester dynprog
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1398Makefile et flags2016-11-29T14:35:46+01:00Vidjil TeamMakefile et flagsJe voulais passer -g -ggdb partout, il y a make debug pour cela, mais cela ne marche pas comme il faut.
Plus généralement, il faudrait revoir comment sont passés les flags entre algo et algo/core ? et vidjil ? $(OPTIM) ? Hum.
***
et algo...Je voulais passer -g -ggdb partout, il y a make debug pour cela, mais cela ne marche pas comme il faut.
Plus généralement, il faudrait revoir comment sont passés les flags entre algo et algo/core ? et vidjil ? $(OPTIM) ? Hum.
***
et algo/tools
***
344feb9, on n'efface plus CXXFLAGS et LDFLAGS définis par le système
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1394Filter/search dans le 'compare patients'2016-11-29T14:35:43+01:00Vidjil TeamFilter/search dans le 'compare patients'merci Marc
***
@Duezmerci Marc
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1393Compare patients : et si on comparait des configs différentes ?2016-11-29T14:35:42+01:00Vidjil TeamCompare patients : et si on comparait des configs différentes ?Y a t-il une raison profonde pour laquelle on ne pourrait pas comparer des points venant de configs différentes ? Quand ils ont le même -w, a priori les points sont fuse-ables. Et même s'ils n'ont pas le même -w, et bien ce serait joli d...Y a t-il une raison profonde pour laquelle on ne pourrait pas comparer des points venant de configs différentes ? Quand ils ont le même -w, a priori les points sont fuse-ables. Et même s'ils n'ont pas le même -w, et bien ce serait joli de les voir à côté.
En ce moment je teste une config particulière, avec des options expérimentale, mais j'aimerais bien voir la différence entre cela et la situation normale.
Un utilisateur peut aussi vouloir comparer la config normale (multi) et une config uniquement TRG.
Certes, pour le mode normal, on stocke les fichiers fusés par config.
Mais, en mode "compare", si j'ai bien compris on ne stocke rien.
***
9de9c73
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1387Par défaut, liste des patients triée par plus récent en haut2016-11-29T14:35:38+01:00Vidjil TeamPar défaut, liste des patients triée par plus récent en hautCela évitera à avoir à se servir de l'ascenseur dans la plupart des cas
***
merci
***
@DuezCela évitera à avoir à se servir de l'ascenseur dans la plupart des cas
***
merci
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1384export html multi-systèmes: voir aussi le % par rapport à chaque système2016-11-29T14:35:36+01:00Vidjil Teamexport html multi-systèmes: voir aussi le % par rapport à chaque systèmeAu lieu de voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80%
On pourrait voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80% (25.40% of IGK)
Cela est particulièrement utile pour le diagnostic, mais aussi pour les autres points.
S'il n'y a qu'un seul système ...Au lieu de voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80%
On pourrait voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80% (25.40% of IGK)
Cela est particulièrement utile pour le diagnostic, mais aussi pour les autres points.
S'il n'y a qu'un seul système sélectionné, peut-être que ce n'est pas la peine
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1379export html: Faire que les séquences soient en format Fasta2016-11-29T14:35:32+01:00Vidjil Teamexport html: Faire que les séquences soient en format FastaCe serait bien que la partie texte prête à copier/coller soit au format Fasta :
>Clone 3 - 3% - IGKV4-V4...
TCGCACTTATACGACATCAGACATA
***
l'apparence n'a pas changé mais le résultat du copier/coller donne du fasta
***
merci !
***...Ce serait bien que la partie texte prête à copier/coller soit au format Fasta :
>Clone 3 - 3% - IGKV4-V4...
TCGCACTTATACGACATCAGACATA
***
l'apparence n'a pas changé mais le résultat du copier/coller donne du fasta
***
merci !
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1377Raccourci clavier : shift-P pour revenir à la liste des patients2016-11-29T14:35:30+01:00Vidjil TeamRaccourci clavier : shift-P pour revenir à la liste des patients
***
@Cyanael
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1376Le champ "search" des patients devrait aussi rechercher dans les infos2017-07-10T17:01:50+02:00Vidjil TeamLe champ "search" des patients devrait aussi rechercher dans les infos
***
@Duez
***
@Duezhttps://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/1366Aho-Corasick: construction, implémentation2016-11-29T14:35:19+01:00Vidjil TeamAho-Corasick: construction, implémentationBiblio : j'imagine qu'il y a plein de papiers sur la construction. Mais l'algo de base suffit peut-être.
Implémentation : librairie externe ? http://multifast.sourceforge.net
http://sourceforge.net/p/multifast/code/HEAD/tree/trunk/ahoco...Biblio : j'imagine qu'il y a plein de papiers sur la construction. Mais l'algo de base suffit peut-être.
Implémentation : librairie externe ? http://multifast.sourceforge.net
http://sourceforge.net/p/multifast/code/HEAD/tree/trunk/ahocorasick/ahocorasick.c
Il doit y avoir mieux.
Mvouais, pas un truc externe au coeur de notre heuristique...
Et c'est relativement facile, en tout cas si on reste sur les algos de base.
***
Après le départ de Marc ?
***
à la rentrée :-)
***
Done, merge prochain :)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1363Dd-Ja2016-11-29T14:35:17+01:00Vidjil TeamDd-Ja1 réarrangements de Necker (pool 94, leur patient B1) est un Dd2 - Dd3 - Ja29
J'imagine qu'on le détecte en Dd2-Dd3.
A voir si on traite (on ne va pas traiter tous les cas les plus rares ?)
***
Avec l'automate d'Aho-Corasick (ou tout aut...1 réarrangements de Necker (pool 94, leur patient B1) est un Dd2 - Dd3 - Ja29
J'imagine qu'on le détecte en Dd2-Dd3.
A voir si on traite (on ne va pas traiter tous les cas les plus rares ?)
***
Avec l'automate d'Aho-Corasick (ou tout autre index qui indexe tous les germlines en même temps), les réarrrangements atypiques peuvent être gérés simplement : théoriquement on a les affectations des différents gènes qui se suivent. En pratique il y a aussi des faux positifs qu'il faut savoir éliminer.
***
À terme, ajouter un réarrangement bizarre ne nous demandera que quelques lignes depuis germlines.data, et de bien viser les "follows", le mieux on visera le moins on aura de faux positifs.
Et on a besoin de transformer "follows" pour qu'il prenne une liste :
TRD > Dd2-Jd > Dd2-Dd3
TRD > Dd2-Ja > Dd2-Dd3
Dd2-Dd3 ne doit être testé qu'après Dd2-Jd et Dd2-Ja.
***
On n'avait pas des problèmes en VdJa (demander Yann/Aurélie) ? Ja 29 ?
***
Ben si… https://www.producteev.com/workspace/t/553fc9bab0fa09cf47000017
***
Normalement c'est bon.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1360changer les systèmes sélectionnés devrait aussi mettre à jour le total des cl...2017-07-05T09:15:56+02:00Vidjil Teamchanger les systèmes sélectionnés devrait aussi mettre à jour le total des clonesEn multi-système, si on change l'affichage TRG / IGH / ... (boite en haut à gauche), le % de clones de la somme devrait se mettre à jour.
***
C'est toujours le cas (pas poussé ?)
***
merci !
***
@CyanaelEn multi-système, si on change l'affichage TRG / IGH / ... (boite en haut à gauche), le % de clones de la somme devrait se mettre à jour.
***
C'est toujours le cas (pas poussé ?)
***
merci !
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1340Après un cache-cache, les clones peuvent devenir obèses2016-11-29T14:34:59+01:00Vidjil TeamAprès un cache-cache, les clones peuvent devenir obèsesDemo L2
→ cacher TRG (par systemBoxMenu)
→ le faire réapparaître en cliquant sur le sp_system
→ les clones TRG ont grossi un peu :-)
Plus généralement, lorsqu'on joue à cache-cache avec les systemBoxMenu, certains clones d'autres syst...Demo L2
→ cacher TRG (par systemBoxMenu)
→ le faire réapparaître en cliquant sur le sp_system
→ les clones TRG ont grossi un peu :-)
Plus généralement, lorsqu'on joue à cache-cache avec les systemBoxMenu, certains clones d'autres systèmes changent leur taille, ce qui n'est pas souhaitable
***
désactiver un systeme ne sert pas a le cacher mais a l'ignorer
les ratios au lieu d'etre calculés sur TRG+IGH ne le sont plus que sur IGH
ca permet d'avoir le nombre de reads segmentés des igh et de connaitre la proportion d'un clone igh parmis les igh
***
Oui, d'accord pour le principe.
... mais il reste un vrai bug, la taille varie par rapport à la même situation (IGH et TRG visibles) :
Demo L3
→ cacher/ignorer TRG (par systemBoxMenu)
→ le faire réapparaître en cliquant sur le sp_system
→ resélectionner le IGH par le sp_system
- les clones IGH rouge/orange ont grossi un peu :-)
***
13df9d50fbd5
***
parfait
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1319Barre de progression lors de l'upload d'un fichier patient2016-11-29T14:34:42+01:00Vidjil TeamBarre de progression lors de l'upload d'un fichier patientSuper
***
@DuezSuper
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1317clones2016-11-29T14:34:40+01:00Vidjil Teamclones
***
#1315
***
#1315https://gitlab.inria.fr/vidjil/vidjil/-/issues/1316sp_system2016-11-29T14:34:40+01:00Vidjil Teamsp_system
***
#1315
***
#1315