MultiQC doesn't include FastQC reports for trimmed reads
santiagorevale opened this issue · 5 comments
Description of feature
I believe that having the FastQC reports for the trimmed reads in MultiQC would be a nice useful addition to the report. I would add it after FASP metrics.
Hi santiagorevale, thanks for testing it. This shouldn't be happening. In fact, the FastP section in MultiQC should display both before-trimming and after-trimming QC data... It worked in older versions of this pipeline properly ... Strange 😅
I think the issue is that we are not passing ch_fastqc_trim_multiqc to the MULTIQC_CUSTOM process. Although I'm not good with MultiQC, to be honest. I'm always having issues with it 😄
Found the issue: when --save_merged true is used, the Fastp JSON output key changes from read{1,2}_after_filtering to merged_and_filtered. Since this JSON file is passed to MultiQC, it expects the read1_after_filtering key by default.
Additionally, it seems that the representation of Fastp merged reads metrics in the MultiQC report is not yet supported. See Multiqc#2826.
But we can replace the FastQC (raw) section in the html report by the FastQC (after-trimming) since FastP before tirmming metrics are always present. (just to avoid haivng repeated FastQC sections in the html report)
Hi Daniel. I think it's better to have both FastQC reports "raw" and "trimmed" in MultiQC. Not only because people is used to them but also because it has some plots that FastP doesn't, like "Adapter Content", which I believe is very important.
Regarding the location, I have changed my mind, and I think that it would be best to show them like:
- FastQC (raw)
- FastQC (trimmed)
- FastP
I believe other pipelines include them all as well.