ReleasePlanning
From SPCTools
(Difference between revisions)
| Revision as of 23:50, 5 December 2012 JoeS (Talk | contribs) (→Under Consideration for 4.7) ← Previous diff |
Revision as of 16:31, 18 December 2012 Jeng (Talk | contribs) (→Under Consideration for 4.7) Next diff → |
||
| Line 15: | Line 15: | ||
| * BUG: Installer needs to create installation directory before writing to installer.log. It may be also that the configure IIS and/or install/configure Apache are happening in the wrong step in the installer | * BUG: Installer needs to create installation directory before writing to installer.log. It may be also that the configure IIS and/or install/configure Apache are happening in the wrong step in the installer | ||
| * BUG: On Windows it seems to have a hardcoded path to perl so that the programs/cgi scripts fail if you put perl in another location, e.g. installing 64 bit perl which goes to C:\Perl64 instead of C:\Perl. | * BUG: On Windows it seems to have a hardcoded path to perl so that the programs/cgi scripts fail if you put perl in another location, e.g. installing 64 bit perl which goes to C:\Perl64 instead of C:\Perl. | ||
| - | * Include comet in distribution | + | * BUG: Lorikeet viewer in TPP has a bug such that peptide mass (and precursor m/z) are missing a hydrogen. So those masses are off and y-ions are off. Update to latest Lorikeet code. |
| == Other Ideas == | == Other Ideas == | ||
Revision as of 16:31, 18 December 2012
This page is intended to assist in release planning by tracking new feature requests/bugs/improvements etc for TPP.
Under Consideration for 4.7
- BUGS: issues brought up at http://www.viva64.com/en/b/0156/
- BUG: lorikeet uses hardcoded paths to the html and javascript directories on the Apache server (e.g. ISB/js/lorikeet.js) instead of using the TPP_WEB Makefile variable.
- IMPROVEMENT: pepXML_v117.xsd has changes that should probably be rolled into v118
- NEW FEATURE: Support of Comet in the prophets
- NEW FEATURE: Include Comet in the distribution
- IMPROVEMENT: Include amztpp in the distribution
- NEW FEATURE: Petunia project dashboard
- IMPROVEMENT: Links to files (LMendoza? came up in lab meeting)
- NEW FEATURE: SGE job submission support (so that users can finally use 100% of petunia at ISB)
- NEW FEATURE: PEFF support in TPP. (Need to define what this means)
- BUG: Installer needs to create installation directory before writing to installer.log. It may be also that the configure IIS and/or install/configure Apache are happening in the wrong step in the installer
- BUG: On Windows it seems to have a hardcoded path to perl so that the programs/cgi scripts fail if you put perl in another location, e.g. installing 64 bit perl which goes to C:\Perl64 instead of C:\Perl.
- BUG: Lorikeet viewer in TPP has a bug such that peptide mass (and precursor m/z) are missing a hydrogen. So those masses are off and y-ions are off. Update to latest Lorikeet code.
Other Ideas
- Add decoy generators to Petunia?
- 64 bit version of TPP? mingw-64 is stable now. http://mingw-w64.sourceforge.net
- Feature thought - Transition petunia from using tandem.params.xml to tandem.params. While I understand in Petunia its historically been called tandem.params.xml and I'm loath to change this because of the impact. Why? For two reason. The first is I expect very shortly we'll be shipping at least one more search engine with TPP (comet) and it doesn't have a "comet.params.xml" file. Secondly on regis we've always (since I've joined ISB at least) called it tandem.params. Now I don't pretend to think we should make our users conform to us, I do however think we need to recognize that internally we support a large array of search engines and we've taken to naming all of the parameter files as <search>.params. To name this omssa.params.xml, inspect.params.xml, etc would be incorrect as these aren't always in xml format. Now I guess for those formats that aren't in xml we could create one but I don't think that's a great approach. Instead I propose following what I've done on regis, which is to use the native parameters file format when possible and in the cases were there isn't one (just command line parameters) use a very simple format that consists of just including all of the command line parameters. Alternately I guess we could just recognize both tandem.params and tandem.params.xml
Legacy Items
Fix iProphet models page ("performance" models are missing)
- Add "Bruker" files option to msconvert in Petunia
- Fix pepxml2html (View Peptide hits) peptide link for SpectraST results
- peptidexmlhtml2 : does not work with AA highlighting option (mark_aa=)
- Add some filtering options to Pep3D (specifically: view only +1 ions)
- Add QuickMod to speclibs page?
- retire getSpectrum -> use readMzXML
- incorporate psm2pdf
- include t2d support(?)
- Petunia: option to convert to mzXML using msconvert
- Petunia: launch all external links in blank/target window
- Reindex mzXML: new file with old name; rename old to: old-index or some such
- Petunia: option to run xinteract jobs as separate (instead of combining into a single analysis)
- Petunia: select pep.xml files only for input to Decoy Models pages
- Petunia: auto cd to dir and strip out full path if all files in same dir (shorten command line)
- Petunia: rename Mascot file on download
- Move /tmp/ directory under tpp-bin (Windows)
- Petunia: Add TPP version check (ping server) --> usage stats
- Petunia: add full filters to msconvert(??)
- Petunia: change tab graphic when jobs are done?
- PepXMLViewer: implement "preferences" tab: choose ions series, spectrum viewer, etc... ?
- PepXMLViewer: no pep-pro probability link in iProphet results
- Libra also needs some love (ability to curate ratios would be a great start...)
== From Henry (perhaps he already checked this in?) :
Following up on this discussion, I would like to propose the following. (This is not urgent since our course doesn't use OMSSA or any of the newly-supported engines, so it doesn't need to be in the release soon.)
1. Change xinteract to run RefreshParser before PeptideProphet.
This takes care of the protein name issues for OMSSA, and makes sure that the NTT and NMC fields are there and calculated correctly for PeptideProphet. Some search engines don't fill in those fields and cause PeptideProphet to crash.
The flip-side is mainly inefficiency. If the user decides not to keep all search hits regardless of probability (i.e. not specifying -p0), then this means RefreshParser unnecessarily refresh a bunch of wrong identifications that won't be in the final pepXML file anyway. But then again, given that nowadays PeptideProphet often relies on the protein name (whether it's a DECOY or not), it seems safer to ensure that the protein names are right -- even for the wrong hits -- before we run PeptideProphet. Also, with the new implementation, for most files RefreshParser is so fast that I don't think it will make much difference in running time anyway.
If the user doesn't want to refresh, he/she can always turn off RefreshParser (-nR option).
2. Have InteractParser detects if the search engine is OMSSA, and if so, apply the fix_pyro_mods_ option automatically.
This goes without saying. The only thing is the user doesn't have to turn on the option manually. I don't know if other engines have the same problem. If so, it's easy to add them to the list.
