[ensembl-dev] VEP: Is it possible to add LRG annotations?

[Andrew Carson]

Hi Dr. McLaren,

Sorry for the additional query, but I would like to add to my last posted question. As I investigate further, it seems that I don't understand how the --lrg flag works. Is it adding a second separate annotation if there is an LRG overlap?
I notice that when I run the commands:



perl variant_effect_predictor.pl --fork 4 --no_stats --everything --lrg --cache --format vcf --force_overwrite --check_existing --check_alleles --vcf --no_progress --pubmed --gmaf --maf_1kg --pick -i input.vcf -o output.VEP.vcf



Whenever I get a LRG annotation, there is a separate regular annotation. For example:



1       92941604        .     C       T       .       .       CSQ=T|ENSG00000162676|ENST00000370332|Transcript|synonymous_variant|1570|1251|417|T|acG/acA|COSM1344916|||7/7||||||

|-1||YES|GFI1|HGNC||||protein_coding|ENSP00000359357|PROSITE_profiles:PS50157&SMART_domains:SM00355&Superfamily_domains:SSF57667|CCDS30773.1|ENST00000370332.1:c.1251G>A|ENST00000370332.1:c.1251G>A(p.%3D)|||||



Followed 105 lanes later by:



1       92941604        .     C       T       .       .       CSQ=A|LRG_63|LRG_63t1|Transcript|synonymous_variant|1501|1251|417|T|acG/acA||||7/7|||||||1||YES|LRG_63|LRG||||LRG_g

ene|LRG_63p1|||LRG_63t1.1:c.1251G>A|LRG_63t1.1:c.1251G>A(p.%3D)|||||



This causes the output .vcf to have out of order variants (no longer properly sorted). Not that this is the same consequence but one shown as the + strand (CSQ=T) and one is shown on the - strand (CSQ=A).



Am I doing something wrong here?

Any help would be appreciated.

Thanks!
Andrew





>Thank you very much Dr. McLaren.

>Just one clarification to the LRG choice. Is the LRG always presented as the first consequence (if it exists)? If this is true, then if the --pick chooses the worst consequence, and there are multiple transcripts with the same >"worst consequence", does VEP --pick the first transcript with that consequence? If that is true, if the LRG contains the "worst consequence" along with other similar transcripts, will --pick successfully choose this consequence >over other equal transcripts?



>Any help on this would be appreciated.

>Thank you again!

>Andrew

>

>I should also say that there's currently no way to prioritise LRG

>consequences other than filtering using filter_vep.pl, though this wouldn't

>be a complete solution.

>

>Will

>

>

>On 1 April 2014 09:51, Will McLaren <wm2 at ebi.ac.uk<http://lists.ensembl.org/mailman/listinfo/dev>> wrote:

>

> Hi Andrew,

>

> In fact this is already possible; just add the flag --lrg at runtime. Note

> however that using LRGs depends on connecting to our database, so this will

> not work using --offline and will connect to ensembldb.ensembl.org when

> using --cache. Because of this database connection you may find that the

> script runs more slowly as it attempts to remap your input variants to LRG

> coordinates.

>

> I'm afraid this is missing from the documentation currently, I will get

> that updated.

>

> Regards

>

> Will McLaren

> Ensembl Variation

>

>

> On 31 March 2014 22:24, Andrew Carson <acarson at invivoscribe.com<http://lists.ensembl.org/mailman/listinfo/dev>> wrote:

>

>> Hi ensembl-dev team,

>>

>> I was just wondering if there are plans to incorporate the LRG (locus

>> reference genomic) records into the VEP annotation pipeline (from here:

>> http://www.lrg-sequence.org/home). I only ask because in the HGVS new

>> clinical reporting guidelines they recommend using the LRG sequence (if one

>> is present) to standardize variant reporting.

>>

>>

>>

>> It would also be very useful to have an option where, if a variant

>> overlaps an LRG, you can choose to "pick" that consequence over other

>> consequences.

>>

>>

>>

>> Any thoughts on if this could be added to the development for the next

>> release cycle?

>>

>> Thanks for all of your help!

>>

>>

>>

>> Andrew R. Carson, Ph.D.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20140407/a0c67830/attachment.html>