Hello!
If I pass a config file (-c) with the list of modules that I want to run, the modules do not appear in the report. They do appear if I don’t pass the config file. The content of the config file is:
run_modules:
- dragen
- dragen_fastqc
Just checked it with the test datasets and it works for me. If I run with the verbose log (-v) I see these lines:
[2024-06-19 12:08:31] multiqc.config [DEBUG ] New config: {'run_modules': ['dragen', 'dragen_fastqc']}
[2024-06-19 12:08:31] multiqc.core.file_search [INFO ] Only using modules: dragen, dragen_fastqc
[2024-06-19 12:08:31] multiqc.core.file_search [DEBUG ] Analysing modules: dragen, dragen_fastqc
The full non-verbose log:
$ multiqc .
/// MultiQC 🔍 v1.23.dev0
config | Loading config settings from: /Users/ewels/.multiqc_config.yml
config | Loading config settings from: multiqc_config.yml
file_search | Only using modules: dragen, dragen_fastqc
file_search | Search path: /Users/ewels/GitHub/MultiQC/test-data
searching | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 2931/2931
mapping_metrics | sum of unpaired/discordant/proppaired/unmapped reads not matching total, skipping mapping/paired percentages plot for: TEST
dragen | Found samples: 18
dragen_fastqc | Found 2 reports
file_search | Only using modules: dragen, dragen_fastqc
write_results | Data : multiqc_data
write_results | Report : multiqc_report.html
multiqc | MultiQC complete
Can you post an example log please?
Did you look at the web report?
My logs also indicate that the the config file is parsed correctly and that the reports and samples are found but they are not present in the web report. I’ve not debugged this yet.
/// MultiQC 🔍 v1.22.2
config | Loading config settings from: /configs/dragen_rnaseq_config.yaml
file_search | Search path: /output
searching | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 169/169
violin | All values are NaN or Inf for metric: Mean/med autosomal coverage
dragen | Found samples: 5
dragen_fastqc | Found 5 reports
write_results | Data : ../../../output/multiqc_data (overwritten)
write_results | Report : ../../../output/test.html (overwritten)
multiqc | MultiQC complete
[2024-06-19 08:19:01] multiqc.config [INFO ] Loading config settings from: /configs/dragen_rnaseq_config.yaml
[2024-06-19 08:19:01] multiqc.config [DEBUG ] New config: {'run_modules': ['dragen', 'dragen_fastqc']}
1 Like
It’s a bit of a nasty one. The run_modules config option actually expects a list of module “anchors”, and for DRAGEN the anchor is all-uppercase:
MultiQC/multiqc/modules/dragen/dragen.py at 034e1c05867475d5643dd439555229410aae5f02 · MultiQC/MultiQC · GitHub, and for dragen_fastqc, it’s dragen-fastqc:
MultiQC/multiqc/modules/dragen_fastqc/dragen_fastqc.py at 034e1c05867475d5643dd439555229410aae5f02 · MultiQC/MultiQC · GitHub
However, passing those as run_modules wouldn’t work either because further MultiQC also checks values against the list of module entry points, which are lowercase dragen and dragen_fastqc. Sorry, it’s a bit of a mess.
I’ve been working on unit tests recently, and added some order into anchors and entry points, making them match with each other and contain only underscore-separated lowercase, so your config would work correctly. I’ll let you know when I’m done. We’ll follow up with a patch release soon.
1 Like
Confirmed that I see the same @jfnavarro - apologies for this. Growing pains as we go back through the codebase and refactor / tidy up past technical debt.
@vlad.savelyev in addition to the above work, we should put in some logging error messages when things aren’t recognised so that it’s immediately obvious that there’s a problem with the MultiQC config…
Fixed now with Correctly use module ids `run_modules` by vladsavelyev · Pull Request #2633 · MultiQC/MultiQC · GitHub - will be a part of the patch release soon!
@vlad.savelyev in addition to the above work, we should put in some logging error messages when things aren’t recognised so that it’s immediately obvious that there’s a problem with the MultiQC config…
We already have it, actually:
It didn’t work this time because the run_modules expected anchors, but the check looked at the lowercase module ids. Fixed that discrepancy now. And I’ll extend the error message with the pointer to the list of available module ids to be more helpful.
2 Likes
No problem @ewels! The refactor had to be done sooner or later 
Glad I can be of help and I appreciate the quick support and turn around
1 Like