vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-01-26T13:29:14+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2767Vidjil-algo ne trouve pas la correspondance si déletion supérieur à 100nt.2021-01-26T13:29:14+01:00Thonier FlorianVidjil-algo ne trouve pas la correspondance si déletion supérieur à 100nt.Une séquence fournie par un utilisateur n'est pas correctement annotée par vidjil. Je met cette séquence dans le should-vdj.
J'ai fait un alignement entre les séquences `V4-39` (trouvé par vidjil, erroné), les `V4-59` (attendues) et la ...Une séquence fournie par un utilisateur n'est pas correctement annotée par vidjil. Je met cette séquence dans le should-vdj.
J'ai fait un alignement entre les séquences `V4-39` (trouvé par vidjil, erroné), les `V4-59` (attendues) et la sequence brut. On voit bien qu'effectivement la séquence avec une identité la plus forte est le V4-59 (enfin les, mais les variations sont minimes). Cependant, l'algo ne les considère même pas. Pire, si on lui fournit un jeu de séquences dans lequel l'ensemble des IGHV ne contient que les V4-59, il trouve la séquence en `unseg`.
Pensant aux evaleurs qui pourraient être faussées par le nombre de séquences, j'ai laissé les autres séquences mais remplacé les A par des G pour fausser la détéction sur les autres segments (solution barbare) : idem, il ne retrouve pas les V4-59.
Dernier point : un caractère inadéquate dans le header des séquences v4-59. A priori non. (J'ai testé d'intervertir avec le header du v4-39)
Je n'ai pas d'explications...
@mikael-s @magiraudAlgo 2017.11Mikaël SalsonMikaël Salsonhttps://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/1967Repasser en -t 0 par défaut au lieu de -t 100 (trim)2017-10-31T12:20:15+01:00Vidjil TeamRepasser en -t 0 par défaut au lieu de -t 100 (trim)Voir autres tâches étiquetées par "trim"
***
ping ?
***
ça va casser des tests mais oui c'est indispensable : raisons de non segmentation trompeuses, ce qui laisse aussi penser qu'on doit pouvoir passer à côté de certaines choses (ce qui...Voir autres tâches étiquetées par "trim"
***
ping ?
***
ça va casser des tests mais oui c'est indispensable : raisons de non segmentation trompeuses, ce qui laisse aussi penser qu'on doit pouvoir passer à côté de certaines choses (ce qui est déjà arrivé pour sûr dans un cas très particulier).
***
2016.09, merci !
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/5065Warning si deux clonotype sont similaire hors primers + Mieux afficher primers2022-10-12T12:03:08+02:00Thonier FlorianWarning si deux clonotype sont similaire hors primers + Mieux afficher primers~"LIL-Lille" nous montre un sample avec 2 clonotypes identiques à un nucléotide près. Ce nucléotide est en fait une divergence présente dans les primers JH et ne devrait donc pas mener a voir deux clonotypes différents.
* [x] Il faudrai...~"LIL-Lille" nous montre un sample avec 2 clonotypes identiques à un nucléotide près. Ce nucléotide est en fait une divergence présente dans les primers JH et ne devrait donc pas mener a voir deux clonotypes différents.
* [x] Il faudrait déjà pouvoir les détecter et indiquer que les séquences sont extrêmement similaires. Probablement déjà la cas, mais nous n'avons pas accès aux données pour le moment. -> Il y a déjà bien le warning W53 (highly similar).
* [ ] Être plus spécifique en indiquant que la variation est située au niveau du primer. Pour ça, il faut être capable d'exploiter les données des primers.
* [ ] À terme, pouvoir en faire un merge automatique depuis l'algo, mais dans ce cas il faut trancher sur le nucléotide à privilégier. Dans le cas présent, les deux clonotypes sont présent dans la même proportion. S'appuyer sur la séquence germline ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/1663notable/shared-brussels.fa et -t 1002020-12-11T13:19:00+01:00Vidjil Teamnotable/shared-brussels.fa et -t 100shared-brussels pas segmenté avec -t 100 : effet de bord coup de chance ?
Doit-on mettre cette séquence en .should-vdj (ne devrait pas être segmentée) ?
***
@magiraud @mikael-sshared-brussels pas segmenté avec -t 100 : effet de bord coup de chance ?
Doit-on mettre cette séquence en .should-vdj (ne devrait pas être segmentée) ?
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1582stanford-label-FaW.should_get et -t 1002019-03-08T17:27:59+01:00Vidjil Teamstanford-label-FaW.should_get et -t 100qu'est-ce ?
***
3e6ace0. Cela ne doit pas être bien grave, mais j'y suis pas arrivé en 5 minutes.
-t 100 change les fenêtres de S22
***
@magiraud @mikael-squ'est-ce ?
***
3e6ace0. Cela ne doit pas être bien grave, mais j'y suis pas arrivé en 5 minutes.
-t 100 change les fenêtres de S22
***
@magiraud @mikael-s