Support for 3-file FASTQ inputs from SRA downloads

[emrunali]

Description of feature

The script assumes fastq files come in pairs. For some chemistries, SRA downloads can produce 3 files per sample. I haven't personally verified this causes a failure but wanted to flag it. Is this a known limitation? Happy to investigate further and contribute.

[grst]

Hi, could you clarify for which protocols the 3-file input is needed? The only one I'm aware is 10x v1 and this plays basically no role anymore.

For later 10x protocols, three files may be produced, but the index file can be ignored.

[emrunali]

Hi @grst,

Thanks for the question! The samples I recently worked with were from the study GSE132771, and they used the 10x Genomics 3' v2 protocol. The SRA downloads (via fasterq-dump --split-files --include-technical) produced three FASTQ files per sample:

• _1.fastq: 8 bp (Sample Index / I1)
• _2.fastq: 26 bp (Cell Barcode + UMI / R1)
• _3.fastq: 91 bp (Transcript Read / R2)

In the current cellranger_count.py script, it looks like the logic is set up to find and validate pairs specifically containing the string "R1" (via the filename_pattern). Since these SRA-style filenames use the _1/_2/_3 suffix instead, I was concerned that the current renaming logic might not automatically recognize them as the R1 and R2 reads.
Furthermore, a blind chunk_iter(fastqs, 2) would incorrectly pair _1 and _2, which would cause Cell Ranger to fail during alignment as it looks for 26bp barcodes in an 8bp index file.

Is there a specific preprocessing step or a different module where these files are usually renamed or filtered before they reach this script?

If there is a preferred place to handle the "SRA-to-Illumina" naming conversion, I would love to look into that. Otherwise, if you think it makes sense to add support for these 3-file SRA triplets directly here to make the module more flexible, I am happy to contribute to that enhancement.

Please share your thoughts. Thank you.

[grst]

So if you specify _2.fastq as fastq_1 and _3.fastq as fastq_2 in the samplesheet, the python script should in principle detect the right files based on sorting the files by name, but it would fail the validation because the filenames don't contain the R1/R2. The index read is not required for v2 protocol.

At some point I have been thinking about making a small python package that generically handles renaming of files for 10x-tools. The same renaming logic could also be useful for e.g. spaceranger. Then the renaming logic would become a separate nextflow module instead of being integrated into the cellranger module. The main downside of this approach is that on some cloud file systems, a simple rename will result in a full down and re-upload of the files.

[emrunali]

Thanks for the context, @grst! That makes sense. I can see how a standalone renaming module would be cleaner and more reusable across tools.

Since I am still a beginner at understanding nf-core architecture, I am happy to follow your lead. Would you prefer I hold off until a dedicated renaming module is in place, or is a small targeted fix here acceptable in the meantime?

Maybe I could update the current script to be a bit more flexible, such that it recognizes _1/_2 or _2/_3 patterns when the standard "R1/R2" string isn't present in the filenames.

Please let me know what you think.

[grst]

This sounds like exactly what we need: nextflow-io/nextflow#6905

If this gets supported by nextflow, we could get rid of the entire custom python logic.