Hi Brendan, I considered this option but it is not so easy to do with iProphet drawing the results for one search run from multiple possible search engines a single MS runs spectra may now be reported across several msms_run_summary elements. Computing how many will be reported is possible, and requires traversal of the input pepXML files to add the number of msms_run_summary elements across them all. However, the number of spectra in different msms_run_summary elements may be quite different so using this value for a progress bar report may not be best.
For your progress bar can you instead consider the file-size and bytes read? Thank you, -David On Sun, Dec 25, 2011 at 10:52 AM, Brendan MacLean <[email protected]> wrote: > The BiblioSpec library builder builds spectral libraries from many > peptide search formats. It has long supported pepXML from > PeptideProphet. I am now looking at expanding this support to include > pepXML from iProphet. One issue I have encountered, however, is that > unlike the PeptideProphet pepXML it does not seem possible to know how > many <msms_run_summary> elements the file contains without reading the > entire file. In the PeptideProphet element: > > <analysis_summary analysis="peptideprophet" ...> > > The number of <inputfile> elements usually corresponds to the number > of <msms_run_summary> to follow, which is extremely useful in > presenting progress information during pepXML parsing. > > Unfortunately, in the corresponding iProphet element: > > <analysis_summary analysis="interprophet" ...> > > The <inputfile> elements are for pepXML files, which themselves may > have contained results for many <msms_run_summary> elements, and many > <inputfile> elements. > > It sure would be nice to have some way of knowing early in the file > parsing how many <msms_run_summary> elements there might be. Also, it > seems like the current strategy of discarding all <inputfile> elements > from included pepXML files and representing them as only a single > <inputfile> element for the containing pepXML file loses useful > information. Perhaps <inputfile> elements could be nested to preserve > the original input files. > > Any other way to have the pepXML forecast the number of > <msms_run_summary> elements would suit my current need as well. > > Thanks for considering. > > --Brendan > > -- > You received this message because you are subscribed to the Google Groups > "spctools-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/spctools-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en.
