#311 Results on reverse complement reads

[Francesca Cordero]

Dear developer,

I have a question about a results obtained by Bowtie2. Considering the following two reads:

@seq1
AGGACCTCTTAAAATCATCAAGGACCCCAAAAAGCTTTGGGTATTGGTGGGT
+
981/959//)///)/7798:4:088;;2;??>-:777+5=3::;050599/9
@seq1_R
ACCCACCAATACCCAAAGCTTTTTGGGGTCCTTGATGATTTTAAGAGGTCCT
+
9/995050;::3=5+777:->??;2;;880:4:8977/)///)//959/189

It's a simple example in which "seq1_R" is the reverse complement of "seq1". If I run Bowtie2 using the following command line:

./bowtie2 -x /home/Data/Reference/hg19 -U ./test.fq --un ./unAligntest -q -p 13 -S ./test.sam -a

I obtain the following result:

seq1 4 * 0 0 * * 0 0 AGGACCTCTTAAAATCATCAAGGACCCCAAAAAGCTTTGGGTATTGGTGGGT 981/959//)///)/7798:4:088;;2;??>-:777+5=3::;050599/9 YT:Z:UU
seq1_R 0 chr6 33268929 255 6M2I6M1D24M1D14M * 0 0 ACCCACCAATACCCAAAGCTTTTTGGGGTCCTTGATGATTTTAAGAGGTCCT 9/995050;::3=5+777:->??;2;;880:4:8977/)///)//959/189 AS:i:-27 XN:i:0 XM:i:0 XO:i:3 XG:i:4 NM:i:4 MD:Z:12^A24^T14 YT:Z:UU

seq1_R maps, even if with a bad score, in a position 33268929 of chr6. Otherwise seq1 is unmapped. I was thinking that seq1 maps in the same genomic location of seq1_R but with a flag equal to 16. Why I obtain this result?

[Ben Langmead]

Hi Francesca,

Bowtie 2 is not guaranteed to find all valid alignments. It uses heuristics (filters) that cause it not to "see" some alignments. In the case of Bowtie 2, some substrings of the read have to match exactly in order for Bowtie 2 to find the overall alignment. The substrings are selected at intervals along the read starting from the left-hand side. When you reverse complemented your read, that changed the positioning of those substrings, and you got a different result.

Increasing the sensitivity (e.g. --very-sensitive) will tend to recover the lost alignments.

Hope this helps,
Ben