New version of IDR code

[Anshul Kundaje]

Hi All,

We now have a beta version of the new IDR code https://github.com/nboley/idr . Thanks to my postdoc Nathan Boley for working on this. And thanks to Prof. Peter Bickel for his help.

It is significantly faster than the previous version and has some changes in the core algorithm as well to make the results more stable (especially in weird boundary conditions).

Its important to note that the new version may not generate the exact same output as the older version of the code for the same IDR threshold. This version is generally more stringent. So we recommend relaxing the IDR thresholds a bit e.g. if you were previously using 0.01 or 0.02 then in this version you might want to use 0.05

Please give it a spin and give us any feedback you might have. Remember this is a beta release (but stable) .. Its possible that it might change a bit (mostly cosmetic changes) in the near future.

Thanks,

Anshul.

[Sergio Espeso Gil]

Thanks!

I will try!!

By the way, I liked the pdf documentation where you could see a plot of an ideal case and a bad example of reproducibility. It was at the end of the pdf of the short version, but the link is broken:    http://www.stat.washington.edu/qli/IDR-AOAS.pdf

Could you please post it again? Or give a new link?

Thanks again! Kind regards,

Sergio.

[Davide Cittaro]

Does it work on broad peaks? analysis of such peaks was discouraged in previous version, but now I see there's the support for broadPeak format...

[Anshul Kundaje]

No. As in its the same problem as before that broad peaks have very poorly calibrated scores from most peak callers. So you can't use IDR naively with these. We will be releasing a broad peak pipeline in 2 months. Stay tuned.

Anshul

On Jun 18, 2015 2:49 AM, "Davide Cittaro" <cittaro...@gmail.com> wrote:

Does it work on broad peaks? analysis of such peaks was discouraged in previous version, but now I see there's the support for broadPeak format...

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Davide Cittaro]

On Thursday, June 18, 2015 at 11:56:08 AM UTC+2, Anshul Kundaje wrote:

No. As in its the same problem as before that broad peaks have very poorly calibrated scores from most peak callers. So you can't use IDR naively with these. We will be releasing a broad peak pipeline in 2 months. Stay tuned.

Good to know. Do you have any recommendation to try a idr-like approach on H3K27me3 data?

FYI: I've been trying to run it anyway and I got nice validation in terms of corresponding RNA data, at least for h3k27me3 peaks located at promoters 

[Anshul Kundaje]

Good to hear. It will work in cases where replicates are truly very similar and sequenced to similar depths. It's in the more challenging situations where it can do weird things if used naively. That's the part we are trying to fix and are pretty close to figuring out. More soon ...

Anshul

--

[Davide Cittaro]

On Tuesday, June 23, 2015 at 5:06:58 AM UTC+2, Anshul Kundaje wrote:

Good to hear. It will work in cases where replicates are truly very similar and sequenced to similar depths. It's in the more challenging situations where it can do weird things if used naively. That's the part we are trying to fix and are pretty close to figuring out. More soon ...

Uhm, that explains a lot of things. I've tested self-consistency in two H3K27me3 experiments. In order to do that I had to create pseudo-replicates which, in principle, contain mostly similar data. Each analysis was ran on different treatments and evidently resulted in a self-consisten list of k27 peaks for each group. The differential analysis made the rest: I've compared only most consistent peaks in different conditions.