<div dir="ltr">Just to follow up, I've pushed a fix to GitHub so that the allele is reported correctly for the LRG consequence lines.<div><br></div><div>Will</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 8 April 2014 10:02, Will McLaren <span dir="ltr"><<a href="mailto:wm2@ebi.ac.uk" target="_blank">wm2@ebi.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Andrew,<div><br></div><div>LRGs have their own coordinate system in Ensembl, with each LRG being mapped to its own "seq_region" (think of this like a mini-chromosome containing the LRG gene and 5kb of flanking sequence either side). This is because the reference sequence for an LRG can differ from the core human reference sequence from GRC. </div>
<div><br></div><div>When you run the VEP with --lrg, the Ensembl API attempts to map your genomic input coordinates to the LRG coordinate system, creates a duplicate internal variation object representing this mapping, then does its usual consequence calling thing on the custom LRG transcript(s) that exist on that coordinate system. As a result of this, since the VEP sorts output by chromosome, the results that map to LRGs will jump out of order here. This will look particularly odd if you use VCF output as the coordinates in the VCF will be retained from your input. I'm afraid currently there's no way around this as it's just how the API operates.</div>
<div><br></div><div>When you use --pick, the code for this considers only the consequence calls within one of these internal variation objects, so for each mapping it will pick one consequence amongst the Ensembl transcripts and one amongst the LRG transcripts.</div>
<div><br></div><div>Regarding the strand issue, this may be a bug - within the LRG coordinate system the LRG gene is considered to map to the forward strand, even if this whole coordinate system maps to the reverse strand of the reference genome (as it would for a reverse strand gene). I'll take a look at this as it may be that the VEP is doing the wrong thing here.</div>
<div><br></div><div>Cheers</div><div><br></div><div>Will</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On 7 April 2014 22:28, Andrew Carson <span dir="ltr"><<a href="mailto:acarson@invivoscribe.com" target="_blank">acarson@invivoscribe.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div lang="EN-US" link="blue" vlink="purple"><div><pre>Hi Dr. McLaren,<u></u><u></u></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:<u></u><u></u></pre><pre><u></u> <u></u></pre><pre>perl <a href="http://variant_effect_predictor.pl" target="_blank">variant_effect_predictor.pl</a> --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<u></u><u></u></pre>
<pre><u></u> <u></u></pre><pre>Whenever I get a LRG annotation, there is a separate regular annotation. For example:<u></u><u></u></pre><pre><u></u> <u></u></pre><pre>1 92941604 . C T . . CSQ=T|ENSG00000162676|ENST00000370332|Transcript|synonymous_variant|1570|1251|417|T|acG/acA|COSM1344916|||7/7||||||<u></u><u></u></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)|||||<u></u><u></u></pre>
<pre><u></u> <u></u></pre><pre>Followed 105 lanes later by:<u></u><u></u></pre><pre><u></u> <u></u></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<u></u><u></u></pre>
<pre>ene|LRG_63p1|||LRG_63t1.1:c.1251G>A|LRG_63t1.1:c.1251G>A(p.%3D)|||||<u></u><u></u></pre><pre><u></u> <u></u></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).<u></u><u></u></pre>
<pre><u></u> <u></u></pre><pre>Am I doing something wrong here?<br><br>Any help would be appreciated.<u></u><u></u></pre><pre>Thanks!<span><font color="#888888"><br>Andrew<u></u><u></u></font></span></pre><div>
<pre><u></u> <u></u></pre><pre><u></u> <u></u></pre><pre>>Thank you very much Dr. McLaren.<u></u><u></u></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?<u></u><u></u></pre>
<pre><u></u> <u></u></pre><pre>>Any help on this would be appreciated.<u></u><u></u></pre><pre>>Thank you again!<u></u><u></u></pre><pre>>Andrew<u></u><u></u></pre><pre>><u></u> <u></u></pre><pre>><i>I should also say that there's currently no way to prioritise LRG<u></u><u></u></i></pre>
<pre>><i>consequences other than filtering using <a href="http://filter_vep.pl" target="_blank">filter_vep.pl</a>, though this wouldn't<u></u><u></u></i></pre><pre>><i>be a complete solution.<u></u><u></u></i></pre>
<pre>><i><u></u> <u></u></i></pre><pre>><i>Will<u></u><u></u></i></pre><pre>><i><u></u> <u></u></i></pre><pre>><i><u></u> <u></u></i></pre></div><div><pre>><i>On 1 April 2014 09:51, Will McLaren <wm2 at <a href="http://ebi.ac.uk" target="_blank">ebi.ac.uk</a><<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a>>> wrote:<u></u><u></u></i></pre>
<pre>><i><u></u> <u></u></i></pre><pre>><i> Hi Andrew,<u></u><u></u></i></pre><pre>><i><u></u> <u></u></i></pre><pre>><i> In fact this is already possible; just add the flag --lrg at runtime. Note<u></u><u></u></i></pre>
<pre>><i> however that using LRGs depends on connecting to our database, so this will<u></u><u></u></i></pre><pre>><i> not work using --offline and will connect to <a href="http://ensembldb.ensembl.org" target="_blank">ensembldb.ensembl.org</a> when<u></u><u></u></i></pre>
<pre>><i> using --cache. Because of this database connection you may find that the<u></u><u></u></i></pre><pre>><i> script runs more slowly as it attempts to remap your input variants to LRG<u></u><u></u></i></pre>
<pre>><i> coordinates.<u></u><u></u></i></pre><pre>><i><u></u> <u></u></i></pre><pre>><i> I'm afraid this is missing from the documentation currently, I will get<u></u><u></u></i></pre><pre>><i> that updated.<u></u><u></u></i></pre>
<pre>><i><u></u> <u></u></i></pre><pre>><i> Regards<u></u><u></u></i></pre><pre>><i><u></u> <u></u></i></pre><pre>><i> Will McLaren<u></u><u></u></i></pre><pre>><i> Ensembl Variation<u></u><u></u></i></pre>
<pre>><i><u></u> <u></u></i></pre><pre>><i><u></u> <u></u></i></pre></div><div><pre>><i> On 31 March 2014 22:24, Andrew Carson <acarson at <a href="http://invivoscribe.com" target="_blank">invivoscribe.com</a><<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a>>> wrote:<u></u><u></u></i></pre>
<pre>><i><u></u> <u></u></i></pre><pre>>><i> Hi ensembl-dev team,<u></u><u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i> I was just wondering if there are plans to incorporate the LRG (locus<u></u><u></u></i></pre>
<pre>>><i> reference genomic) records into the VEP annotation pipeline (from here:<u></u><u></u></i></pre><pre>>><i> <a href="http://www.lrg-sequence.org/home" target="_blank">http://www.lrg-sequence.org/home</a>). I only ask because in the HGVS new<u></u><u></u></i></pre>
<pre>>><i> clinical reporting guidelines they recommend using the LRG sequence (if one<u></u><u></u></i></pre><pre>>><i> is present) to standardize variant reporting.<u></u><u></u></i></pre><pre>>><i><u></u> <u></u></i></pre>
<pre>>><i><u></u> <u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i> It would also be very useful to have an option where, if a variant<u></u><u></u></i></pre><pre>>><i> overlaps an LRG, you can choose to "pick" that consequence over other<u></u><u></u></i></pre>
<pre>>><i> consequences.<u></u><u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i> Any thoughts on if this could be added to the development for the next<u></u><u></u></i></pre>
<pre>>><i> release cycle?<u></u><u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i> Thanks for all of your help!<u></u><u></u></i></pre><pre>>><i><u></u> <u></u></i></pre><pre>>><i><u></u> <u></u></i></pre>
<pre>>><i><u></u> <u></u></i></pre><pre>>><i> Andrew R. Carson, Ph.D.</i><u></u><u></u></pre><p class="MsoNormal"><u></u> <u></u></p></div></div></div><br></div></div>_______________________________________________<br>
Dev mailing list <a href="mailto:Dev@ensembl.org" target="_blank">Dev@ensembl.org</a><br>
Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
Ensembl Blog: <a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>