Hi @Kevin Brockers, Thanks a lot for your feedback! I would definitely be happy to go with option A. My main objective with atacportray has always been to make these additional layers of information routinely accessible from bulk ATAC-seq data, rather than to create a separate pipeline at all costs. If extending the existing nf-core/atacseq pipeline is the most useful and maintainable way to achieve this within nf-core, that makes perfect sense to me. I also agree that this would avoid unnecessary duplication between two pipelines and, importantly, would provide users with a single workflow going from raw ATAC-seq reads to a much broader molecular characterization of their samples. I already have a functional implementation of the proposed analyses, including the different genomic and regulatory branches, so hopefully a substantial part of the work can be reused/adapted rather than starting from scratch. The different downstream analyses were deliberately designed to be optional and largely independent, which should also make their integration into atacseq easier. One thing I should mention, though, is that I am still very new to nf-core pipeline development. atacportray has actually been my first real experience developing a pipeline within the nf-core framework. So while I now have the different analyses implemented and working, I don't yet have a good sense of how much work would be involved in integrating what I have built into an existing and established pipeline like atacseq, or what the best way to approach that integration would be. I would therefore definitely appreciate some guidance from you, @Jose Espinosa-Carrasco and the atacseq developers on that side of things. But from my side: definitely A, and very happy to work together on it! 🙂 Cheers, Pef

Really like it! and agree those additions will nicely enhance the pipeline. I'm up to joining forces to get things implemented, there has also been a request for umi containing libraries, so we could think of this as well. Potentially let's wait until Jose is back from his vacation and we schedule a meeting with him to sort things 🙂 In the meantime, are your proposed tools already available as nf-core components? If not you could start to create some nf-core modules already -> nf-co.re/docs/contributing/contribute-components & nf-co.re/docs/developing/components/creating-components

Hi @Kevin Brockers! Thank you, that sounds great. I would be very happy to join forces, and I agree that it makes sense to wait until Jose is back so that we can discuss the scope together, including support for UMI-containing libraries. In the meantime, I have started contributing the missing nf-core components. The following modules are now implemented in my fork of

nf-core/modules

, with local Docker

nf-test

validation and clean

nf-core modules lint

results: • `nucleoatac/run`: github.com/nf-core/modules/pull/12915 • `telomerehunter2`: github.com/nf-core/modules/pull/12917 • `mgatk/call`: github.com/nf-core/modules/pull/12919 • `tobias/atacorrect`: github.com/nf-core/modules/pull/12921 • `tobias/scorebigwig`: github.com/nf-core/modules/pull/12923 • `tobias/bindetect`: github.com/nf-core/modules/pull/12925 The goal is to keep each tool modular and reusable, then assemble them as optional downstream functionality within

nf-core/atacseq

. I would very much welcome your and Jose’s feedback on the most useful scope and integration strategy before we move further. Cheers !

Sounds like a plan! Great that you already started to integrate the modules, I that's highly appreciated! Are you already a member of the nf-core organization on github? If not potentially join here: #CEB982K2T. I think then CI will trigger automatically in the future. I can have a look at your PRs in the next days. Just ping me in case I forget 😅

Thx a lot for your guidance. I am a contributor now :-) But since everything is completely new to me, i would really appreciate if you can review my PR anyway, at least at the beginning and whenever you have time, to avoid any mistakes on my side. Thx a lot again for your help !

Sure! I think I'm by far not error free but sure, I will have a look at it.

Hi, @pierre-francois.roux and thanks for the proposal, sorry fo the late reply I think your proposal makes a lot of sense, my only concern is that at some point we decided that all the downstream analyses should be drop out from this pipeline. So not sure whether we should implement a different pipeline instead and only modify #CE5EL6326 to be able to produce the input data necessary for atacportray, maybe @Phil Ewels opinion will be also relevant here

You mean for #C045UNCS5R9 @Jose Espinosa-Carrasco? I think that was mostly because that downstream analysis was shared between multiple pipelines, so we would have less duplication and more shared maintenance effort as a separate pipeline.

Thanks @Jose Espinosa-Carrasco and @Phil Ewels! Yes, I would consider the proposed functionality to be ATAC-seq specific, even though some of the individual tools are obviously not. The idea is really to exploit the particular information content of ATAC-seq libraries beyond accessibility, and the genomic applications were specifically benchmarked against matched WGS in our recent work. Since all these additional branches are optional and largely independent, my preference would indeed be to integrate them directly into

nf-core/atacseq

without changing its default behaviour. But I'm very happy to follow your guidance on the best architecture and implementation strategy — I'm still learning the nf-core ecosystem! 🙂

Hi all, @Jose Espinosa-Carrasco / @Phil Ewels sounds as we found a consensus? May I suggest we stick with @pierre-francois.roux suggestion for now: adding those proposed new features as

optional

atacseq specific downstream analysis steps? Would that work for everyone? If so, we could close @pierre-francois.roux pipeline proposal for now and kick things off? I created an #C0C30LAV0G7 channel where we can discuss the implementation further. I think Jose is still on vacation so @pierre-francois.roux we can start and get things going in the meantime.

Yup, if everyone is happy then we close the proposal as "not planned" with a note 👍🏻