Hi Matt, Thanks for the explanations.
I will probably stick with the msconvert Agilent output for now, so I'll post back if I run into any problems, Regards, bio.x2y On Feb 16, 6:54 pm, Matthew Chambers <[email protected]> wrote: > Hi, > > 1. The msconvert scan numbers correspond with the Agilent nativeID > (scanId) which are not consecutive like Thermo scan numbers. I am not a > keen believer in the "scan numbers must start at 1" guideline assumed by > the TPP tutorial. For one thing, simply filtering a file by ms level > will kill that even for Thermo files. That said, there is an outstanding > request for an option in msconvert to force the output mzXML to have a > TPP conforming numbering scheme. Unfortunately it hasn't been > implemented yet. > > 2. In pwiz we use the precursorScanNum attribute of the precursor > element to convey this information. That attribute was added because it > was realized that the nesting semantics were insufficient to represent > some advanced acquisition methods, or at least insufficient without > forcing the scan numbers to be written out of order. It also loses its > meaning with the ms level filtering mentioned above. It also makes the > files somewhat harder to read and write. > > Your final question probably depends on what tool you're referring to. > The only SPC tools I use with regularity are the converters and > sometimes PeptideProphet. But I don't think I've tried PeptideProphet > with msconvert's Agilent output. Your brave testing efforts will be > appreciated. :) > > Hope this helps, > -Matt > > > > bio.x2y wrote: > > Hi, > > > I've been using both trapper and msconvert to convert Agilent > > MassHunter ".d" data to mzXML. I'm using msconvert from the > > proteowizard 1.6.0 distribution, and I'm using the standalone trapper > > 4.3.1 from sashimi. > > > I've noticed that the msconvert output is structured differently from > > the trapper output, and appears to break at least two rules specified > > in the mzXML 2.1 tutorial (http://sashimi.sourceforge.net/ > > schema_revision/mzXML_2.1/Doc/mzXML_2.1_tutorial.pdf). > > > (1) Scan numbers (as per the scan/@num attribute) are supposed to > > start from 1, and ascend sequentially (presumably without skipping). > > The msconvert output numbering appears to be arbitrary (for me, it > > starts at 2273 and ascends with gaps). > > > (2) Scan elements representing MS2 scans are supposed to be nested > > within the elements representing their precursor MS1 scans. The > > msconvert output does not perform this nesting. > > > The trapper output appears compliant. > > > Are these differences causes for concern? Is it possible that SPC > > tools (or others) might function incorrectly when processing msconvert- > > generated mzXML files? > > > Thanks, > > bio.x2y -- 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.
