junction location does not agree with sequence

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run breseq on REL8593B
2. predicts unassigned new junction at 23843.
3. evidence of the new junction has the sequence: 
CTTATGAGCCTGCTGTCACCCTTTGACGTGGTGAT as mapping from 23809-23843.
4. Blast the above sequence against REL606 and it maps to 23795-23829.
5. bam2aln and bam2cov (table) functions used for 23809-23843 give the correct 
REL606 sequence for that location, not the sequence listed as evidence of the 
new junction.

What is the expected output? What do you see instead?
would expect the sequence and the location to agree with each other

What version of the product are you using? On what operating system?
breseq  version 0.19  revision 2e63a8abbf52 
TACC - lonestar

Please provide any additional information below.
same issue for jc4 predicted new junction at 226690‑226724 with seq of 
ACGGTAACAGGAAACAGCTTGCTGTTTCGCTGACG. Blast of that sequence places it at 226674 
- 226708. Other junctions from the same sample are mapping correctly

Original issue reported on code.google.com by Daniel.D...@gmail.com on 10 Sep 2012 at 4:21

Attachments:

• REL8593B.tar.gz

[GoogleCodeExporter]

Possibly a better example and/or more important issue:
Breseq run on REL10950
predicts 2bp deletion at 3,483,361
map any of the reads that span the new junction and it is clearly a 4bp 
deletion, not a 2bp deletion.

possible cause is the left side of the junction incorrectly maps 2bp off while 
the right side of junction correctly maps?

attached output folder for 10950 run

Original comment by Daniel.D...@gmail.com on 11 Sep 2012 at 2:23

Attachments:

• REL10950.tar.gz

[GoogleCodeExporter]

First issue, it appears that we are not accounting for overlap in our 
start_1-end_1 values in the html. Will see how we want to update that.

Original comment by Geoffrey...@gmail.com on 11 Sep 2012 at 5:25

[GoogleCodeExporter]

Incorrect mutation prediction and html sequences have been resolved with 
revision e0f9e4cb57a3. As of revision 5329363f2122 the unassigned junction 
predictions found in REL8593B will no longer be predicted due to a majority of 
the reads supporting that junction failing one of our quality checks.

Thanks Dan!

Original comment by Geoffrey...@gmail.com on 14 Sep 2012 at 6:06

[GoogleCodeExporter]

Original comment by Geoffrey...@gmail.com on 14 Sep 2012 at 6:07

• Changed state: Fixed

[GoogleCodeExporter]

We should add a function that checks the displayed junction sequence in output 
alignment files against the reference sequence for the coords it is quoting. 
This could help find future hard bugs of this type.

Original comment by jeffrey....@gmail.com on 14 Sep 2012 at 6:28

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by jeffrey....@gmail.com on 23 Dec 2012 at 8:49

• Changed state: Fixed