Bit precision of Trapper output

[bio.x2y]

Hi,

Msconvert allows the user to specify the required precision of output
peak data - either 32-bit or 64-bit.
Trapper does not seem to have an equivalent switch (at least there is
no mention of it in the usage documentation).

(1) Is there a way to force Trapper to generate 64-bit precision
output?

(2) I'm wondering if I would "lose" data by using Trapper for Agilent
MassHunter ".d" data.
I'm not comfortable enough with C++ to answer this for myself - when
Trapper/Msconvert call the Agilent interface, do they receive back 32-
bit or 64-bit data? I'd like to know if the 64-bit precision of
Msconvert is actually giving me real data, or just padding out 32-bit
numbers to help collapse my hard drive?

(3) This is probably a question I should be able to answer myself, and
might be much too broad for here, but might there be any practical
benefit for having 64-bit data rather than 32-bit? I suspect that the
different might be negligible in the sense that the difference between
a 32-bit and 64-bit m/z would have no impact on things like peptide
identification or feature detection for quantification?

Thanks again,
bio.x2y

[Matthew Chambers]

1. I don't know.

2. The Agilent IBDASpecData interface returns an array of 64-bit floats
for m/z values and an array of 32-bit floats for intensity values.
However, msconvert ALWAYS defaults to writing 64-bit m/z values and
32-bit intensity values, regardless of the precision of the input. It's
a safe enough assumption. The 1000514 refers to the m/z array term in
the PSI-MS CV and the 1000515 refers to the intensity array. I agree
that behavior is absurdly confusing and jargonish. The byte order is
also pretty much irrelevant since both mzXML and mzML specify a
mandatory byte order. It would only matter for mzData which we don't
support yet.

3. Yes, for high accuracy data, there is benefit to using 64-bit m/z
values. But not a terribly significant benefit:
1234.567 -> 7 significant base10 digits is the worst case for 32-bit
IEEE-794 AFAIK.

-Matt

[bio.x2y]

Thanks again Matt.

Following up on your point 2 above, does this mean that the 32/64/mz32/
mz64/inten32/inten64 flags for msconvert are always ignored, or are
they used elsewhere, e.g. for non-Agilent data?

bio.x2y

On Feb 16, 8:17 pm, Matthew Chambers <matthew.chamb...@vanderbilt.edu>
wrote:

[Matthew Chambers]

Actually those flags are always used if present. They override the
default 64/32 setup for mz/intensity. If you pass --32 or --64, both
arrays will be what you specify. You can use --mz32 and --mz64 to
control the m/z array by itself. The source of the data (Agilent,
Thermo, Waters, mzML, mzXML, etc.) is irrelevant. You can upconvert from
32-bit mzML to 64-bit mzML. This could be useful if some target
consuming application only works with 32 or 64 bit arrays.

-Matt

[bio.x2y]

Hi Matt,

I've had a look at one of the mzXML files generated by msconvert using
default precisions (i.e. I didn't pass any precision flags on the
command line).

The "peaks" element base64 string encodes 128 bits for each peak,
implying that both m/z and intensity values are stored with 64-bit
precision as default, rather than with 64-bit/32-bit as suggested
above. Since the mzXML format seems to insist on a single precision
for both fields (as specified in scan/peaks/@precision), am I
interpreting this correctly?

Thanks,
bio.x2y

On Feb 16, 8:53 pm, Matthew Chambers <matthew.chamb...@vanderbilt.edu>

[Matthew Chambers]

For mzXML, both arrays have to be the same precision since there is only a single attribute to specify the precision of the entire base64 element.  Pwiz takes the maximum precision of the m/z and intensity arrays and set that as the precision for mzXML.

-Matt