We've moved!
This site is now read-only. You can find our new documentation site and support forum for posting questions here.
Be sure to read our welcome blog!

Why is HaplotypeCaller not calling obvious SNPs by default but requires -allowNonUniqueKmersInRef?


I'm calling SNPs for bacterial genomes. I've been using UnifiedGenotyper to call SNPs, and I'm looking to migrate to HaplotypeCaller. This change from UnifiedGenotyper to HaplotypeCaller requires validating SNPs being called. I've came across a situation where a SNP is being called in only some genomes using the HaplotypeCaller, but the SNP is clearer present in all genomes when visually validated in IGV. After trying many HaplotypeCaller arguments, only when using -allowNonUniqueKmersInRef was the position correctly called in all genomes. Can you describe what this flag is doing to allow the position to be called correctly in all genomes, and describe why when using the default HaplotypeCaller parameters this SNP is not found in all?

This is the position when called using -allowNonUniqueKmersInRef.
gi|561108321|ref|NC_018143.2| 3336835 . T C 1278.77 . AC=2;AF=1.00;AN=2;DP=44;FS=0.000;MLEAC=2;MLEAF=1.00;MQ=59.18;MQ0=0;QD=29.06;SOR=0.739 GT:AD:DP:GQ:PL 1/1:0,43:43:99:1307,128,0

Thank you,

Issue · Github
by Geraldine_VdAuwera

Issue Number
Last Updated


  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

    Hi Tod,

    What's probably happening here is that you have a repetitive context around the variant, which causes problems during the re-assembly step of HaplotypeCaller. I'm not sure why the process seems to be more problematic in some samples than in others (coverage and/or quality may be involved) but I can tell you that using the argument allowNonUniqueKmersInRef allows the program more freedom to deal with the repetitive nature of the reference sequence. Without it, the program may be forced to give up on reassembling the region, and to simply skip to the next region, which I believe is why you're not getting calls there at all.

    Using allowNonUniqueKmersInRef systematically can cause problems, so we'd be reluctant to propose it as a general solution for repetitive contexts. Instead, we've been toying with some other ideas for dealing with repetitive contexts in a more appropriate way, but it will be a while before we have a solution ready for general use. In the meantime, you may want to continue using allowNonUniqueKmersInRef, albeit keeping a cautious eye on results.

Sign In or Register to comment.