Tweet
Hi,
I was wondering if anyone else has seen strange behavior with Bowtie's paired-end processing?
I've just started looking at our results recently, and it looks like the "e" parameter is being ignored by the system, resulting in low-quality matches.
For example, the manual indicates that both read alignments from a pair are subject to the v/n/e/l constraints. In our run, we used the "n" alignment mode, and accepted the default "e" value of 70. As I understand it, this means that the sums of the Phred qualities of the mismatches for each read must both be 70 or less.
In practice, this is not the case. The sums in our data vary from 0 to 95 (inclusive). It also does not seem to be the case that only one of the pair mates is subject to the rule, since the sums of the minimum values from each pair range from 0 to 77 (inclusive).
The attached diagram shows the alignment for one of the reads with a mismatch quality sum of 95.
Thanks for your time.
I was wondering if anyone else has seen strange behavior with Bowtie's paired-end processing?
I've just started looking at our results recently, and it looks like the "e" parameter is being ignored by the system, resulting in low-quality matches.
For example, the manual indicates that both read alignments from a pair are subject to the v/n/e/l constraints. In our run, we used the "n" alignment mode, and accepted the default "e" value of 70. As I understand it, this means that the sums of the Phred qualities of the mismatches for each read must both be 70 or less.
In practice, this is not the case. The sums in our data vary from 0 to 95 (inclusive). It also does not seem to be the case that only one of the pair mates is subject to the rule, since the sums of the minimum values from each pair range from 0 to 77 (inclusive).
The attached diagram shows the alignment for one of the reads with a mismatch quality sum of 95.
Thanks for your time.
Comment