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
XCMS is transitioning to a new interface (new functions with different arguments, but that basically does the same) where centerSample is an argument to ObiwarpParam. That it doesn't work with center=NULL but does when you don't specify might be a bug; it should work I think.
I think the reason you don't get a plot is because you have specified plottype = c("none","deviation"). You should only use one of the two. Otherwise the first option is used i.e. none.
Yes, default values are used if you don't specify explicitly.
There are several possible errors in your code.
The double forward slash might be causing trouble if you are sure the path is otherwise correct. Try this (I think this might be a non-issue though):
path <- "G:/mzxml/np/neg"
"system.file" is meant to find files included with some package. Since you are using your own files you should be using "list.files" instead. Also keep in mind that the pattern is case sensitive.
If you write "files" (without quotes) in the console you should see the list of your files.
Variables are kept in memory. They are not written to files. Anything you want written to a file you need to do it explicitly.
An external drive should not be a problem, no.
Btw.: Best practice is to create a project in Rstudio and have a dedicated folder for each project. You then keep your scripts (and smaller support files if you have any) here.
In XCMS in R you cannot use vendor formats.
I would however be careful with waters files. Whether or not the lockmass correction is applied seems to depends on the version of masslynx and the msconvert version... So since it is unknown how XCMS online converts I would make sure my files are OK converted to mzML and upload that.
I suggest you try splitting to two files when you do the conversion of your raw data. You should be able to do that with the polarity filter in msconvert.
Proteowizard cannot do that.
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.
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() if there are multiple peaks per sample.
They appear to be in some binary format.
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 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!)