vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-11-23T15:57:29+01:00https://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/2247Inventaire des warnings dans le fichier .vidjil et ailleurs2021-02-03T09:08:25+01:00Mathieu GiraudInventaire des warnings dans le fichier .vidjil et ailleursPour l'instant, on a quelques warnings par clone qui sont affichés, côté ~client, dans `builder.js`. On pourrait avoir un mécanisme plus général, pour afficher dans le ~client des warnings. Nous avons ajouté un champ `warn`) dans le `.v...Pour l'instant, on a quelques warnings par clone qui sont affichés, côté ~client, dans `builder.js`. On pourrait avoir un mécanisme plus général, pour afficher dans le ~client des warnings. Nous avons ajouté un champ `warn`) dans le `.vidjil, que ce soit par clone ou en global #2916. Mais cela ne suffit pas pour les ~"server-pre-process"...
Inventaire des warnings possibles, à compléter / discuter / implémenter -> https://gitlab.inria.fr/vidjil/vidjil/blob/dev/doc/warnings.md
cc @mikael-s @RyanHerb @flothoniThonier FlorianThonier Florianhttps://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/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/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/4364Documenter `stock_order`2020-07-23T12:11:28+02:00Mikaël SalsonDocumenter `stock_order`Suite à !737Suite à !737Thonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3795Pertinence du format .vdj.fa et documentation2020-07-30T20:49:08+02:00Mathieu GiraudPertinence du format .vdj.fa et documentationLa ~doc du ~cpp a une grande partie, plutôt historique, sur `.vdj`. (Elle est certes après celle sur AIRR... mais par contre le `.vidjil` n'est pas décrit dans cette doc.)
Est-ce que ces infos sur `.vdj` sont toujours à jour ? Je doute ...La ~doc du ~cpp a une grande partie, plutôt historique, sur `.vdj`. (Elle est certes après celle sur AIRR... mais par contre le `.vidjil` n'est pas décrit dans cette doc.)
Est-ce que ces infos sur `.vdj` sont toujours à jour ? Je doute de leur pertinence vu, d'un côté, le `.vidjil`, et, de l'autre, le AIRR. Nous n'avons maintenant pas vraiment envie que des bioinfos construisent des pipelines en s'appuyant dessus, non ?
Supprimer cela ? Le réduire fortement ?Algo 2020.08https://gitlab.inria.fr/vidjil/vidjil/-/issues/3590AIRR et nombre de reads : finalement duplicate_count ?2018-10-24T16:16:48+02:00Mathieu GiraudAIRR et nombre de reads : finalement duplicate_count ?J'allais envoyer le mail à AIRR quand je suis retonbé sur cette discussion par mail:
> > (Vidjil) Note that we focus on *clones* throughout all the Vidjil platform, not on individual reads. We plan to use the "consensus_count" key of th...J'allais envoyer le mail à AIRR quand je suis retonbé sur cette discussion par mail:
> > (Vidjil) Note that we focus on *clones* throughout all the Vidjil platform, not on individual reads. We plan to use the "consensus_count" key of the AIRR format to encode the number of reads belonging to a clone, is it the good way to go ?
> (JVH, AIRR) For counting clones, the `duplicate_count` field would be more appropriate; `consensus_count` is for UMI consensus read annotation. However, if you want a clonotype summary report (eg, count of unique CDR3s without V/J annotations), then the Rearrangement format isn't really suitable for that. This might be a format we have to consider designing, if there is enough demand for it. (This is a grey area though, because it's more of a custom analysis output than something we can standardize.)
Voir https://gitlab.inria.fr/vidjil/vidjil/issues/3457#note_125973 par @flothoni et autres commentaireshttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3569AIRR : ajouter des champs optionnels2021-01-05T18:14:50+01:00Mathieu GiraudAIRR : ajouter des champs optionnels@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/issues/3457#note_125850 :
> (...) cdr3, cdr3_aa, {v,d,j}_support (e-value), {v,d,j}_sequence_{start,end} (...)
cc @flothoni@mikael\-s, https://gitlab.inria.fr/vidjil/vidjil/issues/3457#note_125850 :
> (...) cdr3, cdr3_aa, {v,d,j}_support (e-value), {v,d,j}_sequence_{start,end} (...)
cc @flothoniAlgo 2021.02https://gitlab.inria.fr/vidjil/vidjil/-/issues/3451Format pour transmettre les barplots widgets2018-10-08T11:02:00+02:00Mathieu GiraudFormat pour transmettre les barplots widgetsVoir #3407
Voir aussi https://gitlab.inria.fr/vidjil/stats/issues/199#note_34038
(ci une simple liste [.85, .4, .23, .65] pourrait suffire.
cc @RyanHerbVoir #3407
Voir aussi https://gitlab.inria.fr/vidjil/stats/issues/199#note_34038
(ci une simple liste [.85, .4, .23, .65] pourrait suffire.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3263Des analyses avec des BAM ne fonctionnent pas2020-01-22T15:48:29+01:00Thonier FlorianDes analyses avec des BAM ne fonctionnent pasJe tombe depuis quelques jours sur des bugs lors de lancement d'analyses de fichiers `BAM`.
Au début, comme il y avait des souci avec le missing id, je pensais à un lien. Il apparaît très clairement maintenant que le souci est ailleurs...Je tombe depuis quelques jours sur des bugs lors de lancement d'analyses de fichiers `BAM`.
Au début, comme il y avait des souci avec le missing id, je pensais à un lien. Il apparaît très clairement maintenant que le souci est ailleurs. En regardant le log complet de vidjil, je me rend compte qu'il est incapable de traiter le fichier :
```bash
vidjil-algo: bam.cpp:77: virtual void OnlineBAM::next(): Assertion `(bam_entry->core.flag & (1 | 64 | 128)) == 0' failed.
```
Je ne comprend pas vraiment l'erreur. Comme je n'ai pas d'autres fihciers bam en main, j'en ai téléchargé un depuis le serveur vidjil poru faire des tests. Il se trouve que sur celui-ci vidjil fonctionne parfaitement. J'ai alors pensé à des fichiers corrompus. J'ai alors voulu lancé une analyse via la commande suivante:
```bash
samtools quickcheck -v *.bam > bad_bams.fofn && echo 'all ok' || echo 'some files failed check, see bad_bams.fofn'
```
Le résultat montre que les deux fichiers (celui compatible vidjil et l'autre) sont à priori correctement formatés.
En soit, il ne semble donc pas être corrompus. Je vais quand même demander à l'utilisateur de me fournir un md5sum au cas ou. Le souci est que si l'erreur est en amont, a sa propore génération par le séquenceur, ca ne résoudra pas le souci.
en attendant, si ce n'est pas la source de l'erreur, je ne sais pas quoi faire d'autre.
@mikael\-s : Toi qui a dev la fonction pour les BAM, tu as une idée de la raison ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2920Documenter germline/homo-sapiens.g et les méthodes de recombinaison2020-09-22T10:49:35+02:00Mathieu GiraudDocumenter germline/homo-sapiens.g et les méthodes de recombinaisonEn faisant !75/!76, je me rends compte que ni `doc/vidjil-algo.md`, ni `doc/locus.md` ne détaillent la syntaxe de `homo-sapiens.g`.
Derrière les questions de syntaxe, il y a aussi les questions de méthodes de recombinaison... qui ne so...En faisant !75/!76, je me rends compte que ni `doc/vidjil-algo.md`, ni `doc/locus.md` ne détaillent la syntaxe de `homo-sapiens.g`.
Derrière les questions de syntaxe, il y a aussi les questions de méthodes de recombinaison... qui ne sont tout simplement pas expliquées. Même si on peut renvoyer aux papiers, la ~doc doit fournir quelques éléments d'explications.
- la différence entre `53` et `543` peut sembler triviale, mais autant le dire.
- `MAX12` est évoquées cryptiquement dans `vidjil-algo.md`, c'est un peu mieux dans `locus.md`... alprs que c'est une option quasi "par défaut"
- `MAX1U` n'est pas évoqué (mais pas utilisé / à retester ?)
- et la nouvelle ONE #1724 (et d'ailleurs, trouver mieux que 31581d712d ?)
====
From duplicate #4012:
vidjil-algo is able to handle different germlines, either from IMGT/GENE-DB, or for other sources. Beyond the `-V / `-D`/`-J`options, the`.g\` file is very flexible. However (Zhang, 2019) reports that "more effort should be made to manage customization" vdj#919.
We should ensure that this is properly documented. What is the syntax of the `.g` file, and what are the recommended steps for anyone wishing to better use a custom germline ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2828Export csv AIRR depuis l'algo2018-10-24T16:16:47+02:00Mathieu GiraudExport csv AIRR depuis l'algoDai N. aurait été intéressé par une sortie csv de l'algo, "comme depuis le client".
Peut-être le .vidjil peut aussi lui convenir.Dai N. aurait été intéressé par une sortie csv de l'algo, "comme depuis le client".
Peut-être le .vidjil peut aussi lui convenir.Algo 2018.092018-10-27https://gitlab.inria.fr/vidjil/vidjil/-/issues/2798Interaction avec bioinfos durant le workshop2017-11-29T09:16:55+01:00Mathieu GiraudInteraction avec bioinfos durant le workshop#1589 #2797 #2193
cc @RyanHerb @flothoni @aurelBZH#1589 #2797 #2193
cc @RyanHerb @flothoni @aurelBZHWeb 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2672Segmenteur : l'ID devrait être souligné et non réécrit2023-03-01T16:07:28+01:00Mikaël SalsonSegmenteur : l'ID devrait être souligné et non réécritJ'ai un doute. Pas sûr s'il s'agit d'une ~feature ou d'un ~"!!-bug". Mais on a constaté avec @RyanHerb qu'en prod (mais en dev mode), quand on fait un highlight de la fenêtre celle-ci est écrite en toutes lettres en dessous de la séquenc...J'ai un doute. Pas sûr s'il s'agit d'une ~feature ou d'un ~"!!-bug". Mais on a constaté avec @RyanHerb qu'en prod (mais en dev mode), quand on fait un highlight de la fenêtre celle-ci est écrite en toutes lettres en dessous de la séquence au lieu d'avoir un souligné.
![Screenshot_20170926_172558](/uploads/5c4bffd168a76723ef5c1212e9653b22/Screenshot_20170926_172558.png)
Je ne vois pas bien l'intérêt de la réécrire. Un souligné est plus léger et plus clair.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2551Faire marcher 'algo/tools' avec la réorganisation Fasta/BAM2017-08-28T15:57:38+02:00Mathieu GiraudFaire marcher 'algo/tools' avec la réorganisation Fasta/BAMSuite à !67, les programmes de `algo/tools` ne compilent plus.Suite à !67, les programmes de `algo/tools` ne compilent plus.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2313Affichage de la qualité dans l'aligneur : bikeshedding2021-10-01T11:59:42+02:00Mathieu GiraudAffichage de la qualité dans l'aligneur : bikesheddingMarc avait préparé quelque chose, accessible en dev.
Devrait déjà dépendre de #1982.
(Et pour le cpp, c'est pas exporté en ce moment ?)Marc avait préparé quelque chose, accessible en dev.
Devrait déjà dépendre de #1982.
(Et pour le cpp, c'est pas exporté en ce moment ?)Web 2021.11Mathieu GiraudMathieu Giraud