vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2023-10-19T14:34:09+02:00https://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/5172consensus sequence length: mix of sequence with a nucleotide mix at a positio...2023-10-18T17:56:11+02:00THONIER Florianconsensus sequence length: mix of sequence with a nucleotide mix at a position in the V geneSee sample 59910-50, with either configurations [IGH](https://app.vidjil.org/59910-2?clone=26) or [no-clusterign](https://app.vidjil.org/59910-50?).
We can see that in multi, top clonotype have a short consensus length for read that are...See sample 59910-50, with either configurations [IGH](https://app.vidjil.org/59910-2?clone=26) or [no-clusterign](https://app.vidjil.org/59910-50?).
We can see that in multi, top clonotype have a short consensus length for read that are able to get entire V gene. We can see in no clustering that top 2 clonotypes have a mix of C/T at this specific position that cut the consensus sequence.
In these case, maybe we can extend consensus but show (but how?) the mix of nucleotides.
* bypass mix with a color scale to represent variation. Can also be used to show variation in case of merge of clonotype.
* hover can show precise values variationhttps://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/4427Séquence consensus incomplète analyse comparée2021-04-08T19:03:55+02:00Anne de SeptenvilleSéquence consensus incomplète analyse comparéeJ'ai un problème de séquence consensus pour ce patient séquencé par différents laboratoires.
Avec nos données, la séquence consensus est incomplète (problème de de qualité ? autre ? ce sont de vieilles données... ce qui est étrange c'e...J'ai un problème de séquence consensus pour ce patient séquencé par différents laboratoires.
Avec nos données, la séquence consensus est incomplète (problème de de qualité ? autre ? ce sont de vieilles données... ce qui est étrange c'est que je ne me souvenais pas avoir eu ce problème précédemment avec le même fastq). Par contre pour les 4 autres laboratoires, pas de problème, la séquence consensus est ok et va jusqu'au bout du V. Mais quand je compare les 5 labos ensembles, la séquence est tronquée. Je sais qu'avant Vidjil choisissait plutôt la séquence consensus la plus longue. Quelque chose a changé de ce point de vue là ?
https://app.vidjil.org/31199-2?clone=0
J'ai un autre patient qui a exactement le même profile (séquence consensus tronquée uniquement dans nos données) mais là pas de problème, Vidjil donne une séquence complète lorsque j'affiche les 5 labos ensemble.
https://app.vidjil.org/31213-2?clone=0https://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/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/3897Cas particulier d'un clone retrouvé dans une analyse2019-04-04T18:03:31+02:00Thonier FlorianCas particulier d'un clone retrouvé dans une analyseDésolé pour le nom, il n'est pas très parlant.
@Patrick a remonté une information sur un clone qui avait un problème de dénomination, et qui pouvait l’intéressé car il apparaissait/disparaissait/réapparaissait: https://app.vidjil.org/?...Désolé pour le nom, il n'est pas très parlant.
@Patrick a remonté une information sur un clone qui avait un problème de dénomination, et qui pouvait l’intéressé car il apparaissait/disparaissait/réapparaissait: https://app.vidjil.org/?set=30814&config=25&clone=94
Le souci c'est que ce clone à une séquence consensus très courte, environ 50% de la longueur moyenne. Point positif, on lève bien une alerte.
J'ai voulu regarder de plus près ce clone. J'ai exploité la nouvelle fonction `get_reads` pour obtenir un fichier se concentrant sur ses reads.
En regardant de plus près, on voit que toutes les séquences ont une première partie commune, sur les 60nt en 5', mais complètement différentes sur le reste, avec énormément de stretch de A. (voici le [fichier extrait](/uploads/0c8581c5f6ecd879c49270bffee86876/seq_patrick.fastq)).
J'ai alors voulu jouer avec pour comprendre les affectations, rallonger les fenêtres, ...
```
>seq1
ATCGATTTTCTGCAGAGAGGCTGACAGTGCTCGGTAAGAGATCGGAAGAGCACACGTCTGAACTCCAGTCACTCCGGAGAATCTCGTATGCCGTCTTCTGCTTGAAAAAAAAAAAAAAACAACAATAAAGAACATAAAACTATTCTGAATGTTAAAGAGACAAAAAAACAAATAATATAGAAGATAATATTACGAGGATACAGTAGAGTAATCTAGACATAGCAAAGTAAAACAGGACCAAGAAGGTTGGG
# 18 + VJ 1 18 23 251 seed TRB SEG_+ 1.972121e-08 5.559703e-16/1.972121e-08+B+B+B+B+B+B+B+B+B+B _ _ _ _ _ _ _ _+b+b+b+b+b+b+b+b _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
#>seq1 + VJ 1 18 23 251 w55/10 seed TRB SEG_+ 1.972121e-08 5.559703e-16/1.972121e-08
```
On peut donc voir que l'on n'a que quelques nt vus comme V et J, sur 251nt. Je pense donc qu'il s'agit d'un artefact.
Si j'essaye de rallonger la fenêtre, je n'ai pas le résultat escompté car il m'indique qu'il shift la fenêtre, probablement trop proche en 5'. Je me retrouve donc quoi qu'il arrive avec la même fenêtre.
Quoi qu'il en soit, je ne sais pas quoi faire de cette séquence. Je peux l'ajouter dans un test, mais que devrait-on y mettre ? On ne devrait pas la ressortir comme un clone avec si peu d'affectations de kmer ?
cc @magiraud @mikael\-s @Patrickhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3394BinReadStorage : Pertinence de 30 bins, tests ?2019-03-15T18:21:55+01:00Mathieu GiraudBinReadStorage : Pertinence de 30 bins, tests ?Extrait depuis #3393.
@magiraud :
> Au passage, voir e977c03c :
> > We increase the number of bins to make sure that the better quality reads will be in a different bin than medium quality reads.
> b9c934b4 juste pour voir (mais peut...Extrait depuis #3393.
@magiraud :
> Au passage, voir e977c03c :
> > We increase the number of bins to make sure that the better quality reads will be in a different bin than medium quality reads.
> b9c934b4 juste pour voir (mais peut-être que les tests ne couvrent pas les cas souhaités avec suffisament de reads pour remplir les bins).
Il se trouve donc que les tests passent sur b9c934b4. Est-ce que cela ne vaudrait pas le coup d'expliciter dans un test un cas difficile pour être pleinement convaincu de cette valeur 30 ?
@mikael\-s :
> J'en suis complètement convaincu qu'elle est pertinente. De là à savoir faire un test simple, c'est autre chose. Voici plusieurs jeux de données où cela a permis d'avoir une séquence consensus convenable (où on gagne une à deux centaines de nucléotides) :
>
> - http://rbx.vidjil.org/browser/index.html?sample_set_id=10040&config=35
>
> - http://rbx.vidjil.org/browser/index.html?sample_set_id=11812&config=35
>
> - http://rbx.vidjil.org/browser/index.html?sample_set_id=7520&config=35
>
> - http://rbx.vidjil.org/browser/index.html?sample_set_id=7575&config=26
>
> Ce n'était pas la seule raison de l'amélioration, cela faisait plus largement partie de ddd48c77e, mais c'était bien un élément nécessaire.
> Pour autant ce n'est pas pleinement satisfaisant car il reste des consensus trop courtes voire des cas où ça ne change rien : http://rbx.vidjil.org/browser/index.html?sample_set_id=11808&config=35
>
> Voir mes mails du 2016/10/04 14h44 et du 2016/12/02 16h14https://gitlab.inria.fr/vidjil/vidjil/-/issues/3305Sortir un alignement multiple de reads d'un clone2019-03-08T17:52:08+01:00Mikaël SalsonSortir un alignement multiple de reads d'un clone(similaire mais différent de #1972)
En répondant à #3290 je me rends compte qu'il serait possible de sortir automatiquement (mais à la demande, en cliquant quelque part) un alignement multiple d'un échantillon aléatoire de reads d'un cl...(similaire mais différent de #1972)
En répondant à #3290 je me rends compte qu'il serait possible de sortir automatiquement (mais à la demande, en cliquant quelque part) un alignement multiple d'un échantillon aléatoire de reads d'un clone.
Il suffit de lancer `vidjil-algo` avec l'option `-FaW` sur le germline du clone considéré (c'est donc assez rapide) puis de lancer un alignement multiple. Ce lancement peut se faire de manière asynchrone de la même manière que se fait l'analyse (mystérieuse) de la contamination (cf. #1744).
C'est une première étape qui permettrait ensuite #1972. Cette étape permettrait déjà aux utilisatrices et utilisateurs de vérifier des données que lesquelles des doutes existent.https://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/2287Longueur des séquences consensus sur S222020-12-11T13:13:50+01:00Mathieu GiraudLongueur des séquences consensus sur S22Comparer les sorties Vidjil et MiXCR sur S22 :
- http://app.vidjil.org?sample_set_id=23112&config=39&plot=sequenceLength,Size,bar
- http://app.vidjil.org?sample_set_id=23112&config=25&plot=sequenceLength,Size,bar
Belle gaussienne po...Comparer les sorties Vidjil et MiXCR sur S22 :
- http://app.vidjil.org?sample_set_id=23112&config=39&plot=sequenceLength,Size,bar
- http://app.vidjil.org?sample_set_id=23112&config=25&plot=sequenceLength,Size,bar
Belle gaussienne pour MiXCR. Pour Vidjil, c'est curieux. Peut-être la même chose que #1165 ?
cc @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2003Le résultat de la segmentation change selon le contexte2019-11-23T05:29:48+01:00Vidjil TeamLe résultat de la segmentation change selon le contexteExemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutati...Exemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutation. Or si on exporte ces séquences et qu'on fait tourner le -c segment ou, même, Vidjil avec les mêmes options que sur le serveur (et même avec le vidjil présent sur le serveur)... on ne trouve pas la même segmentation.
Voir le test 88c6e92
***
N'y aurait-il pas un test de e-valeur pour le D qui dépende du nombre de reads ? (dans le test on passe de 2D trouvés avec un seul read, contre 0 D trouvé avec 11 reads)
***
> N'y aurait-il pas un test de e-valeur pour le D qui dépende du nombre de reads ?
Oui... et je pense bien que ce n'est pas un bug, mais une feature (introduite par e6ffb91). C'est précisément pour cela qu'est fait la E-value, non ? On fait strictement la même chose pour la FineSegmentation V/J ("multiplier" dans FineSegmenter()).
Le multiplier est
- nb_reads_for_evalue pour -c segment (pour V/J comme pour D)
- sort_clones.size() pour -c clones (Aïe, je me rends compte qu'il n'y est pas pour V/J, vidjil.cpp:1413 !!!)
Ce multiplier dit bien le nombre de segmentation que l'on fait, bref ce qu'il faut pour transformer la p-valeur en e-valeur.
Après, peut-être que le calcul des p-valeurs du D est trop stringent (voir tâche réouverte).
***
Et on a même une dépendance encore plus vicieuse que celle au nombre de reads : passer de -z 100 à -z 1000 peut faire dé-segmenter une séquence... C'est la vie. Voir si IgBlast a aussi ce type de comportement.
***
Pourquoi le multiplier devrait-il être le nombre de clones plutôt que le nombre de séquences réellement segmentées ?
***
Qu'on n'ait pas les mêmes résultats entre 10M de reads (fine segmentés) et 10 reads, je comprends bien : on change de plusieurs ordres de grandeur. Mais qu'on n'ait pas les mêmes résultats entre 1 read, 6 reads et 11 reads, j'ai plus de mal. Peut-être est-ce juste un problème de seuil de E-valeur
***
> Mais qu'on n'ait pas les mêmes résultats entre 1 read, 6 reads et 11 reads, j'ai plus de mal
Tout à fait, il faut comprendre ce qu'il se passe, et il y a peut-être des bugs
> Pourquoi le multiplier devrait-il être le nombre de clones plutôt que le nombre de séquences réellement segmentées ?
Oui, l'estimation actuelle est trop stricte. Est-ce que cela devrait être un max entre sort_clones.size() et max_clones ?
***
>Oui, l'estimation actuelle est trop stricte. Est-ce que cela devrait être un max entre sort_clones.size() et max_clones ?
J'aurais dit un min ;) Ce qui importe c'est le nombre de séquences qu'on va réellement segmenter.
***
Oui, tout à fait, un min !
J'étais plus en forme hier soir (cela m'a étonné d'ailleurs, c'était après 3 verres, ce a quoi je ne suis pas habitué :-)
***
@magiraud @mikael-sAlgo -- Importanthttps://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-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1567Splitter un clone / ré-analyser un sous-ensemble de reads2021-06-23T11:34:52+02:00Vidjil TeamSplitter un clone / ré-analyser un sous-ensemble de readsÉvoqué directement par Alice (et Matin il y a longtemps). Ma première réaction : non, l’algo ne marche pas comme cela !
Mais bon… si on est capable de récupérer les reads d’une fenêtre, on pourrait les ré-analyser avec d’autres paramètr...Évoqué directement par Alice (et Matin il y a longtemps). Ma première réaction : non, l’algo ne marche pas comme cela !
Mais bon… si on est capable de récupérer les reads d’une fenêtre, on pourrait les ré-analyser avec d’autres paramètres (par exemple un `-w 100` ou `200`, voire un `-w` égal à la taille du read, comme dans l'option `-!`),voire avec un autre programme... le browser n’y verrait que du feu, on pourrait avoir des windows de taille différente. Au final, ce serait un bouton « split to reads ».
On s’éloigne de la philosophie de l’algo, mais pourquoi pas ? D’ailleurs, si certains reads sont trouvés par d’autres méthodes (grep, séquences connues, xxx, autre heuristique, autre logiciel…), leur id va peut-être varier.
***
Marc: "Cela pourrait aussi être fait directement dans la première passe de Vidjil. On détecte mauvais coverage/..., et on applique d'autres paramètres"
***
Avec les données de la Pitié on a tendance à rassembler des choses qui ne devraient pas l'être. Il serait bien que la taille de la fenêtre s'adapte automatiquement aux données, sans avoir à relancer le jeu de données en tâtonnant pour savoir quelle taille de fenêtre est la mieux (une puissance de 10 ou pas ? ;) )
Exemple de jeu où on fait n'importe quoi avec la taille de fenêtre par défaut : http://rbx.vidjil.org/browser/?patient=914&config=26
***
Argh... je pensais à cette tâche justement en voyant votre échange de mail...
https://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/1514RNA-seq, representative, coverage2021-07-12T15:56:45+02:00Vidjil TeamRNA-seq, representative, coverageEst-ce que notre manière de faire la représentative est adaptée au RNA-Seq ? Peut-être que oui, mais on n'y avait pas nécessairement pensé au début... Et notre mesure de coverage.
Voir sur rbx patients/tim-0453/clone-IGL.fa, alignement ...Est-ce que notre manière de faire la représentative est adaptée au RNA-Seq ? Peut-être que oui, mais on n'y avait pas nécessairement pensé au début... Et notre mesure de coverage.
Voir sur rbx patients/tim-0453/clone-IGL.fa, alignement en attaché. Belle distribution (mais quelques splice events à la fin ? Que dit CRAC ?) Ici coverage = 100%, juste parce que la gaussienne doit être belle.
Faudrait-il une autre mesure pour dire un coverage plus absolu, pour différencier le cas où les reads sont exactement alignées ?
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1148Exporter un .fastq pour la représentative / qualité pour la consensus (ensemb...2023-10-19T14:40:36+02:00Vidjil TeamExporter un .fastq pour la représentative / qualité pour la consensus (ensemble de la séquence)et/ou utiliser des N voire autres caractères
***
Mikaël: "ad60c833 est un bon début"
***
Discussion en audio du 11 décembre.
L'objet Fasta se souvient de la qualité. La représentative se souvient des 1000 plus longs. On pourrait déjà fa...et/ou utiliser des N voire autres caractères
***
Mikaël: "ad60c833 est un bon début"
***
Discussion en audio du 11 décembre.
L'objet Fasta se souvient de la qualité. La représentative se souvient des 1000 plus longs. On pourrait déjà faire qualité moyenne sur fenêtre (les 1000 plus longs, voire tout).
Faire sur toute la séquence : plus complexe, comment combiner qualité + nombre des séquences ? Peut-être c'est plus informatif (et simple) de montrer le coverage par base (attention, approximatif car k-mers).
***
Discuté au VW16.
***
Marc a fait cela pour la fenêtre (branche windows_quality)
***
mergé pour la fenêtre
***
@mikael-s