Hi y'all. I'm working on an update to rnaseq to support a more sample-wise mode of operation useful for large-scale sequencing projects, if anyone is interested and wants to comment: https://github.com/nf-core/rnaseq/pull/1744

Hi! I opened a feature request about adding samtools markdup as an optional alternative to Picard MarkDuplicates: https://github.com/nf-core/rnaseq/issues/1759 Short version: I ran a benchmark on 8 human ENCODE samples (~1.5B reads) on a cloud server with 32GB RAM - samtools markdup produced identical duplicate counts on all samples, ran 1.89x faster at 8 threads, and used 2.3x less memory. Picard actually OOM'd on 5 of 8 samples on first attempt, which surprised me. The raw data and scripts are public if anyone wants to poke at them: https://github.com/WeTheAgents/rnaseq_data I know the benchmark doesn't cover optical duplicates or UMI workflows - I'm not sure how much of a gap that is in practice. Would love to hear from people who know this space better than I do.

Hi! I'm currently working on a PR for the pipeline and I had issues for updating the snapshots of the pipeline tests following the recommended workflows (input errors and obviously incorrect snapshot). I did manage to find that running the tests required

--profile=+test,singularity

instead of

--profile=+singularity

and someone pointed out that the pipeline used a slightly different config that the rest. rnaseq (no profile test provided):

// run all tests with the profile(s) specified by each CI workflow

other:

// run all test with defined profile(s) from the main nextflow.config
profile "test"

Is this an intended behaviour ? If so can we add a note somewhere for future contributors ?

Hi all! @Felix Krueger has been working on a rewrite of TrimGalore! recently and reckons he has now gotten to a place where it's equivalent or better than the original, and also substantially faster. #CE8SSJV3N is the biggest nf-core pipeline that uses it (although there are several), does anyone have suggestions about a validation strategy he could follow before releasing this v2 monster? 🦀

Hi! I have added a subworkflow to rnaseq pipeline : https://github.com/nf-core/rnaseq/pull/1755 Slack conversation

Testing Picard vs samtools vs sambamba DONE! (this issue) @Phil Ewels, took a few extra days - sambamba had some surprises in store - but here's the full picture. Three-way: Picard vs samtools vs sambamba (same 8 ENCODE samples, 16 vCPU, t=1/4/8/16, 3 runs each). All three tools produce identical duplicate counts on all 8 samples. No divergence anywhere. sambabma is the fastest (x5.5 vs Picard), but requires some tuning. sambamba out of the box OOMed at 32 GB server. Once you add three memory tuning flags, peak RSS drops to 1.4-3.6 GB - roughly 10x less than Picard. The second surprise: sambamba also hit the OS file descriptor limit mid-run (default 1024 isn't enough). Fixed with

ulimit -n 65536

. Once properly configured, it was rock solid across all 192 runs. Also ran a quick I/O test - suspected the thread scaling plateau (both tools gain only ~1.2x going from t=8 to t=16) was network storage bottleneck. Moved BAMs to local SSD and RAM, but got only 8-15% improvement. So the speed and memory efficiency is real, but not automatic: it requires explicit configuration. All data, scripts, and a setup guide for a budget-friendly Hetzner server, including the sambamba config details: https://github.com/WeTheAgents/rnaseq_data/tree/main/phase3_three_way

heads-up rnaseq devonados: I'm abandoning the configs-next-to-components pattern Harshil introduced shortly before he was deposed, it was never picked up as a pattern and created more difficulties than it solved. In order to avoid a monstrous modules.conf I'm adopting the sarek modules/*.conf pattern. @Maxime Garcia reviewed, but FYI: https://github.com/nf-core/rnaseq/pull/1788

Rewriting STAR in Rust -> STAR 2.0 @Rob Patro & scverse initiated a rewrite of STAR into Rust a few weeks ago which is currently mostly led by James Ferguson. It's supposed to be faithful of course, but also implemented in such a way so that it can be extended with new ideas of Rob that will potentially make it more efficient & accurate. We want to ensure that the new version will be easily extendable and maintainable by the community. Given the size of the task, a lot of the implementation will be Claude guided. A few industry partners are supporting this effort with credits & later potentially engineering hours. This effort will be kicked off officially super soon but the current POC can be found here: https://github.com/Psy-Fer/ruSTAR Given how much STAR is used for various pipelines in nf-core and your recent rustqc efforts, we are wondering: 1. Are there specific pain points in current STAR nf-core usage (memory, startup overhead, output format quirks) that the rewrite should treat as first-class problems to solve? 2. Would anyone here be interested in testing their pipelines with the new STAR version as soon as it's in a good enough state? Contributions are of course welcome. If you're interested in dedicating a substantial amount of time/effort, I'd be happy to put you into touch with the team.

Gentlemen, start your engines agents! 🏁 We go full markdupes After a weeklong Rust vibecode and 24/7 benchmarking I ended up with three things worth showing. All of it sits comfortably inside the rewrites.bio policy @Phil Ewels has been driving — one verified (to my personal limits) rewrite, and two knob-turns that help the unmodified pipeline on the same hardware. 1. markdup-wea — a Rust rewrite of Picard MarkDuplicates 8/8 ENCODE RNA-seq samples (1.55 B records, 934 M duplicates): byte-identical duplicate flags + metrics vs Picard 3.4.0. Zero flag mismatches, zero metrics data divergence. K562_REP1 head-to-head, same 32GB box: 3.26× faster, 54× less RAM (325 MB vs 17.6 GB peak). Drop-in for the

PICARD_MARKDUPLICATES

step in nf-core/rnaseq — same

KEY=VALUE

CLI. • Repo: https://github.com/WeTheAgents/markdup8x-wea • Parity report: https://github.com/WeTheAgents/markdup8x-wea/blob/main/docs/session-report.md • Performance: https://github.com/WeTheAgents/markdup8x-wea/blob/main/docs/perf.md • Known deltas from Picard: https://github.com/WeTheAgents/markdup8x-wea/blob/main/docs/deviations.md 2. Picard memory-tuning proposal for nf-core/rnaseq — zero code change nf-core's

PICARD_MARKDUPLICATES

uses

label 'process_medium'

→ 36 GB reservation,

-Xmx28g

. Measured per-JVM peak RSS on our ENCODE corpus: under 8 GB. ~4× over-allocation on every invocation. Sweep on a 30 GB box:

-Xmx6g × 4

parallel delivers 8/8 byte-identical output to the

-Xmx28g

default and 3.05× end-to-end throughput on the 8-sample batch. Retry envelope verified with a "werewolf" BAM (2× largest ENCODE sample, 445 M records, 17 GB): clean finish at

-Xmx9g

, peak RSS 9.6 GB. Two werewolves in parallel at

-Xmx9g

each → sum RSS 20.8 GB, same wall as one, no OOM. • Full doc: https://github.com/WeTheAgents/markdup8x-wea/blob/main/docs/picard-tuning-proposal.md • Issue: https://github.com/nf-core/rnaseq/issues/1801 3. Downstream parallelism — so the markdup win doesn't get swallowed An 8× throughput bump on markdup is wasted if Qualimap and bedtools then serialize behind it. Both are single-threaded by design, and nf-core's default labels over-budget them — Qualimap asks for 36 GB and really uses ~5–6 GB; bedtools asks for 6 GB and actually scales 4–14 GB by sample complexity. On a 30 GB node that means exactly one of each at a time. Right-sized and run by hand on the same Hetzner 32BG: Qualimap 4-wide × 2 waves → 3.30× speedup (7:51 h → 2:23 h on the 8-sample set), bedtools 2-wide → 1.55× (2-wide is the safe ceiling — 4-wide OOMed on MCF7). Combined across the three heavy BAM-side steps (markdup + Qualimap + bedtools): ~12:49 h → ~3:13 h on 8 samples, same box, no hardware upgrade. Non-specialist caveat: this assumes batch re-processing of pre-staged BAMs as the workload — all inputs local, no aligner in the critical path. I don't know how common that is vs the canonical one-sample-at-a-time flow. If it's common, the savings are literally sitting on the ground. Numbers in the Phase E section: https://github.com/WeTheAgents/markdup8x-wea/blob/main/docs/perf.md Scope and caveats: my dear Claude Agent and I went through everything we could surface: Picard sources + JavaDoc, MarkDuplicates forums and GATK issues, the nf-core module, and the relevant nf-core/rnaseq config layers. What neither of us can speak to is tribal knowledge — production workloads or library types where the 36 GB reservation is genuinely load-bearing rather than conservative legacy. I'm not a practicing bioinformatician. Explicitly outside the benchmark: WGS / WGBS / long-read, very-large-library inputs (> 2× werewolf), optical-duplicate configurations, unsorted BAMs, MarkDuplicatesSpark (different code path entirely). Happy to dig into whichever of the three is most interesting to you right now.

🎉 TrimGalore v2.1.0 — Oxidized Edition Beta 1 is live I would appreciate some help/feedback! Full Rust rewrite, drop-in replacement for Perl v0.6.x. Same CLI, same outputs. Extras in v2.1.0:

--discard-untrimmed

, JSON trimming report for MultiQC native parsing (once MultiQC is updated), MultiQC-compatible. Install: • crates.io:

cargo install trim-galore --version 2.1.0-beta.1

(the

--version

flag is required — plain

cargo install trim-galore

still resolves to v2.0.0 until GA) • Docker (tag):

<http://ghcr.io/felixkrueger/trimgalore:v2.1.0-beta.1|ghcr.io/felixkrueger/trimgalore:v2.1.0-beta.1>

— or

:beta

for the moving “latest beta” • Docker (digest, deterministic):

<http://ghcr.io/felixkrueger/trimgalore@sha256:3e5dd519ea992ce88eb6f01e8d051a33f356e9ecd2d45e79a9c9bd0ac05c5b77|ghcr.io/felixkrueger/trimgalore@sha256:3e5dd519ea992ce88eb6f01e8d051a33f356e9ecd2d45e79a9c9bd0ac05c5b77>

• Multi-arch:

linux/amd64

+

linux/arm64

nf-core/rnaseq integration: PR https://github.com/nf-core/rnaseq/pull/1789 is green on full matrix — x86 (40/40), arm64 (28/28), GPU (4/4). Pinned to image digest so runs are deterministic. No MD5 drift on reference outputs; MultiQC parses both report formats. Release notes: https://github.com/FelixKrueger/TrimGalore/releases/tag/v2.1.0-beta.1 GA-tracking PR: https://github.com/FelixKrueger/TrimGalore/pull/214 (draft,

do-not-merge-until-GA

) Announcement + feedback hub: https://github.com/FelixKrueger/TrimGalore/discussions/215 I am aiming for a 2-week beta window (planned release ~2026-05-03), assuming no critical issues. I would be very happy for some stress-testing, and to hear any feedback. Many thanks! 🫶

Heck, more rewrite-it-in-rust discussions in this channel too - y'all having fun, clearly - any bits need picking up? - I've been pestering #CE9MS66BS for a while now, now it's your turn

Seeking opinons on something: there's currently some d/e documentation on the repo: https://nf-co.re/rnaseq/3.24.0/docs/usage/differential_expression_analysis/de_rstudio I didn't add it, it was done as part of one of the hackathons, I think because Harshil said it would be OK. But I'm not maintaining the content and it doesn't relate directly to pipeline operations. I'm inclined to strip it, folks can still see it in the repo and in old versions of the docs. Anyone going to yell at me if I do that?

Planning yet another release ASAP. Just need a hand to review these fixes if folks have time: • https://github.com/nf-core/modules/pull/11526 - add missing tximport output • https://github.com/nf-core/rnaseq/pull/1832 - Fix the sample-wise mode to not emit files that don't make sense in that context • https://github.com/nf-core/modules/pull/11531 - Pin back resources for the new-and-shiny TrimGalore in Rust (plus the workflow install of the same)

@Felix Krueger @Jonathan Manning moving here as #C05AHQPA9A7 thread is not really the right place 😆 https://nfcore.slack.com/archives/C05AHQPA9A7/p1777984771810759?thread_ts=1777982753.023139&cid=C05AHQPA9A7 Do we still need a separate FastQC task? Can TrimGalore do both pre- and post- trimming reports?

So before everyone (@Felix Krueger @Jonathan Manning) gets too excited about low-memory usage for TrimGalore, I might have a good use for all that juicy high-memory RAM that we have kicking around.. I was chatting to @Stephen Kelly in Boston last week about his tool squish, which is a rewrite / new tool similar to

bbmap clumpify

. The overall concept is fairly simple - if we sort / group the raw reads in FastQ files then we can achieve better gzip compression rates and save disk space. It struck me that TrimGalore would be a great place to do this. We're already writing new FastQ files here, so we can do this optimisation in-flight and avoid having an additional copy of FastQ files in the work dir / scratch. I've had a play with this yesterday / last night and tried a bunch of different implementation approaches. My favourite is to do it all in-memory, as long as we give TrimGalore enough memory to fit the raw data (it'll still work under this, it just kicks out the bins sooner so is less efficient). Disk space savings vary massively by data type, but on low complexity libraries it's fairly significant: • Long read: basically 0% savings and super slow. Don't do this. • WGS: Diverse, pretty minimal savings (5-10% from memory) • RNA-seq PE: 29% smaller • ChIP-seq SE (28.6M reads): 24.0% smaller • ATAC-seq PE: 51.0% smaller (best so far — Tn5 bias creates redundancy) • Ribo-seq PE: 44.2% smaller I'm doing some final cleanup and testing now before opening a PR, but I think this sounds pretty promising: 1/3rd to 1/2 disk space footprint after running TrimGalore with zero data changes (PE files are kept in sync) and only minimal run-time slow down.

Hi all! I'd like to change slightly the way we handle

--genome

/ igenomes. This is motivated by an error @Felix Krueger flagged, caused by my assuming that anyone using

--genome

was using iGenomes, whereas he very reasonably uses his own genome config compatible with up-to-date STAR. I actually replaced an old check based on file names that was brittle and causing problems. So https://github.com/nf-core/rnaseq/pull/1834 re-pitches the functionality to allow for more flexibility. The currently distributed

genomes.config

entries now have a 'legacy' flag on all the genomes so that the pipeline knows to use the older STAR with those indices. Folks can still use their own genome setup without that flag and it'll all be fine. Would really appreciate review if anyone has time, and folks here are more qualified than most! Then we're almost ready to release with the new shiny TrimGalore goodness 🙂

FYI: I have proposed to add an equivalent functionality like

umi_tools prepare-for-rsem

to

fgumi

. I think, it makes total sense to replace the frequently longest running process of the pipeline (6-13h per sample) with a Rust tool as well. Currently, I am running comparisons of the Rust rewrite with the original. Will report back.

Nice!

We should start testing

rustar-aligner

too for a STAR replacement. It has an initial release now, should be feature-complete replacement for STAR., so good to go.. 🦀 ⭐

The rustification continues.. 🦀 • ✅ QC subworkflow • ✅ Trimming • ⏳ umis • ⏳ alignment • 🔨 duplicate marking

Hi team, I’d like to help reduce common support requests by adding a "Troubleshooting & Common Errors" guide to the

nf-core/rnaseq

docs. The goal is to provide a quick "pre-flight" checklist for frequent issues like samplesheet formatting, genome/GTF mismatches, and container errors. I'm happy to draft a PR—does this align with your current documentation goals, or is there a preferred format you'd like me to follow?

I think the GPU runners are still offline for the rnaseq repo. I'm seeing this error on my PR.

Error: Failed to launch runner: We were unable to schedule this runner after 5 attempts. Please have a look at the RunsOn logs for that job for more details.

Hi folks! How are we on the security patch thing? Can we resolve the security advisory that started this all? 'cc @Jonathan Manning @mashehu

@Jonathan Manning started to update hisat2/build for strict syntax, so I replace the params for memory by an input, but that led me to a tiny trip #C073GFZ68PR, and here is what I now propose for hisat2 https://github.com/nf-core/modules/pull/12838 Basically: • updating everything (hisat2 and samtools) • moving away the meta strandness from the modules, we should really be doing that via args anyway • strict syntax Let me know if you see things that you think shouldn't be done. It is definitively not my #C0749PAEU9F

Little spit and polish on the metro maps: github.com/nf-core/rnaseq/pull/1915

✅ rnaseq/test_full completed successfully! 🎉 Run Name shrivelled_kirch Duration 3h 9m 15s Status ✅ Success Tasks Completed: 328 Sep 23, 2026 at 10:17 AM

✅ rnaseq/test_full completed successfully! 🎉 Run Name adoring_mestorf Duration 3h 21m 34s Status ✅ Success Tasks Completed: 328 Sep 23, 2026 at 3:21 PM

✅ rnaseq/test_full completed successfully! 🎉 Run Name sharp_banach Duration 13h 9m 39s Status ✅ Success Tasks Completed: 330 Sep 24, 2026 at 1:09 AM

✅ rnaseq/test_full completed successfully! 🎉 Run Name trusting_minsky Duration 1d 10h 2m 58s Status ✅ Success Tasks Completed: 330, Failed: 2 Sep 24, 2026 at 11:03 PM

@Jonathan Manning nf-core-utils PR: github.com/nf-core/rnaseq/pull/1977