4
$\begingroup$

I have been trying to understand an error that the EBI's vcf_validator gives when run on my vcf file. Consider this minimal file:

##fileformat=VCFv4.1
##reference=foo
##FORMAT=<ID=GT,Number=1,Type=String,Description="Genotype">
##contig=<ID=chr12>
#CHROM  POS ID  REF ALT QUAL    FILTER  INFO    FORMAT  Sample1
chr12   529514  .   AACAC   AATAC   0.00    .   .   GT  0/1
chr12   529516  .   C   T   .   PASS    .   GT  0/1

If I then run vcf_validator on it, it complains about:

$ cat $(LC_ALL="C" ~/vcf_validator_linux  -i test.vcf |& awk '/written to/{print $NF}' )
According to the VCF specification, the input file is not valid
Error: Duplicated variant chr12:529516:C>T found. This occurs 2 time(s), first time in line 6.

This is because the two variants are indeed the same. Changing AACAC to AATAC at position 529514 just means change C to T at position 529516.

OK, but how is that against the VCF standard? What makes that an invalid VCF file? I am trying to automatically validate input VCF files and stop the analysis if they're invalid, but this seems like a perfectly valid file. Why is vcf_validator not letting it through? The vcf-validator perl script from vcftools doesn't complain about this. So is it just a bug in EBI's vcf_validator or is it really somehow illegal to have duplicate variants in a VCF file according to the specs?

$\endgroup$
  • $\begingroup$ What is the use case for having duplicate variant records in a VCF file? $\endgroup$ – John Marshall Jun 5 at 9:30
  • $\begingroup$ @JohnMarshall none that I know of. But someone sent me a file with such duplicates and I was surprised that they caused the vcf_validator to consider the file invalid, so I asked if there was anything in the specs that would actually make such files invalid. $\endgroup$ – terdon Jun 6 at 13:22
6
$\begingroup$

No. The only point the specification makes is that:

It is permitted to have multiple records with the same POS

I suspect this is intended to let the file list different variants occurring at the same position, but this incidentally allows duplicate variants.

This said, you probably don't want duplicate variants, because it will mess with any statistics you apply over the variants, and will unnecessarily clutter the file and slow down processing, if this happens a lot. You might also get variant annotations on one variant but not another, which can become a problem depending on how you query your variants.

$\endgroup$
  • $\begingroup$ Duplicate variants also point to an issue with upstream analysis. If the variants have different statistics (e.g. in this example one has qual 0.00, and the other has qual "."), then there is a bias in the counting. If the variants have the same statistics, then the lines are redundant. $\endgroup$ – gringer Jun 10 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.