Skip to main content
Topic: Getting peaks filled in that don't seem to be there... (Read 4153 times) previous topic - next topic

Getting peaks filled in that don't seem to be there...

I have had a frustrating issue with XCMS for a while now. Rather than describe this I've attached a PPTX file that shows first several peaks of the same m/z which have been listed, and in the second slide there is a trace of the 10 ppm window of that m/z. As you can see there are one or maybe two peaks in the trace but XCMS gave me several more from out of the noise.

How to fix this? I have HF QExactive data, positive mode, Hilic HPLC. I used centWave and obiwarp.

ppm=2.5
SNR=10
peakwidth=c(10,60)
noise=5000
prefilter=c(3,5000)
mzdiff=-0.001
bw=5

[attachment deleted by admin]

Re: Getting peaks filled in that don't seem to be there...

Reply #1
I have the same problem often too and no general solution. XCMS seems to be a bit "too good" at finding peaks in many cases.
Have you tried raising the SNR and/or the prefilter count? If this is the typical noise level your prefilter looks very low. I have also found that real peaks usually survive quite a lot higher SNR.
Blog: stanstrup.github.io

Re: Getting peaks filled in that don't seem to be there...

Reply #2
It has been a while since I have replied (sorry), but I would tend to agree with you, Jan, that a higher SNR does prune some of these false features out. But this is a very fine line for discovery metabolomics. However, setting minfrac around 0.5 or so seems to kill off a large chunk of the false features. Strangely, some will still survive. I am not sure what other parameters to play with in hoping to address this. As I have time in the near future, and now that the forum is back up, I will post my full script with a model data set showing the phenomenon and see if we can make progress.

It may be relevant to point out that I really don't know the best way to determine what mzdiff ought to be on a high resolution instrument such as the HF QExactive. If mzdiff=-0.001, that's allowing two features to overlap by 10 ppm (@ 100.0000 expected m/z) and still be detected... Which seems quite liberal, but as the parameter doesn't scale with m/z (i.e., it is absolute with the units), larger masses will be detected more conservatively. Sure enough, I see *most* of the false features in the low range (85-200 m/z). Does this suggest mzdiff may be the culprit? I have not had time to test it yet, but I will try to spend a bit of time on it later and report back...