The input FastQ file names produce an error in the pipeline execution - cellranger error

[lewis9914]

I have a problem with the nf-core scRNAseq pipeline. I don't get any error in the standard error file "slurm", but I am getting an error in the standard output file that is quite random: every time I try to run the bash script I created, the pipeline randomly stops at a random sample saying that no input FastQs where found for the requested parameters, but the data about these samples is present, the paths in the samplesheet are correct and they don't seem to have any issue, I checked them manually.

After a brief chat on the nf-core #scrnaseq Slack channel, had been told that the problem is actually that the naming conventions of my FastQ files don't match those expected by cellranger, despite the pipeline theoretically being able to take care of that, but probably this has not yet being implemented.

So, I open this issue in order to propose changes in the pipeline to make it rename those files automatically.

I am attaching the error code I get:

executor >  slurm (34)
[71/891855] process > NFCORE_SCRNASEQ:SCRNASEQ:IN... [100%] 1 of 1, cached: 1 ✔
[ce/64a733] process > NFCORE_SCRNASEQ:SCRNASEQ:FA... [100%] 34 of 34, cached:...
[dd/820e7e] process > NFCORE_SCRNASEQ:SCRNASEQ:GT... [100%] 1 of 1, cached: 1 ✔
[c8/bf528c] process > NFCORE_SCRNASEQ:SCRNASEQ:CE... [100%] 1 of 1, cached: 1 ✔
[9f/d82b17] process > NFCORE_SCRNASEQ:SCRNASEQ:CE... [100%] 1 of 1, cached: 1 ✔
[d9/2a3171] process > NFCORE_SCRNASEQ:SCRNASEQ:CE... [100%] 34 of 34, failed:...
[-        ] process > NFCORE_SCRNASEQ:SCRNASEQ:MT... -
[-        ] process > NFCORE_SCRNASEQ:SCRNASEQ:MT... -
[-        ] process > NFCORE_SCRNASEQ:SCRNASEQ:MT... -
[-        ] process > NFCORE_SCRNASEQ:SCRNASEQ:CU... -
[-        ] process > NFCORE_SCRNASEQ:SCRNASEQ:MU... -
Execution cancelled -- Finishing pending tasks before exit
-[nf-core/scrnaseq] Pipeline completed with errors-
Error executing process > 'NFCORE_SCRNASEQ:SCRNASEQ:CELLRANGER_ALIGN:CELLRANGER_COUNT (HPAP-037)'

Caused by:
  Process `NFCORE_SCRNASEQ:SCRNASEQ:CELLRANGER_ALIGN:CELLRANGER_COUNT (HPAP-037)` terminated with an error exit status (1)

Command executed:

  cellranger \
      count \
      --id='sample-HPAP-037' \
      --fastqs=. \
      --transcriptome=cellranger_reference \
      --sample=HPAP-037 \
      --localcores=12 \
      --localmem=72 \
  
  
  cat <<-END_VERSIONS > versions.yml
  "NFCORE_SCRNASEQ:SCRNASEQ:CELLRANGER_ALIGN:CELLRANGER_COUNT":
      cellranger: $(echo $( cellranger --version 2>&1) | sed 's/^.*[^0-9]\([0-9]*\.[0-9]*\.[0-9]*\).*$/\1/' )
  END_VERSIONS

Command exit status:
  1

Command output:
  ERROR: No input FASTQs were found for the requested parameters.
  
  If your files came from bcl2fastq or mkfastq:
   - Make sure you are specifying the correct --sample(s), i.e. matching the sample sheet
   - Make sure your files follow the correct naming convention, e.g. SampleName_S1_L001_R1_001.fastq.gz (and the R2 version)
   - Make sure your --fastqs points to the correct location.
   - Make sure your --lanes, if any, are correctly specified.
  
  Refer to the "Specifying Input FASTQs" page at https://support.10xgenomics.com/ for more details.
  

Command wrapper:
  ERROR: No input FASTQs were found for the requested parameters.
  
  If your files came from bcl2fastq or mkfastq:
   - Make sure you are specifying the correct --sample(s), i.e. matching the sample sheet
   - Make sure your files follow the correct naming convention, e.g. SampleName_S1_L001_R1_001.fastq.gz (and the R2 version)
   - Make sure your --fastqs points to the correct location.
   - Make sure your --lanes, if any, are correctly specified.
  
  Refer to the "Specifying Input FASTQs" page at https://support.10xgenomics.com/ for more details.
  

Work dir:
'''omitting personal folders'''
  /gpfs42/..../..../....../..../...../work/ca/.... 

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

[grst]

Thanks for reporting @lewis9914!
Linking a related (though not identical) issue: #147

[grst]

Should finally be fixed on dev via #246.