MultiQC: confusing values

[DennisSchmitz]

MultiQC is used to collate as many of the logs as possible in the pipeline. However, the summary table is a bit verbose since it puts the HuGo alignment, pre-trimming and post-trimming values into separate rows instead of combining it into one or two. A minor issue, but something to be aware of. Hopefully issue #19 fixes this by making some of these steps obsolete.

A bigger issue is that the number of reads reported by the HuGo alignment module are incorrect. It only counts the pairs, not the unpaired reads. These unpaired reads are correctly reported into the log/Clean_the_data[sample].log files though. So this requires some further investigation. Or we just omit this module and instead rely on the numbers generated by the barcharts rule. @samnooij , what do you think?

[samnooij]

I also think the table becomes a bit too long like that. For read-based quantifications, one may want to check results/profile_read_counts.csv, generated by the rule quantify_output (bin/quantify_profiles.py). These are also saved as percentages and a stacked barchart separately by the same rule. Nonetheless, it would be nice if the MultiQC table could be made more useful and less cluttered.