new junction predicted rather than 4bp deletion

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run breseq on REL2042 (.gd file in dcamp RS0009_TemperatureEvoloved)

What is the expected output? What do you see instead?
a 4bp deletion should be produced
DEL     .       10001   REL606  4508284 4
I have verified this with traditional sequencing

instead unassigned new junction evidence at 3574371 and 4508294 manual 
inspection of the 4508294 junction clearly shows 4bp deletion. 

What version of the product are you using? On what operating system?
breseq  version 0.17e  revision cc27e51c6613 on ranger

Please provide any additional information below.
not sure if this is unique to this particular case, or if this is part of a 
larger problem with small deletions being miscalled as deletions.

Dan

Original issue reported on code.google.com by Daniel.D...@gmail.com on 7 Jun 2012 at 8:14

[GoogleCodeExporter]

I'm working on this.

Original comment by jeffrey....@gmail.com on 22 Jun 2012 at 2:07

• Changed state: Accepted

[GoogleCodeExporter]

This is a problem with SSAHA2 mapping. It doesn't catch one of the other 
mappings even though it could.

Original comment by jeffrey....@gmail.com on 23 Jun 2012 at 2:28

[GoogleCodeExporter]

This can be fixed by lowering the minimum score allowed from SSAHA2 alignment 
from 12 to 6. (However this results in many other spurious junction predictions 
in this data set due to the issue of not masking off the ends of Illumina reads 
marked as bad.)

Original comment by jeffrey....@gmail.com on 24 Jun 2012 at 3:00

[GoogleCodeExporter]

Fixed with major change to using Bowtie2 for mapping/alignment.

Original comment by jeffrey....@gmail.com on 11 Jul 2012 at 1:40

• Changed state: Fixed