# Tagged with #homozygosity 0 documentation articles | 0 announcements | 5 forum discussions

No posts found with the requested search criteria.
No posts found with the requested search criteria.

Created 2014-11-10 18:29:28 | Updated 2014-11-10 18:30:16 | Tags: haplotypecaller homozygosity

Hi,

I have the below variant from GATK Haplotype caller and annotated as 1/1 which means homozygous for the alternate allele.

chr1    10023229    .   G   A   101.03  .   AC=2;AF=1.00;AN=2;BaseQRankSum=-0.742;DP=49;Dels=0.00;FS=0.000;HaplotypeScore=0.0000;MLEAC=2;MLEAF=1.00;MQ=8.21;MQ0=42;MQRankSum=0.742;QD=2.06;ReadPosRankSum=-0.742 GT:AD:DP:GQ:PL 1/1:42,7:47:12:129,12,0


However, the AD column shows there are 42 reads for reference and 7 reads for alternate allele. Could someone comment on this snp being reported as homozygous for alternate allele despite of having very few reads supporting it.

Created 2013-07-04 12:22:17 | Updated | Tags: homozygosity gatk

Hi,

I have two SNP calls as shown below:

The first SNP is categorized as 1/1 and the second SNP as 0/1. For both the SNP's the variant allele ratio are 30/32=0.9375 and 30/33=0.909 which are approximately equal and above 0.9. On what criteria one SNP is determined as 0/1 and the other as 1/1?

As per my knowledge both the SNPs should be 1/1. Could anyone comment the reason for this discrepancy?

Created 2013-06-10 15:35:25 | Updated 2013-06-10 17:13:05 | Tags: unifiedgenotyper homozygosity haloplex heterozygosity

Dear developers, I have looked into the forum for similar questions but I couldn't find any. I have several cases in which I get homozygous calls in positions with ~50% of reads calling the mutation (or less), please find here an example of a position validated by Sanger (as het) in which I have a high coverage (~400 reads in total) here is the results with UnifiedGenotyper:

#CHROM  POS     ID      REF     ALT     QUAL    FILTER  INFO    FORMAT  L1


can you help me in this case? I am really puzzled.
I have run it with v2.2, 2.4 and 2.5 and I always had the same genotype call (the excerpt here is from the 2.5, I have downloaded it just to check it was not caused by a bug already fixed). It's not a downsampling issue since I have high coverage samples (HaloPlex) and used higher dcov than the default.

Created 2013-02-11 16:29:00 | Updated | Tags: unifiedgenotyper homozygosity heterozygosity

I have a VCF containing 7.4m SNPs over 70 individuals from an F2 intercross, called by the UnifiedGenotyper v2.3.6. I am trying to set appropriate thresholds for filtering these SNPs. The attached plots summarise the individual calls from this data set, with depth on the x-axis, genotype quality on the y-axis and frequency of particular DP+GQ combinations shown in greyscale. The first plot shows 0/1 (heterozygote) calls, the second shows 0/0 (homozyote) calls (the 1/1 plot looks similar to the 0/0 plot).

The homozygote plot shows a clear relationship between minimum depth and maximum GQ; it is impossible to get high GQs at low depth. However, this is not the case for heterozygotes. This makes intuitive sense to me - at low depth, one cannot be sure that a call really is homozygote; perhaps the other allele simply hasn't been sequenced. But we can have more confidence in a low depth heterozygote, as both alleles have been seen.

However, I am wondering what your recommendations for best practice are here; do you recommend using the same GQ thresholds for homozygote and heterozygote calls, or different thresholds? If the same thresholds, it seems like there will be a bias at low coverage; many (quite possibly real) homozygote calls will be excluded, which will make it appear that there is an excess of heterozygosity in low coverage individuals.

Also, there seems to be a periodicity in the homozygote (but not the heterozygote) GQ values; GQ values divisible by three have a different distribution to other GQ values. I assume this doesn't affect the results too much (after all, the scale is fairly arbitrary in the first place) but I'd be interested to know what causes this, if it is known.