Skip to main content

Messages

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

Messages - Jan Stanstrup

226
Other / Re: Tandem MS/MS .d files and Proteowizard
As far as I know xcms was never build to be able to use MS2 data for profiling in any smart way. As I suggested I thought it was possible to force it to read it like ms1 data. But it seems I was wrong.

What you can do is first make the ms2 data look like ms1 and then do profiling. This I have done myself before. It goes like this:
for each file you read the data with xcmsRaw, convert it to look like ms1 with msn2xcms from the MetShot package and you can then write it to a file with write.mzdata. With the new files you should now be able to profile normally with xcmsSet.

You will of course loose the MS2 information.


Some other questions:
does your file contain only MS2 or also an MS1 trace? It seems you are expecting this or are you thinking of the precursors as MS1? This would not be the way most programs think of MS1.
Is the MS2 data dependent or are you doing a targeted analysis?
227
Other / Re: Tandem MS/MS .d files and Proteowizard
It is unclear what you are trying to achieve. It doesn't sound like an msconvert issue to me. Do you want to ignore ms2 data and do profiling on ms1 data in the file or do you want to do profiling on ms2 data?
If the first is the case you should use --filter "msLevel 1" with msconvert to get only the ms1 data.

The error you report suggest that you are trying to use xcmsSet on your data  ms2 data? I think you can set mslevel=2 in xcmsSet if you want to do that though I have not tried it myself. You can use xcmsRaw (includeMSn=TRUE) for one file and see how xcms sees your data.
229
XCMS / Re: Identified features does not match mz values in raw file
Check the mzXML files for example in mzMine. It might be that the files have been converted uncalibrated:

Quote
Both proteowizard’s msconvert and the CompassXport tool provided by Bruker to convert the proprietary format only export calibrated data after changing a specific windows registry key (see below). A user being unaware of this fact will obviously not be able to carry out a proper data analysis.

Suggested solutions
Update to a recent version of CompassXport and simply enable the use of calibrated data by modifying the appropriate windows registry key.
Create a file called “UseEnhancedMSMSUseRecalibratedSpectra.reg” and copy the following:
Code: [Select]
Windows Registry Editor Version 5.00 
[HKEY_LOCAL_MACHINESOFTWAREBruker DaltonikCompassXport]
"UseEnhancedMSMS"=dword:00000001
"UseRecalibratedSpectra"=dword:00000001
Then execute this file. The converters should now work correctly.


ref: http://http://link.springer.com/article/10.1007/s00216-013-6954-6
230
XCMS / Re: Duplicate peaks despite grouping
What does your plots from retcor look like? Does the correction work OK? Which setup? HPLC? UPLC? Runtime? Q-TOF or something else? What parameters did use with group when using density? Example of peaks that are the same but split?

I have written a function that might help you debug. It is called analyze.xcms.group and can be found in this package: https://github.com/stanstrup/chemhelper. For the moment it is undocumented. Also the package has an unfortunate number of dependencies so it is quite bothering to install. Sorry about that.


Code: [Select]
library(faahKO)
filepath <- system.file("cdf", package = "faahKO")
xsg <- group(faahko)
xsg <- fillPeaks(xsg)
analyze.xcms.group(xsg,mz=256.1500,rt=3451.305,rt_tol_sample=300,mz_tol_sample=0.01,rt_tol_group=300,mz_tol_group=0.05)

mz and rt correspond approximately to the peak of interest. rt_tol_sample and mz_tol_sample are tolerances for finding related peaks across all samples. rt_tol_group and mz_tol_group are tolerances to find related peak groups.

Output plot from above example:
[attachment=0:3h5rjt98]Rplot.png[/attachment:3h5rjt98]

The rectangles show how the peaks from each sample was grouped. It might help you understand if there is no clear separation and if your issue is in the rt or mz dimension.

[attachment deleted by admin]
231
XCMS / Re: Quantifying centroided MS data with centWave
XCMS quantification works with centroided data. The shape of the mass peak is not reconstructed.
The profStep parameter is not related to continuous data. It is used to create extracted ion chromatograms (mass traces, m/z slices or profiles). The quantification is based on these profiles during fillPeaks. In my experience you get better result if you change the defaults (profStep = 0.1) in xcmsSet by setting profparam in xcmsSet. For example:

Code: [Select]
xcmsSet(files=files,
              ...,
                profparam = list(step=0.005)
)

As far as I have been able to figure it is perfectly safe to set profStep very low since slices are combined to fit the ppm parameter anyway. Smaller slices uses more memory though.
233
XCMS / Re: Find peaks Orbitrap
Did you try looking at your mzXML file in for example mzmine to understand what is in your scans? Do your scans only contain the MS1 data? I would guess that they might alternative between the MS1 and MS2 making the data a bit none-sense. The fact that you need msn2xcmsRaw indicate this.

As far as I remember the solution is to add --filter "msLevel 1" in msconvert. Then you shouldn't need msn2xcmsRaw and you can use xcmsSet normally instead of xcmsRaw + findPeaks.

Also I would be a bit concerned about the number of scans over each peak in your MS1 when you do this many MS2's at the same time. It might not be easy to quantify or even finds the peaks if there are very few scans over each peak.
If the data is in fact with very few scans per peak you might have better luck with matchedFilter than with centWave.
235
XCMS / Re: QQQ MRM data
I have never tried it myself but have you tried playing with the includeMSn and mslevel parameters in xcmsRaw? My guess would be that includeMSn=TRUE might do the trick.
Opening your mzML file in a text editor might also give you an idea how the data has been written.
240
XCMS / Re: Get Spectra using xcmsSet object instead of xcmsRaw obje
Why do you do the peak picking again on the xcmsRaw object? You should be able to use getScan directly on the xcmsRAW if all you want is a single scan.
Be careful about finding your scan if you use retention time correction.

Some ideas:
* If the process is CPU limited you could speed it up by multi-threading it using parApply methods.
* If you can guess approximately which scan you need you can probably speed it up a lot by not reading the whole file. In other words use scanrange in xcmsRaw.


edit: typos.