tophat2/bowtie2 inconsistency in number of unmapped reads
 

We are using the tophat-cufflinks pipeline for RNA seq. With tophat1-bowtie1 mapping, the reads are mapped initially to the predicted transcriptome and then unmapped reads are mapped to the genome to identify splice junctions. So the number of unmapped reads from the initial mapping (see bowtie.left_kept_reads.fixmap.log below) are carried to the next mapping (see bowtie.left_kept_reads.m2g_um.fixmap.log below; I believe m2g_um stands for map to gtf unmapped)

bowtie.left_kept_reads.fixmap.log
# reads processed: 1761894
# reads with at least one reported alignment: 1334963 (75.77%)
# reads that failed to align: 413755 (23.48%)
# reads with alignments suppressed due to -m: 13176 (0.75%)
Reported 2240278 alignments to 1 output stream(s)

bowtie.left_kept_reads.m2g_um.fixmap.log
# reads processed: 413755
# reads with at least one reported alignment: 169629 (41.00%)
# reads that failed to align: 241180 (58.29%)
# reads with alignments suppressed due to -m: 2946 (0.71%)
Reported 184162 alignments to 1 output stream(s)

However, when we try the same dataset with tophat2-bowtie2, the read counts don't seem to match. Mapping parameters are identical (zero mismatches, zero indels). However, the unmapped reads in the first mapping (bowtie.left_kept_reads.fixmap.log) is different from what the second mapping starts with (bowtie.left_kept_reads.m2g_um.fixmap.log).

bowtie.left_kept_reads.fixmap.log
1761894 reads; of these: 1761894 (100.00%) were unpaired; of these:
223293 (12.67%) aligned 0 times
468278 (26.58%) aligned exactly 1 time
1070323 (60.75%) aligned >1 times
87.33% overall alignment rate

bowtie.left_kept_reads.m2g_um.fixmap.log
413755 reads; of these: 413755 (100.00%) were unpaired; of these:
72334 (17.48%) aligned 0 times
190748 (46.10%) aligned exactly 1 time
150673 (36.42%) aligned >1 times
82.52% overall alignment rate

Any of you have any explanations? Thanks for your time!!

I am also looking forward to the explanation. Recently, I also face this problem: http://seqanswers.com/forums/showthread.php?t=21663

@liueagle, it appears that since bowtie2 by default allows less stringent matching (e.g. gaps), the number of mapped reads is higher, but tophat perhaps checks them and makes sure they meet the criteria. Due to the repeated release of betas for cufflinks2, we have put on hold the tophat2-cufflinks2 pipeline and instead are using the stable release tophat1-cufflinks1.