Why the duplicated reads should be removed before peak calling?

[Han-Qin Zheng]

Hello:

I know that duplicated reads caused by PCR effect (including library construction and sequencing) may produce artifact in peak calling. However, the actual biological signal of duplicated reads may be contained in those duplicated reads. And those actual signal should not be removed in my concept.

Why the duplicated reads should be removed before peak calling? Different sequencing depth between input and ChIP, or others? Please tell me in detail.

Otherwise, some peak caller (i.g. MACS2) give pileup height and fold enrichment of peak summit in MACS2 result. And I know phantompeakqualtools (SPP) does not give these information. If I want to get these information, what should I do? 

Thank you

[Anshul Kundaje]

If your library complexity is high you don't need to remove duplicates. But we see a lot of variation in library complexity across datasets in the wild. So to make things more uniform we remove dups by default.

We can add an option to not remove dups in the AQUAS pipeline. @Jinlee - Can you add such an option

If you want fold-enrichment or pile up height - you have 2 options

a. Our pipeline computes fold enrichment genome-wide signal bigwig tracks. So you can easily extract fold-enrichment for peak regions (or any regions) from these

b. You can use MACS2 as the peak caller instead of SPP. But I dont recommend this since MACS2's peak scores/ranks do not have as good rank consistency/reproducibility and show strange artifacts.

Anshul 

--
You received this message because you are subscribed to the Google Groups "idr-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idr-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anshul Kundaje]

Great. There we go. Premonition :)

-Anshul.

On Tue, Feb 14, 2017 at 11:11 AM, Jin <lee...@gmail.com> wrote:

Such option (-no_dup_removal) is already added to the pipeline a few days ago.

Thanks,

Jin