<p>This was answered by the OP -- it was a bug that has been fixed in a subsequent release, 4.1.5.0. See the release notes here: <a href="https://github.com/broadinstitute/gatk/releases/tag/4.1.5.0" rel="nofollow noreferrer">https://github.com/broadinstitute/gatk/releases/tag/4.1.5.0</a></p>

<blockquote>
  <p>Made callable sites a Long to avoid integer overflow (#6303)</p>
</blockquote>

<p>Issue ticket: <a href="https://github.com/broadinstitute/gatk/issues/6302" rel="nofollow noreferrer">https://github.com/broadinstitute/gatk/issues/6302</a></p>

CC BY-SA 4.0
2020-04-08T10:13:28.963Z
Hey ya, this could be a useful answer if you would provide some details, like the version where the bug is fixed and a link to the changelog. Right now it provides nothing than what OP wrote.
Kamil S Jaron
CC BY-SA 4.0
2020-04-08T14:43:50.163Z
Sure; done. I was just looking to not have it show up as unanswered anymore since the problem was effectively solved. But I get your point.
Geraldine_VdAuwera
CC BY-SA 4.0
2020-04-07T03:12:11.520Z
2020-04-08T14:42:48.793Z
2020-04-08T14:42:48.793Z
Geraldine_VdAuwera
<p>I have adapted my pipeline to the new filtering strategies implemented in gatk 4.1.4.0 and while looking at its output I noticed that the stat file generated by mutect2 has a negative number:</p>

<pre><code>callable -1.538687311E9
</code></pre>

<p>I did not find the documentation about this file content but in the gatk forum it is mentioned that is should represent the number of bases above a certain coverage (10 by default). 
This happened for a WGS sample, while for WES I obtain a more sensible value (well, at least positive and integer, even if maybe a tad high):</p>

<pre><code>callable        8.6884303E7
</code></pre>

<p>Has this happened to anyone else?
I compared the resulting calls obtained for the WGS with a previous version of mutect2 and they are comparable-ish (98% of the new "ones" are in common with the "old" ones), but I am still worried that something fishy is happening, expecially considering that the filtering step of the pipeline uses this stats file.</p>

CC BY-SA 4.0
2019-12-06T09:05:31.737Z
quick followup: seems to be a bug due to an integer overflow (yay Java!), GATK developers have fixed it and I'm trying it out.
vodka
<wgs><gatk>
GATK 4.1.4.0 Mutect stats output
# GATK 4.1.4.0 Mutect stats output

(Asked by: username_0 on 2019-11-28)

I have adapted my pipeline to the new filtering strategies implemented in gatk 4.1.4.0 and while looking at its output I noticed that the stat file generated by mutect2 has a negative number:
callable -1.538687311E9

I did not find the documentation about this file content but in the gatk forum it is mentioned that is should represent the number of bases above a certain coverage (10 by default). 
This happened for a WGS sample, while for WES I obtain a more sensible value (well, at least positive and integer, even if maybe a tad high):
callable        8.6884303E7

Has this happened to anyone else?
I compared the resulting calls obtained for the WGS with a previous version of mutect2 and they are comparable-ish (98% of the new "ones" are in common with the "old" ones), but I am still worried that something fishy is happening, expecially considering that the filtering step of the pipeline uses this stats file.

**Tags:** wgs, gatk
> **Comments:**
> **username_0**: quick followup: seems to be a bug due to an integer overflow (yay Java!), GATK developers have fixed it and I'm trying it out.  

---

## 1 answers

### Answer by username_1 on 2020-04-07. Score: 1

This was answered by the OP -- it was a bug that has been fixed in a subsequent release, 4.1.5.0. See the release notes here: <https://github.com/broadinstitute/gatk/releases/tag/4.1.5.0>

> Made callable sites a Long to avoid integer overflow (#6303)

Issue ticket: <https://github.com/broadinstitute/gatk/issues/6302>

> **Comments:**
> **username_2**: Hey ya, this could be a useful answer if you would provide some details, like the version where the bug is fixed and a link to the changelog. Right now it provides nothing than what OP wrote.  
> **username_1**: Sure; done. I was just looking to not have it show up as unanswered anymore since the problem was effectively solved. But I get your point.  

---

