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 <[email protected]> wrote: > 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 wrote: > > 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 <[email protected]> > > wrote: > > >> 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 wrote: > > >>> 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 -- 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.
