vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-02-01T06:07:44+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4985Mettre à jour vidjil-alpha2024-02-01T06:07:44+01:00Mathieu GiraudMettre à jour vidjil-alphavidjil-alpha est notre solution pour le [pre-filtering](https://www.vidjil.org/doc/workflow/#pre-filtering-of-large-datasets), et on l'a maintenant releasé il y a plus d'un an, avec deux releases depuis de vijdil-algo.
J'ai vérifié dans...vidjil-alpha est notre solution pour le [pre-filtering](https://www.vidjil.org/doc/workflow/#pre-filtering-of-large-datasets), et on l'a maintenant releasé il y a plus d'un an, avec deux releases depuis de vijdil-algo.
J'ai vérifié dans le CHANGELOG, pour l'instant rien de critique n'a été mis depuis, mais bon, il y a eu du refactor (des germlines), d'autres sont à venir (!1129), bref cela vaudrait probablement le coup de ne pas trop diverger.
Rebaser ou remerger la bonne MR (c'est d'ailleurs !410 ou !881 ?) et republier un vidjil-alpha à jour ?
cc @mikael-sAlgo 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/3727Utilisation de getS() ou de la graîne avec Aho-Corasick2019-02-28T20:52:32+01:00Mikaël SalsonUtilisation de getS() ou de la graîne avec Aho-CorasickDans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a u...Dans plusieurs endroits du code, notamment `KmerAffectAnalyser::getMaximum`, on utilise le span de la graîne. Or cette graîne peut être différente selon les germlines et selon le gène étudié. Ce n'est pas un problème dans !78 car on a un automate par germline et les graînes ne sont pas encore différenciées selon le gène. Mais cela pourrait poser problème plus tard (ou à d'autres endroits du code), notamment avec #1169.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3501Aho : retirer les hack2024-03-26T12:09:05+01:00Mikaël SalsonAho : retirer les hack5bc753eeae et 5ccd2ec7345bc753eeae et 5ccd2ec734Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/3402Aho : segmentation en DJ au lieu de VDJ2018-10-03T15:57:05+02:00Mikaël SalsonAho : segmentation en DJ au lieu de VDJSur le test simple `should-vdj-tests/igh-vdj.should-vdj.fa` on segmente en DJ au lieu de segmenter en VDJ.
```
>(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 IGHJ4*01 [IGH]
agcctacatggagctgaggagcctgagatctgacgacacggccgtgtattactgtgcga...Sur le test simple `should-vdj-tests/igh-vdj.should-vdj.fa` on segmente en DJ au lieu de segmenter en VDJ.
```
>(IGHV1-18*01, IGHV1-18*04) 0//0 IGHD3-16*01 0//0 IGHJ4*01 [IGH]
agcctacatggagctgaggagcctgagatctgacgacacggccgtgtattactgtgcgagaga
gtattatgattacgtttgggggagttatgcttatacc
actactttgactactggggccaaggaaccctggtcaccgtctcctcag
```
En IGH :
```
IGH SEG_+ 1.339458e-30 2.318227e-129/1.339458e-30+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H ?+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
```
En IGH+ :
```
IGH+ SEG_+ 1.329853e-39 8.909570e-83/1.329853e-39 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _
```
Cela passe en IGH+ à cause du J, qui a pourtant autant d'affectations dans les deux cas. Mais la différence c'est que la fenêtre est plus proche du J en IGH+ qu'en IGH. La e-valeur est donc calculée sur une zone moins grande pour le J en IGH+ qu'en IGH, la e-valeur est donc moins élevée en IGH+ et IGH+ gagne.Heuristique 2.0https://gitlab.inria.fr/vidjil/vidjil/-/issues/2651Aho : quel index load pour le unexpected ?2019-02-28T20:52:32+01:00Mikaël SalsonAho : quel index load pour le unexpected ?Avec Aho, l'index load pour le undetermined est calculé pour le locus auquel on s'intéresse. C'est-à-dire que si on détecte une recombinaison Vh/Jg on aura l'index load des Vh uniquement pour la partie V et l'index load des Jg uniquement...Avec Aho, l'index load pour le undetermined est calculé pour le locus auquel on s'intéresse. C'est-à-dire que si on détecte une recombinaison Vh/Jg on aura l'index load des Vh uniquement pour la partie V et l'index load des Jg uniquement pour la partie J.
Avant on avait l'index load de tous les V/J ensemble. Peut-être serait-il mieux d'avoir l'index load de tous les V insérés d'un côté et tout l'index load des J insérés de l'autre. Sauf que ce n'est pas si simple… et pas forcément souhaitable. À terme le but est bien d'avoir un seul index avec tous les locus : c'est-à-dire la situation actuelle du unexpected.Heuristique 2.0https://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/4226Graines différentes pour V et J : usage2020-04-23T19:24:33+02:00Mathieu GiraudGraines différentes pour V et J : usageAprès #3954/!634.
Attend-on une remise à plat globale des graines #1364 et/ou le seul index pour tous #1169, ou déjà essaie-t-on de mettre dès maintenant quelques J plus petits ? Autre chose ?Après #3954/!634.
Attend-on une remise à plat globale des graines #1364 et/ou le seul index pour tous #1169, ou déjà essaie-t-on de mettre dès maintenant quelques J plus petits ? Autre chose ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3724Supprimer KMER_INDEX ?2019-02-12T22:26:33+01:00Mathieu GiraudSupprimer KMER_INDEX ?Faudra-t-il un jour supprimer `KMER_INDEX` ?
Attendre déjà de voir !78 et les conséquences. Proposition : même si on décide de supprimer, attendre minimum 6 mois, si ce n'est 12, après la release incluant !78.Faudra-t-il un jour supprimer `KMER_INDEX` ?
Attendre déjà de voir !78 et les conséquences. Proposition : même si on décide de supprimer, attendre minimum 6 mois, si ce n'est 12, après la release incluant !78.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/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/2251Minimisation de l'automate2017-03-16T07:20:25+01:00Mathieu GiraudMinimisation de l'automateÀ table, Laurent demandait si on avait essayé de minimiser l'automate. Cela pourrait faire gagner de la mémoire (mais est-ce vraiment une limite ?). Tout dépend de la topologie de notre automate...
cc @mikael-sÀ table, Laurent demandait si on avait essayé de minimiser l'automate. Cela pourrait faire gagner de la mémoire (mais est-ce vraiment une limite ?). Tout dépend de la topologie de notre automate...
cc @mikael-s