Skip to main content
Topic: EIC errors (Read 4548 times) previous topic - next topic

EIC errors

Hello,

[Caveat: I'm a relative novice at manipulating ms data in r/with xcms - apologies if this is a little daft]

I'm using xcms to extract EICs from some LC-MS data (when I say some, I mean a lot - from a list of possible combinations in a combinatorial synthesis). When I compare EICs that are produced by xcms with those I produce using the software from the MS we are using (Bruker), I notice that the ones form xcms seem to incorporate a much wider band (+/- around the mass in question) - manifested in seeing a lot more peaks in the EICs, This is worrying, and I am not sure where I am introducing the error. Here is the workflow:

 - Produce LC-MS data using Bruker Compass/Hystar.
 - Convert to mzXML using MsConvert GUI (Not changing settings: ie. 64 bit, Write index, using zlib compression, TPP compatability).
 - Open in r with xcms: "xr <- xcmsRaw(lcfile, profstep=0.005, profmethod="bin")"
 - Get EIC for each as follows:
      err <- 0.001
      MzRange[1,1] <- td[i,2] - err
      MzRange[1,2] <- td[i,2] + err
      eic <- getEIC(xr, mzrange=MzRange, rtrange=RTRange)
      a <- attr(eic, "eic")$xcmsRaw[[1]]
 - Put the x,y data for the EIC into a plot.

Any ideas why the EIC I get that way would be so different that the one produced in Bruker software with mass +/- 0.001? Does that prodstep need to be much smaller? I imagined that half the err value would be sufficiently low, but I've tried down to 0.002 without any joy (that made my computer groan, but didn't improve the situation)?

Thanks for your help,

Andy

nb. I'm looking at the product of some (non-standard) combinatorial peptide synthesis, although for the problem I'm having, I don't think that's relevant. As well as getting a handle on what is where, I am using the EICs to construct a kind of "virtual BPC" to see if the mass lists I'm producing combinatorially can account for the BPC observed (that is, if all the products are of the kind we expect, even if we can't ID all of them explicitely) - if anyone can tell me if that approach is established/has a name/is stupid, that would also be much appreciated! It seems to produce a really good fit (and even with the wider EICs, that would be really improbable with the reasonable-length mass list I'm matching).

Re: EIC errors

Reply #1
You probably just need to set the "step" argument in getEIC instead of the profstep in xcmsRaw. From what I can figure profstep from the xcmsRaw object is ignored. You can even set profstep=0 to not waste time generating profiles that are recalculated by getEIC anyway.


edit: It might be a good idea for you to set the step value several times lower than the window you want to extract to make sure that the m/z slices that are combined based on your mz range doesn't extend too much outside your mz range.
Blog: stanstrup.github.io

Re: EIC errors

Reply #2
Wow, that was quick!

Thanks Jan, that seems to have sorted my problem - I'm now pretty much reproducing what I see on the instrument software. I hadn't realised that the EIC was going back to the data and binning it again itself.

If anyone has any idea about whether the approach I describe (producing a "virtual BPC" and comparing to the real BPC) is called, or whether its validity has already been questioned (I don't want to reinvent a faulty wheel!), I would appreciate the input.