vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2019-03-05T08:55:46+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2556Mettre Aho par défaut2019-03-05T08:55:46+01:00Mathieu GiraudMettre Aho par défautÉvoqué par @mikael-s pour %"Algo 2017.07".
Avant #1169, on pourrait déjà mettre Aho par défaut.
Problèmes restants sur Aho :
* [ ] #2596 (xxx meilleur que recombinaison classique)
* [x] #3404 (xxx IGHV+/IGHJ+ meilleur que IGH !)
* ...Évoqué par @mikael-s pour %"Algo 2017.07".
Avant #1169, on pourrait déjà mettre Aho par défaut.
Problèmes restants sur Aho :
* [ ] #2596 (xxx meilleur que recombinaison classique)
* [x] #3404 (xxx IGHV+/IGHJ+ meilleur que IGH !)
* [x] #2652 (VD au lieu de VDJ)
* [ ] #3402 (DJ au lieu de VDJ)
* [ ] #2595 (segmentation avec un seul k-mer, mais non bloquant je dirais)Algo 2018.12Mikaë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/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/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/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/2652Aho : Séquences segmentées VD au lieu de VJ2018-07-19T19:50:13+02:00Mikaël SalsonAho : Séquences segmentées VD au lieu de VJLa séquence IGH suivante devrait être segmentée en IGH :
```
>IGHV4-31*03 0/TCCT/1 IGHD3-22 3/AGCG/8 IGHJ4 [IGH]
AGGTGCAGTGGAGCAGTCGGGCCCAGGACTGGTGAAGCCTTCACAGACCCTGTCCCTCACCTGCACTGTCTCTGGTGGTCCATAGCAGTGGTGGTTACTACTGGAGCTGGATCCGCCAGCACCC...La séquence IGH suivante devrait être segmentée en IGH :
```
>IGHV4-31*03 0/TCCT/1 IGHD3-22 3/AGCG/8 IGHJ4 [IGH]
AGGTGCAGTGGAGCAGTCGGGCCCAGGACTGGTGAAGCCTTCACAGACCCTGTCCCTCACCTGCACTGTCTCTGGTGGTCCATAGCAGTGGTGGTTACTACTGGAGCTGGATCCGCCAGCACCCAGGGAAGGGCCTGGAGTGGATTGGGTACATCTATTACAGTGGGAGCACCTATACAACCCGTCCCTCAAGAGTCGAGTTACCATATCAGTAGACACGTCTAAGAACCAGTTCTCCCTGAAGCTGAGCTCTGTGACTGCCGCGGACACGGCCGTGTATTACTGTGCGAGAGATCCTTATTACTATGATAGTAGTGGTTATTACAGCGGACTACTGGGGCCAGGAACCTGGTCACCGTCGTCCTGCAGGTAAG
```
Mais avec Aho ce n'est pas le cas. Car dans le cas où le germline est unexpected, il y a plus de k-mers Dh (les `+V` ci-dessous) que de k-mers Jh (les `+h` ci-dessous). Du coup la e-valeur est meilleure en faisant du V-D que du V-J !
```
# 258 + VJ 1 292 299 374 seed unexpected SEG_+ 3.376699e-37 0.000000e+00/3.376699e-37
_ _ _+H _ _+G _ _ _ _ _ _ _+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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+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
+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+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+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+A _
+H ?+H+H+H+H+H+H _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V+V+V ?+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _+L _ _ _
_ _ _ _ _+h+h+h+h _ _ _ _ _ _ _ _ _ _ _ _ _ _+h _ _ _ _ _ _ _ _ _ _ _ _+K-L _ _ _ _ _ _ _ _ _ _ _ _
```
@magiraud Une idée autre que celle de pénaliser arbitrairement le unexpected ?
Et pas sûr que #1878 arrange les choses là-dessus.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2259Lancer tous les tests should-vdj avec une seule instance de Vidjil ?2022-02-16T16:22:00+01:00Mikaël SalsonLancer tous les tests should-vdj avec une seule instance de Vidjil ?J'anticipe que les tests avec Aho seront plus longs car :
1. la construction de l'automate est plus longue que de mettre des k-mers dans une table ;
2. la destruction de l'automate est assez longue (il faut parcourir l'automate en profo...J'anticipe que les tests avec Aho seront plus longs car :
1. la construction de l'automate est plus longue que de mettre des k-mers dans une table ;
2. la destruction de l'automate est assez longue (il faut parcourir l'automate en profondeur pour le détruire).
Ce n'est pas un problème en pratique car c'est bien l'étape d'analyse des données qui dominera largement le temps. Mais c'est un problème pour les tests car Vidjil est lancé très souvent avec un rechargement à chaque fois des germlines, surtout pour les should-vdj. Pourrait-on faire un gros fichier .fa concaténant tous les should-vdj et lancer Vidjil une seule fois dessus ?
cc @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3209Créer un cas de test pour getMultiResults où la séquence à tester est plus co...2018-06-12T12:36:43+02:00Cyprien BoréeCréer un cas de test pour getMultiResults où la séquence à tester est plus courte que celles représentées par les K-mersLors du filtrage du **BioReader** par la fonction **filterBioReaderWithACAutomaton** dans **segment.cpp**, la méthode **getMultiResults** de l'automate ne retourne pas le bon nombre de gènes. Pour cela il faudrait tester créer un cas spé...Lors du filtrage du **BioReader** par la fonction **filterBioReaderWithACAutomaton** dans **segment.cpp**, la méthode **getMultiResults** de l'automate ne retourne pas le bon nombre de gènes. Pour cela il faudrait tester créer un cas spécifique dans les tests où la séquence qu'on applique à l'automate est plus courte que celles représentées par les K-mers utilisés lors de la construction de l'automate.
Après discussion avec @magiraud il semble nécessaire que chaque état de l'automate comporte le nom (de famille) du gène qu'il représente, même si l'état en question n'est pas un état final de l'automate, mais un état intermédiaire.
Il y a donc deux tests à créer:
- Un vérifiant que pour chaque état de l'automate il y a bien un K-mer avec le nom du gène.
- Un vérifiant que getMultiResults renvoie la bonne map lorsque la séquence est plus courte que celles associés aux K-mers.Cyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3212modifier la méthode insert de automaton pour mettre l'information dans les di...2018-05-15T07:33:15+02:00Cyprien Boréemodifier la méthode insert de automaton pour mettre l'information dans les différentes étapes de l'automateComme la méthode **getMultiResults** de l'automate peut renvoyer un résultat indésirable si la séquence à analyser est plus courte que celles constituant les k-mers, il est souhaitable d'avoir des informations sur chaque état de l'automa...Comme la méthode **getMultiResults** de l'automate peut renvoyer un résultat indésirable si la séquence à analyser est plus courte que celles constituant les k-mers, il est souhaitable d'avoir des informations sur chaque état de l'automate pour ensuite convenir du k-mer le plus ressemblant à la séquence à analyser.
/!\ Respecter la complexité de la boucle de la méthode insert.Cyprien BoréeCyprien Boréehttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3238Aho-Corasick : utiliser un set plutôt qu'une liste pour stocker les informati...2018-06-13T15:45:33+02:00Mikaël SalsonAho-Corasick : utiliser un set plutôt qu'une liste pour stocker les informations ?Les informations contenues dans chaque état sont stockées sous forme de liste ce qui permet facilement d'en ajouter de nouveaux. Le problème c'est que lorsqu'on ajoute la même information plusieurs fois, lorsqu'on requête on renvoie la m...Les informations contenues dans chaque état sont stockées sous forme de liste ce qui permet facilement d'en ajouter de nouveaux. Le problème c'est que lorsqu'on ajoute la même information plusieurs fois, lorsqu'on requête on renvoie la multiplicité de l'information.
Il serait plus pertinent d'avoir un set. À voir si cela pose des problèmes ou si cela passe.Mikaël SalsonMikaël Salsonhttps://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/3404Aho : segmentation en xxx au lieu de IGH VDJ2018-07-19T19:50:01+02:00Mikaël SalsonAho : segmentation en xxx au lieu de IGH VDJMais le plus drôle c'est que le unexpected qui est sorti est du… IGHV+/IGHJ+ !
C'est sur la séquence : should-vdj-tests/7038-long-deletions.should-vdj.fa
On a des e-valeurs plus basses à la fois pour le V et pour le J en `xxx` (10^-89 ...Mais le plus drôle c'est que le unexpected qui est sorti est du… IGHV+/IGHJ+ !
C'est sur la séquence : should-vdj-tests/7038-long-deletions.should-vdj.fa
On a des e-valeurs plus basses à la fois pour le V et pour le J en `xxx` (10^-89 et 10^-32 contre 10^84 et 10^-23). C'est douteux.
Voici les affectations :
IGH
```
seed IGH SEG_+ 1.099395e-23 9.613435e-84/1.099395e-23 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
```
xxx
```
seed unexpected SEG_+ 3.237259e-32 1.203927e-89/3.237259e-32 _ _-L+B _ _ _ _ _-B _ _ _ _ _ _ _-L _ _ _ _ _ _ _ _ _+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 _ _ _ _ _+L+H+H+H+H+H+H+H+H+H+H+H _+H _ _ _ _ _ _ _ _+h+h+h+h+h+h+h+h _ _ _+L _ _ _ _ _ _ _ _ _ _ _ _
```https://gitlab.inria.fr/vidjil/vidjil/-/issues/3419Tests sur les CD qui échouent avec Aho2019-03-05T14:43:03+01:00Mikaël SalsonTests sur les CD qui échouent avec Ahocf. !78
Je pense qu'il nous faut un expert sur le sujet.cf. !78
Je pense qu'il nous faut un expert sur le sujet.Mathieu GiraudMathieu Giraud2018-11-09https://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/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/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/3954Graines différentes pour V et J2020-03-26T12:45:56+01:00Mathieu GiraudGraines différentes pour V et JSpécialise #1169.
Pensé depuis le début avec ~"cpp-aho".
@mikael-s : "on stocke déjà un `index_load` différent" et "en IGK, 30kbp pour V et 300bp pour J, 100 fois moins !"
Voir aussi #1364.Spécialise #1169.
Pensé depuis le début avec ~"cpp-aho".
@mikael-s : "on stocke déjà un `index_load` différent" et "en IGK, 30kbp pour V et 300bp pour J, 100 fois moins !"
Voir aussi #1364.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4225Affectations manquantes avec l'option `-1`2020-03-25T12:09:53+01:00Mikaël SalsonAffectations manquantes avec l'option `-1`Comme noté dans #3954, avec l'option `-1` on se retrouve avec des affectations `_` là où on ne devrait pas.Comme noté dans #3954, avec l'option `-1` on se retrouve avec des affectations `_` là où on ne devrait pas.https://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/4287Pourquoi multi-0 sur 2020.04 est plus rapide ?2020-05-20T16:47:47+02:00Mathieu GiraudPourquoi multi-0 sur 2020.04 est plus rapide ?Extrait de #4275.
Sur plusieurs machines (et Docker ou pas, ce n'est donc pas la question), 2020.04 est significativement plus rapide, revenant presque au niveau de 2018.10, avant !78 : https://gitlab.inria.fr/vidjil/vidjil/-/jobs/642028Extrait de #4275.
Sur plusieurs machines (et Docker ou pas, ce n'est donc pas la question), 2020.04 est significativement plus rapide, revenant presque au niveau de 2018.10, avant !78 : https://gitlab.inria.fr/vidjil/vidjil/-/jobs/642028https://gitlab.inria.fr/vidjil/vidjil/-/issues/1366Aho-Corasick: construction, implémentation2016-11-29T14:35:19+01:00Vidjil TeamAho-Corasick: construction, implémentationBiblio : j'imagine qu'il y a plein de papiers sur la construction. Mais l'algo de base suffit peut-être.
Implémentation : librairie externe ? http://multifast.sourceforge.net
http://sourceforge.net/p/multifast/code/HEAD/tree/trunk/ahoco...Biblio : j'imagine qu'il y a plein de papiers sur la construction. Mais l'algo de base suffit peut-être.
Implémentation : librairie externe ? http://multifast.sourceforge.net
http://sourceforge.net/p/multifast/code/HEAD/tree/trunk/ahocorasick/ahocorasick.c
Il doit y avoir mieux.
Mvouais, pas un truc externe au coeur de notre heuristique...
Et c'est relativement facile, en tout cas si on reste sur les algos de base.
***
Après le départ de Marc ?
***
à la rentrée :-)
***
Done, merge prochain :)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1630Que doit renvoyer l'automate pour indexLoad ?2017-09-12T18:21:11+02:00Vidjil TeamQue doit renvoyer l'automate pour indexLoad ?hihihi
***
@magiraud @mikael-shihihi
***
@magiraud @mikael-shttps://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-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2258Vijdil-benchmark: +35% de mémoire en janvier2017-03-16T09:58:08+01:00Mathieu GiraudVijdil-benchmark: +35% de mémoire en janvierhttps://ci.inria.fr/bonsai/job/Vidjil-benchmark/FILENAME=data%7dStanford_S22.fasta,GERMLINE=-G%20germline%7dIGH,label=bonsai-debian-wheezy-amd64/plot/
Que s'est-il passé ? (Peut-on voir un tableau pour voir précisément le build qui a fa...https://ci.inria.fr/bonsai/job/Vidjil-benchmark/FILENAME=data%7dStanford_S22.fasta,GERMLINE=-G%20germline%7dIGH,label=bonsai-debian-wheezy-amd64/plot/
Que s'est-il passé ? (Peut-on voir un tableau pour voir précisément le build qui a fait monter ?) Serait-ce lié à #2120 ?
cc @mikael-shttps://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.04