are there any specific issues associated with running a large number of samples (ca 650 incl blanks and QCs) using XCMS?
LC-MS data will probably aqcuired by an Agilent 6550, file size approx 500 MB in centroid mode. My computer has Windows 64, 16 GB RAM, and 12 processors.
I mainly wonder if the number of samples will exceed the maximum size of any vectors or objects - then I would want to consider this point already in the study design.
I have been wondering why the mzwid parameter in the group() function (group.density) has to be specified as an absolute value in Dalton and not as a relative (ppm) value. Especially when using a wide m/z range for data acquisition, it seems like a good part of the precious mass resolution is sacrificed in this step, for low m/z peaks.
The only workaround I could think of is to split my xcmsSet object into several mass ranges and then use appropriate mzwid for each mass range. But this is annoying and also it won’t let me do other things with the complete xcmsSet object, like Camera.
The specific problem I am working on is that my mass spec (Agilent 6540 q-Tof, nominal mass accuracy 1ppm, mass range in my study 50-1700 m/z) produces some satellite peaks for the more intensive peaks (see example, random intensive peak, projected using MZmine. Blue=main peak). [attachment=0:1b7n3hil]peak70.png[/attachment:1b7n3hil] I want to remove these satellites in a data preprocessing step, because they inflate my peak list without carrying extra information (except noise). The mass spacing between adjacent satellites is generally between 50 and 100 ppm. These satellites also have a good sample-to-sample mass precision. It is much easier to treat and remove these satellites if I can trust that they are adequately group()ed. Using a suggested absolute mzwid of 0,015 cannot accomplish an adequate group()ing for those satellites. A relative mzwid of 5 or 10 ppm would do the trick. – It would probably also help to mass-resolve real peaks in the low mass region that would be grouped together using mzwid=0,015.
I have some comments and suggestions on (sample) fresh weight correction.
To my understanding, a fresh weight correction must be done either before the initial peak detection with xcmsSet() (i.e. on the raw data) or after fillPeaks(). If it is done inbetween, a weight correction will be applied only to the originally picked peaks, and not on the ones that are added by fillPeaks(), which would be wrong. I could not figure out how to do this on the raw data; also, I would prefer to do it later.
The weight-correction code in the Cookbook at viewtopic.php?f=26&t=143 appears not to be working properly on an xcmsSet object after fillPeaks(), because it does not take into account the order in which peaks are organized in a fillPeaks()ed xcmsSet object (detected peaks first, filled peaks later).
Below is a modified piece of code that should do a weight-correction after fillPeaks(). ( Sorry for the lack of elegance, I am learning R at the same time as I am learning XCMS.)
#first part of factors, for detected peaks factors1 <- rep(100/fw, times=table(peaks(xset13)[,"sample"])) #second part of factors, for filled peaks nrorigpeaks<-nrow(xset13@peaks)+1 nrtotalpeaks<-nrow(xset14@peaks) factors2<-rep(100/fw, times=table(peaks(xset14)[nrorigpeaks:nrtotalpeaks,"sample"])) #combine factors factors<-c(factors1, factors2)
Talking about elegance, it would of course be much nicer with a more “integrated” way of fresh weight correction (or other correction, for that matter). The way of explicit fresh-weight assignment as in the code below will cause trouble in case samples are removed or rearranged upstream. For example, fresh weight could be specified in a table where one column carries the sample names and the other one carries the weights. Does anyone know of a simple way of doing this?
By the way, thanks to the developers for a great xcms! /Axel
