how to know the strands of MACS call peaks

Question

[catherine]

I want to create a heatmap for chip-seq data by Homer program (http://homer.salk.edu/homer/ngs/quantification.html)

The command is like this:

annotatePeaks.pl <peak file> <genome> -size <#> -hist <#> -ghist -d <tag directory 1> [tag directory2] ... > <output matrix file>

My problem is the peak file. it requires a bed file with a column of peak strand.

BED files should have at minimum 6 columns (separated by TABs, additional columns will be ignored)

• Column1: chromosome
• Column2: starting position
• Column3: ending position
• Column4: Unique Peak ID
• Column5: not used
• Column6: Strand (+/- or 0/1, where 0="+", 1="-")

But I used MACS to call the peaks, where the algorithm is combined two peaks from both directions into one. So there is no such info as strands (If my understanding is correct).

Can anyone tell me how to solve this issue? Can I just assume all the peaks are from either one of the strands?

Thank you

[Devon Ryan]

Do you really want to trust the output of any program that thinks strand is always (or even usually) a biologically meaningful concept in ChIPseq for the purposes of annotating gene/feature proximity?

I wouldn't.

Answer 1

[Jennifer Hillman Jackson]

Hi Catherine,

HOMER's "findPeaks" tool will accept input from sequencing runs that are strand-specific. This is why the value is included in the file specifications. But the default when calling peaks is to use "BOTH", which can be interpreted as all peak calls being unstranded (merged). HOMER interprets these as a strand assignment of "0" (translates to +).

In BED files, a dot "." can be used successfully with many tools to represent a "NULL" value for strand (this defaults to "+" when used with some tools). I would give this a try first, but I am not certain if it will work since I haven't tried it. So give it a test. If it doesn't work, just use "+" for all entries in your BED file.

When converting BED to a Peak file (using the tool provided in the HOMER tool suite), the "+" will be converted to "0". This is a good idea to do, since some of the tools in this package only work with strand annotated with "0" or "1". The start coordinate value will also be modified to have a 1-based start, instead of the 0-based start used in BED format.

To my knowledge, stand will not even be considered by many of the functions in HOMER, so I wouldn't worry too much about setting this value to "+" or "0"

Hope this works out for you! Jen