This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Jan Stanstrup
Without knowing what version of XCMS is running on XCMS online it is probably impossible to guess.
If you can get that info and are sure all settings are 100% identical then maybe @johannes.rainer have some idea what change there could be.
A quick suggestion:
I think mzdiff should be left at the negative default. Otherwise it does not allow overlapping peaks as far as I know.
Maybe peakwidth need to be lowered. Your peaks are less than 10 sec.
If that doesn't work you need to understand if the grouping is merging them. Look in peaks() of there are multiple peaks her sample.
Nevermind. Figured out that they are simply access database files.
Does anyone know if there is a way to parse/read the sequence files from Masslynx (SPL files)?
They appear to be in some binary format.
You are looking at tic in masslynx but BPI in mzMine.
The spectrum looks weird. Like it is the wrong spectrum. I think the scan numbers could be offset. I suggest doing EIC of for example 195 so you are sure which scans actually correspond.
You have 106,874 features. That is an insane number. About 10 times what I think is reasonable to get. CAMERA chokes trying to build a network between all these features. With 800 pseudo spectra after the first CAMERA step you have an average of ~ 1000 features in each group. Some group might be much larger.
You should focus on understanding why you get so many features. It looks like peak picking issues since each sample have a very high number of peaks. Check the sanity of your settings. On the top of my head these are the things that could lead to that:
1) too low ppm (split peaks)
2) too low allowed minimum peak width (spikes could get picked)
3) too low allowed maximum peak width (split peaks)
4) No prefilter or too liberal settings (picking noise)
5) noisy data in general
6) contaminants with persistent presence together with liberal settings
7) Continuum mode data instead of profile mode data (important!)
"Found isotopes: 34751" indicates that you have an insane number of peaks. How many peaks in your xset? That is probably why it is hanging.
XCMS needs centroided data. If this is Waters data you can centroid your data in masslynx and then convert. See here: http://www.metabolomics-forum.com/index.php?topic=1247.msg3673#msg3673
No it doesn't sound like IMS is to blame to me.
Ideas to check:
1) decent number of scans per peak?
2) the data is centroided?
3) peak picking settings makes sense?
To centroid a whole file or a set of files you use "Tools" --> "Accurate mass measure" --> "Automatic peak detection" from the main windows of masslynx.
The new set of files will have the files centroided (be sure that your originals are not already centroided) but you still need to check the accurate mass issue.
You can start by trying converting your centroided files with msconvert (to mzML since that is the newer format) without any special parameters. If that doesn't work try the lockmassRefiner filter.
Remember to use the scanEvent filter when you use msconvert. It is by far easiest for your down-stream work to have each scanEvent (function in Waters language) in separate files.
The way to check if things worked is to open the centroided raw file in masslynx and open a few ms spectra. Then you open the extract same spectrum in for example mzMine (the mzML file of course). Check a few masses. If they are exactly the same to at least 4 digits you are OK. If not you probably got uncalibrated data. Do this with a few scans just to be sure.
Regarding the cdf files. They should always be correct regarding the masses but you still need to centroid first.
I would say that 2.5 is almost certainly a bad idea... It needs to be true also for the edges of peaks to work well.
I used 20 for orbitrap data and I remember that setting it significantly lower gave problems.
How did you convert the files? Do they show something sensible in for example MzMine?
You might want to strip the IMS data. I have no experience with this but if you are converting with msconvert the scanEvent filter might be what you need.
With Waters files I have also had good luck simpy deleting the IMS data file (the masswolf converter I was using would crash otherwise)...
A short gradient should make no difference as long as there is still a sensible number of scans per peak.
You will need to know what is in each function/scanEvent to know what is best to do. Analyzing different functions together probably doesn't make much sense. One could be a low energy scan and the other a high energy scan, or MSE.
If you open the _extern.inf file inside the raw folder each function is described at the bottom.
For conversion with proteowizard you have two problems:
1) Centroiding (if your files actually were recorded in profile mode). For waters data msconvert cannot use the Waters centroiding algorithm. It uses its own which is inferior. You can get around it by centroiding the files in masslynx to create centroided raw files that can then be converted
2) Accurate mass. It used to be that msconvert were not able to use the lockmass information to calibrate the masses. So you got uncalibrated data. Now it appears that the solution depends on how the files were recorded and the version of masslynx... So yes a big mess. Options are:
a) Some files will need the lockmassRefiner filter in msconvert. From my short tests it appears that some newer versions of masslynx will do the conversion correctly without this now.
b) Some files now seem to have the correction baked in.
You will need to check the masses masslynx is showing and comparing to the converted file to understand if things were converted correctly.
Would be possible with some hacking, yes. The CDF writer in XCMS is not compatible with any other software though. If you can use one of the XML based formats it is more feasible.
I think what you'd need to do is do peakpicking, feature grouping and retcor. Then use the results from retcor to modify and xmcsRAW object with the corrected retention times.
You will only change the scan times this way though. You won't get any fancy peak warping.
You might want to take a look at MSnbase for handling the raw data. The development version of XCMS uses MSnbase-based handling of the raw data.
Are you talking about adducts and fragments? XCMS does not attempt to give you one feature per compound but one feature per ion.
CAMERA would be the standard tool to try to group ions originating from the same compound. There is however no consensus on how to statistically treat/merge those groups.