Tagged with #liftovervariants 1 documentation article | 0 announcements | 2 forum discussions

Created 2012-07-23 23:56:01 | Updated 2012-07-23 23:56:01 | Tags: liftovervariants gatkdocs

A new tool has been released!

Check out the documentation at LiftoverVariants.

No posts found with the requested search criteria.

Created 2013-05-15 20:22:17 | Updated 2013-05-15 20:26:59 | Tags: liftovervariants

When running the LiftoverVariants command, the resulting VCF header has the old contig names (ex. b37 to hg19, chromosome one's name is still "1" rather than "chr1"). This only affects the header, while the variants themselves are successfully changed. I am running "2013.1-2.4.9-3-g512dc3e". The command I used is shown below: <gatk> -R <human_g1k_v37>.fasta -T LiftoverVariants -V <in>.vcf -dict <hg19>.dict -o <out>.vcf -chain <b37tohg19>.chain

Thanks for your help!

Created 2012-10-18 23:10:15 | Updated 2012-10-19 17:56:13 | Tags: bundle liftovervariants hapmap

Hi,

We are sequencing some of the HapMap samples (NA19240 for instance) and we compared the calls we get for the HapMap samples with the calls that are reported for these samples in the file "hapmap_3.3.b37.vcf" that was part of the GATK bundle 1.5.

We are surprised to find a lot of discordant calls, but when we verified the calls, we could see no evidence in the HapMap sequence data for many of them.

We see the discordance at many sites and the vast majority of those show multiple alleles for the positions (like this one:

13 32914977 rs11571660 A C,T . PASS AC=1,2785;AF=0.00036,0.99964;AN=2786;set=Intersection GT 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 ... )

We call many of these sites as Homozygous REF...

When I inspect the header I see this in the header:

##reference=Homo_sapiens_assembly18.fasta


But the file seem to suggest it was done against b37 which implies hg19... Was this file created with liftover?

Also...Could it be possible that HG19 was updated to reflect the most common allele in the population (as you can see of the MAF of 0.00036 for this example) when it went from HG18 to HG19, but that the VCF file was not updated for the HapMap 3.3 samples to reflect this?

So the bottom line is, that the HapMap3.3 file could not be used to rely on the actual calls for the HapMap samples, since about 10% of the sites show variant calls, while the HG19 reference shows no variance...

I know that HapMap is used for different purpose in GATK (Variant Score Calibration), but we may want to warn the public that you cannot use the file as a source of variation for the HapMap samples it reports on...

Thanks

Thon