group()ing and mass tolerance

June 26, 2012, 02:56:39 AM

Hi,

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.

Thanks for any comments!
Cheers
Axel

[attachment deleted by admin]

Re: group()ing and mass tolerance

Reply #1 – August 01, 2012, 11:51:49 AM

These artifacts (AKA ringing) are a known issue with Agilent instruments.

The artifact peaks usually show up with a distance of m/z 0.01 - 0.02 like in your example.
One way to filter them out is during the feature detection step, by setting the mzdiff parameter to something like 0.1.

I have also heard some rumors that Agilent is planning to release a software update that will fix this problem (by filtering them out I guess).

Ralf