<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Courier New";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><pre>Hi Dr. McLaren,<o:p></o:p></pre><pre>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?<br>I notice that when I run the commands:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Whenever I get a LRG annotation, there is a separate regular annotation. For example:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>1       92941604        .     C       T       .       .       CSQ=T|ENSG00000162676|ENST00000370332|Transcript|synonymous_variant|1570|1251|417|T|acG/acA|COSM1344916|||7/7||||||<o:p></o:p></pre><pre>|-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)|||||<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Followed 105 lanes later by:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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<o:p></o:p></pre><pre>ene|LRG_63p1|||LRG_63t1.1:c.1251G>A|LRG_63t1.1:c.1251G>A(p.%3D)|||||<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Am I doing something wrong here?<br><br>Any help would be appreciated.<o:p></o:p></pre><pre>Thanks!<br>Andrew<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>>Thank you very much Dr. McLaren.<o:p></o:p></pre><pre>>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?<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>>Any help on this would be appreciated.<o:p></o:p></pre><pre>>Thank you again!<o:p></o:p></pre><pre>>Andrew<o:p></o:p></pre><pre>><o:p> </o:p></pre><pre>><i>I should also say that there's currently no way to prioritise LRG<o:p></o:p></i></pre><pre>><i>consequences other than filtering using filter_vep.pl, though this wouldn't<o:p></o:p></i></pre><pre>><i>be a complete solution.<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i>Will<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i>On 1 April 2014 09:51, Will McLaren <wm2 at ebi.ac.uk<<a href="http://lists.ensembl.org/mailman/listinfo/dev">http://lists.ensembl.org/mailman/listinfo/dev</a>>> wrote:<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> Hi Andrew,<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> In fact this is already possible; just add the flag --lrg at runtime. Note<o:p></o:p></i></pre><pre>><i> however that using LRGs depends on connecting to our database, so this will<o:p></o:p></i></pre><pre>><i> not work using --offline and will connect to ensembldb.ensembl.org when<o:p></o:p></i></pre><pre>><i> using --cache. Because of this database connection you may find that the<o:p></o:p></i></pre><pre>><i> script runs more slowly as it attempts to remap your input variants to LRG<o:p></o:p></i></pre><pre>><i> coordinates.<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> I'm afraid this is missing from the documentation currently, I will get<o:p></o:p></i></pre><pre>><i> that updated.<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> Regards<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> Will McLaren<o:p></o:p></i></pre><pre>><i> Ensembl Variation<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>><i> On 31 March 2014 22:24, Andrew Carson <acarson at invivoscribe.com<<a href="http://lists.ensembl.org/mailman/listinfo/dev">http://lists.ensembl.org/mailman/listinfo/dev</a>>> wrote:<o:p></o:p></i></pre><pre>><i><o:p> </o:p></i></pre><pre>>><i> Hi ensembl-dev team,<o:p></o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i> I was just wondering if there are plans to incorporate the LRG (locus<o:p></o:p></i></pre><pre>>><i> reference genomic) records into the VEP annotation pipeline (from here:<o:p></o:p></i></pre><pre>>><i> <a href="http://www.lrg-sequence.org/home">http://www.lrg-sequence.org/home</a>). I only ask because in the HGVS new<o:p></o:p></i></pre><pre>>><i> clinical reporting guidelines they recommend using the LRG sequence (if one<o:p></o:p></i></pre><pre>>><i> is present) to standardize variant reporting.<o:p></o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i> It would also be very useful to have an option where, if a variant<o:p></o:p></i></pre><pre>>><i> overlaps an LRG, you can choose to "pick" that consequence over other<o:p></o:p></i></pre><pre>>><i> consequences.<o:p></o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i> Any thoughts on if this could be added to the development for the next<o:p></o:p></i></pre><pre>>><i> release cycle?<o:p></o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i> Thanks for all of your help!<o:p></o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i><o:p> </o:p></i></pre><pre>>><i> Andrew R. Carson, Ph.D.</i><o:p></o:p></pre><p class=MsoNormal><o:p> </o:p></p></div></body></html>