Issue with Bowtie2 mapping

Question

[reza]

I am working on a sets of paired end reads, in first step I trimmed them using Trimmomatic with following command

java -jar trimmomatic-0.36.jar PE 10.10B_R1.gz 10.10B_R2.gz D1R1P.fastq D1R1U.fastq D1R2P.fastq D1R2U.fastq LEADING:5 TRAILING:5 SLIDINGWINDOW:4:20 MINLEN:50

There are 201720569 reads in each output files (D1R1P.fastq and D1R2P.fastq). Then I mapped outputted files to reference genome using Bowtie2

bowtie2 -x reference -1 D1R1P.fastq -2 D1R2P.fastq --un-conc unmapped -S D1.sam

output of Bowtie2 say me this:

98031099 reads; of these:
  98031099 (100.00%) were paired; of these:
    10497294 (10.71%) aligned concordantly 0 times
    73271391 (74.74%) aligned concordantly exactly 1 time
    14262414 (14.55%) aligned concordantly >1 times

…

98.16% overall alignment rate

Why all paired reads are not including in mapping process?

[ATpoint]

...can you show the summary report of trimmomatic? Probably a lot got trimmed away/discarded.

[reza]

i used clean reads to reference mapping, discarded reads by Trimmomatic deposited into D1R1U.fastq and D1R2U.fastq and were ignored from downstream acts.

[ATpoint]

Ok my bad. How did you count the reads in the fastq files?

[reza]

Based on FastQC report, each cleaned files (for. and rev.) have 201720569 but Bowtie2 used 98031099 reads to mapping

[ATpoint]

I would verify this e.g. by awk '{s++}END{print s/4}' file_cleaded.fastq to be sure.

[reza]

Thank you for trying to help me. i have no problem with reads number. Program in each run, show different behaviors, which I think is due to the existence of a bug.

[ATpoint]

Unlikely, we're talking about two of the most established and widely used bioinformatic tools out there.