MeDIP-seq versus ChIP-seq analyses?

[jjw14]

I've shortened my previous post in hopes of getting a response:

- I am mapping MeDIP sequence reads (Illumina GAII) with Bowtie and using MACS for peak finding.
- Question 1: Should only unique reads be mapped?
- Question 2: How does the pattern/shape of peaks compare between MeDIP-seq and ChiP-seq?

Thanks.

jjw

[jjw14]

Bumping shorter version of original post. Apologies if this is bad form. Just looking for a bit of advice. Much appreciated.
jjw

[mattanswers]

I would think that only unique reads should be mapped because if you map reads which match to multiple locations then you would not be sure about any resulting patterns.

[simonandrews]

MeDIP-Seq is just another form of ChIP-Seq so in crude terms you can use the same techniques as you'd apply to ChIP-Seq to analyse MeDIP data. What I suspect you really want to know if if you should expect that the peaks you see in MeDIP should look like nice small independent events that many of the peak finders expect.

In our experience we see two kinds of enrichment in MeDIP data, there are small, highly enriched events which are very easy to identify and then there are slightly more diffuse, lower enrichment events which can be harder to pick out. The majority of reads will sit in the highly enriched peaks, and looking at these is a good place to start, but there may be some value in looking at the lower levels of enrichment.

[jjw14]

Thanks very much. Your description of the "independent peaks" or peak "frequency" for MeDIP versus ChIP is exactly the type information I was interested in.

I'm using MACS for peak detection. Do you feel there is a more appropriate algorithm for MeDIP peak detection, especially for the areas of low enrichment you describe?

Much appreciated,
jjw

[jjw14]

Thanks for the response. I appreciate it.
jjw

I would think that only unique reads should be mapped because if you map reads which match to multiple locations then you would not be sure about any resulting patterns.

[simonandrews]

We do our analysis within SeqMonk (which we write, so we're somewhat biased!) rather than using an external peak caller.

Normally we'd use the contig based probe generator to do the cluster detection. This allows you to set an enrichment threshold and build clusters where your reads exceed this threshold. There are then facilities for merging adjacent peaks or rejecting enriched regions which are too short. We find that this kind of approach lends itself well to more unusual ChIP experiments where the shape of the peaks might not be what you'd expect from a traditional 'transcription factor' type enrichment.

[jjw14]

Great information. I had actually downloaded the SeqMonk dmg to my Mac about two weeks ago, but wasn't sure if I had enough RAM (4 GB) to run it, so I defaulted to using the available tools on our campus Linux cluster. I see the SeqMonk readme file describes how to change the memory limits in OS X. I may also see if I can get SeqMonk installed on our Linux cluster.

I'll try the sample data file provided on your web site with some of the cluster detection methods you describe. Thank you for providing this resource, and I'll gladly acknowledge your assistance in any publication/report that (hopefully!) is produced.

jjw

[simonandrews]

The standard SeqMonk install assumes a 32-bit machine with 2GB RAM. You can configure it to use more than this, but for modestly sized experiments (up to 10 lanes or so) this shouldn't be necessary. The software is designed to run on desktop machines - I wouldn't see much advantage to installing it on a node of a cluster.