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!

VariantAnnotator: "--annotation Coverage" updating INFO DP but not sample-level (FORMAT) DP

dpoznikdpoznik StanfordMember

I have constructed a VCF using GenotypeGVCFs. Due to downsampling and filtering imposed by HaplotypeCaller/GenotypeGVCFs, four fields of interest within the VCF do not reflect the data that went into building the file. I would like to update a these fields to reflect all read data used in the pipeline, but I have been able to do so for just 3 of the 4. I have been able to update INFO MQ0, INFO DP, and sample-level (FORMAT) AD, but I have not been able to update sample-level (FORMAT) DP.

I have run VariantAnnotator as follows.



java -Xmx10g \
  -jar $gatk \
  -T VariantAnnotator \
  -R $ref \
  -L $inVCFfn \
  --variant $inVCFfn \
  --dbsnp $dbsnp \
  --out $outVCFfn \
  --annotation Coverage \
  --annotation DepthPerAlleleBySample \
  --annotation MappingQualityZero \
  [-I fileName.1.bam … -I fileName.810.bam]

The documentation for --annotation Coverage indicates that it should update both the INFO DP and the sample-level (FORMAT) DP, but the sample-level update seems not to be occurring. For example:

$ awk '($2==7157834) { print $9, "|", $53 }' raw.vcf
GT:AD:DP:GQ:PL | 0:4,0:4:99:0,135

$ awk '($2==7157834) { print $9, "|", $53 }' raw.annotated.vcf
GT:AD:DP:GQ:PL | 0:131,0:4:99:0,135

(Aside: I'm working with a haploid chromosome, hence the single-value GT and two-value AD and PL fields). Although AD was updated from "4,0" to "131,0", the sample-level "DP" remained at "4". Of course I could approximate DP as the sum of AD values, but since AD is pre-filter and sample-level DP is post-filter, this wouldn't quite be correct. I should note that when I run HaplotypeCaller/GenotypeGVCFs on a subset of the data, the sample-level DP values are very close to the sum of AD's, so it's not a matter of most reads being filtered out, but rather that they have been downsampled. Am I missing something?


P.S. The INFO field DP and MQ0 are indeed updated as expected:

$ awk '($2==7157834) { print $8 }' raw.vcf

$ awk '($2==7157834) { print $8 }' raw.annotated.vcf

Best Answer


  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

    Hi David,

    No offense, but this is a very bad idea. By design, the call annotations in the VCF reflect the data that the caller/genotyper actually used in their calculation. Changing them undermines your ability to troubleshoot, analyze and further process calling metrics. If you want the VCF to include information about how much data was originally present in the file, I would suggest adding that as separate annotations, without overwriting the call metrics.

  • dpoznikdpoznik StanfordMember

    Hi Geraldine,

    Thanks for your reply. I didn't plan to delete the original file. Rather, I wanted to generate a parallel file that includes a summary of the available data. For my work, it is helpful to know whether a site resides in a region of inflated read depth or inflated MQ0 proportion, regardless of which reads were evaluated by the genotype caller. Similarly, for genotype look-ups, it's often helpful to know how many reads support a given call, regardless of how many the caller considered.

    If you want the VCF to include information about how much data was originally present in the file, I would suggest adding that as separate annotations, without overwriting the call metrics.

    Could you recommend an efficient means of doing so (ideally with a correct total-data FORMAT DP equivalent)? I'd considered running DepthOfCoverage, processing the results and merging with the VCF. This would yield total-data equivalents of INFO DP, FORMAT AD, and FORMAT DP (but not INFO MQ0), but this approach seemed a less efficient means to the same end. Is there a way to get VariantAnnotator to add fields with a non-default identifier rather than overwrite?

    Thanks for your help!

  • dpoznikdpoznik StanfordMember

    OK, no problem. Thanks for the info!

Sign In or Register to comment.