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, 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 this script: removeAlphas
3. make sure there is a link to the help doc (in the config section: "Select views (help)")
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. check "reset to defaults" button (does it work)
10. Make sure there's a link to the ENCODE Data Release Policy (at the bottom of the description page).
11. Make sure the tracks in the Tier1 and Tier2 Cell Lines are properly colored (no black, and all tracks from one Cell Line have the same color).

Files

• Finding the 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 entries 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!

• Validating the Files

Test a smattering of different file types using this tool: validateFiles (type the program name without arguments to see the usage statement). If there are no errors, there will be no output. For example, for files of type tagAlign, invoke the tool like this:

validateFiles -type=tagAlign -genome=/gbdb/hg18/hg18.2bit /usr/local/apache/htdocs/goldenPath/hg18/encodeDCC/wgEncodeHudsonalphaChipSeq/wgEncodeHudsonalphaChipSeqAlignmentsRep1Gm12878Control.tagAlign.gz

Tim's comments on our running validateFiles:
To get these things through the pipeline, we run them through validateFiles, so I think your running them through again is one time too many. But if you are going to, then each lab and each file type may have negotiated limits (which may change between submissions). These limits are found in the relevant submission directory DAF files.

For tagAligns there are several relevant validateFiles options:

  mismatches  - frequently 2 but negotiated for each lab.  Set this to 5 to be tolerant
  matchFirst - negotiated.  You should set this to 25 and even then you may need to adjust it
  nMatch - negotiated, but you should always have this parameter set.

If you want to be exact, then the metadata as seen on the downloads page tells which submission directory the file belongs to, and the most recent *.DAF (or *.daf) will have a validationSettings line in it which will include the settings that belong to each file type. Example:

  /hive/groups/encode/dcc/pipeline/encpipeline_prod/773/UtaChIPseqBOonlyV1.DAF

has the line:

  validationSettings allowReloads;validateFiles.tagAlign:mmCheckOnInN=100,mismatches=3,nMatch,matchFirst=25

This means that the tag aligns were validated with -mismatches=3 -nMatch -matchFirst=25

• Pushing the Files

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

Once the files have been pushed you can check to see if the push was successful using this script: checkPushedFiles.csh

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.

Subsequent Release of Data (e.g. Release 2)

Periodically, the existing ENCODE tracks will be augmented with new data as labs complete experiments on new cell lines, etc. The new data will come in various formats: some will replace existing data, some will be brand new, some old data will be eliminated, etc. The data wrangler will create a text document, check it into CVS, and place it here: kent/src/hg/makeDb/doc/encodeDccHg18/*.txt

This document should contain complete lists of each table and file and what its disposition is. The tables and files will fall into categories similar to this:

• Untouched - are on public browser and shall remain
• Eliminated - are currently on RR but will no longer be needed and should not be referenced by the public site
• Replaced - are on public browser but will be replaced by something with another name (nothing should be replace by something with the same name)
• Versioned (replacing) - are only currently on test but will need to be pushed to RR as replacements for existing datasets (with a different name)
• New - are only currently on test but will need to be pushed to the RR.

Invariably, this document will not match reality. It may be the case that some of the tables/files do not exist at all, the names are incorrect, they are not present on the machine as listed in the file, they do not match the list that is in the pushQ. The first challenge in QAing a subsequent ENCODE release is to determine if/how the file diverges from reality. Send that information to the data wrangler and pop the track into the B-queue while they sort it out. Otherwise, QA spends far too much time figuring out exactly what they are expected to QA.

Once the list is finalized, proceed with the QA work as outlined above. Note the additional steps in the #Downloads section for how to handle the /releaseN directory.

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 it isn't listed add a line for your track to this page and push hgwdev -> hgwbeta, RR

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

If you need to make a change to the top of the index page (not the list of files) in the downloads directory for this track (e.g. this page ) here are the instructions:

1. Edit the preamble.html file (note that it is not in CVS) in the downloads directory on hgwdev
2. Regenerate index.html by running the script: encodeDownloadsPage.pl index.html
3. Look at results on genome-test. If necessary, go back to step 1.

If this is a re-release of data (e.g. release 2), and you are 100% certain that the parent directory contains the exact same files as the /releaseN directory, copy both files to the /releaseN directory to preserve them:

cp index.html releaseN/
cp preamble.html releaseN/

If you're not sure the files are the same in the /releaseN directory and the parent directory, simply run the encodeDownloadsPage.pl script directly in the /releaseN directory to generate the new index.html page there which will include only links to files that are in this release.

Notification

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