The current GATK version is 3.8-0
Examples: Monday, today, last week, Mar 26, 3/26/04

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Get notifications!

You can opt in to receive email notifications, for example when your questions get answered or when there are new announcements, by following the instructions given here.

Got a problem?

1. Search using the upper-right search box, e.g. using the error message.
2. Try the latest version of tools.
3. Include tool and Java versions.
4. Tell us whether you are following GATK Best Practices.
5. Include relevant details, e.g. platform, DNA- or RNA-Seq, WES (+capture kit) or WGS (PCR-free or PCR+), paired- or single-end, read length, expected average coverage, somatic data, etc.
6. For tool errors, include the error stacktrace as well as the exact command.
7. For format issues, include the result of running ValidateSamFile for BAMs or ValidateVariants for VCFs.
8. For weird results, include an illustrative example, e.g. attach IGV screenshots according to Article#5484.
9. For a seeming variant that is uncalled, include results of following Article#1235.

Did we ask for a bug report?

Then follow instructions in Article#1894.

Formatting tip!

Wrap blocks of code, error messages and BAM/VCF snippets--especially content with hashes (#)--with lines with three backticks ( ``` ) each to make a code block as demonstrated here.

Jump to another community
Download the latest Picard release at
GATK version 4.beta.3 (i.e. the third beta release) is out. See the GATK4 beta page for download and details.

Significantly different runtimes for HaplotypeCaller on same BAMs & region

I have a region which worked fine, but now doesn't seem to work. Here is a part of the run using version 2.5
17:66743059-81195210.it1hc.stdout-INFO 21:59:30,131 ProgressMeter - 17:73500213
17:66743059-81195210.it1hc.stdout-INFO 22:00:30,949 ProgressMeter - 17:73500549
17:66743059-81195210.it1hc.stdout-INFO 22:01:31,026 ProgressMeter - 17:73500549
17:66743059-81195210.it1hc.stdout-INFO 22:02:31,045 ProgressMeter - 17:73500549
17:66743059-81195210.it1hc.stdout:INFO 22:03:31,063 ProgressMeter - 17:73500593
17:66743059-81195210.it1hc.stdout-INFO 22:04:31,098 ProgressMeter - 17:73501295

As you can see it made it by 17:73500549 in about 3 minutes. I am rerunning the same BAMs in the same region with version 2.6, and now it has been stuck on 17:73500549 for >12 hours. Even when rerunning the same version I have noticed that usually runs take about the same time, but every so often are orders of magnitude longer. I am using -dcov 200, so I know there is some sampling variation (although in this region everyone is between 50-100 reads coverage), but a difference of 3 minutes to > 600 minutes seems excessive.

Any suggestions on making runtimes for regions more predictable?



Best Answer


  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie

    Hmm, that does seem excessive. Could you please try re-running that region with the latest nightly build? If you still see problematic runtimes, we'll ask for a test file that reproduces the problem, so we can debug it locally and find out what is causing the slowdown.

  • ebanksebanks Broad InstituteMember, Broadie, Dev

    How many samples/BAMs are you running with?

  • trgalltrgall Member

    ~80 samples with ~110 BAMs.

Sign In or Register to comment.