mmm, interesting, the only modules that I can find (bamcmp and umitools/group) both regenerate the index

I would say that making the sam file for test-datasets would be the easiest.

Thanks for the pointers @Simon Pearce! I saw the mention of the

delete_me

folder in the README for temporary or niche datasets. Since uncompressed SAM files and tool-specific BWA indexes are quite specific to CIRI2 module, would it be safest/preferred for me to upload these to the

delete_me

folder, or should I place them directly into the standard

genomics/homo_sapiens/

directory structure? Let me know what works best!

No, please don't put anything in

delete_me

, it is a terrible place

Do you just need a sam file rather than a bam file?

I'm not convinced you need the -T either

oh, it needs the index for the tool?

image.png

ok, so it works on bam files, and it works with just the genome fasta

so you can test it with the current files

Found another way to test CIRI2 module. Since the standard

test-datasets

are heavily downsampled and yield 0 circular RNAs, I was wondering if I could use the official CIRI2 sample dataset instead? It includes a tiny, pre-aligned

test.sam

and a matching

chr1.fa

that are guaranteed to output circular RNAs, which would allow me to write solid

nf-test

assertions against non-empty files. If that works, would it be okay if I submit a PR to add both the

.sam

and

.fa

files to the

test-datasets

repo simultaneously?

sam and bam are the same data, just one is compressed so it is considerably smaller than the other

the -T filter is entirely optional here, it will just mean that there is less rubbish for the tool to go through

But provided the files are small, you can add them to test-datasets if you really wish.

@Simon Pearce I shared the wrong link yesterday. github.com/nf-core/test-datasets/blob/…/ADD_NEW_DATA.md Here the guidelines hyperlink for test data is broken. Can you please check for this issue.

Hi @Simon Pearce! Regarding this PR: github.com/nf-core/modules/pull/12224 I ran CIRI2 on the author's official test dataset in its native SAM format, and it successfully identified 6 circular RNAs. When converting that exact same file to BAM (preserving all headers and flags via

samtools view -h -b

), CIRI2 ran without throwing a terminal error, but returned 0 circular RNAs.

CIRI2.pl

is a Perl script designed to parse plain text CIGAR strings, SAM headers, and BWA-MEM alignment tags. When given a binary BAM file, the Perl script reads compressed binary stream data instead of text. It doesn't crash, but it fails to recognize any reads or alignment tags, silently yielding zero candidate circular RNAs. If we force the module to take a BAM file directly to satisfy channel format conventions, the module will technically run without error, but anyone running this module on real-world sample data will receive zero predictions, even when circular RNAs are present. Is the primary goal of an nf-core module just to execute cleanly without crashing, or is it to ensure the underlying tool accurately detects real biological signals for users? Looking forward to your review. Thanks!

frankly, if the code is that shoddy, you shouldn't be using it

@Matthieu Muffato Tested process substitution (

<(...)

) to avoid materializing a SAM file but it fails, because CIRI2.pl does two full passes over the input (see its own log: 'First scanning' / 'Second scanning'), which requires a seekable file, not a pipe. I've kept the conversion but added a cleanup step (

rm

after CIRI2 runs) so the intermediate SAM doesn't persist in the final work/output directory, minimizing the disk footprint while still working with the tool's actual requirements.