vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-07-12T18:26:08+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3315Mauvais alignement du J : check_and_resolve_overlap() et alignements curieux ...2018-07-12T18:26:08+02:00Mikaël SalsonMauvais alignement du J : check_and_resolve_overlap() et alignements curieux localementDans https://gitlab.inria.fr/vidjil/vidjil/merge_requests/148#note_99705 un alignement étrange est observé pour
(7efab5bb5) :
>
On s'attend à avoir `TRGV3*01 3/TCTTC/39 TRGJ2*01` mais on trouve `TRGV3*01 3//36 TRGJ2*01`. J'aurais pu me...Dans https://gitlab.inria.fr/vidjil/vidjil/merge_requests/148#note_99705 un alignement étrange est observé pour
(7efab5bb5) :
>
On s'attend à avoir `TRGV3*01 3/TCTTC/39 TRGJ2*01` mais on trouve `TRGV3*01 3//36 TRGJ2*01`. J'aurais pu me louper dans mon alignement mais `algo/tools/align` me dit bien cela pour l'alignement avec le TRGJ :
>
```
===== -m 2 : LocalEndWithSomeDeletions
194 TGTTGTCACAGGTAAGTATCGGAAGAAT (sequence)
||||||||||||||||||||||||||||
39 TGTTGTCACAGGTAAGTATCGGAAGAAT (TRGVJ2*01)
```
Et surtout les séquences amont n'ont rien à voir :
>
```
VVVVnnnnnJJJJJJJ...
seq GGACTCTTCTGTTGTCACAGGTAAGTATC
||||||||||||||||||||
TRGJ2*01 AACAACACTTGTTGTCACAGGTAAGTATC
```
Je vois mal comment TCTTC pourrait s'aligner avec ACT…
En regardant un peu plus, la `box_J` change suite à la résolution de l'overlap :
```
[/18 @173 TRGJ2*01(1) @173 18/]
[/36 @189 TRGJ2*01(1) @173 18/]
```
Je ne suis pas sûr de comprendre ce que cela signifie (on passe de 18 délétions à 36 ?). Mais pourquoi l'alignement trouvé par Vidjil n'est pas celui donné ci-dessus (le premier) ? Il a été obtenu avec l'outil `align` qui utilise les mêmes coûts et mode d'alignement que `DynProg`. Voilà comment l'obtenir (avec l'ordre actuel des germlines) :
```
algo/tools/align -m 2 -c 2 -i 0 -j 1 algo/tests/should-vdj-tests/7849-deleted-J.should-vdj.fa germline/homo-sapiens/TRGJ+down.fa
```
Ping @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2825Coût du FineSegmenter : est-on trop généreux avec les mismatches ?2018-06-26T10:41:27+02:00Mikaël SalsonCoût du FineSegmenter : est-on trop généreux avec les mismatches ?Il y a certains cas où le nombre de mismatches, proches d'une extrémité semble important par rapport au nombre de matches.Il y a certains cas où le nombre de mismatches, proches d'une extrémité semble important par rapport au nombre de matches.Algo -- Importanthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2119Pas d'assigation VDJ lorsqu'il y a de grosses délétions2024-01-31T17:25:11+01:00Mikaël SalsonPas d'assigation VDJ lorsqu'il y a de grosses délétionsVoici [un exemple](http://app.vidjil.org/?patient=4601&config=25) où il y a 2 ou 3 centaines de nucléotides délétés dans le V. Le FIneSegmenter échoue à proposer une solution. Il me semblait qu'on avait déjà une issue sur le sujet, mais ...Voici [un exemple](http://app.vidjil.org/?patient=4601&config=25) où il y a 2 ou 3 centaines de nucléotides délétés dans le V. Le FIneSegmenter échoue à proposer une solution. Il me semblait qu'on avait déjà une issue sur le sujet, mais je ne l'ai pas retrouvée (lorsqu'à Lille on avait un patient dans une situation comparable). IgBlast trouve sans problème des solutions pour le V (avec 19 nucléotides dans le V c'est un peu juste pour déterminer duquel il s'agit), le D et le J.
Serait-ce dû à des optimisations pour ne chercher que sur la diagonale ? Peut-on la désactiver si on ne trouve pas de segmentation ?
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2002Configuration trop stringeante sur la recherche du D2022-05-12T11:42:47+02:00Vidjil TeamConfiguration trop stringeante sur la recherche du DExemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutati...Exemple : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2
On prend le gros clone et les petits clones autour. La moitié a un D trouvé, pas l'autre moitié. Le D fait 22bp il n'est pas trouvé dès qu'il y a une erreur/mutation.
***
Alors il y a bien un problème mais il n'a rien à voir. Voir « Le résultat de la segmentation change selon le contexte » #2003
***
Notons que toutes les séquences ici ont normalement le même "multiplier" de E-value (nb de clones analysés).
... et effectivement, il y a bien un problème (de calcul de p-valeur) : cela semble gros qu'une seule mutation sur 22pb fasse tout louper.
***
Surtout qu'il y a une séquence avec une mutation dans le D, où le D est bien trouvé...
***
Seuil de e-valeur pour le D : .05
J'imagine qu'il y a une raison pour cette faible valeur, mais les D sont courts et atteindre de très faibles e-valeur est compliqué (à l'inverse de ce qu'on a avec le kmer segmenteur). Pourquoi le seuil est-il à 0,05 ?
***
@magiraud @mikael-sThonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3275Gaps affine pour deletion_end pour de très grandes délétions2021-04-01T17:37:10+02:00Mathieu GiraudGaps affine pour deletion_end pour de très grandes délétionsLié à #3165.
Il serait apparament simple de changer la fonction qui utilise `deletion_end` :
`if (mode == LocalEndWithSomeDeletions) tbest += cost.deletion_end*(n-j); `
Faudrait-il un gap affine (ou même autre chose) pour permettre ...Lié à #3165.
Il serait apparament simple de changer la fonction qui utilise `deletion_end` :
`if (mode == LocalEndWithSomeDeletions) tbest += cost.deletion_end*(n-j); `
Faudrait-il un gap affine (ou même autre chose) pour permettre de très grandes délétions ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3038dynprog : Avoir une fonction donnant le score maximum et/ou une distance2018-02-08T11:00:09+01:00Mathieu Girauddynprog : Avoir une fonction donnant le score maximum et/ou une distanceVoir bddb09364.
On devrait pouvoir appeler directement un `dp.distance()` ou un `dp.max_score()`.Voir bddb09364.
On devrait pouvoir appeler directement un `dp.distance()` ou un `dp.max_score()`.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2110Favoriser une meilleure distribution des insertions dans le FineSegmenter2017-11-22T12:17:33+01:00Mathieu GiraudFavoriser une meilleure distribution des insertions dans le FineSegmenterTout en restant "déterministe" au sens de Th. Mora, on pourrait avoir un score pour les insertions pour ne pas avoir trop d'insertions trop courtes. "Maximum probability scenario" selon Th. Mora, fait par "Partis" (mais moins bien que "I...Tout en restant "déterministe" au sens de Th. Mora, on pourrait avoir un score pour les insertions pour ne pas avoir trop d'insertions trop courtes. "Maximum probability scenario" selon Th. Mora, fait par "Partis" (mais moins bien que "IGoR").
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1879Seuil pour les D, e-valeur2020-10-14T11:25:55+02:00Vidjil TeamSeuil pour les D, e-valeurVW16: deux écoles.
* 4nt (Hélène ~"PAR-Debré" ), pour éviter de faire un primer qui tombe dedans
* 8nt (c'est bien cela ?), (Frédéric ~"Paris-Pitié" , "vieux papiers")
Et nous, on a dit "euh, 5nt". Sommes-nous confiant dans notre c...VW16: deux écoles.
* 4nt (Hélène ~"PAR-Debré" ), pour éviter de faire un primer qui tombe dedans
* 8nt (c'est bien cela ?), (Frédéric ~"Paris-Pitié" , "vieux papiers")
Et nous, on a dit "euh, 5nt". Sommes-nous confiant dans notre calcul de e-valeur pour les D ?
***
Oui c'est bien cela. Le seuil de 8nt correspond à un seuil immuno pour avoir un D qui ait du sens.
***
segment.cpp, FineSegmenter::FineSegmentD
`float evalue_D = multiplier * (r-l) * germline->rep_4.totalSize() * segment_cost.toPValue(box_DD->score[0].first);`
Ouf, `(r-l) `est bien la taille de la zone considérée.
Calcul à priori correct... sauf qu'il dépend de` .toPValue`, donc de `K` et `lambda` qui sont fixés à la légère (mais qui ne devraient pas changer l'ordre de grandeur)
***
Depuis 2016.08, on peut jouer avec `-E`.
Avec e6ffb91, on a perdu 6 séquences de .should-vdj VDDJ.
Retravailler là-dessus, voir s'il faut des seuils différents pour premier D et D suivants, peut-être retravailler sur le score et/ou K/lambda.
***
ping, voir "Configuration trop stringeante sur la recherche du D" #2002
***
@magiraud @mikael-sAlgo -- ImportantThonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2856Plusieurs configurations pour les coûts2017-11-27T18:44:26+01:00Mathieu GiraudPlusieurs configurations pour les coûtsJ'ai une vague impression que l'on entend deux objectifs contradictoires, qui peuvent dépendre des applications :
- d'un côté, on peut vouloir détecter plus de D (et donc 'plus longs') #1879, #2002, #2298
- de l'autre, on peut préférer...J'ai une vague impression que l'on entend deux objectifs contradictoires, qui peuvent dépendre des applications :
- d'un côté, on peut vouloir détecter plus de D (et donc 'plus longs') #1879, #2002, #2298
- de l'autre, on peut préférer que les V ne soient 'pas trop longs' au niveau de la jonction, #2124, #2825 (et #1408 #1412)
Cela me semblerait bizarre d'étendre au plus les D et de restreindre les V/J.
Si nous n'arrivons pas à tout faire en un seul coup/coût, peut-être qu'une solution serait d'avoir deux configurations (que ce soit ~"cpp-options" ou ~"server-config"). On pourrait en profiter pour être, d'un côté, vraiment stringeant, et, de l'autre, vraiment tolérant.
Au passage, nouveau label ~"cpp-costs", peut-être similaire à ~"bio-e-value", mais pas toujours. En tout cas certaines issues ~"cpp-finesegmenter" / ~"cpp-finesegmenter-D" ne sont pas ~"cpp-costs".https://gitlab.inria.fr/vidjil/vidjil/-/issues/2768Gaps affines pour le FineSegmenter2024-02-06T17:27:21+01:00Mathieu GiraudGaps affines pour le FineSegmenter#1368 s'est conclu fin 2016 par :
> Les gaps affines ne sont pas utilisés pour le FineSegmenter (...). Mais on n'en veut pas nécessairement : le FineSegmenter fait déjà les gaps de délétion à la fin.
Cette justification me semble désor...#1368 s'est conclu fin 2016 par :
> Les gaps affines ne sont pas utilisés pour le FineSegmenter (...). Mais on n'en veut pas nécessairement : le FineSegmenter fait déjà les gaps de délétion à la fin.
Cette justification me semble désormais fumeuse. Si on a des gaps affines, on pourrait aussi s'en servir pour les délétions qui ne sont pas aux extrémités dans le FineSegmenteur. En particulier, on pourrait avoir des délétions de 3 nucléotides ou d'autres choses qui apparaissent.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2124Avoir une meilleure modélisation des délétions à la fin du V et au début du J2021-01-26T13:29:14+01:00Mathieu GiraudAvoir une meilleure modélisation des délétions à la fin du V et au début du JDiscussion du 18 janvier avec @mikael-s et @flothoni
On souhaiterait avoir un meilleur paramètre pour `del_end` pour éviter des mutations proches de la fin, ce qui réduirait les soucis de #2110.
Actuellement, c'est `-1`, dans `const Co...Discussion du 18 janvier avec @mikael-s et @flothoni
On souhaiterait avoir un meilleur paramètre pour `del_end` pour éviter des mutations proches de la fin, ce qui réduirait les soucis de #2110.
Actuellement, c'est `-1`, dans `const Cost VDJ = Cost(+4, -6, -10, -1, -2)`.
Ce qui fait (par rapport au score de `VVVVVV`, six matches parfait en fin de V)
```
del_end = -1 0 +1
1 mutation
VVVVXV -10 VVVVnn -10? -8* -6*
VVVXVV -10 VVVnnn -15 -12* -9*
VVXVVV -10 VVnnnn -20 -16 -12*
VXVVVV -10 Vnnnnn -25 -20 -15
2 mutations
VVVVXXV -20 VVVVnnn -15 -12 -9*
VVVXXVV -20 VVVnnnn -20? -16* -12*
VVXXVVV -20 VVnnnnn -25 -20? -15*
VXXVVVV -20 Vnnnnnn -30 -24 -18*
XXVVVVV -20 nnnnnnn -35 -28 -21
```
- Colonne de gauche: on étend le V autant que possible, en prenant une pénalité `X` pour une subtitution.
- Colonnes de droite: on étend plutôt le N, et donc on a des pénalités `del_end` + on perd le `+4` par position.
`*`: on prend celui-là. `?`: même score que les mutations.
On souhaiterait favoriser `VVVnnn` et peut-être même `VVnnnn`. Des valeurs comme `0` ou même `+1` ont été évoquées. Des valeurs positives permettraient effectivement de diminuer l'attrait des mutations, mais conduiraient à favoriser un `TRGJ1*02` + 3 délétions à la place d’un `TRGJ1*01`.
Ou bien changer le `-6` ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2072Recherche des recombinaisons DDH2021-09-08T17:15:26+02:00Mikaël SalsonRecherche des recombinaisons DDHMail de @flothoni du 01/12 : le germlines.data actuel ne recherche pas de D dans le cas d'une recombinaison DJ. C'est effectivement le cas :
```
"recombinations": [ {
"5": ["IGHD_upstream.fa"],
"3": ["IGHJ...Mail de @flothoni du 01/12 : le germlines.data actuel ne recherche pas de D dans le cas d'une recombinaison DJ. C'est effectivement le cas :
```
"recombinations": [ {
"5": ["IGHD_upstream.fa"],
"3": ["IGHJ.fa"]
}],
```
Est-on d'accord qu'on voudrait le rajouter ? Ou alors seulement si l'option `-d` (recherche de D multiples) est passée ? Mais dans ce cas c'est difficile car impose d'avoir un germline qui dépend d'une option.
@magiraudThonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1971Plusieurs J à la suite : prendre le premier J2018-02-23T12:03:13+01:00Vidjil TeamPlusieurs J à la suite : prendre le premier Jcf. mail de Vincent ~"PAR-Debré" du 09/08/2016 15h13
***
@magiraud @mikael-scf. mail de Vincent ~"PAR-Debré" du 09/08/2016 15h13
***
@magiraud @mikael-s