[ensembl-dev] VEP v82: Different handling when SVTYPE is defined in VCF INFO field

[Will McLaren]

Hi Cyriac,

The SVTYPE info field flags to the VEP that it should treat the input as a
structural variant.

These are treated as different object types by the VEP. The main effect is
that sequence is not considered as it not normally provided explicitly for
SVs.

If you can, you should only use SVTYPE to annotate "true" structural
variants, i.e. those described as e.g. <DEL> or <TDUP> in the ALT field.
For any that have explicit sequence in the REF and ALT fields, you should
remove the SVTYPE field as this will lead to more precise annotation in the
VEP for these positions.

Regards

Will McLaren
Ensembl Variation

On 23 November 2015 at 22:55, Cyriac Kandoth <kandoth at cbio.mskcc.org> wrote:

> Hi,
>
> For the minimalist VCF and VEP command below, using mus_musculus and
> GRCm38, the output VCF appears to skip reporting fields like HGVSc,
> ALLELE_NUM, and EXON/INTRON positions. This does not happen if I remove
> "SVTYPE=DEL" from the input VCF. Am I breaking VCF conventions by
> specifying SVTYPE=DEL? Should it only be used for larger structural
> variants?
>
> Thanks,
> Cyriac
>
> --
> *test.vcf contains:*
> ##fileformat=VCFv4.2
> #CHROM POS ID REF ALT QUAL FILTER INFO
> 11 96283450 . TG T . PASS SVTYPE=DEL
>
> *VEP v82 command with local GRCm38 cache:*
> perl variant_effect_predictor.pl --offline --species mus_musculus
> --assembly GRCm38 --vcf --input_file test.vcf --output_file test.vep.vcf
>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20151124/f8c6b78a/attachment.html>