I have

samtools flagstat

for my FASTQ file as below (only R1, same numbers for R2 as well):

27029628 + 0 in total (QC-passed reads + QC-failed reads)
27029628 + 0 primary
0 + 0 secondary
0 + 0 supplementary
0 + 0 duplicates
0 + 0 primary duplicates
0 + 0 mapped (0.00% : N/A)
0 + 0 primary mapped (0.00% : N/A)
27029628 + 0 paired in sequencing
27029628 + 0 read1
0 + 0 read2
0 + 0 properly paired (0.00% : N/A)
0 + 0 with itself and mate mapped
0 + 0 singletons (0.00% : N/A)
0 + 0 with mate mapped to a different chr
0 + 0 with mate mapped to a different chr (mapQ>=5)

After processing with

oncoanalyser

, I have the

samtools flagstat

for redux BAM files as below:

59520069 + 0 in total (QC-passed reads + QC-failed reads)
59501038 + 0 primary
0 + 0 secondary
19031 + 0 supplementary
11655993 + 0 duplicates
11653556 + 0 primary duplicates
59461559 + 0 mapped (99.90% : N/A)
59442528 + 0 primary mapped (99.90% : N/A)
59501038 + 0 paired in sequencing
29750519 + 0 read1
29750519 + 0 read2
59155516 + 0 properly paired (99.42% : N/A)
59437080 + 0 with itself and mate mapped
5448 + 0 singletons (0.01% : N/A)
247516 + 0 with mate mapped to a different chr
229968 + 0 with mate mapped to a different chr (mapQ>=5)

I am wondering how the number of reads increased after the alignment, i.e. went from 27M to 29.7M.

Hi Ömer, is this a single lane (with 2 rows) vs a single redux bam (post alignment of that sample) or some other type of comparison?

Yes single lane.

Hi @Ömer An, the difference in read counts here results from consensus read formation in REDUX for duplicate reads

Thanks for the explanation @Stephen Watts, not it’s clear where they come from. However now the question is how these extra consensus reads are affecting the downstream analysis? For example, when picard CollectHsMetrics is run, is the bait/target coverage elevated due to the consensus reads?

I’m not familiar with how CollectHsMetrics works and I don’t have appropriate data to check the behaviour

Actually it does in the (PF_READS), that’s how I discovered this issue, although there is another field for unique reads (PF_UNIQUE_READS). However, my concern is not counting the marked duplicates in the stats, which is good to know the number of duplicates before and after deduplication. My concern is overcounting them, i.e. the marked duplicates are counted and consensus reads are also counted, leading to a higher number of reads than in the original FASTQ if the flags are not considered.