Skip to main content ↑ ↓

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - ajsp

1
XCMS / Re: Extracting peak picking information
No suggestions???

I'm not any further forward, and as I have tens of thousands of peaks, making a pdf of all of them is not practical (and ENORMOUSLY slow)......
2
XCMS / Re: Extracting peak picking information
For the moment, I'm using this "pdf(fnamepdf, onefile=TRUE)" before the xcmsSet construction, then "graphics.off()" after. That does the trick, but takes aeons.

Any tips from xcms ninjas for optimising peak picking for these kinds of 'busy" chromatograms? Help would be much appreciated....

Andy
3
XCMS / Extracting peak picking information
"Executive version":
 How do I extract the figures produced by the centwave algorithm to describe peak fitting, without watching all 60k ROIs flash past?


Hello xcms gurus,

Having previously used xcms as a way to automate extraction of EIC data, I'm having a crack at using it to pick peaks for our systems. The problem here is that I am a little bit of a fraud here - I am not doing metabolomics, but combinatorial 'systems' chemistry, and I fear that the systems I'm looking at are less amenable to this - the result of a messy "combinatorial explosion" (ca. 60k ROI per sample; lots of samples, and this is the first stage in my complexity progression)....

I am using the centwave algorithm, and a lot of the traces you get as it picks peaks have the kind of problem illustrated here:

[attachment=0:3u05twde]multiple peaks to pick.png[/attachment:3u05twde]

To get this image, I had to run something like the line below, and wait endlessly.

Quote
xset <- xcmsSet(datafiles, method="centWave", ppm=15, peakwidth=c(0.2,5), snthr=6, mzdiff=0.005, integrate=1, noise=0, fitgauss=TRUE, sleep=0.001)
[n.b. settings slightly different to produce the image - different peakwidth, no fitgauss]

How do I extract these figures AFTER the process (or to files during it)? That would let me supervise, and return to the same EICs time after time, to check the optimisation. Alternatively, is there another way to plot what has been picked against the real data??

The products we're looking at are peptides. In the end I hope to look at sequence bias. Any suggestions? I feel like I'm getting somewhere (slowly), but would appreciate knowing if there is a smarter/established way to do this... e.g. I can produce (v. long) lists of possible products - should I be using a more targeted approach?

Cheers,

Andy

[attachment deleted by admin]
4
XCMS / Re: EIC errors
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.
5
XCMS / 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).
7
XCMS / Re: extracting metadata from mzXML
Thank you people. I have sorted out what I wanted to do using Ralf's suggestion, and thanks to meow for the suggestion - good learning.

Sorry for the late reply,

Andy
8
XCMS / Correction of retention times 'by hand'
Dear All,

I'm pretty new to LC-MS. I am using it to compare a sample/set of samples from chemical experiments (complex systems) looking for new/unique products compared to a single blank/control (usually just the HPLC derivitisation procedure). I thought the peak-picking in xcms might be rather good at picking up things that we haven't noticed 'by eye' (in the UV detector or TIC) as we build up complexity.

Unfortunately, we're using a less-than-pro LCMS setup: we lack the hardware to synch the the LC and MS, so we are synching by pausing the MS acquisition until the LC injects. As a result, the LC retention times are all skewed by a significant gap, which can be read as the gap between the first and second scan, minus the time taken for the scans (typically 30-60 seconds, minus 1 second). The retcor function of xcms seems to have problems dealing with this; I imagine understandably, as the blank contains very few of the peaks observed in the other samples (in contrast to a lot of metabolomics applications, where most things seem to be present, and you're looking for smaller percentage changes in intensity).

This brings me to ask two questions:

 - Is there a straightforward way to adjust the retention time 'by hand', either in the mzXML files, in original Waters .raw files, or after loading into xcms?

 - Can anyone experience suggest a better approach than xcms for this application (making a list of 'significant' peaks, ideally disregarding those present in the blank) that doesn't require a lot of very expensive proprietary software? Or, indeed, a better approach within xcms that deviates significantly from the workflow described in "LC/MS Preprocessing and Analysis with xcms" document at http://http://bioconductor.org/packages/release/bioc/vignettes/xcms/inst/doc/xcmsPreprocess.pdf.

Thanks for your help,

Andy


nb. MS is a Synapt, acquiring HRes continuum data (0.5s scans) with a lockmass; converting .raw files to mzXML using mzconvert at the command line (ordering wrt retention time to fold in lockmass scans).

[Disclaimer: I'm new to LC-MS and I've tried to look for the answers to my question, but my sincere apologies if I'm asking an astonishingly stupid question]
9
XCMS / Re: Ion Mobility data
Fereshte (or anyone else hanging around),

Still no useful advance on the approach I outlined before, but you may be interested in checking out a program called "Amphitrite" from the Thalassinos group in London. It doesn't seem to be available online yet, but "soon", and there is a publication describing it here: http://http://dx.doi.org/10.1016/j.ijms.2012.09.005

It looks rather handy - I'm certainly keen to dump my bespoke procedures and use it for some things when I can get my hands on it.

Andy
11
XCMS / Re: Ion Mobility data
Fereshte,

I haven't got my head round this yet, I'm afraid. I have been in contact with the Waters application people, but they weren't able to help much beyond what I've already worked out (in fact they weren't even able to point me as far as I have arrived). I imagine that it must be possible or being developed at the moment, as they are selling more and more of these machines......

When you say that you want to convert you .raw to something with ONLY ion mobility data, do you mean only DT data (as opposed to DT vs. RT, or DT vs. m/z)?

Andy
12
XCMS / extracting metadata from mzXML
Hi,

I'm converting Waters data to .mzXML using msconvert, then loading it to xcms as raw data (something like, spec.raw <- xcmsRaw("spec.mzXML", profstep=0.001, profmethod="bin")). I would like to be able to extract metadata on the original Waters .raw file from which the .mzXML was taken; I know this is stored, as I can see it if I load the mzXML using  readMzXmlFile (stored at specsm$metaData$parentFile[[1]]$fileName), but I havne't figured out how to get it out of xcms.

Any suggestions?

Thanks very much,

Andy

[edit: Or any other clever way to get the data out, without using the route I have been, since it takes about 10 mins to load the > 200 Mb files]
13
XCMS / Re: Ion Mobility data
ps. Are there many other people dealing with IMS-MS data here?
14
XCMS / Re: Ion Mobility data
Fereshte,

Are you using LC/some other separation, or just doing direct infusion?

If you're just doing direct infusion of samples, then you can export IMS data from Driftscope with the retention time data stripped, then treat it just like LC/MS data (with very short retentin times). I'm just learning this stuff, but I've been using MSConvert to get into mzXML files, then the world is your oyster. Oh, if you export with the drift time in ms, you need to divide by 60 (along with some factor of 10 I can't remember off the top of my head) to get the drift time in ms.

If you're using a separation, I'll be waiting here to see how you go about it....

Good luck,

ajsp