New track checklist

This is the checklist for QA to follow when checking releasing tracks. General rule: Stop testing when you come to the first non-trivial error, and mark the track on-hold in the queue until the track sponsor fixes it.

Background familiarity

If you haven't worked with a track like this one, and it already exists on the RR for another assembly, use it a bit on the RR to become familar with it. For complex tracks, look for genomewiki pages on it, and/or look through the push queue for previous problems encountered on similar tracks. Familiarize yourself with the tables and files needed for this track.

Push to hgwbeta

(If this is an update to an to an existing track, you may want to hold off on this step so that you can compare old and new tracks on hgwdev and hgwbeta.)

Push all tables from hgwdev to hgwbeta. There are two ways:

 sudo mypush $db $table mysqlbeta

or, for many tables:

 bigPush.csh $db $tableList

Make beta on hgwbeta in kent/src/hg/makeDb/trackDb like so:

 make beta DBS=$db

Request a push of all supporting files in /gbdb from hgwdev to hgnfs1. Note that both hgwbeta and the RR share the files on hgnfs1.

Makedocs

Look for an entry for your track in src/hg/makeDb/doc/$db.txt. If there is no mention of this track, make a request to the track sponsor. Basic tracks that are loaded automatically with a new assembly may only have a tiny reference in the makedoc. UCSC Genes has its own document.

Release Log and URL

The "release log" field in the qaPushQ should generally contain the shortLabel of the track. The entry in this field will be added to the auto-generated release log page. If it makes sense to link to the hgTrackUi page for this track, make an entry in the releaseLogUrl field like so:

 ../.../ (need to fill this out

Check that tables are sorted and internally consistent

• checkTableCoords

For positional tables, checks that the genomic coordinates are legal (e.g., coordinates are not off the end of a chromosome).

• positionalTblCheck

For any positional table, check to see that the table is ordered by chrom and chromStart. The utility positionalTblCheck does this. A positional table being out of order can cause a huge slowdown in display speed. If the table passes there will be no output. If the table does not pass there will be an error message like: "table hg18.snp129 not sorted starting at row 4867: chr1:387005" Note that it is not important that the items be sorted exactly in order - as long as the items are almost all in order, it will not affect performance.

• genePredCheck/pslCheck

For gene prediction tracks (with tables in the genePred format, run genePredCheck (run the command with no arguments for instructions). For psl tables, run pslCheck.

Index

Check the indices for the primary table using the mySQL command "show index from ". Expect to find chrom/chromStart and chrom/chromEnd. Press show sizes in the push queue and look at the indexes. Make sure no tables are missing and all return valid values.

Searching

If the track item names are relatively unique, perform a few searches. If search isn't enabled, make that request to the track sponsor. This isn't required for the push. If the track item names are relatively similar (i.e. RNA Genes, TFBS) we don't want to enable search, it would return too many matches.

The checkHgFindSpec tool with the -checkTermRegex option will check that all of the names in a table that is searched match the regular expression specified in trackDb.ra. There is not an option to run it on a single table, so just run it on the whole database and look for output specific to your table. For instance:

 checkHgFindSpec -checkTermRegex hg19

If this gives errors pertinent to your track, request that the track sponsor edit the search entry in trackDb.ra.

joinerCheck

Time permitting, ask the track sponsor about applicable rules in all.joiner for your track and run joinerCheck -identifier -database -keys. You can also use Bob's runJoiner.csh.

Chromosome coverage

Some tracks don't have data on all chromosomes. To check which ones do have data: countPerChrom.csh db table and/or: countPerChrom.csh db table histogram OR: SELECT DISTINCT chrom FROM encode_UVA_DNARep_0_2; If a "regular" chrom (not random or haplotype) is missing data, it should NOT be listed in the trackDb restrictList setting. You you can check the restrictList in trackDb as follows: SELECT tableName, restrictList FROM trackDb WHERE tableName like 'encode_UVA_DNARep%'; restrictList (if not blank) should be a comma-separated list of chroms with data. In trackDb.ra, the chromosomes line specifies the contents that later becomes restrictList after doing a "make strict" on beta. e.g. chromosomes chr2, chr4, chr5.

EASY GRAPHICAL WAYS TO CHECK COVERAGE: (1) Import the table into Genome Graphs. (2) To see a count plus a histogram of chrom coverage, select the table in the Table Browser, hit the "describe table schema" button, and click the "values" link for the chrom field.

In addition, you can use the countPerChrom.csh script to get a count of track items for each chromosome, and checkCoverage.csh, to get a list of the largest blocks of non-annotated regions (with links) that are not gaps.

Gaps

Compare your track to Gap. Zoom out 10x until 100 million bases or full chrom. Use dense mode as necessary. Perform for a sampling of chromosomes. Look for large areas of missing data. Allow for "gene-desert" regions.

FeatureBits

Run featureBits, or use the runBits.csh script to run featureBits. The script will also check the track items for overlap with undbridged gaps (which is bad, but permissible in some cases -- check with the developer if you are not sure). Put results in pushQ entry. If previous assembly also has this track, compare featureBits between current assembly and previous assembly.

Can also use getYield.csh if comparing to refGene:cds.

Track description

Read the track description and edit for clarity, spelling, and grammar. Ensure references are in the correct format. Ensure quotes and ampersands are in the right html format. (need a link to html formatting page here.)

Make sure that any email addresses given on the details page have been through Hiram's sanitizer (encodeEmail.pl). It turns the address into an encrypted HREF "mailto:" address that makes it harder for spammers to use.

All details: 1 data point

Choose a representative data point for the track from the mysql table. Check all details for this data point, including all links. Make sure information from the table is displaying correctly (e.g., if a color is used in the table, make sure that color appears for the item.)

Gene annotations only

Choose a gene that is on the positive strand, exonCount of 1. Check that the protein sequence displayed by the details page matches the sequence displayed by the Base Position track.

Comparison

Compare your track to Known Genes. Look for alignment of exons.

Default Position

Re-evaluate the default position. Does the new track appear as a default? Should it? Location (dbDb.defaultPos) & track priorities (trackDb.ra) should be optimized to make available annotation esthetically pleasing and scientifically interesting.

Performance and Display

For tracks displayed by default, the full chromosome view (chr1) should display within 20 seconds. For tracks which are not displayed by default, the full chromosome view should display within a minute. Update qa/test-results/perf/display.html. Use JKSQL_PROF=on to measure SQL time (reported in Apache error log).

Turn on to full display mode a track that is located physically below your track in the display. Make sure that when your track is in full display mode, that the items in the track below it are still mapping correctly. Sometimes there can be an off-by-one error which is caused by your track. If this is happening, you should not push your track.

Track Settings (hgTrackUi)

Click on the track name or the mini-button to the left of the track (in hgTracks) to get to the track settings page. Make sure that the track settings work as expected.

Table Descriptions

Hit the "view table schema" button (on hgTrackUi, hgc, or hgTables) and make sure there is a description column present with descriptions of the table fields. If a track has more than one table, be sure to check for table descriptions on each of them. The description column uses the 'tableDescriptions' table to display this information. This table is built nightly on hgwdev and hgwbeta, and must be pushed to the RR if it contains descriptions for a new type of table (things like psl will already be out there).

Background on the tableDescriptions table is here.

trackDb and hgFindSpec

Check whether trackDb needs to be pushed to the RR (use table browser on RR). Check that no rows would get deleted when pushing trackDb. Check whether other rows get added. If so, update the pushqueue for that, or, temporarily delete the row, push trackDb, then regenerate it on hgwbeta. Can use compareTrackDbs.csh hgwbeta hgw1 hg16 Can use compareHgFindSpecs.csh hgwbeta hgw1 hg16 (will create 2 output temp files in current directory per assembly checked)

push request

Ask admins (push-request at soe) for a push of the table (incl trackDb, if needed) to the RR. Notify (cc:) the track submitter on the push request, in case they are not on the browser-qa alias.

Be sure to ask the pushers to 'unexclude' any of the hgnfs1 files that need to be available for the track to work for the mirror sites.

Validate on the RR

Check your track on the RR. Also check that all default tracks still display.