vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2023-10-26T15:49:32+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2653SEG_METHOD_ONE: comment comparer aux autres SEG_METHOD_* ?2023-10-26T15:49:32+02:00Mathieu GiraudSEG_METHOD_ONE: comment comparer aux autres SEG_METHOD_* ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2648Calcul efficace d'un minimizer : par Aho ?2017-09-18T11:07:46+02:00Mathieu GiraudCalcul efficace d'un minimizer : par Aho ?Ce qui est dans !76 pour #2643 fonctionne : `kaa.minimize(const KmerAffect &affect, int margin, int width)` retourne la position (hors de `margin` sur les bords) tel que le k-mer de longueur `width` soit minimal (maximal en fait). Idéale...Ce qui est dans !76 pour #2643 fonctionne : `kaa.minimize(const KmerAffect &affect, int margin, int width)` retourne la position (hors de `margin` sur les bords) tel que le k-mer de longueur `width` soit minimal (maximal en fait). Idéalement on n'aimerait pas avoir de paramètre `width`, juste `minimize(const KmerAffect &affect, int margin)`.
Mais le code actuel est trivial, c'est du `O(n * width)`, et on utilise `tools.dna_to_int` (qui ne sert pas ailleurs, c'était une tentative il y a longtemps..., ~"dev-dead-code" ?). Si on se met à faire cela pour chaque read reconnue par SEG_METHOD_ONE (par exemple des CDs dans du RNA-seq #1801), c'est perdu.
Il y a sûrement des moyens de faire `O(n)`... voir #915 ?
@mikael-s, ne serait-ce pas possible, de coder simplement et efficacement `minimize`? Par exemple l'état final avec `affect` telle que son *adresse mémoire* soit minimale ? Si on joue avec cela, serait-ce reproductible d'un lancer à l'autre ? Si non reproductible, stocker un autre `int` dans chaque état d'Aho sur lequel on trie ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2596[Aho] Meilleure e-valeur avec xxx qu'avec une recombinaison classique2019-03-06T09:57:28+01:00Mikaël Salson[Aho] Meilleure e-valeur avec xxx qu'avec une recombinaison classiqueSur `should-vdj-tests/BRI_multi.should-vdj.fa` (par exemple) une séquence est segmentée en xxx au lieu de l'être en TRA+D. La e-valeur en xxx est 10^-109 contre 10^-100 en TRA+D.
Pourtant l'index load du xxx est bien plus élevé (3,7% con...Sur `should-vdj-tests/BRI_multi.should-vdj.fa` (par exemple) une séquence est segmentée en xxx au lieu de l'être en TRA+D. La e-valeur en xxx est 10^-109 contre 10^-100 en TRA+D.
Pourtant l'index load du xxx est bien plus élevé (3,7% contre 0,004%).
La séquence est :
```
>TRDV2*01 3/CGGAGG/19 TRAJ48*01 [TRA+D]
TGCAAAGAACCTGGCTGTACTTAAGATACTTGCACCATCAGAGAGAGATGAAGGGTCTTACTACTGTGCCTGTGACCGGAGGGAAATTAACCTTTGGGACTGGAACAAGACTCACCATCATACCCAGTAAGTTCTTCATCCTTGGTCAGGAAATCAGCCTGCATAAGATTCTGGGGA
```Heuristique 2.0Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2595Segmentation avec un seul k-mer avec Aho-Corasick2019-02-28T20:52:32+01:00Mikaël SalsonSegmentation avec un seul k-mer avec Aho-CorasickLa version de Vidjil avec Aho-Corasick échoue sur un test dans `chimera-fake.should-get` sur cette séquence (qui est un faux mélange de TRG/TRD) :
> TCTTCCAACTTGGAAGGGAGAACGAAGTCAGTCACCAGGCTGACTGGGTCATCTGCTGAAGCCCAGAAGGTTACTCAAGCCCAGTCAT...La version de Vidjil avec Aho-Corasick échoue sur un test dans `chimera-fake.should-get` sur cette séquence (qui est un faux mélange de TRG/TRD) :
> TCTTCCAACTTGGAAGGGAGAACGAAGTCAGTCACCAGGCTGACTGGGTCATCTGCTGAAGCCCAGAAGGTTACTCAAGCCCAGTCATCAGTATCCATGCCAGTGAGGAAAGCAGTCACC
Or Vidjil segmente cette séquence en IGK et la chaîne d'affectations ressemble à cela :
```
# 11 - VJ 1 79 108 120 seed IGK SEG_- 1.858802e-01 1.858801e-01/1.009101e-07 _ _-k ? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+K _ _ _ _ _ _ _ _ _ _ _ _-K-K-K-K _ _ _ _ _ _-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-K-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Il n'y a qu'un seul `-k`, et la e-valeur est très haute, mais ça passe tout juste. Pourquoi ?
1. L'index load est faible sur les J (0,013%), contre 1,048% auparavant (il n'y avait pas de distinction entre l'index load des V et des J).
2. La séquence est relativement courte (120nt).
3. Il a peu de séquences dans le fichier.
Bref, que faire ? On est (à peu près) contents de notre calcul de e-valeur. Avoir un index load séparé pour les V et les J semble plus pertinent. Faut-il allonger la séquence pour tricher et refaire passer la e-valeur au dessus du seuil fatidique ?Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2508Vh pas trouvé, uniquement Dh-Jh2018-06-27T18:53:42+02:00Mathieu GiraudVh pas trouvé, uniquement Dh-JhAurélie ~"LIL-Lille" :
> I have a question on the results I obtain on the following sample: http://app.vidjil.org/?sample_set_id=23852&config=25
>
> Let's look on the following clones:
> >IGHD2-2*02 2/TGA/5 IGHJ5*02 362 nt, 148 52...Aurélie ~"LIL-Lille" :
> I have a question on the results I obtain on the following sample: http://app.vidjil.org/?sample_set_id=23852&config=25
>
> Let's look on the following clones:
> >IGHD2-2*02 2/TGA/5 IGHJ5*02 362 nt, 148 525 reads (10.64%, 53.45% of IGH/IGH+, 2042% of IGH+)
> GGAGTCGGGGGAGGCTTGGTCCAGCCTGGGGGTCCCTGAGACTCTCCTGTGCAGCCTCTGGATTCACCTTCAGTGACTACTACATGAGCTGGGTCCGCCAGGCTCCCGGGAAGGGGCTGGAGTGGGTAGGTTTCATTAGAAACAAAGCTAATGGTGGGACAACAGAATAGACCACGTCTGTGAAAGGCAGATTCACAATCTCAAGAGATGATTCCAAAAGCATCACCTATCTGCAAATGAACAGCCTGAGAGCCGAGGACACGGCCGTGTATCAAGGGGCATTTATTGTAGTAGTACCAGCTGCTAT
>
> ATG
> ATGGTTCGACCCCTGGGGCCAGGGAACCCTGGTCACCGTCTCCTCAGGTAAG
>
>
>
> Bonjour,
>
> Ce clone est mal nommé, il ne reconnaît pas le VH, bien présent puisque nous avons pu merger des clones qui étaient VDJ. Cela m’embête car ce clone étant majoritaire, le merge ne permet pas de corriger la séquence.
>
> Pourriez-vous y regarder et me dire pourquoi le VH n’a pas été reconnu ?
>
> Merci
>
> AurélieAlgo -- Importanthttps://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/2250Que signifie une e-valeur de 1 ?2017-03-14T17:48:13+01:00Mathieu GiraudQue signifie une e-valeur de 1 ?@mikael-s, à propos de #2230 :
> Un des problèmes vient du fait qu'une e-valeur de 1 n'est pas délirante quand on a 100 séquences, mais si on en a qu'une (comme dans les should-vdj) ce n'est pas la même histoire (mais ce n'est pas le seu...@mikael-s, à propos de #2230 :
> Un des problèmes vient du fait qu'une e-valeur de 1 n'est pas délirante quand on a 100 séquences, mais si on en a qu'une (comme dans les should-vdj) ce n'est pas la même histoire (mais ce n'est pas le seul problème).
J'ai eu un soucis similaire pour #2107, qui a mené à 3f023b73 : vu que c'est désormais uniquement le test de e-valeur qui mène à `UNSEG_ONLY_V/J`, des séquences vont être désormais segmentée avec une e-valeur de 1 alors qu'elles ne l'étaient pas avant (il y a avait `DETECT_THRESHOLD`). Pas de soucis dès qu'on a le multiplieur.
Faudrait-il mettre la e-valeur par défaut à 0.01 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2168Mieux construire la pseudo-germline xxx en prenant aussi les gènes D2018-10-03T15:52:36+02:00Mathieu GiraudMieux construire la pseudo-germline xxx en prenant aussi les gènes DLes gènes `D` ne sont pour l'instant pas pris en compte.
Voir 3ea1027 et #2167.
@mikael-sLes gènes `D` ne sont pour l'instant pas pris en compte.
Voir 3ea1027 et #2167.
@mikael-sHeuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/2167Mieux construire la pseudo-germline xxx en ne prenant pas les doublons2017-02-04T12:26:33+01:00Mathieu GiraudMieux construire la pseudo-germline xxx en ne prenant pas les doublonsOn devrait initialiser `xxx` avec tous les répertoires disponibles (voir aussi #2168), mais faire en sorte qu'on ne prenne qu'une fois chaque fichier (sinon on génère des `AFFECT_AMBIGUOUS`, voir !6 et c7a85b67).On devrait initialiser `xxx` avec tous les répertoires disponibles (voir aussi #2168), mais faire en sorte qu'on ne prenne qu'une fois chaque fichier (sinon on génère des `AFFECT_AMBIGUOUS`, voir !6 et c7a85b67).Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1964e-values .vidjil sont celles du Kmer, pas du Fine2019-09-16T16:32:48+02:00Vidjil Teame-values .vidjil sont celles du Kmer, pas du Fine(Vu au sujet de "evalue > 1")
Le code actuel sort dans le .json la evalue du Kmer (champ "seg" vient de la fusion des deux toJson, Fine et Kmer, mais seul Kmer sort la e-valeur). Est-ce souhaitable de mettre plutôt le Fine, plus robuste...(Vu au sujet de "evalue > 1")
Le code actuel sort dans le .json la evalue du Kmer (champ "seg" vient de la fusion des deux toJson, Fine et Kmer, mais seul Kmer sort la e-valeur). Est-ce souhaitable de mettre plutôt le Fine, plus robuste (euh, K/lambda ?)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1936Véracité des causes de non segmentation (et implications du -t ou -2)2016-12-06T10:22:13+01:00Vidjil TeamVéracité des causes de non segmentation (et implications du -t ou -2)Les causes de non segmentation varient grandement en fonction des paramètres utilisés, ce qui induit en erreur.
Par exemple sur des données de LLC, ajouter un -t 0 (par défaut -t 100), conduit à considérer le V dans toute sa longueur et ...Les causes de non segmentation varient grandement en fonction des paramètres utilisés, ce qui induit en erreur.
Par exemple sur des données de LLC, ajouter un -t 0 (par défaut -t 100), conduit à considérer le V dans toute sa longueur et donc le UNSEG too few V/J passe de ~10^5 à ~10^3, les séquences passant en fait en « UNSEG only V/5' ». Cela amène d'ailleurs à se poser la question de la pertinence de -t 100 : il y a des séquences qui contiennent vraiment du V mais dont on pense qu'elles n'en ont pas à cause du -t 100.
Par ailleurs sur ces mêmes données, utiliser un -2 fait passer une très grosse partie des séquences de « UNSEG only V/5' » à « UNSEG only J/3' » pour une raison que je n'explique pas.
Les données en question : patient 1803 et 1806 (Lille).
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1915Graîne pour xxx2020-08-27T12:47:39+02:00Vidjil TeamGraîne pour xxxLa graîne utilisé pour xxx est plus courte que pour d'autres locus (IGH, TRA, TRB, IGH+, TRA+D, TRD+), du coup une séquence ne passant pas dans un locus normal (à cause d'erreurs ou hypermutations) pourrait passer en xxx alors que la rec...La graîne utilisé pour xxx est plus courte que pour d'autres locus (IGH, TRA, TRB, IGH+, TRA+D, TRD+), du coup une séquence ne passant pas dans un locus normal (à cause d'erreurs ou hypermutations) pourrait passer en xxx alors que la recombinaison n'a rien d'extraordinaire. Exemple ici : http://rbx.vidjil.org/browser/index.html?patient=1655&config=25
***
Bien vu. Je me demandais ce que faisait ces séquences.
Que doit-on faire ?
1) allonger la graine de xxx (ou les seuils de e-valeur) pour ne plus avoir cela
2) interdire que xxx retourne un V/J d'un autre locus
3) ou... "sauver" ces séquences et les remettre (même dans le C++) dans le locus d'origine. **Si** on a confiance dans nos calculs d'e-valeur, ce serait la bonne chose à faire : une séquence xxx qui passe est pertinente.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1889evalues > 12019-09-16T16:58:45+02:00Vidjil Teamevalues > 1Des e-valeurs > 1 sont sorties pas Vidjil. Exemple ici : http://rbx.vidjil.org/browser/?patient=1634&config=25 prendre le premier clone de la liste avec un warning. La e-valeur vaut 480061.
***
Vu aussi par Tatiana, e-value >1 sample 370...Des e-valeurs > 1 sont sorties pas Vidjil. Exemple ici : http://rbx.vidjil.org/browser/?patient=1634&config=25 prendre le premier clone de la liste avec un warning. La e-valeur vaut 480061.
***
Vu aussi par Tatiana, e-value >1 sample 3703
***
Je n'arrive pas à retrouver un exemple : le bug sur le 1634 est confirmé ?
***
Je ne vois plus les e-valeurs. Elles ne sont plus affichées ?
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1878Prise en compte de la central région pour la p-valeur : mauvaise idée pour ch...2020-12-04T12:07:46+01:00Vidjil TeamPrise en compte de la central région pour la p-valeur : mauvaise idée pour choix du meilleur locusSur l'exemple ci-dessous (IgJC/IgVC souris,), c'est le IgVC qui devrait moralement passer : le V est beaucoup plus beau (1e-110) que le J (1e-38). *Mais* le fait d'avoir pris la "central region" pour la e-valeur (2e23e720) donne finaleme...Sur l'exemple ci-dessous (IgJC/IgVC souris,), c'est le IgVC qui devrait moralement passer : le V est beaucoup plus beau (1e-110) que le J (1e-38). *Mais* le fait d'avoir pris la "central region" pour la e-valeur (2e23e720) donne finalement une plus mauvaise e-valeur pour le segment droit (C) et finalement pour IgVC.
Je suis prêt à parier qu'on retrouve la même chose sur certains DhJh / VDJ IGH humain.
```
>6
ACATTTGGGAAGGACTGACTCTCTGAGGAGACGGTGACCGTGGTCCCTGTGCCCCAGACATCGAAGTACCACCGTAATCCCCTCCTTCGAGCACAGTAGTATGTGGCAGTATCTGCAGTGTCCACACTGGTGATCTTGAGGAATACCTGGTTTCTGGAGGTATCCTTGGAGATTGTGAGCCGGCTCTTCAGGGATGGGTTATAGCGCTTGTCATCATCCCAGTAAATGTGTGCCAGCCACTCCAGACCCTTTCCTGAAGGCTGACGAATCCAGCTCACACCCATACCAGAAGTGCTCAGTGAAAACCCAGAGAAAGAACAAGTCAGACTGAGGGTCTGGGAGGACTGCAATATCCCAGGGCCAGACTCTTTCAGAGTAACCTGGGACAGGACATATGCAGGGACAATCAGCAGCAGGAATGAGGAAGTA
# 32 - VJ 0 405 407 428 seed IgJC SEG_- 9.531439e-38 7.491827e-38/2.039612e-38-c-c-c-c-c-c-c-c-c-c-c _ _ _ _ _ _ _ _ _ _ _-C-C-C-C _ _ _ _-C-C-C-C-C-C-C _ _ _ _ _ _-C _ _ _ _ _ _-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (...)
# 81 - VJ 0 339 406 428 seed IgVC SEG_- 2.634030e-23 2.634030e-23/3.652017e-110-c-c-c-c-c-c-c-c-c-c-c _ _ _ _ _ _ _ _ _ _ _-Q-Q-Q-Q _ _ _ _-Q-Q-Q-Q-Q-Q-Q _ _ _ _ _ _-Q _ _ _ _ _ _-Q-Q-Q-Q-Q-Q-Q-Q-Q _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _-C _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _-C-C-C-C-C-C-C-C-C-C _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (...)
#>6 - VJ 0 405 407 428 seed IgJC SEG_- 9.531439e-38 7.491827e-38/2.039612e-38
```
***
Que faire ? Arrêter la central région si on rencontre un k-mer "4" ? plusieurs k-mers "4" ?
***
Pas sûr de comprendre le problème. N'est-il pas censé y avoir une région centrale aussi ? Pourquoi y a-t-il trois types d'affectation dans la séquence du bas (`-c`, `-Q`, `-C`) ?
***
En bas, c'est `5`=`V`=`-C`, `4`=`J`=`-Q`, `3`=`isotypes`=`-c`.
Ne pas oublier que les k-mers 4 sont dans l'index.
Mais bon, reformulation plus simple : le problème est le choix entre VDJ et DJ :
```
VVVVVV-------DDDDDD-------JJJJJJJ donc 33333(-----44444-----)5555
DDDDDD-------JJJJJJJ donc 33333(-----)5555
```
La zone centrale, entre parenthèses, est plus grande en haut qu'en bas, d'où une moins bonne e-valeur pour la région J en haut par rapport à en bas.
***
test 69ea8e6
***
ping
***
Choses en cours dans hotfix_evalue_incomplete_germline
Voir aussi aho et xxx (pénalité qui était implicite avant) ?
***
À voir d'ici 2016.09
***
Il y a eu le hack pour 2016.09.
À revoir tranquillement pour la prochaine releaseAlgo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1801CD et autres choses utiles pour l'immuno en RNA-Seq2021-11-19T11:06:55+01:00Vidjil TeamCD et autres choses utiles pour l'immuno en RNA-Seq(splité depuis "Classes des Ig en RNA-Seq" #2261 ?)
On ne va pas devenir un outil générique de mapping...
... néanmoins, est-ce que cela ne vaudrait pas le coup de détecter qui pourraient arriver en RNA-Seq ? (voire en capture, cela dé...(splité depuis "Classes des Ig en RNA-Seq" #2261 ?)
On ne va pas devenir un outil générique de mapping...
... néanmoins, est-ce que cela ne vaudrait pas le coup de détecter qui pourraient arriver en RNA-Seq ? (voire en capture, cela dépend du protocole)
Par exemple au moins les CD3, CD4, CD8, CD19, CD45RA/CD45RO... ou d'autres...
***
Cela est fortement tentant d'avoir une méthode de segmentation qui fait... uniquement du mapping sur des gènes connus #1724. Hum, c'est interdit par la doxa de Vidjil (recombinaisons)... mais l'intérêt serait toujours de suivre des populations et des ratios (par exemple, un pseudo-germline avec tous les CDx, et les ratios seraient intéressants).
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1760Une séquence ambiguë à tort ? -42017-02-04T10:11:36+01:00Vidjil TeamUne séquence ambiguë à tort ? -4Hier, tu as dit à un moment "c'est bizarre que cette séquence soit ambigüe".
Tu te souviens de laquelle c'était ?
***
C'est quand tu faisais un -4 (sur les données de Florian ?), en xxx la séquence passait en unknown alors qu'il y avait ...Hier, tu as dit à un moment "c'est bizarre que cette séquence soit ambigüe".
Tu te souviens de laquelle c'était ?
***
C'est quand tu faisais un -4 (sur les données de Florian ?), en xxx la séquence passait en unknown alors qu'il y avait pas mal de delta à la fin qui était bien reconnu
***
Ah, ok, si c'est -4 c'est expérimental :-)
***
Euh… pourquoi le calcul de l'ambigu différerait entre le -4 et le reste ?
***
C'est une bonne question.
***
J’ai comparé 0ce12ff et 783d0b1 (diff: changements de la semaine dernière, plus de reads en ambiguous)
/vidjil -g germline/ -i -K ~/notable/data_translocation.fasta
Une séquence passe de only V en too few V/J, et c’est mieux ainsi.
Bref, pas de soucis avec les dernières modifs.
Avec -4, pas encore tout compris ce qu’il se passe, mais rien d’urgent de ce côté, on verra cela en janvier.
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1628Heuristique : analyser les germlines non recombinés2017-12-13T08:22:37+01:00Vidjil TeamHeuristique : analyser les germlines non recombinés0618/R1, de Maria
- on ne segmente < 0.1% en mutli+inc+xxx
- mais 18% en MAX_1U (avec -e 10000000)
(et même 21% en -t 0)
En en ayant regardé le premier cluster, plus que du MAX_1U, c'est en fait du... non recombiné.
On devrait av...0618/R1, de Maria
- on ne segmente < 0.1% en mutli+inc+xxx
- mais 18% en MAX_1U (avec -e 10000000)
(et même 21% en -t 0)
En en ayant regardé le premier cluster, plus que du MAX_1U, c'est en fait du... non recombiné.
On devrait avoir une méthode de segmentation qui sort des trucs non recombinés. #1724.
On prend l'affectation maximum, et regarde combien il y en a... mais quel calcul de proba faire ensuite ? Pour que cela ne passe pas devant une vraie séquence recombinée ? #2653
Faut-il avoir des probas conditionnelles ?
***
Germlines avec les séquences avals des V et amonts des J, et on fait du V, contre du V-aval ou du J-amont contre du J de façon tout à fait classique.
***
Pourquoi pas... mais devra-t-on rentrer toutes ces germlines ?
Ou bien, si elles sont juste présentes quelque part, le MAX_12 va les trouver.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1592segmenter.h/c: rationaliser les attributs d'information2016-11-29T14:38:19+01:00Vidjil Teamsegmenter.h/c: rationaliser les attributs d'informationdans le Kmer et le FineSegmenter, on stocke différentes chaînes d'information :
info, info_extra, code, code_short, code_light
puis on s'en sert à des degrés divers sur la sortie standard et dans le .vidjil.
Voir aussi finishSegmentati...dans le Kmer et le FineSegmenter, on stocke différentes chaînes d'information :
info, info_extra, code, code_short, code_light
puis on s'en sert à des degrés divers sur la sortie standard et dans le .vidjil.
Voir aussi finishSegmentation() et getInfoLine().
Voir si tout cela ne pourraît pas être simplifié.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1581Tailles de fenêtres différentes selon les locus2018-04-10T12:29:07+02:00Vidjil TeamTailles de fenêtres différentes selon les locusMikaël : "pourquoi ne pas mettre la taille de la fenêtre dans Germline
et avoir des tailles différentes selon les germlines ? Je ne vois pas
pourquoi TRG et IGH (par exemple) devraient nécessairement avoir la même
taille de fenêtre."
**...Mikaël : "pourquoi ne pas mettre la taille de la fenêtre dans Germline
et avoir des tailles différentes selon les germlines ? Je ne vois pas
pourquoi TRG et IGH (par exemple) devraient nécessairement avoir la même
taille de fenêtre."
***
Ce serait un rétro-pédalage depuis le -w 50 (mais c'est possible, et plus pertinent de changer selon la germline que selon l'option multi ou pas)
Les raisons (peut-être mauvaises) qui avaient poussé à un -w unique :
- on souhaite pouvoir comparer IGH et IGH+
- et TRD avec TRD+, avec VdJa, avec TRA -> par transitivité TRA avec TRD, alors que VJ et VDJ
mais est-ce vraiment important ? deux fenêtres IGH et IGH+ n'ont de toute façon rien à voir ensemble...
***
... et si on resplite un clone, on aura des tailles de fenêtres encore différentes à l'intérieur d'un même locus...
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1573Coverage plus que douteux sur certains jeux de données2021-04-08T19:03:56+02:00Vidjil TeamCoverage plus que douteux sur certains jeux de donnéesSur les 20 premiers clones de Stanford S22, avec -w 60, près de la moitié ont un coverage <= 65%.
Et plusieurs sont à <= 55%.
***
Et avec -w 100, ce n'est pas vraiment mieux.
N'est-ce que des hypermutations somatiques, ou est-ce plus gr...Sur les 20 premiers clones de Stanford S22, avec -w 60, près de la moitié ont un coverage <= 65%.
Et plusieurs sont à <= 55%.
***
Et avec -w 100, ce n'est pas vraiment mieux.
N'est-ce que des hypermutations somatiques, ou est-ce plus grave ?
***
Titre changé : cela ne concerne pas que S22.
Autre exemple de jeux de données avec des coverages très douteux :
http://rbx.vidjil.org/browser/index.html?patient=786&config=26
***
@magiraud @mikael-s