excellent suggestion! The parameters are however already vectorized. peakCol, peakBg and peakPch can be either of length 1 or length equal to the number of peaks the XChromatogram/XChromatograms object has peaks (i.e. nrow(chromPeaks(x)) with x being a XChromatogram or an XChromatograms object). You can then define the color for each individual peak (the order of the colors passed along has to match the order of the peaks returned by chromPeaks.
Thanks for the feedback - indeed we might have to check the code again. I've never centroided MS2 data so far.
The good news is that we've added the msLevel parameter to the pickPeaks method. This means you could call pickPeaks on your object with msLevel. = 1L to perform the centroiding only on MS 1 and keep the MS2 spectra as they are.
To use the new functionality you would however have to switch to the current Bioconductor developmental version:
so far there is no possibility to do the peak picking (centroiding) separately for each MS level (or to do that specifically on a single MS level). I've added an issue in MSnbase (https://github.com/lgatto/MSnbase/issues/478) and will work on that.
Meanwhile, could you please check if you can do the peak picking at all in MS2 (i.e. read only MS2 data, or use filterMsLevel to restrict the data to MS level 2 only and call pickPeaks on that data)?
I'm no expert in MS2 data analysis but I'd say that also MS2 data should be centroided. Note also that if you do the centroiding with the pickPeaks function from MSnbase you will by default centroid MS1 and MS2 spectra in your object.
the *peak density* alignment method requires a certain number of features (AKA grouped peaks) across all samples to perform the alignment. Without knowing more about your data it is pretty hard to tell what the problem is. I'd suggest you redo the correspondence analysis (peak grouping) with less stringent settings and retry.
Secondly: I would suggest that you switch over to the *new* user interface and functions (see https://bioconductor.org/packages/release/bioc/vignettes/xcms/inst/doc/xcms.html for details). There you will e.g. also have the possibility to do the alignment on a subset of samples (e.g. if you have QC samples) or to exclude blank samples from the alignment (these in fact could cause the problem described above).
## Subset to one file, assuming xdata is an XCMSnExp with identified chrom peaks xdata_1 <- filterFile(xdata, 1) chrs <- chromatogram(xdata_1, rt = chromPeaks(xdata_1)[, c("rtmin", "rtmax")], mz = chromPeaks(xdata_1)[, c("mzmin", "mzmax")]) head(lengths(chrs)) ## median number of scans for all peaks in a the file median(lengths(chrs))
Note: this should be done separately for each file, hence the filterFile step.
AFAIK xcmsOnline uses an old version of xcms (that's what you see in the logs) - and most likely also an old version of R. The development of xcms and xcmsOnline somehow diverged at some point and all the new developments in xcms (aka xcms3) are not used/available in the online version.
For a thourough comparison one would however have to start with an standalone R xcms version 1.47.3 and compare its results to those of xcmsOnline. Could be that xcmsOnline has some internal helper functions and modifications that are not available in the standalone R version of xcms ... but I am only guessing here.
I would be careful with the scmin/scmax lmin/lmax columns - I do not recall what they exactly mean. We do by default not record from which spectrum the data of a chromatographic peak comes, but with the retention time and m/z range available it is easy to subset/extract all spectra for one chromatographic peak.
What exactly do you want/need to do with the data? Maybe there is a simple solution for that...
I'm also not familiar with SRM/MRM data. But we have implemented a readSRMData function in MSnbase to read chromatographic data from mzML files. Would be nice to know if that works for you and what is missing. Note also that xcms can do now peak detection also on purely chromatographic data (i.e. Chromatogram/Chromatograms classes which are returned by the readSRMData function).
Thanks for sharing your ideas. If you would like some changes in xcms I would however appreciate if you open an issue at the xcms github repository as this enables me also to keep track of what to do (and what was done) - a pull request would actually be even better
Regarding the code in xcms centWave - I did not write that code and I am veeerrry hesitant to change anything within it as this will affect all xcms users.
Regarding your concern, the fillChromPeaks will always use the adjusted retention times if retention time adjustment has been performed. So, the results should be the same, with or without applyAdjustedRtime.
Regarding the error: I fixed that. You can install the updated version from github:
Excellent summary @CoreyG ! In the end the 78 cores don't help unless you have enough memory to fit the full data from 78 mzML files at once into memory. Peak detection and filling in missing peak data both need to load the full data of a file (all spectra). You could load one of your mzML files into memory and then calculate the size of that using the object_size function from the pryr package:
You could thus estimate how many processes you could run in parallel. On top of that you will however also need some more memory to fit the chromPeaks matrix and later the featureDefinitions data frame and R will need some more space to copy stuff in the background.
This looks like a nasty bug in xcms. I will have a look into it, as you should not get this error when doing fillChromPeaks. Also, applyAdjustedRtime is a valid approach. But this should not affect fillChromPeaks.