wrong report of reads processed when "-k" is used in Bowtie 1.2.1.1

[ndaniel]

It looks like Bowtie 1.2.1.1. (the pre-built binaries for x64 Linux) reports wrongly the number of processed when the command line parameter -k is used.

Here is how it can be reproduced:

wget ftp://ftp.ensembl.org/pub/release-81/fasta/homo_sapiens/cdna/Homo_sapiens.GRCh38.cdna.all.fa.gz

wget https://sourceforge.net/projects/fusioncatcher/files/test/reads_1.fq.gz

gzip -d *.gz

mkdir transcriptome

/tools/bowtie-1.2/bowtie-build \
-f \
--quiet \
--offrate 1 \
--ftabchars 7 \
Homo_sapiens.GRCh38.cdna.all.fa \
transcriptome/

When running bowtie 1.2 as follows:

/tools/bowtie-1.2/bowtie \
-k 10 \
transcriptome/ \
reads_1.fq  \
b12.map

one has:

# reads processed: 12546
# reads with at least one reported alignment: 11906 (94.90%)
# reads that failed to align: 640 (5.10%)
Reported 77282 alignments to 1 output stream(s)

When running bowtie 1.2.1.1. as follows:

/tools/bowtie-1.2.1.1/bowtie \
-k 10 \
transcriptome/ \
reads_1.fq  \
b1211.map

one has:

# reads processed: 77922
# reads with at least one reported alignment: 77282 (99.18%)
# reads that failed to align: 640 (0.82%)
Reported 77282 alignments to 1 output stream(s)

The input FASTQ file reads_1.fq has 12546 reads and not 77922 as Bowtie 1.2.1.1 reports!

When running bowtie 1.2.1.1 without -k then it reports correctly the number of reads processed

/tools/bowtie-1.2.1.1/bowtie \
transcriptome/ \
reads_1.fq  \
b1211_.map

one has:

# reads processed: 12546
# reads with at least one reported alignment: 11906 (94.90%)
# reads that failed to align: 640 (5.10%)
Reported 11906 alignments to 1 output stream(s)

This bug might be related to #54 .

[BenLangmead]

Rone: Please take a look when you get a chance. As the poster says, it's likely this is related to the earlier issue. We should think about how to test accuracy of the alignment rate reports in the automated test suite.

[ch4rr0]

I may have found a solution but I first need to discuss with Ben before pushing. Unfortunately this issue is unrelated to issue #54.