[ensembl-dev] dev-owner at ensembl.org

Helen Schuilenburg helens at ebi.ac.uk
Tue Jun 18 11:52:17 BST 2019


Hi David

On 18/06/2019 10:08, David Tamborero wrote:
> Hi Helen,
>
> (sorry for the late response, i was travelling)
>
> indeed, it looks like the combo to make the VEP run stop is:
>
> - --tab as output format
> - the REF==ALT
> - the next line to the REF==ALT entry is *a different* chromosome
>
There was a bug when the last entry on a chromosome was a variant with 
REF==ALT.
We pushed a fix yesterday to our current release (release/96) and it 
will be in future releases.

Thank you for reporting the problem.
> on the other hand, regarding the 'concept' of null variant, do you 
> think that a REF==ALT should be considered as so? I mean, should not 
> be annotated as silent, as opposite to true 'non valid' variant 
> statements as that passing an ALT of '.' ?
>
When using the --allow_non_variant VEP expects a non-variant to be 
represented with an ALT with the missing value (.)

If the variant has REF==ALT, the variant is not included in tab output 
but included in VCF (with no consequence).

For vcf variants with REF==ALT, vcf-validator warns "REF allele listed 
in the ALT field??"

We will review the REF==ALT  in VEP and VEP documentation.

Regards
Helen

> thanks!
> d
>
> El jue., 13 jun. 2019 a las 10:06, Helen Schuilenburg 
> (<helens at ebi.ac.uk <mailto:helens at ebi.ac.uk>>) escribió:
>
>     Hi David
>
>     On 07/06/2019 18:44, David Tamborero wrote:
>>     Hi Helen
>>
>>     FYI, if I m not wrong at this time of the day, VEP run (--tab
>>     output) stops(w/o any msg or warning file created) as soon as a
>>     line with REF==ALT is reached, so it does not seem to need to
>>     'accumulate' a number of these 'non-variant' entries
>>
>     I am looking into this. Is the variant following the line with
>     REF==ALT on the same chromosome?
>>     on the other hand, as you say, when using vcf as output with the
>>     --allow_non_variant flag, entries as e.g.
>>
>>     12 111352091 16500 C C . PASS
>>
>>     are included in the output w/o any annotation,
>>
>     When using VCF format as input and output, by default VEP will
>     skip non-variant lines of input (where the ALT allele is null).
>
>     Enabling the --allow_non_variant option the lines will be printed
>     in the VCF output with no consequence data added.
>
>     VEP expects the ALT allele to be null to skip non-variant lines e.g.
>
>
>     ##fileformat=VCFv4.0
>     #CHROM    POS    ID    REF    ALT    QUAL    FILTER INFO
>     22    17181903    var_1    A    G    .    .    .
>     22    17188416    var_2    T    .    .    .    .
>     22    19353405    var_3    G    A    .    .    .
>
>     Regards
>     Helen
>
>
>>     thanks!
>>     and have a nice weekedn
>>     d
>>
>>
>>     El vie., 7 jun. 2019 a las 18:25, Helen Schuilenburg
>>     (<helens at ebi.ac.uk <mailto:helens at ebi.ac.uk>>) escribió:
>>
>>         Hi David
>>
>>         Thanks for the information.
>>
>>         The VEP should skip non-variant lines of input by default and
>>         not stop.
>>
>>         We will look at updating the stats to report the lines skiped.
>>
>>         When using VCF format as input and output, by default VEP
>>         will skip non-variant lines of input. Please could you try
>>         running your sample variants with vcf output (--vcf) and
>>         --allow_non_variant.
>>
>>         https://www.ensembl.org/info/docs/tools/vep/script/vep_options.html#filt
>>
>>         With the text output, it should also skip the non-variant
>>         lines. VEP could be stopping on your input file, if it has
>>         skipped a number of non-variant lines. We will look into this
>>
>>         Regards
>>         Helen
>>
>

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


More information about the Dev mailing list