Question on MS level

[Matthew Chambers]

This is a simple question I think: is the precursor of a MSn spectrum
the most recent MSn-1 spectrum, or the most recent MS1 spectrum?

-Matt

[Greg Bowersock]

Either. It depends on the instrument method (on the Thermo equipment atleast). I could make a method where I did the following:

1 Full Range MS

2 MSMS on Top Peak from 1

3 MSMS on Second Peak from 1

4 MSMSMS on the Top Peak from 2

5 MSMSMS on the Top Peak from 3

6 MSMS on Third Peak from 1

etc

 

There is no general rule, since it could be setup anyway that the person running the instrument wanted. Atleast in theory. I haven't tried to do a run with anything like that, but I know it could be setup.

 

Greg

 

[Matthew Chambers]

Good point. I think looking at the scan events is the only way to get it
right. Both ReAdW and msconvert (ProteoWizard equivalent tool) use the
latter method I mentioned (most recent MS1 spectrum). I fixed it in
LibMSR to use the former method which I think is likely to work
correctly for the vast majority of use cases, but your example is quite
reasonable and should be properly handled. Thanks!

This brings up the issue of how this should be handled in mzXML with the
nested scan elements. Should scan 4 be nested inside scan 2's element
and scan 5 nested inside 3's element? And both 2, 3 and 6's elements
would be nested in scan 1's? This is particularly important since few
mzXML writers actually use the optional precursorScanNum attribute
(unfortunately).

-Matt

Greg Bowersock wrote:
> Either. It depends on the instrument method (on the Thermo equipment
> atleast). I could make a method where I did the following:
> 1 Full Range MS
> 2 MSMS on Top Peak from 1
> 3 MSMS on Second Peak from 1
> 4 MSMSMS on the Top Peak from 2
> 5 MSMSMS on the Top Peak from 3
> 6 MSMS on Third Peak from 1
> etc
>
> There is no general rule, since it could be setup anyway that the
> person running the instrument wanted. Atleast in theory. I haven't
> tried to do a run with anything like that, but I know it could be setup.
>
> Greg
>
>

> On 3/27/08, *Matthew Chambers* <matthew....@vanderbilt.edu

[Ning Zhang]

Well, in that regard, I like the schema version 1, in that all Scans are
recorded sequentially. I met the problem when I try to modify the JRAP
parser for schema 2.0 from 1.0.

My two cents.
--Ning

[Brian Pratt]

As I understand mzXML, you'd expect this nesting:

{ 1
{ 2 { 4 } }
{ 3 { 5 } }
{ 6 }
}

which probably knocks holes in a number of apps that expect the scan order
to match up with the time order (including InsilicosViewer, I think).

Brian

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com] On Behalf Of Matthew Chambers
Sent: Thursday, March 27, 2008 12:28 PM
To: spctools...@googlegroups.com
Subject: Re: Question on MS level

[Jimmy Eng]

I never liked scan nesting and the example Greg brings up is exactly why
nesting doesn't make sense. I'd suggest recording scans sequentially as
they are acquired and reporting some reference to the parent scan for
each daughter scan.

- Jimmy

[Brian Pratt]

Hmm, it might be a good idea to make RAMP tidy up the index to enforce a
time ordering of the scans if we think we're going to see this kind of data
in the wild. AFAIK up 'til now we've only encountered the variety
{ 1
{ 2 { 3 } }
{ 4 { 5 } }
{ 6 }
}
I say this as the issue has never been raised that I recall, but I think
maybe Ning is saying otherwise.

[Greg Bowersock]

What about the case for Triple Play data? Which when setup correctly is like this:

1 Full Scan MS

2 Zoom Scan MS on a window of the Top peak from 1

3 MSMS on the Top Peak from 2

4 Zoom Scan MS on a window of the 2nd peak from 1

5 MSMS on the Top Peak from 4

 

It is similar to the nesting that Brian shows, but the MS level isn't really nested like that.

 

Greg

 

[Joshua Tasman]

Hi all,

Thanks for bringing up this discussion again, Matt. I'm fine with getting rid of nesting scans and only having a "parent scan" reference. I'm not exactly sure how to examine the scan methods to determine how to interpret the correct parent, but it sounds like you could show me how, Matt. Let's continue off-list. Thanks for everyone's examples.

I do want to correct one thing-- the current readw converter will take the last MS[n-1] as the precursor (not the last MS1) for n>2.

Josh

Greg Bowersock wrote:
> What about the case for Triple Play data? Which when setup correctly is
> like this:
> 1 Full Scan MS
> 2 Zoom Scan MS on a window of the Top peak from 1
> 3 MSMS on the Top Peak from 2
> 4 Zoom Scan MS on a window of the 2nd peak from 1
> 5 MSMS on the Top Peak from 4
>
> It is similar to the nesting that Brian shows, but the MS level isn't
> really nested like that.
>
> Greg
>
>

> On 3/27/08, *Brian Pratt* <brian...@insilicos.com

> >> <mailto:matthew....@vanderbilt.edu

[Brian Pratt]

I think that would just be:

{ 1 }

{ 2

   { 3 }

}

{4

   { 5 }

}

 

As I understand it, the nesting expresses MSn/MSn+1 relationships, not zoom scan relationships.  The whole zoom scan thing wasn’t really considered in mzXML, I think.  If it’s being written out by some converters as

{ 1

  { 2

     { 3 }

  }

  {4

     { 5 }

  }

}

then I think that’s an error.

 

Brian

---

<br

[Dmitrii Tchekhovskoi]

Hi,

I would like to share some experience on finding the precursor scan
using a modified ReAdW code.
I do not insist that what I describe below is the only right way; I even
am not sure it is the right way.
However, so far it seems to be a reasonable approach.
Please correct me if I am wrong.

(1) Determining the precursor scan of a MS2 spectrum
The Xcalibur method
void GetPrecursorInfoFromScanNum(long nScanNumber, VARIANT *
pvarPrecursorInfos, long * pnArraySize)
works only for ms2 spectra (the program crashes on an attempt to call it
for MSn (n>2) most probably due to some kind of allocation bug inside
the Xcalibur software). This method provides a reasonable precursor scan
number that is not necessarily the latest ms1 scan. It also provides a
higher accuracy Isolation m/z. (However, the monoisotopic m/z and
precursor charge it provides are not useful. Both of these values may
differ from the TrailerExtra numbers: the former seems to be sometimes
the same as the Isolation m/z and the latter may be the charge of the
precursor scan base peak; this usually happens when the corresponding
TrailerExtra values are missing)

(2) Determining the precursor scan of a MSn (n>2) spectrum
Since Xcalibur software does not provide this without crashing the
converter application, the simplest way seems to be finding among the
most recent preceding scans those MS(n-1) scans that have all
PrecursorMz@CollisionEnergy entries in the filter line exactly identical
to the first n-2 entries in the filter line of the MSn in question.

(3) It looks like some additional information useful for selecting a
single precursor scan out of several candidates found in (2) could be
obtained by parsing the Instrument Method record and choosing the the
precursor scan candidate that has the right event number.

I haven't done (3) yet because I could not find any description of the
Instrument Method record syntax .
Is there a way to find such a description for all possible kinds of ms
RAW files?

Regards

Dmitrii