vidjil issueshttps://gitlab.inria.fr/groups/vidjil/-/issues2020-06-03T19:51:25+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4316evalue D et autres dans .vidjil2020-06-03T19:51:25+02:00Mathieu Giraudevalue D et autres dans .vidjilAcutellement, on a `seg.evalue_{left,right}`.
1) Renomme-t-on cela en `seg.{5,3}.evalue` ? C'est un breaking change du format.
2) Ajoute-t-on un `seg.4.evalue` ? C'est un champ de AIRR #3569, pour l'instant on ne le sort pas. D'autant ...Acutellement, on a `seg.evalue_{left,right}`.
1) Renomme-t-on cela en `seg.{5,3}.evalue` ? C'est un breaking change du format.
2) Ajoute-t-on un `seg.4.evalue` ? C'est un champ de AIRR #3569, pour l'instant on ne le sort pas. D'autant que la e-valeur sur D peut-être informative #2002https://gitlab.inria.fr/vidjil/vidjil/-/issues/4267Problème détection d'un 2e D trop court2020-06-23T11:47:49+02:00Anne de SeptenvilleProblème détection d'un 2e D trop courtPour ce patient, détection étrange d'un 2e D de 3 nucléotides.
http://app.vidjil.org/index.html?set=37540&config=2&clone=79Pour ce patient, détection étrange d'un 2e D de 3 nucléotides.
http://app.vidjil.org/index.html?set=37540&config=2&clone=79https://gitlab.inria.fr/vidjil/vidjil/-/issues/4188Retirer les séquences de faible complexité des germlines ?2022-02-17T18:36:48+01:00Mathieu GiraudRetirer les séquences de faible complexité des germlines ?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Voir a089d5b6ed dans !606 :
> It appears that `cacacacacac` exists in a J+down sequence.
Maybe we should remove low-complexity sequences?Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4163AIRR: warnings pour IgBlast2020-01-24T10:49:25+01:00Mathieu GiraudAIRR: warnings pour IgBlast@flothoni : ~"bio-e-value"
mais "IgBlast n'est pas un bon candidat"@flothoni : ~"bio-e-value"
mais "IgBlast n'est pas un bon candidat"https://gitlab.inria.fr/vidjil/vidjil/-/issues/4056Séquences non recombinées mais KmerSegmentées à tort ?2019-11-23T06:51:30+01:00Mathieu GiraudSéquences non recombinées mais KmerSegmentées à tort ?Deux échantillons a priori indépendants: http://app.vidjil.org/index.html?custom=67009&custom=67033&clone=4
Partagent un `D7-27-0/92/0-J1` (bien taggué depuis #2232), mais aussi deux clones en IGK et IGL, en plus non FineSegmentés. Sera...Deux échantillons a priori indépendants: http://app.vidjil.org/index.html?custom=67009&custom=67033&clone=4
Partagent un `D7-27-0/92/0-J1` (bien taggué depuis #2232), mais aussi deux clones en IGK et IGL, en plus non FineSegmentés. Serait-ce des cas similaires à du D7-27 / J1 ?
Ping #1664
cc @flothoni @duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3981On trouve un clone sur très peu d'identité.2019-09-16T16:58:44+02:00Thonier FlorianOn trouve un clone sur très peu d'identité.Suite à des demandes d'éclaircissement, je regarde pourquoi des clones n'ont pas d'identification VDJ. Je prends les séquences bruts de ce clone par l'identifiant, puis lance vidjil dessus avec `-K` pour voir l'affectation.
Je me rends...Suite à des demandes d'éclaircissement, je regarde pourquoi des clones n'ont pas d'identification VDJ. Je prends les séquences bruts de ce clone par l'identifiant, puis lance vidjil dessus avec `-K` pour voir l'affectation.
Je me rends alors compte que nous prédisons un clone, alors que sur 95nt, nous n'avons que 12 matchs de V au début de la séquence, et 6 matchs de J en fin de séquence, les 80nt intermédiaires étant vides.
De plus, comme nous avons des matchs à 100% sur ces portions, la evalue est assez élevé, à 1.78e-15 et 5e-21.
Le clone concerné est le premier de ce sample : https://app.vidjil.org/?set=33551&config=2&clone=41
```
>seq_identifie_vidjil
GAGACCCTGTCCCTCACCTGCGCTCCTGCGAGACCAGATATAAAACTAGCTGCCAACCCAGCCTGTGGCCAGGTCACCGTCTCCTCAGGTCCT
# 18 + VJ 1 24 72 93 seed IGH SEG_+ 2.087323e-16 4.085299e-22/2.087319e-16+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
Je pense que l'on est dans un cas limite, et on ne devrait probablement pas retourner de clone la dessus.
J'ai cherché une issue qui s'y rapporterait. Je ne sais pas si cela à un lien avec #1964, mais le fine pourrait déjà permettre de faire un filtre plus précis non ?
ping @magiraud @mikael-shttps://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/3780FineSegmenter donne Unexpected +TRBV/+TRBJ+down au lieu de VJ2019-03-06T19:44:59+01:00Mathieu GiraudFineSegmenter donne Unexpected +TRBV/+TRBJ+down au lieu de VJVient d'un rapport de ~"LIL\-Immuno".
Dans quelles conditions peut-on produire cela ? #2596 ? N'arrive plus avec le hack dans !78 ?Vient d'un rapport de ~"LIL\-Immuno".
Dans quelles conditions peut-on produire cela ? #2596 ? N'arrive plus avec le hack dans !78 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3726AFFECT_UNKNOWN à la fin des affectations avec Aho et probas2019-02-12T14:36:35+01:00Mathieu GiraudAFFECT_UNKNOWN à la fin des affectations avec Aho et probasDepuis !78, tant qu'on a un automate par germline avec des graines fixes, on a `k` affectations `_` à la fin.
Est-ce que cela pourrait fausser nos calculs de p-valeur sur les J ? @mikael\-s : "peut-être, mais l'index load sur les J a te...Depuis !78, tant qu'on a un automate par germline avec des graines fixes, on a `k` affectations `_` à la fin.
Est-ce que cela pourrait fausser nos calculs de p-valeur sur les J ? @mikael\-s : "peut-être, mais l'index load sur les J a tellement baissé qu'on ne le verrait probablement pas". À voir en tout cas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3187Filtrage du BioReader pour align_against_collection : gérer le cas s'il y a p...2018-07-12T18:00:22+02:00Mikaël SalsonFiltrage du BioReader pour align_against_collection : gérer le cas s'il y a peu de résultats à getMultiResults()On pourrait avoir le cas où on a peu de k-mers correspondent à des gènes V existants (à cause de mutations par exemple).
Si on a seulement 3 k-mers qui correspondent à du V4 et 2 à du V6, a-t-on vraiment envie de privilégier ces deux gè...On pourrait avoir le cas où on a peu de k-mers correspondent à des gènes V existants (à cause de mutations par exemple).
Si on a seulement 3 k-mers qui correspondent à du V4 et 2 à du V6, a-t-on vraiment envie de privilégier ces deux gènes-là plutôt que les autres ? Il y a donc un certain seuil à partir duquel on n'a plus envie de filtrer le `BioReader`.
On pourrait calculer un seuil de p-valeur pour savoir si le nombre de k-mers est satisfaisant par exemple. On a déjà tout ce qu'il faut normalement.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2853Différencier les réarrangements incomplets et pseudo-incomplets2018-12-12T10:52:33+01:00Mikaël SalsonDifférencier les réarrangements incomplets et pseudo-incompletsSuggéré par Dai lors du VW.
On pourrait effectivement différencier un vrai réarrangement incomplet (dans lequel on doit avoir la région amont du D) d'un pseudo-incomplet dans lequel le read est juste trop court ou il n'y a pas assez d'i...Suggéré par Dai lors du VW.
On pourrait effectivement différencier un vrai réarrangement incomplet (dans lequel on doit avoir la région amont du D) d'un pseudo-incomplet dans lequel le read est juste trop court ou il n'y a pas assez d'info pour trouver le V.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2666e-valeur de SEG_METHOD_MAX1U et index_load de AFFECT_UNKNOWN2017-09-25T10:31:56+02:00Mathieu Giraude-valeur de SEG_METHOD_MAX1U et index_load de AFFECT_UNKNOWNLe test de `chimera-fake-half.should-get` qui ne passe pas dans !79 (alors que !79 est bon dans l'esprit) révèle que les e-valeurs de `SEG_METHOD_MAX1U` sont mal calculées (et donc on en a très peu souvent).
Séquence :
```
>TRGV1*01--cg...Le test de `chimera-fake-half.should-get` qui ne passe pas dans !79 (alors que !79 est bon dans l'esprit) révèle que les e-valeurs de `SEG_METHOD_MAX1U` sont mal calculées (et donc on en a très peu souvent).
Séquence :
```
>TRGV1*01--cgcg
tcttccaacttggaagggagaacgaagtcagtcaccaggctgactgggtcatctgctgaa
cgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcg
```
Affects :
```
# 6 - VJ 1 59 88 100 seed IGK SEG_- 2.526646e+01 2.452207e+01/7.443986e-01 _ _-k ? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+K _ _ _ _ _ _ _ _ _ _ _ _-K-K-K-K _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
# 49 ! seed TRG UNSEG ambiguous 9.600000e+01 2.122587e-92/9.600000e+01+G+G+G ?+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G+G _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
IGK par chance (avec !79, et encore, e-value pourrie), mais ici c'est clairement un MAX1U qui doit passer (et plus que SEG_METHOD_ONE #1724).
Voir aussi #2655.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2658VD/VJ : Changer d'avis au moment du Fine2018-07-06T12:39:42+02:00Mathieu GiraudVD/VJ : Changer d'avis au moment du FineIndépendamment des discussions de #2655.
Lors de la deuxième passe, on réévalue chaque read représentative pour le meilleur locus, et on lance le Fine dessus. Mais on a le temps... on pourrait tout à fait lancer deux Fine et prendre le ...Indépendamment des discussions de #2655.
Lors de la deuxième passe, on réévalue chaque read représentative pour le meilleur locus, et on lance le Fine dessus. Mais on a le temps... on pourrait tout à fait lancer deux Fine et prendre le meilleur, l'estimation de ~"bio-e-value" étant supposée plus précise lors du Fine.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2657SEG_METHOD_34_NOT52018-07-13T16:24:48+02:00Mathieu GiraudSEG_METHOD_34_NOT5Une possibilité (pas forcément souhaitable) pour #2655 : en cas de VD, regarder derrière s'il y a des k-mers J, et faire le calcul qu'il faut pour dire qu'il ne devrait pas en avoir.Une possibilité (pas forcément souhaitable) pour #2655 : en cas de VD, regarder derrière s'il y a des k-mers J, et faire le calcul qu'il faut pour dire qu'il ne devrait pas en avoir.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2656Central region : couper en deux pour ne pas pénaliser deux fois2019-03-14T16:17:37+01:00Mathieu GiraudCentral region : couper en deux pour ne pas pénaliser deux foisDans 2e23e720, j'avais écrit :
> A more exact option could have been to use something like
> (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
> The selected option should anyway improve the estimation...Dans 2e23e720, j'avais écrit :
> A more exact option could have been to use something like
> (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
> The selected option should anyway improve the estimation in most of the cases.
Je pense que ce qui me chiffonait pour la symétrie, c'était qu'doit être invariant aux reads rev-compés. Prendre la position (first_pos_max + last_pos_max) / 2 n'est pas reproductible. Mais il suffit de dépasser d'un nucléotide quand c'est impair, et plus de soucis. On comptera dans ce cas une position deux fois, mais ce sera mieux que toute la zone centrale comptée deux fois.
Voir aussi #1878.Algo -- ImportantMathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2655Comparer des e-valeurs venant de méthodes de segmentation différentes ?2023-10-26T15:49:32+02:00Mathieu GiraudComparer des e-valeurs venant de méthodes de segmentation différentes ?Titre initial : *Ne pas* comparer des e-valeurs venant de méthodes de segmentation différentes :-)
Nous avons plusieures tâches ou bugs passés, actuels et futurs liés à la comparaison de ~"bio-e-value" entre `SEG_METHOD_*` ou germlines ...Titre initial : *Ne pas* comparer des e-valeurs venant de méthodes de segmentation différentes :-)
Nous avons plusieures tâches ou bugs passés, actuels et futurs liés à la comparaison de ~"bio-e-value" entre `SEG_METHOD_*` ou germlines différentes :
- VD/VDJ : #2652, #1878
- xxx/*: #2596, hack 5bc753eea, #2651, hack 951facdc
- ONE/* : #2653
Discussion avec @mikael-s il y a quelques jours : une p-valeur d'une séquence est la probabilité qu'elle sorte, étant donné un modèle. Mais là... on a des modèles différents, et aucune connaissance sur ces modèles. Comparer n'est donc pas pertinent.
Supposons une read honnête, V^20 D^30 J^5. Quoi que l'on pénalise, ce sera ici toujours plus beau en VD qu'en VJ. Et #1878 n'arrange pas.
Nous devons peut-être changer complètement de point de vue. Si le filtre de e-valeur est de 10^-6, et que VD et VJ passent ce filtre (1), je veux exactement avoir la réponse la plus complète : "la séquence est VJ" (voire V(D)J après `Fine`, (2)). Le fait que VD puisse être à 10^-100 et VJ à 10^-10 ne change rien au fait que la réponse complète soit vraie "avec une erreur d'au plus 10^-6" (et même 10^-10 ici). (Et... vous savez quoi ? On peut dire avec e-valeur quasi nulle que "il y a des séquences humaines dedans", mais cela n'ajouterait pas grand chose.)
(1) VD et VJ *compatibles*, comme VhDh et VhJh. S'ils ne sont pas compatibles, c'est une autre histoire, voir ci-dessous.
(2) On pourrait aussi avoir une `Kmer`-heuristique détectant V-D-J, #2654, mais pareil, rien ne dit que les e-valeurs soient comparables avec les autres.
Une proposition serait donc **d'arrêter de choisir le locus avec la meilleure e-valeur**, et d'avoir plutôt une situation évoquée dans le passée (mais jamais implémentée, ou peut-être en dur au tout début quand on a fait `IGH+`) avec un ordre partiel `SEG_METHOD_ONE < xxx (MAX_12, MAX_1U) < IGH+ < IGH`. Entre deux germlines passant le filtre de e-valeur et comparables dans l'ordre partiel, on prend la germline la plus complète. Entre deux non-comparables, on prend la meilleure e-value (3). (À voir en pratique. On définit des `stage`, 0 pour les complets, 1 pour les `+`, 2 pour `xxx`, 3 pour `ONE`... ? on utilise un `after` pour encoder la relation ?)
(3) Et encore... Si j'ai TRB et IGH qui passent tous deux à 10^-6, cela veut bien dire que, avec très forte probabilité, la séquence est ambiguë. Les mettre plutôt en `AMBIGUOUS` ?
- Cette définition est encore un chouia ambiguë: si on a `IGH+` 10^-30, `IGH` 10^-10, `TRG` 10^-10, que choisir ?
- Et qu'est-ce que cela donne pour les `TRD+` avec Dd2- ... ?
Cela peut sembler un retour en arrière par rapport à #1499/ae1ac525 (printemps 2015)... mais non: nous sommes contents de nos calculs de e-valeurs (et bien plus sûrs qu'en 2015) pour dire si une recombinaison est signifiante ou pas. Each cell counts.https://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/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/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/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 ?