Genome Browser FAQ (original) (raw)

Frequently Asked Questions: Assembly Releases and Versions

Topics

• List of UCSC genome releases
• Initial assembly release dates
• Patch sequences for human and mouse
• UCSC assemblies
• Comparison of UCSC and NCBI human assemblies
• Looking for a genome assembly not shown in the tree?
• Differences between UCSC and NCBI mouse assemblies
• Accessing older assembly versions
• Frequency of GenBank data updates
• Coordinate changes between assemblies
• Converting positions between assembly versions
• Converting SNPs between assembly versions
• Missing annotation tracks
• What next with the human genome?
• Mouse strain used for mouse genome sequence

Return to FAQ Table of Contents

List of UCSC genome releases

How do UCSC's release numbers correspond to those of other organizations, such as NCBI?

The first release of an assembly is given a name using the first three characters of the organism's genus and species classification in the format gggSss#, with subsequent assemblies incrementing the number. Assemblies predating the 2003 introduction of the six-letter naming system were given two-letter names in a similar gs# format and human assemblies are named hg# for human genome.

Initial assembly release dates

When will the next assembly be out?

UCSC does not produce its own genome assemblies, but instead obtains them from standard sources. Because of this, you can expect us to release a new version of a genome soon after the assembling organization has released the version. A new assembly release initially consists of the genome sequence and a small set of aligned annotation tracks. Additional annotation tracks are added as they are obtained or generated. Bulk downloads of the data are typically available in the first week after the assembly is released in the browser.

Patch sequences for genome assemblies

Why am I seeing chr_alt or chr_fix chromosomes on the Genome Browser?

Since the intial Genome Reference Consortium (GRC) release of the human and mouse genome assemblies, there have been updates to these assemblies known as "patches". Patches are accessioned scaffold sequences that add information to the assembly without disrupting the chromosome coordinates. Patches are given chromosome context by aligning the sequence to the current assembly. Together the scaffod sequence and the alignment define the patch to the genome assembly. The GRC patch releases do not change any previously existing sequences; they simply add new sequences for fix patches or alternate haplotypes that correspond to specific regions of the main chromosome sequences. For most users, the patches are unlikely to make a difference and may complicate the analysis as they can introduce duplication.

There are two kinds of GRC patch sequences, chr_alt and chr_fixsequences:

• Novel patches (alternative haplotypes) - Chromosomal regions of the genome that exhibit sufficient variability to prevent adequate representation by a single sequence. Also referred to as alternate loci. The Genome Browser labels these haplotype sequences by appending "_alt" to their names, i.e.,chr5_KI270794v1_alt.
• Fix patches - Error corrections (addressed by approaches such as base changes, component replacements/updates, switch-point updates or tiling-path changes) or assembly improvements, such as the extension of sequence into gaps. The Genome Browser labels these fix sequences by appending "_fix" to their names, i.e., chr1_KN538361v1_fix.

The Patching up the Genome blog post contains more information on how patch sequences are incorporated into the UCSC Genome Browser. For more information about how patch sequences can affects BLAT and isPCR results, please refer to the following BLAT FAQ.

Data sources - UCSC assemblies

Where does UCSC obtain the assembly and annotation data displayed in the Genome Browser?

All the assembly data displayed in the UCSC Genome Browser are obtained from external sequencing centers. To determine the data source and version for a given assembly, see the assembly's description on the Genome Browser Gateway page or the List of UCSC Genome Releases.

The annotations accompanying an assembly are obtained from a variety of sources. The UCSC Genome Bioinformatics Group generates several of the tracks; the remainder are contributed by collaborators at other sites. Each track has an associated description page that credits the authors of the annotation.

For detailed information about the individuals and organizations who contributed to a specific assembly, see the Credits page.

Which UCSC assemblies are equivalent to Ensembl or NCBI assemblies?

The asmEquivalent table on the hgFixed database is available on the public MySQL server to show which assemblies versions are identical (or almost identical) to each other between UCSC, Ensembl, Genbank, and RefSeq assemblies.

mysql --user=genome --host=genome-mysql.soe.ucsc.edu -A -e 'desc asmEquivalent;' hgFixed +----------------------+-------------------------------------------+ | Field | Type | +----------------------+-------------------------------------------+ | source | varchar(255) | | destination | varchar(255) | | sourceAuthority | enum('ensembl','ucsc','genbank','refseq') | | destinationAuthority | enum('ensembl','ucsc','genbank','refseq') | | matchCount | bigint(20) | | sourceCount | bigint(20) | | destinationCount | bigint(20) | +----------------------+-------------------------------------------+

The "Count" indications are the count of individual sequences in the assembly. When all three counts are identical, matchCount == sourceCount == destinationCount, then the match between genome assemblies is perfectly identical.

Non-perfect matches can be due to a number of factors:

1. different or not included chrMT genome sequences in an assembly
2. identical duplicated sequences present or absent from an assembly
3. some smaller contigs not included in an assembly
4. slight differences in versions of assemblies where some contain sequences not in the other assembly

Comparison of UCSC and NCBI human assemblies

How do the human assemblies displayed in the UCSC Genome Browser differ from the NCBI human assemblies?

Human assemblies displayed in the Genome Browser (hg10 and higher) are near identical to the NCBI assemblies when it comes to primary sequence. Minor differences may be present, however. Sources include:

• NCBI genomes are repeat masked with RepeatMasker, however, UCSC genomes are independently masked with both RepeatMasker (with different flags) and WindowMasker, ultimately using the program output with the highest percentage masked for the base sequence
• In genome download files, UCSC uses the 'chr1' nomenclature for sequence identifiers, whereas the primary NCBI sequence identifiers are RefSeq accessions
• The original mitochondrion (chrM) for hg19 differs from the one in NCBI (GRCh37)
• The mitochondrion released by NCBI after the hg19 browser was built has been added to the assemby as chrMT. See our documentation for details.

Looking for a genome assembly not shown in the tree?

When looking for a specific assembly, the best place to start is the Gateway page. If you begin to type the common name, species name, or NCBI RefSeq accession number in the search box on the left side of the screen, suggestions will appear if any matches are found. This search will also match any assembly hubs that are listed in UCSC's Public Hubs. Nearly every NCBI RefSeq assembly and Vertebrate Genomes Project assembly is included here within theGenArk hubs. NCBI RefSeq assemblies can be loaded with direct links such ashttp://genome.ucsc.edu/h/GCF_001984765.1 with the GCF accession. These assembly hubs are automatically updated, but not reviewed by UCSC. The species tree shows all genomes reviewed by UCSC.

If the assembly of interest is not found, please visit ourassembly request page. Search that page for your assembly. If there is a "view" link you can launch the existing genome browser. Otherwise, click the "request" button to fill out a form to add your genome of interest. An existing GCA_ or **GCF_**identifier must exist, reflecting that the assembly has been deposited into Genbank at NCBI, before we can process it. See the Assembly Submission Guidelines page at NCBI for directions on their submission process if your genome needs to be deposited. Also, review the UCSC GenArk Blog postsfor examples of accessing and reviewing technical details about GenArk hubs.

Another option available to all users is to create an assembly hub. These are assemblies created and hosted by users and displayed on the Genome Browser. This requires no intervention by the UCSC Genome Browser and can be done for any assembly. See our Quick Start Guide to Assembly Hubs page for additional information and resources. If you create an assembly hub, consider sharing it with others as a Public Hub.

If you would like information about creating a track hub for an existing assembly hub, please refer to the following FAQ entry.

Differences between UCSC and NCBI mouse assemblies

Is the mouse genome assembly displayed in the UCSC Genome Browser the same as the one on the NCBI website?

The mouse genome assemblies featured in the UCSC Genome Browser are the same as those on the NCBI web site with one difference: the UCSC versions contain only the reference strain data (C57BL/6J). NCBI provides data for several additional strains in their builds.

Accessing older assembly versions

I need to access an older version of a genome assembly that's no longer listed in the Genome Browser menu. What should I do?

In addition to the assembly versions currently available in the Genome Browser, you can access the data for older assemblies of the browser through our Downloads page.

Frequency of GenBank data updates

How frequently does UCSC update its databases with new data from GenBank?

GenBank updates for mRNA, RefSeq, and EST data occur on a semi-quarterly basis, following major NCBI releases. These updates are in place for most Genome Browser assemblies. Assemblies that are not on an incremental update schedule are updated whenever we load a new assembly or make a major revision to a table.

Coordinate changes between assemblies

I noticed that the chromosomal coordinates for a particular gene that I'm looking at have changed since the last time I used your browser. What happened?

A common source of confusion for users arises from mixing up different assemblies. It is very important to be aware of which assembly you are looking at. Within the Genome Browser display, assemblies are labeled by organism and date. To look up the corresponding UCSC database name or NCBI build number, use the release table.

UCSC database labels are of the form hg_#, panTro#_, etc. The letters designate the organism, e.g. hg for human genome or panTro for Pan troglodytes. The number denotes the UCSC assembly version for that organism. For example, ce1 refers to the first UCSC assembly of the C. elegans genome.

The coordinates of your favorite gene in one assembly may not be the same as those in the next release of the assembly unless the gene happens to lie on a completely sequenced and unrevised chromosome. For information on integrating data from one assembly into another, see the Converting positions between assembly versions section.

Converting positions between assembly versions

I've been researching a specific area of the human genome on the current assembly, and now you've just released a new version. Is there an easy way to locate my area of interest on the new assembly?

See the section on converting coordinates for information on assembly migration tools.

Converting SNPs between assembly versions

How can I convert SNP annotation coordinates between assembly versions?

While the LiftOver tool exists to convert coordinates between assemblies, it is NOT recommended to use LiftOver to convert SNPs between two assembly versions. Using LiftOver to convert a very small region, especially a single base SNP, is not always a trivial task as the alignment may not get a high enough score to be considered a successful conversion.

The mapping from one genome assembly to the next is automatically generated from sequence alignments and is not complete nor perfect, just a best attempt. The stability of rsIDs is why we recommend mapping across assemblies using rsIDs first and then falling back to using cross-assembly mappings to look up the positions of items that didn't map. When an rsID in hg18 is not found in the hg38 dbSNP data, that rsID has been withdrawn or replaced by a different rsID. In that case, mapping the hg18 position of the disappeared rsID to hg38 and looking for a new rsID at the corresponding position may help to find the new rsID.

dbSNP started assigning rsIDs in the 1990s, before the human genome was assembled. At that point, SNPs were defined by flanking sequences with the varying base(s) in the middle -- local sequence context, with no genomic location because there was no genome. rsIDs are supposed to be stable across genome assemblies despite the changing genomic positions. Regardless of the genome assembly version, "rs429358" refers to the same polymorphic variant in the 4th exon of the ApoE gene with T as the major allele and C as the minor allele. Its genomic position in hg18 is chr19:50103781, and its genomic position in hg38 is chr19:44908684.

Instead, the recommended process to convert a SNP's coordinates between assemblies is to use a SNP track to search for each rsID on the target genome assembly. For example, after creating a list of rsIDs for your conversion, you would then search for each rsID on the target's Genome Browser using the dbSNP track for human assemblies (i.e. hg19 or hg38) or the EVA SNP track on mouse assemblies (i.e. mm10 or mm39) to perform the conversion.

To summarize the setps:

1. Create a file of all rsIDs
2. Use the Table Browser to map the file of rsIDs to the other assembly's coordinates
3. Create another file containing any rsIDs that were not mapped by the Table Browser
4. Using the file from the previous step, use the Table Browser to create a BED4 file for the rsIDs that were not mapped by the Table Browser
5. Run LiftOver on the BED4 file to get the new coordinates in the other assembly
6. Use the Data Integrator to map the LiftOver results to new rsIDs where possible
7. Combine the Table Browser rsID-mapped BED4 with the LiftOver/Data Integrator-mapped BED4. Beware duplicates that will cause downstream problems. You will need to decide whether to remove duplicates as unreliable or resolve duplicates

How can I convert a large set of SNP annotations?

For bulk conversions, the Table Browser can be used to extract the coordinates for the rsIDs on the target assembly. More information about performing batch queries on the Table Browser can be found on the followingTable Browser help page. An example of using the Table Browser to convert SNP between assemblies can be found on a previously answered question available on themailing list archive.

If you are using versions dbSNP 153 and above, the data are formatted as bigBed files instead of being stored as a MariaDb table. For very large queries, this may cause the Table Browser to timeout before the query finishes as dbSNP has grown to include over 700 million variants. If you find that your Table Browser query timesout for your list of rsIDs, you can use thebigBedNamedItems command-line tool to extract the rsID coordinates directly from the bigBed file instead of using the Table Browser. More information and examples using thebigBedNamedItems utility can be found on the followingFAQ entry. As a reminder, you can run any Kent command-line tool without arguments to get the usage statement.

Missing annotation tracks

Why is my favorite annotation track missing from your latest release?

The initial release of a new genome assembly typically contains a small subset of core annotation tracks. New tracks are added as they are generated. In many cases, our annotation tracks are contributed by scientists not affiliated with UCSC who must first obtain the sequence, repeatmasked data, etc. before they can produce their tracks. If you have need of an annotation that has not appeared on an assembly within a month or so of its release, feel free to send an inquiry to genome@soe.ucsc.edu. Messages sent to this address will be posted to the moderated genome mailing list, which is archived on a SEARCHABLE, PUBLIC Google Groups forum.

What next with the human genome?

Now that the human genome is "finished", will there be any more releases?

Rest assured that work will continue. There will be updates to the assembly over the next several years. This has been the case for all other finished (i.e. essentially complete) genome assemblies as gaps are closed. For example, the C. elegans genome has been "finished" for several years, but small bits of sequence are still being added and corrections are being made. NCBI will continue to coordinate the human genome assemblies in collaboration with the individual chromosome coordinators, and UCSC will continue to QC the assembly in conjunction with NCBI (and, to a lesser extent, Ensembl). UCSC, NCBI, Ensembl, and others will display the new releases on their sites as they become available.

Mouse strain used for mouse genome sequence

What strain of mouse was used for the Mus musculus genome?

C57BL/6J.