FastP file name colission in multi-lane sequencing setups

[marchoeppner]

Description of the bug

It's probably exceedingly rare, but if and when you sequence a library across multiple lanes, the pipeline runs into a file name colission downstream of fastp.

This is because fastp uses this naming schema for merging PE files:

meta.id + ".fastp.fastq.gz"

However, since 'meta.id' will be the same for multiple lanes of the same library, the pipeline then goes "boom" when all files belonging to one 'meta.id' are staged into the same folder.

So maybe something like "reads[0].getBaseName()" might be more appropriate here.

Command used and terminal output

ERROR ~ Error executing process > 'NFCORE_SMRNASEQ:SMRNASEQ:MIRTRACE:MIRTRACE_RUN (1)'

Caused by:
  Process `NFCORE_SMRNASEQ:SMRNASEQ:MIRTRACE:MIRTRACE_RUN` input file name collision -- There are multiple input files for each of the following file names: TER12.fastp.fastq.gz, EC1.fastp.fastq.gz, GCT72_R.fastp.fastq.gz, TER1.fastp.fastq.gz, GCT72.fastp.fastq.gz, GTS6.fastp.fastq.gz, GTS15.fastp.fastq.gz, YST2.fastp.fastq.gz, GTS2.fastp.fastq.gz, NCCIT.fastp.fastq.gz, 1411H.fastp.fastq.gz, NT2D1.fastp.fastq.gz, YST3.fastp.fastq.gz, GTS11.fastp.fastq.gz, 2102EP.fastp.fastq.gz, YST1.fastp.fastq.gz, TER13.fastp.fastq.gz, EC2.fastp.fastq.gz, GTS14.fastp.fastq.gz, GTS7.fastp.fastq.gz


Tip: when you have fixed the problem you can continue the execution adding the option `-resume` to the run command line

Relevant files

No response

System information

No response

[marchoeppner]

Right, so this seems to come from somewhere else...

I was under the impression the pipeline allows paired-end inputs. But apparently not? So I had 2 lanes, paired reads - and this was not merged into one emission of merged reads, but two. I think because the paired reads triggered the branching for the merging step, rather than the two lanes being grouped by tuple and then merged (?).

Running this as manually merged single-end set runs through fine, apparently...

[jonoave]

AFAIK, the pipeline only accepts or process single-end reads. Similarly, another smrnaseq workflow mirge3 also accepts only single-end reads.

Not sure if you should merge paired-end reads for smrnaseq analyses.

[marchoeppner]

I suppose you wouldn't merge R1 and R2, since apparently they contain the same information anyway. So the solution would be to only use R1. I think the issue is that the pipeline uses the default nf-core documentation template, which also speaks of PE configurations. So I guess that needs to be removed then.