Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add IDR analysis #87

Open
drpatelh opened this issue May 30, 2019 · 5 comments
Open

Add IDR analysis #87

drpatelh opened this issue May 30, 2019 · 5 comments
Labels
feature-request Request to add new functionality
Milestone

Comments

@drpatelh
Copy link
Member

Would be nice to add the IDR analysis that is currently carried out by the ENCODE pipelines:
https://github.com/kundajelab/atac-seq-pipeline
https://docs.google.com/document/d/1f0Cm4vRyDQDu0bMehHD7P7KOMxTOP-HiNoIvL1VcBt8/edit

Another implementation in NF:
https://github.com/DoaneAS/atacflow

ENCODE ATAC-seq Guidelines:
https://www.encodeproject.org/atac-seq/

Amongst other things, this will probably also involve creating pseudo-replicates by merging and equally sampling alignments across replicates.

See: nf-core/atacseq#36

@drpatelh drpatelh added the feature-request Request to add new functionality label Jun 26, 2019
@JoseEspinosa JoseEspinosa added this to the 2.0 milestone Sep 23, 2021
@JoseEspinosa
Copy link
Member

This one could be also relevant for the implementation of the IDR analysis specifically for ChIP-seq analysis, implemented in NF:
https://github.com/bioinfo-pf-curie/chip-seq

@drpatelh
Copy link
Member Author

We would need to think about how we define "replicates" here to use that right? Now that we have removed the replicate column from the samplesheet. Maybe we can have an optional column for replicates in the samplesheet for this kind of thing? 🤔

@JoseEspinosa
Copy link
Member

Yes, that could be an option, another one could be to have a separate file with the information about replicates... In the case we want to keep the samplesheet standard across pipelines

@drpatelh
Copy link
Member Author

I did think about having a separate metadata file but why?! Keep it simple and have one would be my preference.

@JoseEspinosa
Copy link
Member

Yes, I agree two metadata files means increasing at least 2x the possibility of making mistakes 😝

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request to add new functionality
Projects
None yet
Development

No branches or pull requests

2 participants