Open suzyhh opened 1 month ago
Hi @suzyhh , thank you for reporting the issue. Can you kindly provide us the input file/test input used?
@likhitha-surapaneni
I have attached the input file (bgzipped for compatibility with github) that generates the error - ta!
Hi @suzyhh , thank you for providing us the file. We know why --hgvsg
might be erroring out and are trying to push in a post-release fix for it (related to https://github.com/Ensembl/ensembl-variation/pull/1124)
Regarding the warnings associated with --hgvs
, we are trying to investigate this and will update you
Hi @suzyhh , the fixes for the error are now available on the latest docker images (latest
or release_113.1
).
The warning "Transcript-assembly mismatch in rs586178" means there is a mismatch between refseq and ensembl in this position. By default, VEP uses the ref alleles from refseq. For this example variant rs586178, the HGVSc is NM_001330430.4:c.48C>C, this is not a valid variant (basically edits the ref G to a C ). After editing the allele the variant becomes C>C. The consequence is synonymous which is also not correct. If you use --use_given_ref , the output would be NM_001330430.4:c.48G>C. Hope this is useful. We will try to make the warning and docs clearer for this case.
Thank you and let us know if this solves the issue.
@likhitha-surapaneni Thanks so much for this fix, I can now run the new version of 113 :)
I have to admit I don't 100% understand the --use_given_ref
option, but I have tested in v113 and it doesn't seem to have the behaviour you describe. I've tested using rs778986.
When I run without --use_given_ref
I see the behaviour you described, with the variant being incorrectly described as synonymous with the nomenclature G>G:
However when I run with --use_given_ref
, the HGVSc is no longer G>G, but I think is also incorrect (A>G and it should be T>C?), and the consequence and codons is also incorrect:
I've tested with v112 using --use_given_ref
and this gives me what I expect is the correct behaviour:
The cDNA change in the HGVSc is also T>C in v112 which I think is correct
Many thanks!
Hi @suzyhh ,
Thank you for reporting this issue with clear examples. We are currently putting in a fix to return the correct HGVSc. Upon investigation, it turns out that the consequence calculation is ignoring the flag --use_given_ref
particularly in 113 (it is reported correctly in 112 as illustrated in the examples provided). We are working on this and will let you know once we have an update.
Thank you for your patience.
Hiya @likhitha-surapaneni
I think I've found an additional bug(s) in the HGVS calculations in v113.1 possibly relating to the original error I reported. I've found several instances where variants are describe as "ins" by the HGVSc but "dup" by the HGVSg and vice versa:
1) HGVSc described as "ins"; HGVSg described as "dup": While I haven't checked extensively, it looks like this error is occuring on variants with more than 1 alternate allele. This is the VCF entry for the first variant in the above screenshot: Here is an example of the VCF VEP output for a few of these variants: hgvsC_ins_example.vep.vcf.txt
2) HGVSc described as "dup"; HGVSg described as "ins": There's fewer of these, and I can't see anything tying these variants together apart from the fact they are all rather large duplications (all are >50bp in size). Here is an example of the VCF VEP output for a few of these: hgvsG_ins_example.vep.vcf.txt
Thank you!
Describe the issue
Hello, I'm testing v113 using the v113 docker obtained from docker hub and the v113 cache downloaded using the following command:
docker run --network host -t -i -v /mnt/data1/software/vep/:/opt/vep/.vep ensemblorg/ensembl-vep:release_113.0 INSTALL.pl -a c -s homo_sapiens_merged -y GRCh38
I have successfully tested v113 with a VCF containing structural variants, but I encounter an error when running with a VCF containing SNVs/indels. After the error the process just hangs doing nothing until I kill it. The output files contains the VCF header but no variants.
System
Full VEP command line
Full error message
I have tested my command using v112 and it completes successfully with no errors/warnings so it does seem to be a v113 problem. Running locally I have found that the problem occurs when using the
--hgvsg
flag. If I run using only--hgvs
I do not get the above error, but I do get several warnings, here is a small snippet:I do not receive any errors or warning when I run v113 without both
--hgvs
and--hgvsg
. This unfortunately renders v113 unusable for us as we rely on the hgvs annotations.Many thanks!