Time for scan x greater than scan y - ProteoWizard

[hpbenton]

You converted a file using proteoWizard to an mzXML, you load it into xcms and you get something like the following error :

Time for scan X greater than scan Y

This is the default converting action of protoWizard. You will need to load the the not graphical user interface (GUI) version of the converter, msconvert.exe. Using a line somthing like the following in the dos prompt:

Code: Select all

msconvert D:\Data\MyFile.RAW --filter "sortByScanTime" --mzXML -o D:\Data\Output\

Currently, version 2.2, the "sortByScanTime" option is only avaiable in the command line version of the software and has not been ported over to the GUI yet.


Hint: If you're using MassLynx you can load up the run list and have it automatically run the converter on each file:

1) Open MassLynx and above the Sample Table select Samples → Format → Customise. Enable the following Fields to display
Process
Process Options

2) Choose Samples → Format → Save and save the new Sample List format.

3) Make sure that MassWolf/msconvert is in the MassLynx directory. Choose massWolf/msconvert from the Process drop down list. As massWolf/msconvert is a command-line tool it requires some parameters to make it function. In the below example the following line has been added to the 'Process Options' column;

massWolf add: --mzXML C:\MassLynx\Default.pro\Data\1234.raw

msconvert add: D:\Data\MyFile.RAW --filter "sortByScanTime" --mzXML -o D:\Data\Output\

4) To process data that has already been acquired use the usual MassLynx Run (play) icon and select “Auto Process Samples”. When processing starts a command prompt will open when required and will output the mzXML file into the parent folder.

[cbroeckl]

Paul,

I am trying to use proteowizard as you describe (i have been using databridge) to convert waters Raw to mzXML format. However, I am seeing some conversion issues which make me uncomfortable. Whenever I use databridge to convert to cdf, the masses are identical between the raw data and the cdf data. When I use massWolf to convert to mzXML, same mass data. When I use MSConvert - either throuh command line or GUI, I see a shift in mass, with an increase of about 0.05 - 0.1 Da. Have you seen this? I just want to make sure I am not doing anything wrong - and if I am not, then I want to make sure that others are aware of the bug - kinda throws a wrench in mass accuracy....

[Jan Stanstrup]

Proteowizard does not do the lockspray calibration that is needed for waters data:
http://sourceforge.net/mailarchive/foru ... -developer

So the error you see is simply uncalibrated data unfortunately.


edit: I just checked with masswolf and remembered why I don't use that. You get calibrated data all right but the lockmass scans are mixed in with you normal scan. Did you find a way to avoid/fix this?

[cbroeckl]

I actually collect the data as centroid, lockmass corrected, so I don't think that is the issue - it should already be lockmass corrected I think??? Unless I am misunderstanding the way waters writes the data. And no - I don't have a fix for the lockmass intermingled with the experimental data. Even though the MassWolf readme says "If the last function is MS and not MSMS, then it is assumed to be lockspray;" I am thinking that I just need to delete it from the 'raw' files before conversion, but I haven't tried this yet; such a crude method may cause more problems

All I want is to be able to bring MSMS data files from waters into XCMS, and it isn't trivial - any ideas?!

[hpbenton]

So when I started using waters data I used the massWolf converter. I noticed as you say Jan that the calibration scans are intermingled with the analyte scans. We corrected it by taking the nearest scans and placing them back into those scan. More detail is documented here :
http://www.ncbi.nlm.nih.gov/pubmed/20671148
This is now a function in xcms where you can add the line lockMassFreq=TRUE to xcmsSet.

As for getting MS/MS data into xcms from waters data I would try using massWolf. Then all of the scans that are MS/MS should be labeled as such in the mzXML file. The lock spray should not interfere with the MS/MS scans. After that you should be able to follow the regular pipeline :

Code: Select all

xraw <- xcmsRaw(mzdatafiles[1], includeMSn=TRUE)
peaks <- findPeaks(xraw, method="MS1") ## for a single MS/MS file

## OR
xs <- xcmsSet(mzdatafiles, method="MS1")
xfrag<- xcmsFragments(xs)


The xcms MSMS documentation is here:
http://www.bioconductor.org/packages/re ... cmsMSn.pdf

[cbroeckl]

I just tried deleting the lockmass scan data from the raw file, then converting using MassWolf to mzXML. The masses in the MS channel data are the same in the original waters data file as viewed with MassLynx as they are in the converted mxXML data as viewed by the Insilicos viewer. THis implies that the data, as they are stored in the Waters format raw data file are in fact lockmass corrected already - it should not need to be done by the converter. Maybe ProteoWizard is trying to use it to adjust the MS data???

massWolf --mzXML R:\Project.PRO\Data\Filename.RAW

Also, the conversion seemed to work fine - all the MS data looks like it is there, and it seems that all the MSMS data is there as well. So simply deleting the FUNC0003 DAT IDX and STS files might be a simple option for MassWolf conversion - I am not a programmer but I bet one could easily script that.... I just tried in on a single file, but seems functional.

[Jan Stanstrup]

Hi Paul.

I have been trying to use your stitch method but I always get an error:

Code: Select all

> temp = xcmsSet(file, lockMassFreq=TRUE)
20111213-001:
Error in if (length(by) && by == 0 && length(del) && del == 0) return(from) :
  missing value where TRUE/FALSE needed

> traceback()
11: seq.default(from = start, to = length(object@scanindex), by = freq)
10: seq(from = start, to = length(object@scanindex), by = freq)
9: makeacqNum(object, freqLock, start)
8: makeacqNum(object, freqLock, start)
7: AutoLockMass(lcraw)
6: AutoLockMass(lcraw)
5: do.call(type, list(object, lockMass))
4: .local(object, lockMass, ...)
3: stitch(lcraw, AutoLockMass(lcraw))
2: stitch(lcraw, AutoLockMass(lcraw))
1: xcmsSet(file, lockMassFreq = TRUE)

Any ideas?


edit: In the paper you write that length of each gap is a parameter and defaults to 2. I cannot see a way to set that parameter. In my case there is only 1 lockmass scan per gap.

[hpbenton]

Jan could you send the file to me so that I could have a look?
I've just committed some new code which hopefully should over come these issues. Some of the new file from the newer waters machines seem to be acting a little differently and I'm not sure why yet. Since the peer I took the variable scan length out since all files we had seen were the same length.

[cbroeckl]

I had the same problem, for what it is worth. And I have been collecting data files where the lockmass scan time does differ from the analytical scan time, so having that feature in there would still be valuable, in my opinion. Thanks for all the effort Paul.

[hpbenton]

@Jan, Thanks for the file. I've found the fix. I've not seen a file like this before. I tied it with both the netCDF and mzXML and the scan times are very different. Out of interest is this a newer machine?

@cbroeck - I'll try and add the varying lock mass scans length back into the code. I was under the impression from some engineers that only the frequency was changeable and not the actual number lock mass scans for calibration.

Paul