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.
