Hi atacseq channel!

I am using your lovely pipeline. I am wondering how i can control max mem for the pipeline

i hit a memory error and it shut everything down including my srun interactive session 😞

i am happy to provide more info if someone wants to assist me in my struggles 🙂

you should be able to use the max_memory params for this

cf https://nf-co.re/atacseq/2.1.2/parameters/#max_memory (you probably need to check

show hidden

) on the right hand side

I wonder if the latest version has the option to create a CSI index for BAM files instead of the traditional BAI index, which is required for genomes with large chromosomes

Hello, due to some limitations, I could only run nf-core/atacseq on a MacBook with 8 cores and 8 GB of memory. I added

-profile arm

to my command and nextflow.config in my working directory:

process {
  resourceLimits = [
    cpus: 8,
    memory: 8.GB
  ]
}

Everything worked well until SAMTOOLS_SORT, where I kept encountering error exit status (137), so I assume there was still an out of memory issue. (Also tried adding

--max_memory 8GB

to my command but didn't work as well.) Is there any chance I could bypass this error? Thank you.

Hello! I have just started trying to run the ATAC-seq pipeline locally on my computer and found that trimming was taking a rather long time. In particular, it seemed like the FastQC part of TrimGalore was only running on a single core. In

atacseq/modules/nf-core/trimgalore/main.nf

, the paired-end command for

trim_galore

is:

trim_galore \\
            $args \\
            --cores $cores \\
            --paired \\
            --gzip \\
            ${prefix}_1.fastq.gz \\
            ${prefix}_2.fastq.gz

Checking the TrimGalore manual, it implies that the

--cores

argument is the number of cores used for trimming. There is also a

--fastqc_args "<ARGS>"

option for passing additional arguments to FastQC. As such, maybe this could be incorporated, so as to pass

$cores

(or maybe

$task.cpus

) to the

--threads

argument of FastQC?

My current run of the atacseq pipeline is failing at the step NFCORE_ATACSEQATACSEQMERGED_REPLICATE_BAM_TO_BIGWIG:BEDTOOLS_GENOMECOV with an out of memory error after retrying with up to 72G of RAM for one of the conditions. I modified the config file (passed on the command line with the -c option) to try to increase the memory allocation for bedtools genomecov, but this didn't work. I then read that for DSL2 pipelines the parameter block in a custom.config will not override the defaults, and that parameter override options must be provided with -params-file in yaml or json format. I've been searching for information about how to provide a process configuration for a specific tool in yaml or json format but have so far come up short. Could somebody provide some pointers for how to instruct the atacseq pipeline to require BEDTOOLS_GENOMECOV to execute with 96G of memory? This is the block I included in my .config file to try to achive the same result. withName : NFCORE_ATACSEQATACSEQMERGED_REPLICATE_BAM_TO_BIGWIG:BEDTOOLS_GENOMECOV { time = '8h' cpus = 6 memory = '96.G' }

Hi all, newbie here, hope to get any useful insights from you guys. My pipeline is failling at 2 deeptools steps as shown below. I have left quite enough CPUs and memory but not sure what would be the reason why it still says out of memory. Here is my config file: profiles { local { process.executor = 'local' executor.$local.cpus = 4 } standard { process.executor = 'slurm' process.cpus = 12 process.memory = '128 GB' } genomics { process.executor = 'slurm' process.memory = '64 GB' process.clusterOptions = {task.time > 4.hour ? '' : '--qos genomics --time=0-40000' } process.queue = { task.time > 4.hour ? 'comp' : 'genomics' } } }

Hi, thanks so much for creating and maintaining the atacseq pipeline, it's very useful. I'm running the dev version on the IFB SLURM cluster (using ifb_core config) and encountering an error that I need help with: [TaskFinalizer-3] ERROR nextflow.processor.TaskProcessor - Error executing process > 'NFCORE_ATACSEQATACSEQMERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS (consensus_peaks)' Caused by: Process

NFCORE_ATACSEQ:ATACSEQ:MERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS (consensus_peaks)

terminated with an error exit status (1) (...) Command error: INFO: Environment variable SINGULARITYENV_TMP is set, but APPTAINERENV_TMP is preferred INFO: Environment variable SINGULARITYENV_TMPDIR is set, but APPTAINERENV_TMPDIR is preferred INFO: Environment variable SINGULARITYENV_NXF_TASK_WORKDIR is set, but APPTAINERENV_NXF_TASK_WORKDIR is preferred INFO: Environment variable SINGULARITYENV_NXF_DEBUG is set, but APPTAINERENV_NXF_DEBUG is preferred WARNING: While bind mounting '/shared:/shared': destination is already in the mount point list Error: package or namespace load failed for ‘UpSetR’ in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]): namespace ‘rlang’ 0.4.12 is being loaded, but >= 1.1.0 is required Execution halted There is no info about the R version loaded by the pipeline in results/nf_core_atacseq_software_mqc_versions.yml although I see

cat <<-END_VERSIONS > versions.yml

"NFCORE_ATACSEQ:ATACSEQ:MERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS":

python: $(python --version | sed 's/Python //g')

r-base: $(echo $(R --version 2>&1) | sed 's/^.*R version //; s/ .*$//')

END_VERSIONS

in the command, is this saved in another location? I'd like to know which R version is pulled to update rlang accordingly. I enclose the nextflow.log Thanks in advance

Hi nfcore team, I'm encoutering a weird error and I worked with Claude to document it

Bug report: nf-core/atacseq v2.1.2 — BWA_MEM silently receives 0 tasks when BWA index is built from FASTA (no pre-built index provided) Hi all, I'm running into an issue with nf-core/atacseq v2.1.2 where

BWA_MEM

never receives any tasks when the pipeline builds the BWA index from scratch (i.e., when

params.bwa_index

is null/not provided). The pipeline completes "successfully" but skips alignment and everything downstream. Environment: • Nextflow 24.04.2 • nf-core/atacseq v2.1.2 • Singularity (HPC cluster, NYGC profile) •

--genome GRCh38

(iGenomes, S3-backed references) What happens: 1.

PREPARE_GENOME:BWA_INDEX

builds the index from the FASTA — completes successfully (exit 0), index files are correct. 2.

FASTQ_FASTQC_UMITOOLS_TRIMGALORE

completes — 18/18 FASTQ pairs processed.

FASTQ_ALIGN_BWA:BWA_MEM

shows

-

(0 tasks submitted). Never fires. All downstream processes (samtools, picard, MACS2, deeptools) also show

-

. 1. Pipeline reports "completed successfully" because processes with 0 tasks are treated as complete. Reproduction: This happens on a completely fresh run (clean work directory, no

-resume

cache). I confirmed by deleting the

work/

and

.nextflow/

directories and re-running. The Nextflow log confirms:

"It appears you have never run this project before -- Option -resume is ignored"

. Root cause (suspected): In

subworkflows/local/prepare_genome.nf

, the BWA index channel is created differently depending on whether a pre-built index is provided: • Pre-built index provided (

params.bwa_index

is set): • •

ch_bwa_index = [ [:], file(params.bwa_index) ]

• This creates a plain Groovy list, which Nextflow implicitly treats as a value channel. Value channels broadcast to all items in the reads queue channel → BWA_MEM gets 18 tasks. ✅ • Index built from FASTA (

params.bwa_index

is null):

ch_bwa_index = BWA_INDEX ( ch_fasta.map { [ [:], it ] } ).index

This is a queue channel (process output). Queue channels pair one-to-one with other queue channels. Since the reads channel has 18 items and the index channel has 1 item, at most 1 BWA_MEM task could be created — but in practice 0 tasks fire, and the pipeline silently completes. ✘ In

workflows/atacseq.nf

, the index is passed directly without

.collect()

or

.first()

to convert it to a value channel:

FASTQ_ALIGN_BWA (
    FASTQ_FASTQC_UMITOOLS_TRIMGALORE.out.reads,
    PREPARE_GENOME.out.bwa_index,   // <-- queue channel when built, value channel when pre-built
    false,
    PREPARE_GENOME.out.fasta.map { [ [:], it ] }
)

Suggested fix: Convert the queue channel to a value channel before passing to

FASTQ_ALIGN_BWA

, e.g.:

PREPARE_GENOME.out.bwa_index.collect()
// or
PREPARE_GENOME.out.bwa_index.first()

Why this matters: On HPC clusters without direct S3 access (or where S3 directory paths aren't supported), the default iGenomes

bwa_index

path (

<s3://ngi-igenomes/.../BWAIndex/version0.6.0/>

) can't be resolved. Setting

params.bwa_index = null

to force local index building is the expected workaround, but it triggers this channel-type mismatch. Context: • The same pipeline (v2.1.2) with

--genome mm10

works fine because mm10 iGenomes does not include a pre-built BWA index, so the "build from FASTA" path is always taken. (I confirmed this from a previous successful run with the same Nextflow version.) • nf-core/cutandrun v3.2.2 does not have this issue — its Bowtie2 index handling resolves S3 paths correctly. Happy to provide full logs or

.nextflow.log

if helpful. Thanks!

let me know if that makes sense!

Hi nfcore gang, I'm reposting this as I'm still stuck: I pulled the latest dev version, ran in narrowpeak mode on the IFB SLURM HPC (using the ifb_core config) - same happens in broadpeak - and it crashes at the MERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS step. It looks like the pipeline is loading a very outdated version of rlang inot supported UpSetR.

Error executing process > 'NFCORE_ATACSEQ:ATACSEQ:MERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS (consensus_peaks)'

Caused by:
  Process `NFCORE_ATACSEQ:ATACSEQ:MERGED_LIBRARY_CONSENSUS_PEAKS:MACS3_CONSENSUS (consensus_peaks)` terminated with an error exit status (1)

(...)

Command exit status:
  1

Command output:
  (empty)

Command error:
  INFO:    Environment variable SINGULARITYENV_TMP is set, but APPTAINERENV_TMP is preferred
  INFO:    Environment variable SINGULARITYENV_TMPDIR is set, but APPTAINERENV_TMPDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_TASK_WORKDIR is set, but APPTAINERENV_NXF_TASK_WORKDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_DEBUG is set, but APPTAINERENV_NXF_DEBUG is preferred
  WARNING: While bind mounting '/shared:/shared': destination is already in the mount point list
  Error: package or namespace load failed for 'UpSetR' in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
   namespace 'rlang' 0.4.12 is being loaded, but >= 1.1.0 is required
  Execution halted

I'm attaching the command.run from the wd and the tools version. Could someone please look into this as I don't know what can be done on my side link to my previous post https://nfcore.slack.com/archives/CE5EL6326/p1773238134341339 command.run https://nfcore.slack.com/files/U09GUS6B162/F0AM1S0E6JZ/command.run tools versions https://nfcore.slack.com/files/U09GUS6B162/F0AM59AKG2E/nf_core_atacseq_software_mqc_versions.yml Thanks in advance

Hi all, I'm a software engineer at Seqera, and formerly a bioinformatician, and I made a small issue and PR of 162 lines of syntax change to drop the number of nextflow strict syntax warnings to 0. It was AI-assisted using our new agent, but human-reviewed, and end to end tested.

I want to run atacseq on a test dataset we ran. It only has 1 sample. Will the pipeline run okay, or will it error out if it can't do comparisons?

Why does nf-core/atacseq use MAPQ ≥1 rather than a stricter cutoff such as MAPQ ≥30 before peak calling? Does MAPQ ≥1 truly restrict the BAM to uniquely mapped reads? @Jose Espinosa-Carrasco

withName: 'BAMTOOLS_FILTER' {

ext.args  = {

[

meta.single_end ? '-F 0x004' : '-F 0x004 -F 0x0008 -f 0x001',

params.keep_dups ? '' : '-F 0x04 @00',

params.keep_multi_map ? '' : '-q 1'

].join(' ').trim()

}

Hi everyone, We’re exploring the implementation of optional UMI-aware preprocessing in nf-core/atacseq and wanted to get some feedback before starting the work. The motivation comes from the UMI-ATAC-seq protocol described by Li et al. (Communications Biology, 2020), which introduces a UMI on Read 1 to distinguish true PCR duplicates from independently generated fragments. Compared to conventional coordinate-based deduplication, the paper reports improved duplicate classification and better recovery of signal in highly accessible chromatin, ultimately leading to increased transcription factor footprint sensitivity. We’ve reviewed both the publication and the accompanying implementation. While the original code demonstrates the methodology, it appears to be tightly coupled to the specific workflow described in the paper and relies on several implementation choices (custom batching, bespoke scripts, limited scalability) that make it difficult to integrate directly into a production-grade Nextflow pipeline. Instead, we’re considering a native nf-core implementation that would: • introduce an optional --with_umi execution path; • reuse existing nf-core modules wherever possible (e.g. Cutadapt, UMI-tools, alignment, samtools); • implement only the protocol-specific preprocessing steps locally (primarily Mosaic End processing and associated workflow logic); • delegate all parallelisation to Nextflow rather than implementing manual file splitting or thread management; • validate the implementation by reproducing the key benchmark figures reported in the original publication. We’d like to understand whether this is something the community would be interested in accepting as a contribution to nf-core/atacseq. In particular, we’d appreciate feedback on a few architectural questions: 1. Would support for this protocol be considered in scope for nf-core/atacseq? 2. If so, would you recommend implementing the UMI preprocessing as: ◦ a local subworkflow specific to nf-core/atacseq, or ◦ new reusable nf-core modules where appropriate? To our knowledge this protocol applies only to ATAC-seq experiments. 3. For protocol-specific processing steps (such as Mosaic End trimming), would you generally prefer keeping them local to the pipeline, or would there be interest in modularising them despite their limited reuse? 4. Are there any architectural patterns in existing nf-core pipelines that you would recommend following for optional protocol-specific preprocessing branches? If there’s interest, we’d be happy to open an issue outlining the proposed design before starting the implementation so we can align with nf-core conventions from the outset. Thanks!

Hello, the read length in the fastqs in the study = 101 whereas the only available options for read length=50,75,100 etc. Is it appropriate to use 100 for --read_length in this case?

@Nico De Veaux / @Kevin Brockers / @Jose Espinosa-Carrasco and others working on this pipeline. Could I please bother you take a look at this pipeline proposal? It has significant overlap with the #CE5EL6326 pipeline and it'd be great to get your take on which direction we should take with it. Also, there's a post from @Francesco Tabaro just above that needs some eyes on it 👆🏻 Thank you! 🙏🏻

Hi all ! Thanks for the invitation 🙂

Hi @pierre-francois.roux, I really like the pipeline steps you proposed (for others interested check the proposal here: github.com/nf-core/proposals/issues/153). However, I think it could also be a very nice extension to the current atacseq pipeline. To get the discussion going and potentially find a common ground 🙂 I see two potential routes: A) Would it be fine for you to implement the proposed analyses steps in the current pipeline? • We would need to see what Jose will say. • I wouldn't mind to get involved here as well / review things when needed. B) Would you want to develop an independent downstream analysis pipeline? - • It could be similar to the scdownsteam pipeline. • Here I see more overhead for you and the atacseq pipeline devs to get things compatible and in sync. • In case you prefer this, I think it would be good to clarify which files you would need as inputs for such a downstream pipeline and redefine your proposal to minimize overlap with the existing atacseq pipeline. What do you think? Cheers, Kevin

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

Hi all ! As the ATAC-seq extensions are now well underway, I have started thinking about a short software article once the real-data validation is complete. The work currently in the pipeline includes: > • regulatory analyses: ROSE super-enhancer calling, TOBIAS footprinting, chromVAR and NucleoATAC; > • complementary genetic analyses from ATAC-seq reads: small-variant calling, CNV calling, mitochondrial analysis with mgatk, and telomere-content analysis with TelomereHunter2; > • Several reusable nf-core components are already submitted or under review, including NucleoATAC, TelomereHunter2, mgatk, and the TOBIAS and motifmatchr components. Would the nf-core/atacseq team be interested in developing this collaboratively? I would be very happy to include active contributors as co-authors according to their contributions, and to align the manuscript with the eventual integration into nf-core/atacseq.

Hi all, sightly off topic : do you know any NF implementation of tobias that is working/has been tested ? thanks

Hi @yokofakun! I've recently implemented the following TOBIAS modules : nf-co.re/modules/tobias_atacorrect nf-co.re/modules/tobias_bindetect nf-co.re/modules/tobias_scorebigwig These correspond to the 3 steps of a TOBIAS workflow, but they are not embedded yet in an nf-core pipeline. I would be happy though if you could validate those moduels on your own data.

Hi all, I'm coming back from paternity leave, and I'm reviewing a PR I had started to update nf-core modules (PR #448). Along the way, I discovered a bad code smell that I think should be a new issue:

modules/local/multiqc.nf

is pinned to MultiQC 1.13, but the

nf-core multiqc

module is installed and tracked in

modules.json.

And from what I can tell, the latter is totally unused. Module updates and template syncs keep bumping it (to 1.35 in PR #455 for example), which makes it look as if the pipeline uses a newer MultiQC than it does. This should be a new issue, right? With the solution being to remove

modules/local/multiqc.nf

in favor of

modules/nf-core/multiqc

?

depictio Depictio dashboard for atacseq: feedback wanted Depictio (open source, from EMBL) turns the output of a workflow run into an interactive dashboard you can share, so nobody has to write a Shiny or Streamlit app for each project. Point a template at any run of a pipeline and you get the same dashboard, which you can edit (UI & YAML), version and comment. 🧬 The atacseq dashboard template (no account needed) shows library quality (TSS enrichment, fragment sizes), called peaks with their gene annotation and consensus peaks. 🙌 We need your help! Feedback and ideas welcome in #C0AFS06G9HR (all templates and details there) or in the atacseq GitHub discussion.