Heads up:
We’re moving the GATK website, docs and forum to a new platform. Read the full story and breakdown of key changes on this blog.
If you happen to see a question you know the answer to, please do chime in and help your fellow community members. We encourage our fourm members to be more involved, jump in and help out your fellow researchers with their questions. GATK forum is a community forum and helping each other with using GATK tools and research is the cornerstone of our success as a genomics research community.We appreciate your help!

Test-drive the GATK tools and Best Practices pipelines on Terra

Check out this blog post to learn how you can get started with GATK and try out the pipelines in preconfigured workspaces (with a user-friendly interface!) without having to install anything.

interval lists and -nct threading

Regarding the observation elsewhere: "HaplotypeCaller is slower when restricted to intervals": My test-bed is a 48 core, 100GB RAM CentOS 7 system with GenomeAnalysisTK-3.5 on it. If i submit the command:

java -Xmx16g -jar GenomeAnalysisTK.jar -T HaplotypeCaller -I chr12.bam -R hg19.fasta -o out.vcf -L chr12:40600000-40800000 -nct 36

I can see that the system is indeed using all 36 cores through completion.

But if I choose a small subset of ranges such as


, put them in the file test.list, then the command

java -Xmx16g -jar GenomeAnalysisTK.jar -T HaplotypeCaller -I chr12.bam -R hg19.fasta -o out.vcf -L test.list -nct 36

executes, but quickly drops to one core usage for almost the entire run, taking an unexpectedly long time to complete. This does not seem like the efficiency gain anticipated. I have tested this with other interval file formats, but the problem persists and is easily reproducible. This is indeed unfortunate behavior. Examining just the exons of a region should take less time than examining the whole region, not more.

Is there any hope that this will ever operate as expected, or is the problem too deeply embedded in the threading algorithm? Some explanation would be useful. I am doing everything I can to speed up the GATK best practices methods to use on whole exome datasets, but things like this are frustrating.

-- Fred P.

Best Answer


  • pishottapishotta UBCMember

    Believe it or not, I think I figured out why this is happening. Something like: When you supply a list of regions, the caller steps through that list in sequence, using a number of threads it thinks appropriate for that region. If the regions are small, like the above, it will use just a small number of computational threads, not necessarily the number specified in the -nct option. So in the above example, it used just 1 or 2 threads consecutively for each of the 10 regions, which is why the command with "-L test.list" takes so much longer that "-L chr12:40634200-40672115" which is bigger in total, but therefore able to elicit more simultaneous threads.

    Misleading behavior, but I see no way to force the number of threads used. -nct only seems to set an upper bound. Bottom line: Looks like -nct can hurt you if you are checking many small regions like in an exome analysis.

    Have to rethink this. Maybe it I targeted whole genes and filtered out introns afterwards... Hardly ideal, but it's a thought.

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

    The implementation of multithreading in HC is not very efficient, as you observe. We've seen some benchmarking results that suggest there is no point to using more than 4 to 8 threads with HC.

    In our own work we use scatter-gather parallelism to speed up execution of HC, and scatter by exome target.

Sign In or Register to comment.