Multiqc: Kraken ZeroDivisionError

[choudharis2]

Description of bug:
Some of our samples reporting following Kraken module error in multiqc 1.9. we are using the kraken2/2.0.7.

MultiQC Error log:

Module kraken raised an exception: Traceback (most recent call last):
  File "/python3.7/site-packages/multiqc-1.9-py3.7.egg/multiqc/multiqc.py", line 569, in run
    output = mod()
  File "//multiqc/1.9/lib/python3.7/site-packages/multiqc-1.9-py3.7.egg/multiqc/modules/kraken/kraken.py", line 60, in __init__
    self.sum_sample_counts()
  File "//multiqc/1.9/lib/python3.7/site-packages/multiqc-1.9-py3.7.egg/multiqc/modules/kraken/kraken.py", line 134, in sum_sample_counts
    self.kraken_sample_total_readcounts[s_name] = round(float(row['counts_rooted']) / (row['percent'] / 100.0))
ZeroDivisionError: float division by zero

File that triggers the error:

MultiQC run details (please complete the following):

• Command used to run MultiQC:
• MultiQC Version:
• Operating System:
• Python Version:
• Method of MultiQC installation:

Additional context

[acbellorib]

Hi there,
thanks for providing this wonderful tool! Just to report that I've gotten exactly the same error message when trying to run MultiQC 1.9 (installed on a fresh Conda environment with Python 3.7, just like suggested in the MultiQC manual, over a Linux CentOS 7 3.10.0-957.27.2.el7.x86_64 kernel) on one of our Kraken (1.1.1) reports. I will continue to investigate the issue on my side but any hint or help would be highly appreciated! Cheers, Antonio.

[apeltzer]

Hi both!

I've just encountered the same issue and found the reason for this behaviour. If you run Kraken2 on data and supply the parameter --report-zero-counts, then some categories will have a denominator of zero, which leads to such a divison by zero and thus to a numeric exception raised by python and a failure of the kraken2 module.

https://github.com/nf-core/viralrecon/blob/master/main.nf#L2076--L2085

(as an example code). When I remove that --report-zero-counts, the module runs fine for all the datasets that crashed previously.

Solution/Bugfix would be that we add a pseudo-count to zero-counts (?) and thus the division cannot go wrong here: https://github.com/ewels/MultiQC/blob/7584e64e10885f38367628a5a4a9033d48e82011/multiqc/modules/kraken/kraken.py#L134

@ewels what do you think? I can probably take this on then for an upcoming MultiQC release....

[apeltzer]

Sorry if that wasn't clear: For _me_ it was the --report-zero-counts but I'm not sure whether this holds true for everyone else! Although I believe that this setting controls whether to display zero counts in the output at all in general - so should potentially help resolve this for others until we have a working bugfix in the kraken2 module that fixes the issue in MultiQC. Until then, simply omitting that parameter in kraken/kraken2 should make the current MultiQC module work for you @choudharis2 , @acbellorib and @rpetit3

[acbellorib]

Thanks, Alexander, for the verification and tip! I'll make some tests asap! Cheers, Antonio.

[davidealbanese]

I encountered the same error using kraken2 2.0.9-beta without the option --report-zero-counts and MultiQC 1.9.
I think that using the kraken2 percentages (row['percent']) in:

https://github.com/ewels/MultiQC/blob/7584e64e10885f38367628a5a4a9033d48e82011/multiqc/modules/kraken/kraken.py#L134

is quite dangerous since they include only two decimal digits and can potentially be 0.00 in all samples considered.

Files that trigger the error:
kraken_reports.tar.gz

[ewels]

Thanks all! Sounds sensible @apeltzer though I would prefer to simply catch the exception - that's what I usually do in these circumstances. eg:

try:
    self.kraken_sample_total_readcounts[s_name] = round(float(row['counts_rooted']) / (row['percent'] / 100.0))
except ZeroDivisionError:
    self.kraken_sample_total_readcounts[s_name] = 0

@davidealbanese - is there an alternative to using the percentages? I would assume from looking at the code snippet that this is a workaround to get the total counts which would be impossible by other means. If we have actual total counts then I agree that it would be better. I have a vague, vague memory that the report might truncate off some categories which meant that they couldn't be summed to a library total or something? But I could be confusing this with another MultiQC module.

Phil

[davidealbanese]

@ewels, the PR #1347 fix the issue by using the counts only. The total count is simply the sum of the counts of each taxa.
I'm pretty sure that kraken2 only reports the classified reads, and the reported percentages refer to that number.