[ensembl-dev] [VEP] Allele representation leading to strange annotation

Will McLaren wm2 at ebi.ac.uk
Thu May 28 13:56:11 BST 2015

Hi again Konrad,

I added in a flag for release 80, --minimal, see

Note the caveats that reported coordinates etc may get screwed up (they
shouldn't if you use VCF output), but if you use VCF in and out and
--allele_number you should be able to keep track of everything OK.



On 16 April 2015 at 15:43, Will McLaren <wm2 at ebi.ac.uk> wrote:

> Hi Konrad,
> Thanks for finding this.
> We'll look into a solution, though as it will involve significant code
> refactoring, it won't be available until (at the earliest) the next
> VEP/Ensembl release (80, due some time next month).
> In the short term you could break out the variant onto separate VCF lines,
> though I appreciate that introduces difficulties with individual-level data.
> Regards
> Will
> On 16 April 2015 at 05:30, Konrad Karczewski <konradk at broadinstitute.org>
> wrote:
>> Hi Will, VEP folk,
>> Unfortunately, allele representation has bit us once again. We have the
>> following variant:
>> Which is really a SNV that overlaps a larger deletion. VEP reads this
>> and since that sequence overlaps a splice acceptor (e.g. ENST00000378373),
>> it marks it as a splice_acceptor_variant (even though it doesn't change the
>> acceptor site - just tried VEP v79 on GRCh37 and same issue). Ideally, we'd
>> put this through minimal representation (as we have implemented here:
>> https://github.com/ericminikel/minimal_representation which nicely cuts
>> the alleles down), but unfortunately inside a multi-sample VCF, this
>> doesn't really work. Is there a way for this to happen inside VEP/is there
>> a fix to this?
>> Thanks!
>> -Konrad
>> _______________________________________________
>> 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/20150528/b6575e4c/attachment.html>

More information about the Dev mailing list