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

[David Tamborero]

thanks for this and your work!

br
d

El mar., 18 jun. 2019 a las 12:53, Helen Schuilenburg (<helens at ebi.ac.uk>)
escribió:

> 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>)
> 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>)
>> 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
>>>
>>
>>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org
> Ensembl Blog: http://www.ensembl.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20190618/ad94f758/attachment.html>