Question About Handling Technical Replicates in ATAC-seq

Question

[LuciaNhu]

Hi ATAC-seq team,

Thank you for the great work in building such a wonderful pipeline!

I have a question regarding technical replicates. I have 11 samples, each with 2 technical replicates. Each replicate was prepared using a separate library, but with the same protocol and sequencing machine.

When I process them individually, their FRiP scores differ—one is about 0.2 higher, and the other is about 0.2 lower. The coverage between the replicates is also inconsistent.

My questions are:

• Should I merge these replicates?
• If yes, should the merging be done at the FASTQ level, BAM level, or peak level (e.g., overlapping peaks)?
• What are the advantages and disadvantages of merging at each of these levels?
• Additionally, is FRiP (Fraction of Reads in Peaks) conceptually similar to fracOverlap in featureCounts?

Thank you in advance for your help!

Best regards,
Nhu

Answer 1

[rfran010]

Should I merge these replicates? If yes, should the merging be done at the FASTQ level, BAM level, or peak level (e.g., overlapping peaks)? What are the advantages and disadvantages of merging at each of these levels?

Were they prepared in parallel or in independent experiments. If prepared in parallel, there is little explanation for variation, so merging them regardless of how well they agree would make sense. Plus, you don't have a third to know if one is just wonky.

If prepared in separate batches, then I would check how well they match each other. If they match well (e.g. metaplots/heatmaps/correlation), I would say merge them. Otherwise, you can analyze them separately and see if they have the same trends.

Merging at fastq or bam level should be similar. The consideration here is sequencing depth. If you have one library with double the amount of reads, it will be overrepresented to the other. You can downsample to solve that. I think this makes more sense when treating them as technical replicates. If prepared in separate batches, then perhaps just take common peaks, so "merge" at peak level, although officially that wouldn't be a merge, but an intersection or something.

Additionally, is FRiP (Fraction of Reads in Peaks) conceptually similar to fracOverlap in featureCounts?

I would say no. FRiP counts all reads that overlap the peak, so if you have 10/100 reads overlapping the peak, that would be 10%. fracOverlap would define how those reads are counted. For example, should you count a read if only one base overlaps the peak regions, or should you require 50% of the read to overlap. So it is the number of bases that overlap the peak divided by the total number of bases in the read. This could change the FRiP number, as a higher fracOverlap requirement would be expected to lower the FRiP since less reads would pass the filter.