fix(trimgalore): drop process label to process_low

[pinin4fjords]

Summary

Drops the TRIMGALORE process label from process_high (12 cpus / 72 GB / 16 h) to process_low (2 cpus / 12 GB / 4 h, scaling with task.attempt).

Why

trim-galore 2.x is a Rust binary that streams reads, so memory stays flat with input size rather than scaling with read count. The process_high ceiling was inherited from the Perl-based 0.6.x era and is now massively over-provisioned, starving shared HPC schedulers for no benefit.

Empirical data (30M PE on nf-core/rnaseq)

Metric	Observed	process_low budget
peak_rss	~100 MB	12 GB (~120×)
realtime	1.25–2.0 min (median 1.5)	4 h (~80×)
cpus consumed	1 worker thread	2 cpus (≥1 worker)

The script already auto-derives --cores from task.cpus and caps the worker count at 8, so over-allocating cpus doesn't help anyway.

Why process_low and not process_single?

process_single (1 cpu / 6 GB / 4 h) is the only smaller standard bucket. For trim_galore's worker-thread math both yield 1 worker (since cores = max(1, task.cpus - 4) on paired), so the trimming parallelism is identical. The runtime difference comes from the surrounding I/O pipeline:

• A paired trim_galore invocation spawns ~6–8 helper processes (cutadapt for R1/R2, pigz reader/writer pairs, validator).
• On 1 cpu they all contend for a single core; on 2 cpus the OS can overlap I/O with the worker thread, which is most of the wall-time on real data. The ~1.5 min realtime above came from a 2-cpu run; collapsing to 1 cpu would likely give some of it back.
• process_single also semantically signals "single-threaded by nature" (utilities, parsers, R scripts). trim_galore is genuinely multi-process even when only running one trimming worker, so process_low reads more honestly for "small resource ceiling, still parallel I/O".

Users with bespoke needs (huge inputs, custom adapter detection, etc.) can still override resources at the pipeline level.

What's not changing

• Container, environment, output channels, args - all unchanged.
• Module-level snapshots - unaffected; the label isn't captured in snap content.

Test plan

• Module-level nf-test passes against the new label.
• Downstream pipelines (rnaseq, methylseq, atacseq, ...) still complete on real data with the new ceiling.

[pinin4fjords]

Thanks @SPPearce !

[FelixKrueger]

As a comment on this, the invocation was --cores 8, which uses:

• ~12 CPUs
• ~100MB of RAM
• with roughly 20M read pairs per minute

Please note that the threading model is N+4, so using --cores 2 uses 6 cores, while --cored 8 uses 12 cores.

Using --cores 2 is still good time wise, but the wall clock time can be reduced by a further 75% by using 12 CPUs (--coreds 8).

[SPPearce]

Please note that the threading model is N+4, so using --cores 2 uses 6 cores, while --cored 8 uses 12 cores.

Uh?