The current GATK version is 3.7-0
Examples: Monday, today, last week, Mar 26, 3/26/04

#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

You can opt in to receive email notifications, for example when your questions get answered or when there are new announcements, by following the instructions given here.

#### ☞ Got a problem?

1. Search using the upper-right search box, e.g. using the error message.
3. Include tool and Java versions.
4. Tell us whether you are following GATK Best Practices.
5. Include relevant details, e.g. platform, DNA- or RNA-Seq, WES (+capture kit) or WGS (PCR-free or PCR+), paired- or single-end, read length, expected average coverage, somatic data, etc.
6. For tool errors, include the error stacktrace as well as the exact command.
7. For format issues, include the result of running ValidateSamFile for BAMs or ValidateVariants for VCFs.
8. For weird results, include an illustrative example, e.g. attach IGV screenshots according to Article#5484.
9. For a seeming variant that is uncalled, include results of following Article#1235.

#### ☞ Formatting tip!

Wrap blocks of code, error messages and BAM/VCF snippets--especially content with hashes (#)--with lines with three backticks (  ) each to make a code block as demonstrated here.

**GATK4-BETA.2** is here. That's TWO, as in the second beta release. Be sure to read about the known issues before test driving. See Article#9881 to start and https://github.com/broadinstitute/gatk/blob/master/README.md for details.

Member

I am trying to liftover from NIST b37 to hg19. I have all the files I need and I can kick off the liftover just fine, but I keep running into problems because the NIST vcf has tags in the variant line INFO field that are not in the header.
##### ERROR MESSAGE: Key PLHSWG found in VariantContext field INFO at chr1:52238 but this key isn't defined in the VCFHeader. We require all VCFs to have complete VCF headers by default

I identified about 90 tags that are not properly documented in the header.
Is there a way to ignore all of these INFO header lapses?

Tagged:

You can probably work around this using --unsafe LENIENT_VCF_PROCESSING` but keep in mind there's a good reason why this argument is called unsafe... And if you experience issues down the road with this VCF, we won't be able to provide any support (using an unsafe argument is a bit like voiding the warranty on an electronic device).