Hi, I noticed that the Qualimap reports calculate ...
# methylseq
d
Hi, I noticed that the Qualimap reports calculate coverage including duplicate reads. Was this a deliberate choice, or is there a reason why Picard/MarkDuplicates-flagged reads aren’t excluded by default?
p
Off the top of my head, so take with a pinch of salt as it's been a while, I think that bismark deduplicates after the alignment step.
So I think that the reads are excluded by default, just not at the time that qualimap runs
Caveat: I might be talking rubbish 😅
d
I forgot to mention that I was running taps and bwa-meth branches of the workflow. I guess, it shouldn’t affect bismark branch due to deduplication step but in other branches qualimap doesn’t exclude picard’s markduplicates. I checked yesterday by rerunning qualimap manually by adding
Copy code
--skip-duplicated --skip-dup-mode 0
in addition to the default parameters and compared with default results. By default qualimap picks up duplicates but doesn’t remove them from the coverage calculations, while by adding options I mentioned above drops the coverage. I could create a PR and add these options :)
p
Qualimap is only a reporting / QC step, not preprocessing as I remember? In both branches I think.
image.png
Does the bwa-meth arm not run Picard MarkDups ?
(looks like I was wrong based on this graph btw, Qualimap does run after bismark dedup and not before)
I guess to take a step back: are you sure that deduplication isn't being honoured in your results? It might be that they're being marked and ignored in the bisulfite calling steps, even if the reads are still there in the BAM file. In which case, marked is basically functionally the same as removed, and removal gives relatively little advantage?
d
Yes, qualimap doesn’t do any preprocessing, just qc reporting. So, I’m only concerned about qualimap’s reported coverage as it doesn’t include markduplicates, otherwise this doesn’t affect any downstream tasks.