You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're finding that in rare instances that GenotypeGVCFs can emit a variant with a spanned allele (*), and a genotype that references the spanned allele, but fail to emit the upstream spanning variant. This seems like a bug to me - either the spanning variant should be emitted or the spanned allele should revert to a reference call.
FWIW I have a sneaking suspicion that this is related to setting a non-zero value for -stand-call-conf (see #5793). My guess is that in one part of the code it determines the upstream variant will be emitted so retains the allele as spanned, but then somewhere later the upstream variant is filtered out.
Affected tool(s) or class(es)
GenotypeGVCFs
Affected version(s)
Latest public release version [4.1.2.0]
Latest master branch as of [not tested]
Description
Here's the example from the VCF in the attached zip file:
#CHROM POS ID REF ALT QUAL FILTER INFO FORMAT test_sample
chr17 46806234 . TC T 148.64 . ... GT:AD:DP:F1R2:F2R1:GQ:PL 0/1:208,25:239:116,16:90,8:99:156,0,6824
chr17 46806237 . TTCTCTCTCTCTC TTCTC,* 1528.04 . ... GT:AD:DP:F1R2:F2R1:GQ:PL 1/2:3,60,33:174:1,29,20:1,21,11:99:3633,1088,2142,1538,0,3285
You can see from this that a) the first variant does not have a spanned allele, implying that there cannot be a spanning event further upstream and b) the second variant has a spanned allele that is present in the 1/2 genotype.
Steps to reproduce
The attached zip file contains a reduced test case with a 3-record gVCF and a 2-record VCF that exhibits the problem. To reproduce:
Unzip the attached zip file
Edit command.sh to put in the path to HG19
Run . command.sh in the directory with the extracted files
Expected behavior
Either the spanning variant should be emitted, or the spanned allele should not be.
Actual behavior
A spanned allele is emitted when there is no spanning variant!
Bug Report
We're finding that in rare instances that
GenotypeGVCFs
can emit a variant with a spanned allele (*
), and a genotype that references the spanned allele, but fail to emit the upstream spanning variant. This seems like a bug to me - either the spanning variant should be emitted or the spanned allele should revert to a reference call.FWIW I have a sneaking suspicion that this is related to setting a non-zero value for
-stand-call-conf
(see #5793). My guess is that in one part of the code it determines the upstream variant will be emitted so retains the allele as spanned, but then somewhere later the upstream variant is filtered out.Affected tool(s) or class(es)
GenotypeGVCFs
Affected version(s)
Description
Here's the example from the VCF in the attached zip file:
You can see from this that a) the first variant does not have a spanned allele, implying that there cannot be a spanning event further upstream and b) the second variant has a spanned allele that is present in the
1/2
genotype.Steps to reproduce
The attached zip file contains a reduced test case with a 3-record gVCF and a 2-record VCF that exhibits the problem. To reproduce:
command.sh
to put in the path to HG19. command.sh
in the directory with the extracted filesExpected behavior
Either the spanning variant should be emitted, or the spanned allele should not be.
Actual behavior
A spanned allele is emitted when there is no spanning variant!
ZIP file with test case: spanned_allele_not_spanned.zip
The text was updated successfully, but these errors were encountered: