Original parameters (v. 3.22.2?): trim_galore \ --fastqc_args '-t 12' \ --cores 8 \ --paired \ --gzip \ C1_trimmed_1.fastq.gz \ C1_trimmed_2.fastq.gz => Illumina universal adapters removed, some polyA/polyG remaining. Added extra parameters, (v.3.26.0): trim_galore \ --fastqc_args '-t 8' --nextseq 20 -a G{10} -a A{10} -a2 G{10} -a2 A{10} \ --cores 4 \ --paired \ --gzip \ C1_trimmed_1.fastq.gz \ C1_trimmed_2.fastq.gz => Illumina universal adapters Not removed, polyA/polyG removed. Adding --stranded_illumina: trim_galore \ --fastqc_args '-t 8' --nextseq 20 --stranded_illumina -a G{10} -a A{10} -a2 G{10} -a2 A{10} -n 3 \ --cores 4 \ --paired \ --gzip \ C1_trimmed_1.fastq.gz \ C1_trimmed_2.fastq.gz => Illumina universal adaptors are still present, polyA/polyG removed.

So adding extra arguments for trimgalore appears to suppress the automatic detection and removal of adaptors, even if specifically added as "--stranded_illumina"

It removed beautifully all primers and polyA/polyG tracts

When I supplied the nf-core/rnaseq with the argument "--extra_trimgalore_args ' --nextseq 20 --poly_g --poly_a -n 3 '" it came back with this error:

"error: the argument '--poly_a' cannot be used multiple times"

The command line shown was:

... " --fastqc_args '-t 8' --nextseq 20 --poly_a --poly_a --poly_g -n 3 \"

I thought that was strange and tried again with this edit:

"--extra_trimgalore_args ' --nextseq 20 --poly_g --poly_a -n 3 ' \"

The error message was similar:

"error: the argument '--poly_g' cannot be used multiple times"

It seems that somehow the "--poly_a" or "--poly_g" gets repeated twice on the command line in the pipeline, while it is supplied only once in the argument.

I don't seem to be able to submit a bug to "github.com/nf-core/rnaseq/issues".

Here is a summary of my tests:

• trim_galore_2.1.0 in nf-core/rnaseq 3.26.0 without any extra arguments does not remove polyG and polyA (0.2-0.3% remaining from both) • with "--extra_trimgalore_args ' --nextseq 20' " results in Illumina universal primers and polyG removed; polyA not removed • using "--extra_trimgalore_args ' --nextseq 20 --poly_a --poly_g -n 3 ' " breaks the pipeline with error "--poly_a cannot be used multiple times" • using "--extra_trimgalore_args ' --nextseq 20 --poly_g --poly_a -n 3 ' " breaks the pipeline with error "--poly_g' cannot be used multiple times"

The actual commands from the pipeline in the last couple of cases are documented as containing "--nextseq 20 --poly_a --poly_a --poly_g -n 3 " and "--nextseq 20 --poly_g --poly_g --poly_a -n 3 "

Running trim_galore_2.1.0 as a standalone application and using "--nextseq 20 --poly_a --poly_g -n 3" removes Illumina universal adaptors as well as polyA and polyG stretches.

We have had projects with up to 5% polyA and it will be good to remove that explicitly.

Two separate things going on here, one of them is Trim Galore related The adapters iissue

-a

replaces adapter auto-detection rather than adding to it, so

-a G{10} -a A{10}

told Trim Galore that the adapter is a G or A homopolymer — the Illumina sequence was never searched for. Adding

--stranded_illumina

didn’t change that, because an explicit

-a

wins over the presets. That’s why the adapters survived. Don’t use

-a

for poly tails:

--poly_a

and

--poly_g

are separate trimming stages and they leave auto-detection alone. That’s exactly why your standalone run worked. So the command you want is the one you already proved:

--nextseq 20 --poly_a --poly_g -n 3

with no `-a`/`-a2` at all. The duplication is a pipeline bug, in

conf/modules/trimgalore.config

. It parses

--extra_trimgalore_args

into a map with:

def parts = arg.trim().split(/\s+/, 2)
extra_args_map[parts.first()] = parts.last()

For a flag that takes no value, that split returns a single-element array, so

first()

and

last()

are the same thing — the map ends up holding

"--poly_a" -> "--poly_a"

and renders it as

--poly_a --poly_a

. It only hits the flag that isn’t followed by a single-dash argument, because the splitter breaks on`--

only, so

-n 3` stays attached to the flag before it and accidentally acts as its value. That is why swapping

--poly_a

and

--poly_g

moved the error. I’ll open an issue on nf-core/rnaseq with that detail. In the meantime,

--nextseq 20

on its own goes through the config unharmed, and you can reach the rest by putting a single-dash argument after each valueless flag —

--poly_a -n 3 --poly_g -n 3

comes out intact, if inelegantly. Separately, I’ll make Trim Galore tolerate a repeated flag instead of refusing it. Perl Trim Galore accepted repeats silently, so this is a v2 regression in a place nobody should have to think about. One additional word regarding Poly-G trimming which is arguably more than the flag duplication in your case: you’re on v2.1.0, and

--poly_g

was broken for Read 2 until v2.3.0 (#321). On 2.1.0 it looked for poly-C at R2's 5' end instead of poly-G at the 3' end, so it both missed R2's real poly-G and clipped legitimate 5' bases off R2 where they happened to be C-rich. I’d not trust R2 from any paired run you’ve done with

--poly_g

on 2.1.0 — please upgrade to 2.3.0. The pipeline pins 2.1.0, so that pin needs bumping too; I’ll raise it that too while we are at it. And one for the next release: with

--poly_a

and

--poly_g

together, a poly-A tail sitting behind a poly-G run was not removed, because poly-A ran first and the G-run blocked its scan. Fixed on dev, shipping in v2.4.0 — which is likely the rest of the poly-A you are still seeing.

I replied to the issue - will take another look at this tomorrow, it’s getting a late. thanks