ENCODE QA

run qaEncodeTracks.csh

You will need to dump the list of tables from the pushQ to a file (i.e. tableList in the usage statement). Then run qaEncodeTracks.csh (~ann/qa/tracks/ENCODE/200903/qaEncodeTracks.csh) which does:

• featureBits
• countPerChrom
• check for entry in tableDescriptions table
• check that shortLabel does not exceed 16 characters
• check that longLabel does not exceed 80 characters
• check that there are no underscores in the table names
• check for indices on the tables
• check that positional tables are sorted
• runs pslCheck if applicable
• checkOffEnd

Other things to check by hand

1. Run genePredCheck/pslCheck if applicable. (i.e. if your track is a gene prediction track)
2. To remove "release alpha" from trackDb use the "removeAlphas" script in /cluster/bin/scripts/
3. make sure there is a link to the help doc (in the config section _Help on views_)
4. check metadata field of trackDb entry
5. read description page
   • is it detailed enough, especially Methods
   • are the citations in correct format
   • does the "Display Conventions and Configuration" section cover all track types
   • test all hyper-links
6. Release log: Check to be sure the release log entry is right. Usually it should just be the shortlabel, but if there is something weird about the data that needs to be noted, make sure it fits in nicely with the current release log entries. (url should be of the format: ../../cgi-bin/hgTrackUi?db=hg18&g=wgEncodeAffyRnaChip )
7. configuration section (does it work)
8. multi-view config: matrix etc.
9. Make sure there's a link to the ENCODE Data Release Policy (at the bottom of the description page).

Files

One of the most time-consuming things we do is track down items that should have been placed in the "Files" section of the pushQ entires but weren't. It takes us a long time to (a) figure out what's missing, and (b) find it. If developers can ensure that both the /gbdb and /goldenPath files are there, it would be a huge help!

Files of this form get pushed hgwdev -> hgnfs1

 /gbdb/hg18/wib/wgEncode*.wib

Files of this form get pushed hgwdev -> hgdownload

 /usr/local/apache/htdocs/goldenPath/hg18/encodeDCC/wgEncode*/index.html
 /usr/local/apache/htdocs/goldenPath/hg18/encodeDCC/wgEncode*/wgEncode*.[bed/wig].gz

Testing in the Browser

1. test one point from table to view in GB
2. zoom into base level (at different visibilities)
3. zoom way out 1million bps (at different visibilities)
4. searching: should items be searchable
5. default visibility: should this track be on by default?
6. Check URL in Release Log (should go to track description page)
7. Check for lab contact (sanitize email addresses using encodeEmail.pl script)

Performance Tests

1. Does the first 'Signal' subtrack pass the chr1 test (chr1 loads in less than one minute)
2. Do all views for one experiment pass chr1 test (e.g. Pol2 in GM12878 cells)?
3. A user-oriented test would be to test the performance in a gene-size region of the track with just the default-on subtracks (for the Yale track, and many other ENCODE tracks, default-on subtracks will be all experiments in the GM12878 cell lines, Signal view only -- this should be the configuration you see after a cart reset, then turning the overall track vis to full).
4. Note that ENCODE tracks can have any number of subtracks, and will continue to grow with time. We should definitely assure that useful subsets can be displayed in user-friendly time.

Downloads

When you are ready to release make sure your track is listed on the downloads page (http://genome.ucsc.edu/ENCODE/downloads.html)- if not add your track to this page and push hgwdev -> hgwbeta, RR

/usr/local/apache/htdocs/ENCODE/downloads.html

Notification

When you release the track, be sure to cc both the data wrangler for this track and encode@soe.ucsc.edu.