<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi again,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The missing BAM_EDIT field will be fixed in release/91 of VEP, due in a few weeks.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="margin: 0px;"><a href="https://github.com/Ensembl/ensembl-vep/commit/d1204ccc0a17b8056a8a789ed29f1c5e434ed21c">https://github.com/Ensembl/ensembl-vep/commit/d1204ccc0a17b8056a8a789ed29f1c5e434ed21c</a></div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Regards</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Will</div> <br> <div id="bloop_sign_1511796551929594880" class="bloop_sign"></div> <br><p class="airmail_on">On 23 November 2017 at 9:42:21 am, William McLaren (<a href="mailto:wm2@ebi.ac.uk">wm2@ebi.ac.uk</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div>
<title></title>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
Sorry, I wasn’t clear - BAM_EDIT should appear in the VCF output,
but I think there’s a bug that means it isn’t being included.</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
Will</div>
<br>
<div id="bloop_sign_1511430107232079104" class="bloop_sign"></div>
<br>
<p class="airmail_on">On 23 November 2017 at 7:30:00 am, Luke
Goodsell (<a href="mailto:l.goodsell@achillestx.com">l.goodsell@achillestx.com</a>)
wrote:</p>
<blockquote type="cite" class="clean_bq">
<div bgcolor="white" lang="EN-GB" link="blue" vlink="purple" xml:lang="EN-GB">
<div>
<div class="WordSection1">
<p class="MsoNormal"><span>Hi Will,</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thanks for the information and
suggestion. How do I find the BAM_EDIT status in the VCF
annotation?</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<p class="MsoNormal"><span><span style="color:black">Kind
regards,</span></span></p>
</div>
<p class="MsoNormal"><span style="color:black">Luke</span></p>
<p class="MsoNormal"> </p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From:</span></b> <span style="font-size:12.0pt;color:black">Dev <dev-bounces@ensembl.org>
on behalf of William McLaren <wm2@ebi.ac.uk><br>
<b>Reply-To:</b> Ensembl developers list
<dev@ensembl.org><br>
<b>Date:</b> Wednesday, 22 November 2017 at 13:20<br>
<b>To:</b> Ensembl developers list <dev@ensembl.org><br>
<b>Subject:</b> Re: [ensembl-dev] VEP missing annotation for
intergenic-corrected variants</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div id="bloop_customfont">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Hi
Luke</span></p>
</div>
<p class="MsoNormal"> </p>
<p class="airmailon">On 22 November 2017 at 11:41:43 am, Luke
Goodsell (<a href="mailto:l.goodsell@achillestx.com">l.goodsell@achillestx.com</a>)
wrote:</p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Hi
Will,<span class="apple-converted-space"> </span><br>
<br>
Thanks for fixing the bug so quickly. I have tested the variant
with your change and it now annotates correctly for me.<span class="apple-converted-space"> </span><br>
<br>
If I understand correctly:<span class="apple-converted-space"> </span><br>
<br>
* Using EnsEMBL’s corrected alignment of the RefSeq transcripts (as
a consequence of the implicit use of ‘--use_transcript_ref’ from
the new BAM-containing VEP cache), these variants hit NBPF1 and
LOC645166, but are synonymous and non-coding
respectively.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>Correct - these consequence calls really now just represent the
location of the called variant, not the impact of any allele change
(since there isn’t one!)</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
* Using RefSeq’s alignment of the transcripts (when forced with
‘--use_given_ref’) they are annotated as missense and non-coding
respectively.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>—use_given_ref forces VEP to use your input allele (i.e. the one
from the genome) to call the consequences in place of the one from
the RefSeq transcript. This annotation should be considered invalid
in this case, as any consequence calls would be made on incorrect
data (at least for that transcript).</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
* The variants have been flagged with ‘rseq_cds_mismatch’, so the
transcripts’ sequences don’t match the reference
genome.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>Correct; this system was used by VEP before we provided the
BAM-edited transcripts.</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
* When I use default output rather than VCF, the BAM_EDIT status is
“OK”, so the sequence of the corrected model matches that in the
BAM alignment.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>Correct. In very rare cases the BAM edit can fail; these are
flagged as such to warn the user there may be errors in any derived
annotation.</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
* When using ‘--use_transcript_ref’, I can check the GIVEN_REF and
USED_REF annotations to see if the reference base has changed as a
result of the corrected alignment.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>Correct again.</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
Remaining questions:<span class="apple-converted-space"> </span><br>
<br>
1. Does EnsEMBL have any recommendations as to what to do in the
event of differing alignments? Use RefSeq/EnsEMBL/caution? The
default use of corrected alignments suggests that you advise
such.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>This is an interesting quandary, and we don’t as yet have any
formal recommendations. Almost all variant calls fed to VEP are
from resequencing experiments where the reference genome has been
used to call variants. Ensembl transcript models are built from the
reference genome, so it is fully valid to use these variant calls
as is to predict how they affect Ensembl transcript models.</p>
<p>RefSeq’s transcript models are built from primary sequence
evidence without necessarily referring to the reference genome (and
the inherent biases in it), so there is an argument that in some
cases it can be more suitable to use these models. However, because
variants are typically called using the reference genome, mapping
those calls to non-genome-based transcript models can be
potentially invalid.</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
2. If variants subject to differing consequences should be handled
with caution, is there an easy way to identify them without running
VEP twice? The last point above only tells me if the specific
reference base is the same, not if it’s in the same position in the
transcript, for example.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>I would not advise combining interpretation across VEP runs with
—use_given_ref vs —use_transcript_ref. I would, however, advise
using the merged cache containing both Ensembl and RefSeq
transcripts, as this allows you to compare annotations between
transcript sets, and follow up with more detailed investigation in
those cases where perhaps they disagree and there is potential for
an effect on your interpretations and conclusions.</p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
Incidentally, it’d be useful to be able to get the BAM_EDIT field
in VCF output, too.<span class="apple-converted-space"> </span></span></p>
</div>
</div>
</blockquote>
</div>
<p>This should be there; I’ll take a look.</p>
<p>Cheers</p>
<p>Will</p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
Kind regards,<span class="apple-converted-space"> </span><br>
Luke<span class="apple-converted-space"> </span><br>
<br>
From: Dev <dev-bounces@ensembl.org> on behalf of William
McLaren <wm2@ebi.ac.uk><span class="apple-converted-space"> </span><br>
Reply-To: Ensembl developers list
<dev@ensembl.org><span class="apple-converted-space"> </span><br>
Date: Tuesday, 21 November 2017 at 17:21<span class="apple-converted-space"> </span><br>
To: Ensembl developers list <dev@ensembl.org><span class="apple-converted-space"> </span><br>
Subject: Re: [ensembl-dev] VEP missing annotation for
intergenic-corrected variants<span class="apple-converted-space"> </span><br>
<br>
Hi Luke,<span class="apple-converted-space"> </span><br>
<br>
Thanks for the report. This was occurring because your input
variant has an ALT allele that matches the reference base in the
RefSeq transcript; VEP was then dismissing this as non-variant so
not producing any output. See [1] for more info on how VEP deals
with RefSeqs that do not match the reference genome.<span class="apple-converted-space"> </span><br>
<br>
I've patched a fix to the ensembl-variation repo which contains the
code for handling this; if you re-run INSTALL.pl you should be able
to pick up the fix.<span class="apple-converted-space"> </span><br>
<br>
We’ll get the web code updated to match hopefully
tomorrow.<span class="apple-converted-space"> </span><br>
<br>
Regards<span class="apple-converted-space"> </span><br>
<br>
Will McLaren<span class="apple-converted-space"> </span><br>
Ensembl Variation<span class="apple-converted-space"> </span><br>
<br>
[1]:
http://www.ensembl.org/info/docs/tools/vep/script/vep_other.html#refseq<span class="apple-converted-space"> </span><br>
<br>
On 21 November 2017 at 2:34:55 pm, Luke Goodsell
(l.goodsell@achillestx.com) wrote:<span class="apple-converted-space"> </span><br>
Apologies for the scrambled VCF data. Here it is with spaces for
tabs:<span class="apple-converted-space"> </span><br>
<br>
#CHROM POS ID REF ALT QUAL FILTER INFO<span class="apple-converted-space"> </span><br>
chr1 16903882 . T C . . .<span class="apple-converted-space"> </span><br>
chr1 148932885 . C T . . .<span class="apple-converted-space"> </span><br>
<br>
Kind regards,<span class="apple-converted-space"> </span><br>
Luke<span class="apple-converted-space"> </span><br>
<br>
On 21/11/2017, 14:32, "Dev on behalf of Luke Goodsell"
<dev-bounces@ensembl.org on behalf of
l.goodsell@achillestx.com> wrote:<span class="apple-converted-space"> </span><br>
<br>
Hi,<span class="apple-converted-space"> </span><br>
<br>
I have a couple of variants (listed below) that are missing output
when run through vep v90.7 for GRCh37 RefSeq transcripts with the
latest cache.<span class="apple-converted-space"> </span><br>
<br>
#CHROMPOSIDREFALTQUALFILTERINFO<span class="apple-converted-space"> </span><br>
chr116903882.TC...<span class="apple-converted-space"> </span><br>
chr1148932885.CT...<span class="apple-converted-space"> </span><br>
<br>
Example command:<span class="apple-converted-space"> </span><br>
<br>
vep --input_file snvs.vcf --output_file snvs_annotated.vcf
--dir_cache [PATH] --fasta [PATH] --cache --offline --assembly
"GRCh37" --refseq --vcf<span class="apple-converted-space"> </span><br>
<br>
The output file is exactly the same as the input but with vep’s
header lines added. I would expect at least something like
“CSQ=C|intergenic_variant|MODIFIER||||||||||||||||||||||||||||” to
be added to the INFO field to show that the variant was passed
through vep.<span class="apple-converted-space"> </span><br>
<br>
I have reproduced this with the online VEP interface
(https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgrch37.ensembl.org%2FHomo_sapiens%2FTools%2FVEP&data=02%7C01%7Cl.goodsell%40achillestx.com%7C06520598b7a04c5c832108d530ecaf4c%7C6681f8afefec4f58b633944e0b80eb58%7C0%7C0%7C636468715487973256&sdata=nCL2VQoHuvQKkUOdjflkHT5A4KK3iuauWga1ioNoZAw%3D&reserved=0
; select “RefSeq transcripts” and set “Get regulatory region
consequences” to “No”).<span class="apple-converted-space"> </span><br>
<br>
Comparing the positions in EnsEMBL’s genome browser and UCSC’s,
these regions appear to be intergenic in EnsEMBL while in UCSC
theyo hit RefSeq transcripts - a pseudogene (LOC645166) and a
protein-coding gene (NBPF1) respectively. If I add the
“--use_given_ref” flag, vep reports the same transcripts as UCSC.
However, this raises two questions:<span class="apple-converted-space"> </span><br>
<br>
1. Is adding the “--use_given_ref” flag the right thing to do? Vep
reports mismatches
(“rseq_mrna_nonmatch&rseq_5p_mismatch&rseq_cds_mismatch&rseq_3p_mismatch&rseq_ens_no_match”),
which suggests that this is not the best mapping for the transcript
and hence why EnsEMBL’s alignment is different.<span class="apple-converted-space"> </span><br>
<br>
2. If I don’t add the “--use_given_ref” flag, why isn’t VEP
reporting these variants as intergenic?<span class="apple-converted-space"> </span><br>
<br>
Kind regards,<span class="apple-converted-space"> </span><br>
Luke<span class="apple-converted-space"> </span><br>
<br>
This e-mail message contains confidential information intended only
for the use of the individual or entity to which it is addressed.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise.
Instead, please notify us immediately by return e-mail and then
delete and discard all copies of the e-mail. We have taken all
reasonable precautions to check this e-mail and any attachments for
viruses, but we cannot accept any liability for any damage
sustained as a result of any virus, worm or other malicious
software. Achilles Therapeutics Limited (10167668) is registered in
England and Wales. The registered office is at 215 Euston Road,
London, NW1 2BE, UK.<span class="apple-converted-space"> </span><br>
_______________________________________________<span class="apple-converted-space"> </span><br>
Dev mailing list Dev@ensembl.org<span class="apple-converted-space"> </span><br>
Posting guidelines and subscribe/unsubscribe info:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.ensembl.org%2Fmailman%2Flistinfo%2Fdev&data=02%7C01%7Cl.goodsell%40achillestx.com%7C06520598b7a04c5c832108d530ecaf4c%7C6681f8afefec4f58b633944e0b80eb58%7C0%7C0%7C636468715487973256&sdata=p1feCi5bUXNnVUui6bmDrG0NnTfhFSiDRDxv65ZolBM%3D&reserved=0<span class="apple-converted-space"> </span><br>
Ensembl Blog:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ensembl.info%2F&data=02%7C01%7Cl.goodsell%40achillestx.com%7C06520598b7a04c5c832108d530ecaf4c%7C6681f8afefec4f58b633944e0b80eb58%7C0%7C0%7C636468715487973256&sdata=pO6uWQUmnm9tLVK3bBjXxZi8RzSgxABgsxVX9V8Vh14%3D&reserved=0<span class="apple-converted-space"> </span><br>
<br>
<br>
<br>
This e-mail message contains confidential information intended only
for the use of the individual or entity to which it is addressed.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise.
Instead, please notify us immediately by return e-mail and then
delete and discard all copies of the e-mail. We have taken all
reasonable precautions to check this e-mail and any attachments for
viruses, but we cannot accept any liability for any damage
sustained as a result of any virus, worm or other malicious
software. Achilles Therapeutics Limited (10167668) is registered in
England and Wales. The registered office is at 215 Euston Road,
London, NW1 2BE, UK.<span class="apple-converted-space"> </span><br>
_______________________________________________<span class="apple-converted-space"> </span><br>
Dev mailing list Dev@ensembl.org<span class="apple-converted-space"> </span><br>
Posting guidelines and subscribe/unsubscribe info:
http://lists.ensembl.org/mailman/listinfo/dev<span class="apple-converted-space"> </span><br>
Ensembl Blog: http://www.ensembl.info/<span class="apple-converted-space"> </span><br>
<br>
<br>
This e-mail message contains confidential information intended only
for the use of the individual or entity to which it is addressed.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise.
Instead, please notify us immediately by return e-mail and then
delete and discard all copies of the e-mail. We have taken all
reasonable precautions to check this e-mail and any attachments for
viruses, but we cannot accept any liability for any damage
sustained as a result of any virus, worm or other malicious
software. Achilles Therapeutics Limited (10167668) is registered in
England and Wales. The registered office is at 215 Euston Road,
London, NW1 2BE, UK.<span class="apple-converted-space"> </span><br>
_______________________________________________<br>
Dev mailing list Dev@ensembl.org<br>
Posting guidelines and subscribe/unsubscribe info:
http://lists.ensembl.org/mailman/listinfo/dev<br>
Ensembl Blog: http://www.ensembl.info/</span></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
This e-mail message contains confidential information intended only
for the use of the individual or entity to which it is addressed.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise.
Instead, please notify us immediately by return e-mail and then
delete and discard all copies of the e-mail. We have taken all
reasonable precautions to check this e-mail and any attachments for
viruses, but we cannot accept any liability for any damage
sustained as a result of any virus, worm or other malicious
software. Achilles Therapeutics Limited (10167668) is registered in
England and Wales. The registered office is at 215 Euston Road,
London, NW1 2BE, UK.
_______________________________________________<br>
Dev mailing list Dev@ensembl.org<br>
Posting guidelines and subscribe/unsubscribe info:
http://lists.ensembl.org/mailman/listinfo/dev<br>
Ensembl Blog: http://www.ensembl.info/<br></div>
</div>
</blockquote>
</div></div></span></blockquote></body></html>