Mauvais alignement du J : check_and_resolve_overlap() et alignements curieux localement
Dans !148 (comment 99705) un alignement étrange est observé pour (7efab5bb) :
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 AACAACACTTGTTGTCACAGGTAAGTATCJe 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.faPing @magiraud