Greetings,

I am working on a project that requires a detailed audit of the entire
MS processing chain, including the conversion of the Finnigan raw data
into mzXML.

I've got a question about the source of precursor intensity values in
MS2 scans obtained with Thermo instruments. Because precursor
intensity is not be found anywhere in the Finnigan files (not as a
named attribute), but it is found in the profile data, I assume readw
(or the Thermo library it uses -- not sure how the code is divided
between them) searches the parent scan's profile to find the intensity
corresponding to the precursor mass.

Q1: If that's what it does, what is the algorithm?

Q2: Does it always do that correctly?

A case in point:

http://www.pil.sdu.dk/1/MSQuant/LTQ-FTsampleDataSet1,2004-02-14.zip

readw v. 4.3.1 generates the following data set for the first MS2 scan
in this file:

   <scan num="395"
    msLevel="2"
    peaksCount="184"
    polarity="+"
    scanType="Full"
    filterLine="ITMS + c ESI d Full ms2 [email protected]
[90.00-755.00]"
    retentionTime="PT904.361S"
    lowMz="110.959"
    highMz="474"
    basePeakMz="354.963"
    basePeakIntensity="1354.62"
    totIonCurrent="6636.68"
    collisionEnergy="27" >
    <precursorMz precursorIntensity="574.678" activationMethod="CID"
>370.12</precursorMz>
    . . .

The naïve way to do it (and I can think of no other) would be to take
the stated precursor mass (370.121154785156) and look for a matching
bin value in the parent scan's profile (in this case, scan 394):

370.117473251246        2696.37426757812
370.119133095675        6863.94091796875
370.120792954993        9653.3193359375
370.122452829198        8103.22998046875

In this case, I would simply grab the value at 370.120792954993.

Readw, however, picks 574.678. Where does it get it?

I do a search across the entire file and find matching values at four
locations:

       addr           hex       decimal
 72d24a  6AAB0F44  574.6783
1731572  65AB0F44  574.678
32c86ce  67AB0F44  574.6782
33de66a  60AB0F44  574.6777

Of these, only the first one seems to be relevant, as it happens to be
in the profile data for scan 393 -- the one immediately preceding my
parent scan:

370.112977204668        432.1953125
370.116296831858        565.481323242188
370.119616518597        574.678344726562
370.122936264888        449.774383544922

Is this a common array indexing error, or is there some magic I fail
to understand?

Thanks,

--Gene

-- 
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.

Reply via email to