SelectVariants cannot filter variant types for GVCFs (VariantTypesVariantFilter)

[michaelgatzen]

When running gatk SelectVariants -V ... --select-type SNP -O ... on GVCFs the output is empty, since every GVCF VariantContext is assigned the type MIXED in HTSJDK, due to its symbolic alternate allele (e.g. <NON_REF>,A).

[michaelgatzen]

Is this expected? If not, how should we address that? I could think of copying the type determination code from HTSJDK into VariantTypesVariantFilter and accounting for this case, which would fix the problem for this filter. However I could also imagine that always assigning MIXED to every GVCF variant isn't very helpful in other situations, but making a change in HTSJDK's VariantContext would probably have massive downstream effects.

Also referenced here: https://gatk.broadinstitute.org/hc/en-us/community/posts/360071943332-SelectVariants-error

[droazen]

@michaelgatzen I agree that this behavior seems non-helpful -- perhaps SelectVariants needs a special GVCF-aware mode. I'd consult with @ldgauthier to see what she thinks would be best here.

[kachulis]

I think something somewhat similar is happening in #7100, related to the treatment of spanning deletions in htsjdk (discussed a few year ago here: samtools/htsjdk#806). So if there is interest is improving some of the variant typing in htsjdk might be useful to try to resurrect that conversation.

[droazen]

@ldgauthier Would you mind weighing in here on what you think the SelectVariants behavior with GVCFs should be? Should we add in a special mode that is aware of the NON_REF allele?

[droazen]

Another likely related ticket: #7100

[ldgauthier]

GVCF-aware types would be very useful. I've wanted this in the past. My natural inclination is always to add extra args so we don't change the default behavior. How about "--ignore-non-ref-in-types"? And maybe a log info/warning if the input file extension is ".g.vcf" or ".g.vcf.gz" and "-selectType" is specified without the new arg?

I wish that the span del (*) allele was considered symbolic in htsjdk. There a bunch of places I have methods to check for it that really should be pushed down into htsjdk.

[kachulis]

Fixed by #7193

[kachulis]

apparently #7193 hasn't been merged yet...