ENCODE QA: Difference between revisions
mNo edit summary |
m (typo) |
||
Line 29: | Line 29: | ||
==Files== | ==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 | 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! | ||
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: | 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: |
Revision as of 22:32, 30 July 2009
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
- Run genePredCheck/pslCheck if applicable. (i.e. if your track is a gene prediction track)
- To remove "release alpha" from trackDb use this script: removeAlphas
- make sure there is a link to the help doc (in the config section: "Select views (help)")
- check metadata field of trackDb entry
- 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
- 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 )
- configuration section (does it work)
- multi-view config: matrix etc.
- 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 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!
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
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
- test one point from table to view in GB
- zoom into base level (at different visibilities)
- zoom way out 1million bps (at different visibilities)
- searching: should items be searchable
- default visibility: should this track be on by default?
- Check URL in Release Log (should go to track description page)
- Check for lab contact (sanitize email addresses using encodeEmail.pl script)
Performance Tests
- Does the first 'Signal' subtrack pass the chr1 test (chr1 loads in less than one minute)
- Do all views for one experiment pass chr1 test (e.g. Pol2 in GM12878 cells)?
- 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).
- 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 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
Notification
When you release the track, be sure to cc both the data wrangler for this track and encode@soe.ucsc.edu.