HaplotypeCaller failed to make a variant call

There are a few possibilities as to why HaplotypeCaller chose not to make a call for this SNP. 

1. HaplotypeCaller uses a more stringent mapping quality filter than UnifiedGenotyper (Is UnifiedGenotyper what you meant by “GenotypeCaller”?). Depending on what the mapping qualities in this area of reads is, the evidence that HaplotypeCaller is seeing may be very different than what UnifiedGenotyper is seeing to make the call.
2. HaplotypeCaller is not a locus walker as UnifiedGenotyper is. It doesn’t look at the pileup as presented to it. In areas of potential variation, it will gather all of the reads that pass its quality filters and perform a de novo assembly of these reads. This can potentially resolve false positives due to misalignment. And once the reassembly occurs, the BAM will not look like the original BAM that you are seeing in the browser picture.

One way to determine if the newly assembled BAM still shows this SNP is to use the “-bamout” argument in HaplotypeCaller. This will print out a new BAM file reflecting the reassembled reads that HaplotypeCaller is ultimately using to make its calls. As doing this for an entire BAM is quite compute intensive, we suggest writing out these small BAMs on test regions only, limiting your work using a “-L” argument to a region of ~1000 bp around the area you wish to examine. For example, you would run HaplotypeCaller as you previously did, but add “-bamout WhateverBAMNameYouLike.bam –L 19:38992600-38993600”. Make sure the chromosome designations match your reference genome designations. This would be –L 19 for GRCh37 and –L chr19 for hg19 reference.