"Obvious variant" missed by GATK UnifiedGenotyper

[Jon_Keats]

You need to be careful of calling so aggressively that the "not-so-likely" variants are called. What will most likely happen is your will end up with a bunch of recurrent variants that are all noise as some regions will come up again and again with such relaxed settings and you will waste your time and money validating false positives. If you goal is what you say try screening samples with a stringent filter, then generate a pileup of the individual positions with samtools to see if the same variant exists in the other samples. Assuming the variant if frequent is should show up with a stringent filter in at least one sample if not a couple/most of the samples. This should limit the number of false positives detected and eliminate a horrible realization that your bioinformatics filtering strategy resulted in a validation rate of 2%. Tends to make PIs and pipet jockeys chase you around the institute with anger in their eyes.

[Yilong Li]

Yes, I fully agree that this particular position has so many dubious factors that it is unlikely to be a true variant .

However, currently we would like to find recurrent variants present in multiple samples. For example, if a high confidence variant was called at this position in another sample, we would like to know whether there is even the weakest evidence that a variant exists also in the current sample. That's why we want to get the not-so-likely variants called as well.

[nilshomer]

Also observe that all the Cs are from reads on the same strand. Not a good thing!

[Yilong Li]

I have done realignment but not base quality recalibration.

If I understood correctly though, GATK UG calls variants from a bam file and does not know whether the realignment or recal has been done, so even if the base qualities I use were recalibrated, GATK UG wouldn't make any differing calls.

[jstjohn]

Hi Yilong,
Did you follow the full GATK protocol with realignment and base quality recalibration prior to genotyping? I agree that a "C" call does not seem very likely in that position though.
-John

[Yilong Li]

Sorry, I didn't provide enough information regarding the situation. I ran GATK UG using --min_base_quality 1 (so all the grey C bases should have been included in the calling). Data is from Illumina.

There are several C bases in the position with decent quality, although I must say those reads do seem a bit dubious. I agree that this could be a false positive (haven't Sanger sequenced), but I am still interested what happens internally in GATK UG at this position and how I could call this or similar position as variant loci. I am trying to find recurrent mutation within a set of samples and therefore want to achieve maximal a relatively high sensitivity for single sample variant calls.

[nilshomer]

Two things to observe:

1. The "C" bases are shaded or greyed out, meaning they are of low quality.
2. They are towards the ends of reads (SOLID?), and are therefore more ambiguous. Also, he top C read has another improper C to the left (same for some of the others), so how much should we trust this/these reads?

I think the genotyper did the absolute correct thing. Have you tried validating this with Sanger Sequencing?

I would not trust a C here.

[Yilong Li]

Hi all,

We have noticed in our lab that GATK UnifiedGenotyper misses some variants (as one shown in the IGV figure below) that seem reasonably obvious with good alt. allele counts.

I ran GATK UG -all_bases, and this site was called as

1       43308444        .       A       .       35.64   .       AC=0;AF=0.00;AN=2;DP=38;Dels=0.00;MQ=57.26;MQ0=0        GT:DP:GQ:PL     0/0:24:5.65:0,6,677

Does anybody have any ideas why GATK UG called this site as ref (with such high confidence!) and how to loosen up the GATK UG parameters to have this site called as a variant?

Yilong