vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-04-08T18:56:34+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4753Warning s'affiche sur un coverage faible alors que ce n'est pas le coverage p...2021-04-08T18:56:34+02:00Mikaël SalsonWarning s'affiche sur un coverage faible alors que ce n'est pas le coverage pris par fuseSur un sample set avec plusieurs échantillons, dans l'un des échantillons le clone principal a un coverage faible. Du coup le warning est affiché alors que ce n'est pas la séquence consensus prise par le fuse. Le warning induit ici en er...Sur un sample set avec plusieurs échantillons, dans l'un des échantillons le clone principal a un coverage faible. Du coup le warning est affiché alors que ce n'est pas la séquence consensus prise par le fuse. Le warning induit ici en erreur.
https://app.vidjil.org/31213-2?clone=0https://gitlab.inria.fr/vidjil/vidjil/-/issues/4263Vidjil-algo : Double free or corruption2020-05-07T21:56:26+02:00Mikaël SalsonVidjil-algo : Double free or corruptionAvec la configuration « Export all clones » du serveur (`-3 -y all -z all -e 1 -2 -d -w 50 -r 5 --no-vidjil`), fichier 64565.Avec la configuration « Export all clones » du serveur (`-3 -y all -z all -e 1 -2 -d -w 50 -r 5 --no-vidjil`), fichier 64565.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3898Erreur dans le calcul de certain coverage2019-04-05T10:15:36+02:00Thonier FlorianErreur dans le calcul de certain coverageJe viens de regarder des données : https://app.vidjil.org/index.html?custom=53049&custom=54345&clone=43,82
Il s'agit du même clone avec une variation dasn le strectch de A. donc en lisant les tableaux de coverage de l'un et de l'autre, j...Je viens de regarder des données : https://app.vidjil.org/index.html?custom=53049&custom=54345&clone=43,82
Il s'agit du même clone avec une variation dasn le strectch de A. donc en lisant les tableaux de coverage de l'un et de l'autre, j'ai eu un doute.
|_average_read_length | 251 | 251 |
|:---------------------:|:-----:|:------:|
|_coverage_info |119 bp (51% of 251.0 bp) | 129 bp (51% of 251.0 bp)|
|_coverage | 0.51792| 0.51394|
En comparant les deux tableaux, j'ai remarqué que `129 gt 119`, pourtant, le coverage est en sens inverse. En faisant le calcul, il se trouve que c'est le premier qui est faux, 119 étant moins que la moitié que 251... On devrait donc avoir pour être précis `47,4103585657` dans la première colonne.
Je ne sais pas à quoi cette variation est dûe. Elle est présente dans le .vidjilhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3792valgrind-functional et representative-random-read-chooser.should-get2019-03-14T18:46:27+01:00Mathieu Giraudvalgrind-functional et representative-random-read-chooser.should-gethttps://gitlab.inria.fr/vidjil/vidjil/-/jobs/278963https://gitlab.inria.fr/vidjil/vidjil/-/jobs/278963https://gitlab.inria.fr/vidjil/vidjil/-/issues/2967Clone chimère2018-06-26T10:40:27+02:00Anne de SeptenvilleClone chimèrePatient DES, clones attendus attendus : V3-15 J6 et V3-21 J5
https://app.vidjil.org/index.html?set=26067&config=2
Problème pour le clone V3-21 J5 :
Vidjil semble créer une sorte de clone étant une combinaison des 2 attendus.
Pour...Patient DES, clones attendus attendus : V3-15 J6 et V3-21 J5
https://app.vidjil.org/index.html?set=26067&config=2
Problème pour le clone V3-21 J5 :
Vidjil semble créer une sorte de clone étant une combinaison des 2 attendus.
Pourtant Arrest n'a pas de problème particulier avec cet échantillon.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2908Nombre de répétitions de TAC différent entre Sanger et NGS2019-03-25T11:43:50+01:00Mathieu GiraudNombre de répétitions de TAC différent entre Sanger et NGS@Anne@Annehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2217Algo: trimSequence ne fait pas ce qu'on attend d'elle2017-03-08T12:19:06+01:00Mikaël SalsonAlgo: trimSequence ne fait pas ce qu'on attend d'elleLe bug #2214 a mis un coup de projecteur sur la fonction `trimSequence`, qui ne fonctionne pas comme elle devrait. Son but : obtenir le plus long facteur dont chaque préfixe et suffixe contient moins de RATIO_TOO_MANY_N % de N. Les (nouv...Le bug #2214 a mis un coup de projecteur sur la fonction `trimSequence`, qui ne fonctionne pas comme elle devrait. Son but : obtenir le plus long facteur dont chaque préfixe et suffixe contient moins de RATIO_TOO_MANY_N % de N. Les (nouveaux) tests montrent que ce n'est pas le cas. Il faut revoir l'algo complètement.
cc @magiraudAlgo 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/2214Boucle infinie dans le calcul de la représentative2017-03-08T12:19:06+01:00Mikaël SalsonBoucle infinie dans le calcul de la représentativeQuatre Vidjil tournent depuis plus d'un jour (cf. #2213). Il s'agit du même fichier de séquences dans les quatre cas. Le processus boucle sur le 91è clone à segmenter. Ce clone est composé de trois reads (de toute beauté), en voici un :
...Quatre Vidjil tournent depuis plus d'un jour (cf. #2213). Il s'agit du même fichier de séquences dans les quatre cas. Le processus boucle sur le 91è clone à segmenter. Ce clone est composé de trois reads (de toute beauté), en voici un :
```
>M02707:35:000000000-AYHTM:1:1118:11403:1189
CCCNNNNNNNCTCCTGTNNNNNNNCTGGATTNNNNNNNAGTAGCTNNNNNNNGAACTGGNNNNNNNAGGCTCCNNNNNNNGGGCTGGNNNNNNNCTCATCCNTTNNNNGTAGTAGNNNNNNNATATACTNNNNNGACTCAGTGANNNNNNGATTCACCATCTCCNNAGACNACGCCAAGNNCTCACTGTATCNNNNNNNGAACAGCCTGAGAGCCGAGCCACGGGGCTGAGAATACTATTACGATTTTTGGAGTGGTTATCAACTGGGGCCAGGGAACCCTGGTCACCGTCTCCTCAGGT
```
C'est bien le calcul de la représentative qui pose problème car le problème est toujours présent avec un `-z 0 -y 100`.
Un test suit dans un commit.
cc @magiraudAlgo 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1576Pas de représentative pour les séquences étiquetées2017-07-05T09:15:56+02:00Vidjil TeamPas de représentative pour les séquences étiquetéesstanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la conditio...stanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la condition de mettre -r 1.
En tout cas, c'est un bug.
***
f3cab65
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1564Longueur des reads d'un clone, prendre tous les reads en compte2016-11-29T14:37:58+01:00Vidjil TeamLongueur des reads d'un clone, prendre tous les reads en compteLa longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en ...La longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en être très loin).
Problème : on peut avoir des chimères, et elles vont se trouver parmi les premières séquences considérées. Par exemple, la fameuse séquence de Yann (patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11 clone TRDV1*01 -5/0/-3 TRDD2*01 -1/0/-7 TRAJ29*01), sur ma machine j'ai une représentative de 257 bp (58% of 438 bp). On pourrait se dire : c'est moche. En fait non.
On va dans le tableau de Yann et la taille en électrophorèse est 255 !
Bilan : il faudrait calculer la taille sur les reads stockés. Le BinReadStorage peut donner l'info (il peut même donner l'info pour tous les reads et pas seulement pour ceux qu'il stocke).
Maintenant qu'on propose le coverage comme un axe d'analyse en disant que c'est une bonne mesure de la qualité, c'est assez critique comme problème.
***
De mémoire, n'est-ce pas sur l'ensemble des 2000 premiers reads ? Est-ce que ce 2000 ne devrait pas atténuer les quelques chimères au début ? Est-ce que cela signifie, pour la séquence de Yann, que de nombreux reads chimériques sont là ?
Cela dit, même si c'est le cas, quand on a beaucoup de reads, les 2000 premiers peuvent faire sens "les plus gros"... Mais les résultats donc ne sont plus cohérents entre un gros clone 20 000 reads et un petit 2 000.
Donc tu as sans doute raison, il faudra faire cette moyenne sur *tous les reads*. Mais alors la coverage pourra être bien au-dessus de 1.00, s'il y a des petits reads...
***
Ben non, c'est pas sur les 2000 premiers… j'ai regardé dans le code. Tu avais mis le calcul de la longueur dans la boucle qui calcule la représentative. Mais pour le calcul de la représentative je ne parcours pas tous les reads. Je m'arrête au read qui m'a donné la meilleure représentative + stability_limit (30 par défaut).
***
Argh.
***
(Et j'ai donc mal répondu à Yann tout à l'heure.)
Et oui, ce serait bien de le faire sur l'ensemble des reads via BinReadStorage.
Idéalement instancier un objet Stats par BinReadStorage, cela permettra d'avoir plus que la longueur si un jour Stats fait mieux (la distribution par exemple)
***
Notons que le "av. len" dans les infos du run est lui bien calculé, sur toutes les reads (windowExtractor.cpp:57)
***
38cbe4d
Finalement le Stats est instancié dans windows.cpp : stats_by_windows, de la même manière que germline_by_windows, status_by_windows et seqs_by_windows.
(On devrait faire du ménage là-dedans, et bouger tous ces trucs dans le BinReads ?)
J'ai bien vu qu'il y avait aussi des calculs de longueur dans BinReads, on aurait pu le faire avec (voir tâche Stats / BinReads), mais je maîtrisais mieux l'autre côté :-)
***
Il y a quelque chose qu'on n'utilise pas assez dans producteev c'est le « in progress ». Avant d'aller manger j'avais un code qui faisait ça (en passant par BinReadStorage), mais qui ne compilait pas encore. Ni moi, ni toi n'avons utilisé le « in progress », d'où le doublon.
***
oui, tout à fait.
***
désolé...
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1541La représentative couvre mal certains jeux de clones2023-10-18T13:07:37+02:00Vidjil TeamLa représentative couvre mal certains jeux de clonesJeu de données IGH de Cristina http://rbx.vidjil.org/browser/index.html?patient=527&config=27 (voire les clones en fonction de clone length/GC content). Tous les reads font 250 bp, on a des représentatives autour de 50bp.
Même chose ave...Jeu de données IGH de Cristina http://rbx.vidjil.org/browser/index.html?patient=527&config=27 (voire les clones en fonction de clone length/GC content). Tous les reads font 250 bp, on a des représentatives autour de 50bp.
Même chose avec ce jeu de données (F. ~"Paris-Pitié") : http://rbx.vidjil.org/browser/index.html?patient=510&config=26 (certains clones sont autour de 70bp alors que les reads font 300bp)
***
Dans les deux jeux de données, même raison : il s'agit d'une séquence normale, suivie d'une série de A de longueur variable, suivie d'une séquence quelconque. On avait déjà eu ça dans un jeu de données. Rennes ? Exemples en pièce jointe (clone.fa-4 c'est pour le patient 527 et clone.fa-18 c'est pour le patient 510).
***
Oui c'était bien Rennes (mail du 18/03/2015, 18h10).
***
La représentative couvre donc mal ces jeux, mais c'est normal. Ce qu'on aimerait c'est récupérer les reads du clone depuis Vidjil :)
***
(écrit il y a deux heures, grr producteev)
On va bien sûr essayer d'améliorer cela, mais on aura toujours des séquences bizarres.
- un filtre côté c++ pour éjecter ces séquences
- + côté browser les warnings
***
hmm… qu'entends-tu par « éjecter ces séquences » ? Si la séquence amont accroche (avec les seuils de e-valeur), a-t-on vraiment envie de la virer ?
***
Il se trouve d'ailleurs qu'au niveau du polyA, la qualité chute dans le FASTQ : c'est le séquenceur qui se tape un délire ?
***
Problème lorsqu'on a un fort taux d'erreur sur R2, même avec la nouvelle heuristique, il y a des cas qui se passent mal :
http://rbx.vidjil.org/browser/index.html?sample_set_id=11808&config=26
http://rbx.vidjil.org/browser/index.html?sample_set_id=11812&config=35 (sur le 2è clone)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1468Représentative : mesure de qualité2016-11-29T14:36:42+01:00Vidjil TeamReprésentative : mesure de qualité(voir aussi "Représentative : trop courte ?")
Il faudrait avoir une mesure de qualité *globale* de la représentative (.fastq, autre tâche, voir ailleurs). Vu les expériences rapportées dans "Représentative : trop courte ?", dans de nomb...(voir aussi "Représentative : trop courte ?")
Il faudrait avoir une mesure de qualité *globale* de la représentative (.fastq, autre tâche, voir ailleurs). Vu les expériences rapportées dans "Représentative : trop courte ?", dans de nombreux cas cela fonctionne très bien et on aurait quelque chose qui s'approche de 1.0. Mais cela serait un bon outil pour détecter s'il y a eu des problèmes, notamment si on se met à segmenter olé-olé.
- ratio de la longueur de la représentative / des reads (maximum, moyen, médiane ?)
- ratio de kmers ?
Dans les deux cas, ce ne serait pas grave si on considère uniquement le dernier BinReadStorage (et si vraiment on voudrait avoir une mesure exacte, on pourrait stocker des choses en plus dans le BinReadStorage).
Au final, c'est presque plus important d'avoir une mesure de confiance que d'améliorer le calcul :-)
***
"coverage", c'est bon
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3866Avoir par défaut la séquence représentative calculée sur un échantillon aléat...2019-05-24T09:46:52+02:00Mikaël SalsonAvoir par défaut la séquence représentative calculée sur un échantillon aléatoire de readsLes résultats dans #3586 (avec `--consensu-on-random-sample`) sont bons. De plus la sélection actuelle peut entraîner un mauvais choix de séquence consensus et, éventuellement, entraîner un mauvais design d'amorce pour le suivi du clone,...Les résultats dans #3586 (avec `--consensu-on-random-sample`) sont bons. De plus la sélection actuelle peut entraîner un mauvais choix de séquence consensus et, éventuellement, entraîner un mauvais design d'amorce pour le suivi du clone, ce qui serait hautement problématique.Algo 2019.05https://gitlab.inria.fr/vidjil/vidjil/-/issues/3764SampleReads : échantillon aléatoire des reads.2020-07-28T19:39:52+02:00Mikaël SalsonSampleReads : échantillon aléatoire des reads.@Anne m'a parlé de problèmes de séquences consensus qui ne représentent pas vraiment l'ensemble des reads du clone.
C'est dû à notre manière de conserver les reads : quand il y en a trop on n'en conserve qu'un échantillon composé des re...@Anne m'a parlé de problèmes de séquences consensus qui ne représentent pas vraiment l'ensemble des reads du clone.
C'est dû à notre manière de conserver les reads : quand il y en a trop on n'en conserve qu'un échantillon composé des reads les plus longs et de meilleure qualité. Dans certains cas cela peut entraîner un biais, comme favoriser les séquences qui possèdent des insertions.
On pourrait essayer de ne conserver qu'un échantillon aléatoire des reads qui, selon la statistique, devrait être représentatif de l'ensemble des reads. Si les reads ainsi conservés sont de mauvaise qualité ou trop courts… hé bien on n'aurait pas fait mieux avec l'échantillon complet.
@Anne n'hésite pas à nous pointer vers un ou deux exemples pour qu'on puisse tester si cela changerait effectivement quelque chose.Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5173Merge clonotype on exact VDJ sequence (excluding primers)2023-10-19T14:34:09+02:00THONIER FlorianMerge clonotype on exact VDJ sequence (excluding primers)In some case, user upload data with primers. We have in these cases mix of primer of various length able to be used for a same clonotype. And in some configuration (no-clustering), we saw 2 clonotypes or more that are an artefact.
As p...In some case, user upload data with primers. We have in these cases mix of primer of various length able to be used for a same clonotype. And in some configuration (no-clustering), we saw 2 clonotypes or more that are an artefact.
As position and size of primer can vary, we can't make only a trimming of it.
Can we make a merge based on sequence but limited to Vstart ?
See case here: [59910-50?clone=27,35,45,81](https://app.vidjil.org/59910-50?clone=27,35,45,81)https://gitlab.inria.fr/vidjil/vidjil/-/issues/4578Warnings, avoir un nouveau warning si un clone a plusieurs productivité sur d...2021-02-23T10:33:35+01:00Thonier FlorianWarnings, avoir un nouveau warning si un clone a plusieurs productivité sur différents samplesEn lien avec #4566. Nous avons d'autre cas pour lequel c'est la productivité qui varie.
D'une manière générale, quels sont les champs pour lesquels nous devons lever une alerte ? Quel niveau ? Pour l'instant j'ai mis `warn/jaune`, mais...En lien avec #4566. Nous avons d'autre cas pour lequel c'est la productivité qui varie.
D'une manière générale, quels sont les champs pour lesquels nous devons lever une alerte ? Quel niveau ? Pour l'instant j'ai mis `warn/jaune`, mais il faudrait possiblement mettre un niveau plus élevé pour le faire ressortir (en attendant une meilleur gestion du bruit des warnings).
De plus, comment faire ressortir que c'est le sample 3 qui présente la divergence sur les XXX présent ? E tque c'est les samples 3 et 5 sur les YYY présent ?
Il faudrait faire des fusions des warning pour permettre d'extraire l'information et la fusionner au besoin au sein d'une seule entrée plus lisible.
cc @magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3970fuse.py: quelle séquence conserver ? plus grande, meilleur top, plus de reads ?2022-05-20T11:45:37+02:00Thonier Florianfuse.py: quelle séquence conserver ? plus grande, meilleur top, plus de reads ?Un utilisateur [compare deux protocoles](https://app.vidjil.org/browser/index.html?custom=60329&custom=60331&clone=0) IGH: FR1 et primer leader.
Mais lors du fuse, nous conservons par défaut la séquence de la première analyse, à priori...Un utilisateur [compare deux protocoles](https://app.vidjil.org/browser/index.html?custom=60329&custom=60331&clone=0) IGH: FR1 et primer leader.
Mais lors du fuse, nous conservons par défaut la séquence de la première analyse, à priori sans considération sur la taille, qui est pourtant bien plus significative dans le second cas.
Nous devrions rajouter une vérification dans le script.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3904Clustériser sur la représentative et non pas sur la fenêtre2020-12-16T15:49:35+01:00Mathieu GiraudClustériser sur la représentative et non pas sur la fenêtreÉvoqué avec @mikael\-s ce midi.Évoqué avec @mikael\-s ce midi.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3304Calcul de la séquence consensus : changer le choix des reads utilisés2020-12-11T13:15:02+01:00Mikaël SalsonCalcul de la séquence consensus : changer le choix des reads utilisésPour des questions d'optimisation tous les reads ne sont pas stockés et nous n'utilisons qu'un échantillon des reads d'un clone (pour les gros clones) afin de calculer le consensus. Ce choix est géré dans la classe `ReadQualityScore` du ...Pour des questions d'optimisation tous les reads ne sont pas stockés et nous n'utilisons qu'un échantillon des reads d'un clone (pour les gros clones) afin de calculer le consensus. Ce choix est géré dans la classe `ReadQualityScore` du fichier `read_score.cpp` : on se base à la fois sur le dernier percentile de la qualité du read et sur la longueur du read. Les reads les plus longs et de meilleure qualité sont donc choisis.
On va donc biaiser le choix en faveur des séquences les plus longues. Ce qui est à la fois souhaitable : pour des raisons de qualité de séquençage on pourrait se retrouver avec uniquement une faible portion des reads du clone qui sont de pleine longueur (si on a beaucoup d'erreurs sur R2 le merge va échouer par exemple). Et c'est à la fois non souhaitable car on va privilégier les séquences les plus longues qui ne sont pas forcément représentatives du clone (cf. #3290).
Une solution serait de se contenter d'un échantillon aléatoire des reads de meilleure qualité (ce qui est plus représentatif du clone). Cela pose la question de comment constituer cet échantillon aléatoire au fur et à mesure sans connaitre a priori la taille du clone et sans biaiser en faveur des premiers ou des derniers reads.
Si cette solution donne une séquence consensus dont la longueur n'est pas satisfaisante on peut ensuite passer à une autre stratégie privilégiant les longueurs les plus élevées.
Mais je n'arrive pas à voir une solution unique qui donnerait le résultat attendu dans tous les cas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/1972Sortir la séquence consensus complète en donnant un histogramme de la représe...2018-06-25T16:48:04+02:00Vidjil TeamSortir la séquence consensus complète en donnant un histogramme de la représentativité (à la JalView)Cf. mail de Marine du 16/08 17h20 : on a une séquence consensus sortie par Vidjil qui ne fait que ~120bp parce qu'il se passe quelque chose de bizarre dans le FR3 (beaucoup de variabilité apparemment). L'histogramme sur la totalité du co...Cf. mail de Marine du 16/08 17h20 : on a une séquence consensus sortie par Vidjil qui ne fait que ~120bp parce qu'il se passe quelque chose de bizarre dans le FR3 (beaucoup de variabilité apparemment). L'histogramme sur la totalité du consensus (donné par Jalview) est en pièce jointe.
***
@magiraud @mikael-s