https://nf-co.re logo
Join Slack
Powered by
Hi. I ran the rnaseq pipeline basically as default...
# rnaseq
w
Hi. I ran the rnaseq pipeline basically as default, without 
--remove_ribo_rna
. And I checked the parameter json file in the report to make sure it was indeed 
false
. However, the multiqc report still has a section named "Bowtie2 (rRNA removal)", and the following "Paired-end alignments" section appears to be a sub-section. I believe this is just a fake title, but wonder why the pipeline renders it this way.
j
Thanks for the report, I'll look into it
Pretty sure this is the fix, would you be able to try it out off the branch if you can? https://github.com/nf-core/rnaseq/pull/1761
👍 1
thankyou 1
w
The dev branch fixed it. Thanks!
👍 1
@Jonathan Manning Sorry, but I just noticed another thing. The "General statistics" section is misformatted. The data for different samples are expanded in inconsistent ways. Some samples have no data at all. See the attached example. I checked the files under 
multiqc_report_data
. 
multiqc_bowtie2_bowtie2_alignment.txt
has correct data, but the content in 
multiqc_general_stats.txt
is messed up. They are attached.
multiqc_general_stats.txt
multiqc_bowtie2_bowtie2_alignment.txt
j
OK thanks, will look
The issue is that MultiQC's 
table_sample_merge
feature groups samples ending in `_1`/`_2` as "Read 1"/"Read 2" in the General Statistics table. This works well for most sample naming schemes, but when sample IDs themselves end in 
_1
or 
_2
(like your 
Td_Mut1365_1
, 
Td_Mut1365_2
), it misinterprets those as read pair indicators and corrupts the table. As an immediate workaround, create a small YAML file (e.g., 
no_merge.yml
) with this content:
Copy code
table_sample_merge: false
Then pass it to the pipeline:
Copy code
--multiqc_config no_merge.yml
This disables the read-pair grouping in the General Statistics table, and your samples should display correctly. The per-read detail is still available in the dedicated FastQC and Cutadapt report sections. I've also opened (https://github.com/nf-core/rnaseq/pull/1777) to add a 
--multiqc_table_sample_merge false
parameter so this can be toggled directly on the command line without needing a config file. Actually we decided the config file is probably any enough workaround.
w
@Jonathan Manning Thanks! I just renamed my samples to avoid _1 _2 suffixes. I added rRNA removal (using SortMeRNA by default) this time. In the general statistics section, %rRNA is shown for read2 only. I guess this is some sort of mistake, not because SortMeRNA was run only on Read2, or only Read2 could be matched to rRNA in SILVA ref, am I right? Sorry to keep bugging you!
j
No need to apologise, these are good catches! You're right that this is a display artifact, not a real biological result. SortMeRNA processes both reads together as a pair (
--paired_in
) and produces a single log per sample. The issue is that MultiQC's SortMeRNA module extracts the sample name from a "Reads file:" line inside the log content rather than from the log filename. For paired-end data, the log contains two "Reads file:" lines (one per read), and the parser happens to use the second one (R2). That name retains a 
_2
suffix after cleaning, so 
table_sample_merge
slots the %rRNA value into the "Read 2" row. The %rRNA value itself is correct for both reads combined. As before, you can work around this with a custom MultiQC config. Create a YAML file (e.g., 
fix_sortmerna.yml
) with:
Copy code
use_filename_as_sample_name:
  - sortmerna

extra_fn_clean_exts:
  - ".sortmerna"
Then pass it to the pipeline:
Copy code
--multiqc_config fix_sortmerna.yml
This is definitely something we should do, so I've also pushed a fix in https://github.com/nf-core/rnaseq/pull/1781 so this will be included in the next release.
w
Thanks! I'll try this. About rRNA removal, even though ribo-depletion was included in the library prep for these samples, there is still up to ~10% rRNA content reported by SortMeRNA. Would you recommend doing rRNA removal in this case?
j
Maybe ask this on the channel in a new thread? There are others here with wider experience on actually running these experiments who might have more useful insight
👍 1
2 Views
Open in Slack
PreviousNext
Powered by