I annotated my variants with SnpEff using SnpEff eff: annotate variants (Galaxy Version 4.3+T.galaxy1) on usegalaxy.eu.
When checking the annotated information for two example variants and comparing it to the information available on the Ensemble webpage (Variant Effect Predictor, web version), I found some different transcript information.
For the transcript ENST00000595514 the SnpEff annotation did not include " WARNING_TRANSCRIPT_NO_START_CODON", even though this information is supplied by Ensemble. For all other incomplete transcripts, the warning was correctly annotated.
Furthermore I did not find a way so far to double check the HGVSc annotation by SnpEff for downstream/upstream_gene_varaints, as this is not supplied by e.g. the Ensemble VEP. Is there another easy way to double check the annotated information for downstream/upstream_gene_variants. Or is this not needed, as I can be sure that the annotation process worked correctly, when the rest of the SnpEff annotation (everything except HGVSc for upstream/downstream_gene_variants) for this variant has been proofed correct?
I would be glad for any suggestions!
All the best,
Rose
With the tool you are using, the available built-in indexes can vary across Galaxy servers. When built-in indexes are used, it is important to know these are pre-computed and based on a specific version of the annotation sourced from the SnpEff website: https://sourceforge.net/projects/snpeff/files/databases/v4_3/.
Pre-computed SnpEff indexes can become outdated over time due to additions, changes, or fixes. The annotation reviewed directly at the Ensembl website is always the most current available.
The most current SnpEff annotation can be downloaded or created directly with these tools:
SnpEff download
SnpEff build
As far as double-checking annotation results, the most important item is to avoid genome/build chromosome naming conflicts between inputs. The overall VCF format should also be confirmed to be correct, especially if you needed to modify that VCF in any way (adjust the chromosome names).
Tools that can help with QC or renaming chromosomes (if needed) are here. Usage instructions are on the tool forms.
SnpEff chromosome-inf: get chromosome names in a built-in SnpEff database
SnpSift Extract Fields: get chromosome names in a VCF dataset
Replace chromosome names: change chromosome names in a tabular/VCF file. Use as needed for this and other reasons/tools/protocols. Many chromosome mapping files are available between genome builds/versions or you can create your own mapping file.
SnpSift vcfCheck: basic VCF format validation. It can be run first. And definitely should be run after making any changes.
I used the tool âSnpEff downloadâ to download the SnpEff annotation database. The following is an extract from the stderr with further information regarding the version.
â|00:00:00|SnpEff version SnpEff 4.3t (build 2017-11-24 10:18), by Pablo Cingolani|
|â|---|
|00:00:00|Command: âdownloadâ|
|00:00:00|Reading configuration file âsnpEff.configâ. Genome: âGRCh37.75â|
|00:00:00|Reading config file: /data/dnb02/galaxy_db/job_working_directory/006/494/6494647/working/snpEff.config|
|00:00:00|Reading config file: /usr/local/tools/_conda/envs/__snpeff@4.3.1t/share/snpeff-4.3.1t-0/snpEff.config|
|00:00:03|done|
|00:00:03|Downloading database for âGRCh37.75â|
|00:00:05|Connecting to http://downloads.sourceforge.net/project/snpeff/databases/v4_3/snpEff_v4_3_GRCh37.75.zip|
|00:00:06|Following redirect: https://netcologne.dl.sourceforge.net/project/snpeff/databases/v4_3/snpEff_v4_3_GRCh37.75.zip|
|00:00:07|Local file name: â/tmp/snpEff_v4_3_GRCh37.75.zipâ|â
So I am still confused, why I have a slight difference in the annotated information for one of my example variants compared to the output of the variant effect predictor. (Missing information ( WARNING_TRANSCRIPT_NO_START_CODON) for ENST00000595514). Do you have another idea?
I think my second question was misleading. When checking the annotated information with VEP (Variant Effect Predictor by Ensemble) I had to find out that VEP does not supply the HGVSc for upstream and downstream variants. So I was wondering if there is another option to check the HGVSc for upstream and downstream variants? Or if I am going to far and donât have to do this as I can be sure that using the tool snpeff eff annotate with the downloaded snpeff database on usegalaxy.eu without an error, that the annotation worked fine?
Thanks for the information regarding the QC and renaming chromosome. As I ran the bcftools norm after variant calling and before annotation, I thought this would be sufficient to make sure the vcf is compatible for annotation afterwards (as recommended in the âsomatic variant tutorialâ). Am I wrong?
The version of the SnpEff hosted pre-built indexes and the Galaxy tool that retrieves those indexes have some cross-dependencies. This is due to how database URLs change over time at SnpEff. It is not always obvious which SnpEff indexes can be retrieved with any particular SnpEff download tool version. If the most current tool version fails for a particular pre-built index, then try earlier tool versions.
That said, the current version of the tool SnpEff Download Download a new database (Galaxy Version 4.3r.1) will extract the GRCh37.75 genome annotation at https://usegalaxy.eu. The GRCh37.87 version of the data is more recent (2018) but will not download, even with this version of the Galaxy tool. And GRCh37.98 is the most current, and not pre-indexed at the SnpEff site. Thatâs Ok, you can make your own based on Ensembl 98, or whatever the most current is at any time.
From my testing, none of the 2018 SnpEff indexes at https://sourceforge.net/projects/snpeff/files/databases/v4_3/ are working with the most current version of SnpEff Download. The exception is mm9. The tool wrapper probably needs another update to reflect the URL changes at SnpEff. Iâll ticket that.
The genome/build version and annotation version matter when comparing annotation obtained from indexes versus what is posted at websites.
Ensembl annotation is at version 98 now. Version 75 is older.
You donât have to use pre-compiled indexes. Try making your own, based on the most current annotation (98), with the tool SnpEff build, if you want it to match what is at the Ensembl website. The tool form explains the different âbuildâ options.
If you included upstream/downstream variants in a VCF file, the HGVSc would be reported (when those variants are in a coding region). Whether to do this or not is up to you. The annotation is a match for the specific variant in your VCF, so there is no reason to think that something went wrong. Unless the chromosome names are not quite matching upâŚ
The same base reference genome build/version needs to be used/input for all steps in an analysis pathway. GRCh37 (has Ensembl chromosome names) is the same underlying genome (nucleotides) but a different build version (identifiers) versus hg19 (has UCSC chromosome names). Trying to use both together can lead to âgreenâ dataset content problems, not always âredâ dataset errors. That is why I suggested the other tools to check the chromosome naming identifiers in your particular VCF data, the indexes used (built-in, downloaded, or created), and to make adjustments as needed.
Reference data/indexes used in tutorials becomes outdated over time. The training purpose is to show how to use the tools/workflow covered. Tutorials also use simplified inputs to keep the processing small in size and faster to process. When running an analysis with real full-size data, use the most current annotation indexes for the most current annotation results.
The majority of the data I checked using the VEP, which only works with the current version of Ensemble. Thanks to your good advice, I know looked at the Transcript in the old Ensemble Version (http://feb2014.archive.ensembl.org/Homo_sapiens/Transcript/Summary?db=core;g=ENSG00000074181;r=19:15272436-15280961;t=ENST00000595514). However, I did not see what you have told me, which is that on the Ensemble Archive Website (version 37.75) there is no annotation regarding the warning âWARNING_TRANSCRIPT_NO_START_CODONâ, but I actually do find this information in the transcript table online. Or does only the text below the text oft the âSummaryâ-Saction for this Transcript is, what gets annotated using this Ensemble version?
In regard to your recommendation to be careful when using GRCh37 and hg19 in the same analysis workflow ( âGRCh37 (has Ensembl chromosome names) is the same underlying genome (nucleotides) but a different build version (identifiers) versus hg19 (has UCSC chromosome names)â.): Both variant callers (for my two different data types) use hg19 (UCSC) as the reference genome. Using bcftools norm the Reference genome I selected is âHuman (Homo sapiens): hg19â. However, when I annotated my variants with snpeff eff I use GRCh 37.75. Is that a problem, I did not know of?
The best choice is to use the SnpEff annotation built-in for hg19.
Ensembl updated/improved how they reported certain data warnings. Compare the two releases and youâll see that the transcript table is formatted/tagged differently.
The reason I used GRCh is because SnpEff does not recommend to use the hg19 from UCSC anymore. ( WARNING: Usage of hg19 genome is deprecated and discouraged, you should use GRChXX.YY instead (e.g. the latest version at the time of writing is GRCh37.70). Reference sequence and annotations are made for an organism version and sub-version. For examples human genome, version 37, sub-version 70 would be called (GRCh37.70). UCSC doesnât specify sub-version. They just say hg19. This annoying sub-version problem appeared often and, having reproducibility of results in mind, I dropped UCSC annotations in favor of ENSEMBL ones (they have clear versioning)."http://snpeff.sourceforge.net/SnpEff_manual.html ).
As the vcf had been annotated with GCRh37 before by Illumina and Quiagen Software for the two sample times respectively (which for consistency of data analysis I removed and now want to annotate both sample types with the same annotation engine), I thought it would be fine to use GCRh 37.75.
What do you think?
I see the difference. Thanks a lot.
Thanks again for your help! I am very glad for your support!
Ok, that information helps. Letâs back up a bit â it is not clear now which exact genome version/build was used for the original mapping and variant calling steps.
Would you please post back the entire header and first 10 or so data lines from the two original vcf files? The versions before you started to manipulate them in Galaxy. Or, you can send that in a direct message if you want to keep it private for some reason. Copy/paste is fine â we are checking content, not format.
What the header will clarify:
There are other content differences between hg19 (UCSC) and GRCh37 (NCBI, Ensembl) besides updated/additional assembly and annotation content and the chrom identifier nomenclature differences. The version of the mito assembly incorporated is different in the v37 releases across data providers, which complicates it even more. UCSC used the human v36/hg18 mito for v37/hg19 while NCBI/Ensembl used an updated mito assembly for v37/CHRh37. The short-ish âwhyâ is that which mito assembly to incorporate changed during the data staging steps for the v37 release. UCSC had already started annotating the genome using the older mito and decided to not re-do those steps (computationally expensive steps) since the v38 release was expected to be released quickly after ⌠then it wasnât. Full details about the hg19 assembly content, including this part, is at the UCSC website: http://genome.ucsc.edu/ > Genomes > hg19 > Assembly details.
Iâm also curious if the genome mapped against was stripped down to include just the 1) primary autosomes (1-23/chr1-chr23), 2) both X/chrX and Y/chrY or just X/chrX, and 3) mito (MT/chrM) â and which version of mito. A common choice when calling variants is to use just autosomes, X, and mito (excluding Y to avoid PAR mapping issues). Or, it could have included Y plus possibly all the haplotypes, unmapped, ect in the original release.
hg19 vs GRCh 37.75
I double checked a couple thinks to ensure that snpeff is working fine:
i)There are no errors in summary stats reported.
ii)For all chromosomes (where there is a variant detected), there is an annotation in the vcf visible. My QIAGEN example-sample does not contain a variant chr. 18,21,23,Y, so that I cannot check those chromosomes. However, for all other variants there is an annotation available.
iii)I checked if there is an error annotated. For both example variants there is no error annotated. (ERROR_CHROMOSOME_NOT_FOUND, http://snpeff.sourceforge.net/SnpEff_faq.html)
Maybe that might be enough to indicate that the annotation works probably?
Transcript Warning
Unfortunately the Ensemble help desk disagrees, and says that the transcript warning is definelty in the database version 37.75. They underlined though, that what other annotation programs (snpeff via galaxy) and what they âmake of the databaseâ is not of their knowledge. Well I honestly do not exactly know what to do with this information. What do you think? How can we be so sure about that the âmissingâ transcript warning in my snpeff annotation is not really missing, but just not available in the GRCh 37.75 snpeff database, even though it is visible on the ensemble archive website for GRCh37.75. Do you have another idea how I could double check this (maybe view the snpeff database somehow?)?
So I finally have a guess why this happens.
This specific transcript, ENST00000595514, has its biotype assigned as Nonsense mediated decay both in Ensemble 37.75 and in the snpeff genome database of that same version.
This turns out to be key here since, by default, SnpEff does NOT report its four transcript consistency warnings:
for anything but transcripts with biotype Protein coding.
I didnât find this documented anywhere, but itâs in SnpEffâs source code, and it makes kind of sense though you might disagree.
Just for completeness, because the behavior surprised me: WARNING_TRANSCRIPT_INCOMPLETE does NOT mean that either the start or the stop codon is missing, but that the number of bases in the transcriptâs cds is not a multiple of 3. This one IS documented though at http://snpeff.sourceforge.net/SnpEff_manual.html.
I hope this answers your question?
Best wishes,
Wolfgang
