High Variability when Peak Calling with SEACR

Question

[hunter.a.ogg]

I have recently been comparing a few peak callers for our group CUT&RUN experiments. We are performing our experiments with antibodies against a broad and a narrow histone modification (H3K9Me3 and H3K27Ac respectively) in a non-model organism.

When testing SEACR, we noticed it seemed incredibly inconsistent. While the number of peaks for MACS2 would be fairly consistent between samples (generally between 6000 and 9000 peaks), SEACR varied greatly. It would call nearly 60,000 peaks for some acetylated samples while calling less than a dozen in others. This behavior could be altered drastically simply by using different input samples from replicates of the same biological condition, with samples that previously had next to no peaks suddenly having more than 10,000.

For H3K9Me3 and nonspecific IgG, peaks called were generally a few dozen although some methylated samples could reach a few hundred.

Input samples were used when calling peaks in all cases for both MACS2 and SEACR. Both the relaxed and stringent parameters were tested for SEACR, as well as a variety of parameters for MACS2.

Has anyone had similar experience with high levels of variability in peak calls with SEACR? Is there any way to reduce the variability when using SEACR or would it be recommended to stick with a more traditional peak caller such as MACS2 when using CUT&RUN on histone modifications? Are there any recommendations regarding preprocessing of aligned reads before passing them to SEACR?

Answer 1

[jared.andrews07]

In my hands, SEACR has similarly been all over the place and is very dependent on data quality. If you have much background at all it tends to go haywire. While everyone seems to act like CUT&RUN is the cleanest thing ever, we've found it to be quite antibody dependent. MACS is easier to adjust to get reasonable results with IMO.

6-9k peaks for H3K27ac is quite low though (at least in human/mouse samples), so I'd be wary of data quality and eyeball it to see how things look.

After fiddling with SEACR a bit, we've pretty much chucked it in the bin in favor of MACS since it generally just works and can deal with some background without crapping the bed.

[RD]

Hi Jared, I’m trying to figure out the right parameters to use with MACS3 for CUT&RUN data. My understanding is that it’s best to convert the BAM file to BEDPE format and run MACS3 with the parameters: --keep-dup all --nomodel --shift -100 --extsize 200 This way, MACS3 treats each paired-end fragment as a single unit.

However, I’m wondering if it would be better to instead convert the data to BED format (where each paired read is split into two single reads) and then run MACS3 with bed mode. Could you clarify which approach is more appropriate for CUT&RUN peak calling?

jared.andrews07