xcms
xcms copied to clipboard
sneumann
fillPeaks: MS1 and MS2 filling (Waters MSe data)
Hello all, I have previously been using waters databridge to convert MS / MSe data to two separate .cdf files. MS would be exported as myfile01.cdf, MSe (no precursor selection, high collision energy) as myfile02.cdf. I would process each with XCMS, passing through feature finding (centwave), grouping, retention time correction, and peak filling. I separated this later in ramclustR. I am trying to move to proteowizard for conversion, and have hit a stumbling block.
Process:
convert .RAW MS1 data to mzML (myfile_01.mzML)
convert .Raw MS2 data to mzML (myfile_02.mzML)
perform peak detection on MS1 (centwave)
perform peak detection on MS2 (centwave)
concatenate the two xset <- c(xset_MS1, xset_MS2)
retention time correct
group
So far so good. However, when I get to my fillPeaks.chrom step, I receive an error (correctly) stating that "No MS1 data found in file..." and it lists the _02.mzML files.
Is there a possibility of having the fillPeaks function use the MS level on a file by file basis rather than MS1 only? Other suggestions are welcomed too. I have considered no fillPeaks as on option, but I am throwing away a nice function in taking that approach and would rather not go that route if I do not have to. Many thanks Corey
One possibility could also be to not throw an error if there are no MS1 spectra but only a warning - I could implement that. But you're still using the old xcmsSet objects?
warnings seems like a perfectly acceptable option.
Re. old xcmsSet - guilty as charged in this area. I am using new for some workflows, but this isn't yet a large enough fire to require putting out ;-). We are working toward a full transition though - I promise!
Thanks!
I fixed it now for the new functions/objects. I also had a look at the old code base and it is not clear to me where the error is thrown so I was not able to fix it there - and might not find the time in the near future to do a deep dive into the old code...
Maybe this might be a good reason to switch to the new functions (let me know if you need help with that)? With that you could have the MS1 and MS2 within the same mzML file, peak detection can be done separately for MS1 and MS2 (or MSx), alignment will be performed on MS1 signal, but both MS1 and MS2 retention times will be adjusted...
Thanks you @jorainer. I will adapt the old code to new. I was trying to find the source of the error message yesterday too and it does seem pretty well hidden...
Corey
troubleshooting:
### XCMS feature detection
cwp <- CentWaveParam(peakwidth = peak.width,
ppm = ppm,
snthresh = 5,
mzdiff = ms.fwhm,
fitgauss = TRUE,
verboseColumns = TRUE)
xdata <- findChromPeaks(raw_data, param = cwp, msLevel = 1)
if(mse) {
xdata2 <- findChromPeaks(raw_data, param = cwp, msLevel = 2)
xdata <- c(xdata, xdata2)
rm(xdata2)
}
### XCMS feature grouping, pre-RT correction
pdp <- PeakDensityParam(sampleGroups = sample.groups,
minFraction = minfrac, bw = bw.pre)
xdata <- groupChromPeaks(xdata, param = pdp)
### XCMS retention time adjustment, peak density
pgp <- PeakGroupsParam(
minFraction = 0.5
)
xdata <- adjustRtime(xdata, param = pgp)
Error in do_adjustRtime_peakGroups(chromPeaks(object, msLevel = msLevel), :
The length of 'rtime' does not match with the total number of samples according to the 'peaks' matrix!
the adjustRtime function therefore seems to be thrown for a loop since I concatenated MS and MSe files at step 1. Any quick fix for this one? Thanks.
alternatively:
> xdata <- adjustRtime(xdata, param = pgp,
+ msLevel = c(1,2))
Error in .local(object, param, ...) :
Alignment is currently only supported for MS level 1
> package.version("xcms")
[1] "3.9.2"
First of all, please install devtools::install_github("sneumann/xcms", ref = "jomaster"). Could you try to first load all data into xdata (i.e. the MS1 and MS2 files) and then run the peak detection sequentially (findChromPeaks with msLevel = 1 and then with msLevel = 2). Could well be that this does not work out of the box but then we can fix it.
Questions:
- is there a way you could merge the MS1 and MS2 spectra/files into a single mzML file?
- could you eventually provide some (2 or 4) test files so that I could play around with it and we would be able to fix the issues faster.
Of course - https://drive.google.com/open?id=1OBW7XOXWb3r8K2cOyDDoIy7Ksee43vzX
There are four files present. Each is a different sample, converted from waters MSe .RAW to mzML using proteowizard. The data is centroided at acquisition. I have used PW to remove the lockmass function, so there are two functions present. The first is the MS level data, the second is MSe level data. Each mzML file contains both MS and MSe data.
The full function I have been using can be found here: https://github.com/cbroeckl/csu.pmf.tools/blob/master/R/pmf-xcms_new.R
It is basically just a wrapper around XCMS.
When I ran the code above, I did perform MS and MSe level peak picking sequentially from the same file, where 'files' is a vector of the four filenames I have posted:
raw_data <- readMSData(files = files,
pdata = new("NAnnotatedDataFrame", data.frame(sample.names)),
mode = "onDisk"
)
xdata <- findChromPeaks(raw_data, param = cwp, msLevel = 1)
xdata2 <- findChromPeaks(raw_data, param = cwp, msLevel = 2)
xdata <- c(xdata, xdata2)
The full XCMS section after peak grouping is tentatively:
sample.groups <- rep(1, length([email protected][[1]]@fileIndex))
if(mse) {
sample.groups <- c(sample.groups, rep(2, length([email protected][[2]]@fileIndex)))
}
### XCMS feature grouping, pre-RT correction
pdp <- PeakDensityParam(sampleGroups = sample.groups,
minFraction = minfrac, bw = bw.pre)
xdata <- groupChromPeaks(xdata, param = pdp)
### XCMS retention time adjustment, peak density
pgp <- PeakGroupsParam(
minFraction = max(0.5, minfrac)
)
xdata <- adjustRtime(xdata, param = pgp,
msLevel = c(1,2))
### XCMS feature grouping, pre-RT correction
pdp <- PeakDensityParam(sampleGroups = sample.groups,
minFraction = minfrac, bw = bw.post)
xdata <- groupChromPeaks(xdata, param = pdp)
### XCMS fillPeaks
fpp <- FillChromPeaksParam(expandMz = 0, expandRt = 0, ppm = 0)
xdata <- fillChromPeaks(xdata, param = fpp)
Thanks for the effort and time.
With the latest code from the jomaster branch (install with devtools::github_install("sneumann/xcms", ref = "jomaster")) I did the following:
library(xcms)
fls <- dir(pattern = "mzML$")
data <- readMSData(fls, mode = "onDisk")
table(msLevel(data))
1 2
10816 10812
Then we can do chromatographic peak detection on MS level 1, followed by MS level 2 (note the new parameter add = TRUE, new peaks will be added to the already identified ones). Note that the settings for centwave are most likely completely off for the present data set...
xdata <- findChromPeaks(data, param = cwp)
table(chromPeaks(xdata)[, "sample"])
## This required most recent xcms (jomaster branch)
xdata <- findChromPeaks(xdata, param = cwp, msLevel = 2L, add = TRUE)
table(chromPeakData(xdata)$ms_level)
1 2
934 877
We have thus about 1000 peaks in MS1 and about 900 in MS level 2. To get/extract only the MS1 peaks:
head(chromPeaks(xdata, msLevel = 1L))
mz mzmin mzmax rt rtmin rtmax into intb
CP001 118.0851 118.0841 118.0871 27.032 6.202 46.571 84084.220 83004.936
CP002 283.0503 283.0456 283.0539 49.142 43.143 54.712 6654.677 6644.394
CP003 179.0408 179.0376 179.0434 49.142 33.459 65.253 5882.650 5869.282
CP004 285.0474 285.0445 285.0508 49.142 43.572 58.140 10696.808 10686.525
CP005 336.0529 336.0446 336.0568 49.142 42.715 56.854 12563.851 12551.854
CP006 340.0472 340.0448 340.0508 49.142 33.887 54.712 22070.259 22058.296
maxo sn sample
CP001 16385.891 330 1
CP002 1228.000 756 1
CP003 1020.000 181 1
CP004 1762.000 768 1
CP005 2182.488 395 1
CP006 3480.000 1228 1
And for the MS2 peaks:
head(chromPeaks(xdata, msLevel = 2L))
mz mzmin mzmax rt rtmin rtmax into intb
CP0011 120.0793 120.0768 120.0822 38.815 14.992 56.640 4059.659 3968.052
CP0021 177.0439 177.0408 177.0464 48.928 35.815 55.783 11551.160 11539.179
CP0031 179.0408 179.0387 179.0441 49.784 44.214 74.037 12384.502 12372.660
CP0041 146.0609 146.0580 146.0642 58.782 43.786 77.036 6493.301 6403.540
CP0051 118.0640 118.0623 118.0660 60.068 52.355 80.035 6450.335 6427.149
CP0061 114.0898 114.0875 114.0921 107.973 100.002 117.827 4422.056 4408.242
maxo sn sample
CP0011 659.0000 25 1
CP0021 1853.0000 1289 1
CP0031 2166.0000 1241 1
CP0041 870.0000 38 1
CP0051 900.0000 122 1
CP0061 713.4751 223 1
Performing the alignment. Note that alignment is by default performed on MS1 peaks, but that both, MS2 spectra as well as MS2 chromatographic peaks are adjusted too. Also be aware that peak grouping (aka correspondence) supports currently only to group MS1 chromatographic peaks - and that again the settings are not tuned for the present data set.
pdp <- PeakDensityParam(sampleGroups = rep(1, length(fileNames(xdata))),
minFraction = 0.8, bw = 2)
xdata <- groupChromPeaks(xdata, param = pdp)
pgp <- PeakGroupsParam(minFraction = 0.8)
xdata <- adjustRtime(xdata, param = pgp)
xdata <- groupChromPeaks(xdata, param = pdp)
I don't know what exactly you want to do next - but we'll figure out a solution for that.
Thank you! I will try this ASAP. Re. what to do next, nothing in XCMS, I hope. At this point we have an XCMS object that is used as input for ramclustR. I can parse the peak table there.
EDIT: I do have one additional request. The only function I use from XCMS in ramclustR is the groupval (old xcms) or featureValues (new xcms) matrix extraction function. When I run:
xcms::featureValues(xcmsObj, value = "into")
on the xcms object containing both MS1 and MS2 level peak picking, only the MS1 level data is returned. Can you add an msLevel option to the featureValues() function to enable retreival of the MS2 peak areas? The expectation I have is that this dataset would have the exact same features and dimensions as the MS1 dataset from the same function. Alternatively, can you just return all peak picked and aligned data by default (MS1 and MS2, when available)?
@jorainer :
Follow up question: I noticed that sampleGroups argument in the PeakDensityParam() function requires a vector the same length of the number of files (4, in my test set), not one the length of the number of files*MSlevels ( 4 * 2 = 8). Can you clarify how the minFraction value is applied in this case? for this case, I am treating all four files as if they are in the same sample class, but lets say I have 20 samples comprised of a treatment group and a control group with 10 replicates each. If i set minFraction = 0.55, this dictates that I need a feature to be detected in 6 of 10 in either the treatment or control (or both). If I now have MS2 (MSe, MSall, AIF...) data present, do I need a feature to be in 12 of 20 (control MS1 + control MS2, or treatment MS1 + treatment MS2), or is 6 of 10 in the control MS2 data sufficient?
There was an error reported in the console output that did not prevent the function from running/completing: "Error in (function (x) : attempt to apply non-function".
I also want to say that I have run through the XCMS process and it has finished succesfully. Thanks again for the effort and time! It is an amazing job you are doing with XCMS.
Re featureValues: so far, correspondence analysis (groupChromPeaks) can only be performed on MS1 data, which means that only MS1 peaks get grouped and you will only have MS1 features defined. I would have to implement this functionality - I wasn't aware that it might make sense to group MS2 chrom peaks?
Re sampleGroups: yes, this variable has to have the same length than you have files hence assuming you have one sample per file. As detailed before, groupChromPeaks will only work on MS1 level data and it a a length equal to the number of files is thus required. The minFraction is always the proportion of samples of the same sample group. If you have a sampleGroup = c("A", "A", "B", "B") and you specify minFraction = 0.5 a feature is defined if a peak is present either in 50% of samples from group "A" or 50% of samples from group "B". Also here, if you need a correspondence analysis that groups MS2 peaks I would have to implement that, and I would also want to run the correspondence on MS2 separately from the one on MS1 (e.g. because you might want to use different settings ...).
Re Error in (function(x): ...: no worries. This is an error that I somehow can not get rid off. In fact it is not an error, since the call completes and is not stopped. It must have to do with the garbage collection of R and the finalization of variables/objects.
Thanks for the detailed response. I guess I failed to clearly present the workflow I have been using for the past several years in the old format. As I had implemented this, each cdf file contained either MS1 or MS2 data. if I had 20 samples, I had 40 files. I told XCMS to treat each file as if it were a separate sample, so all processing steps were performed on both MS1 and MS2. The aggregate xcmsSet at the end of the workflow contained a data frame of 40 files by 5000 (for example) features. I then split this dataframe into MS1 and MS2 data, which generated mapped features between MS1 and MS2, and each data frame had the same dimensions. There are features that are (1) present at MS1 level only, (2) present at MS2 level only and (3) a pretty high frequency of features that are present in both low and high collision energy. This latter group represents in-source fragments in the MS1 data that are also in MS2 data, incompletely fragmented molecular ion remaining in the MS2 data, and sodiated or potassiated adducts which often fragment poorly and are therefore often at similar intensity in both low and high CE. As such, the approach I described worked fairly well.
As I see it now, I see a few paths forward.
- If you are willing to implement correspondence and peak filling in the MS2 data in XCMS, I can retain my full workflow.
- I try to play some tricks on XCMS to get it to do what I want it to. This would probably entail replacing the msLevel values from MS2 data, from '2' to '1' to avoid triggering the errors and aligning the full set as the old approach had done
- run parallel XCMS processing workflows on MS1 and MS2 data, generating two xcms objects and aligning by sample name post-hoc (in ramclustR). To make this work with my existing code/algorithm would require coercing these into a structure where all the features are mapped across the two data frames - the whole approach built above is coded around the MS1 and MS2 datasets that have been fully aligned.
- change the ramclustR algorithm entirely to assign MS2 detected chromPeaks to MS1 level compounds or features.
Your perspective on (1) will help me to figure out my path forward. Thanks again.
I have implemented a functional 'trick XCMS' method, in reference on option 2 above.
- export MS1 data and MSe (MSMS) data as two separate files
- the list of samples is the list of files for each level, concatenated (i.e file1_ms1.mzML, file2_ms1.mzml... file1_ms2.mzml, file2_ms2.mzml...)
- there must be a unique file name string that can identify the two for later processing in ramclustR
I set up a raw_data format first, store the orignal msLevel values, run peak detection in XCMS so that it assumes each file is in fact a new sample, set up sample groups to reflect MSlevel, proceed through correspondance, retention time adjustment, and fillPeaks, then replace the fake MSlevel values with the originals.
This brings me back the the approach I had been using previously, but in the new XCMS MSnbase format. I don't know if it is ideal, and I will likely run into a road block at some point, but it does provide an alternative to extensive XCMS edits. I can try to put together a short tutorial on this to make it more clear, but a code chunk looks like this:
mcpar <- SnowParam(workers = 4, type = "SOCK")
raw_data <- readMSData(files = files,
pdata = new("NAnnotatedDataFrame", data.frame(sample.names)),
mode = "onDisk"
)
orig.msLevel <- raw_data@featureData@data$msLevel
raw_data@featureData@data$msLevel <- rep(1, length(orig.msLevel))
cwp <- CentWaveParam(peakwidth = peak.width,
ppm = ppm,
snthresh = 5,
mzdiff = ms.fwhm,
fitgauss = TRUE,
verboseColumns = TRUE)
xdata <- findChromPeaks(raw_data, param = cwp, msLevel = 1, BPPARAM = mcpar)
sample.groups <- c(
rep(1, length([email protected][[1]]@fileIndex)/2),
rep(2, length([email protected][[1]]@fileIndex)/2)
)
pdp <- PeakDensityParam(sampleGroups = sample.groups,
minFraction = minfrac, bw = bw.pre)
xdata <- groupChromPeaks(xdata, param = pdp)
pgp <- PeakGroupsParam(
minFraction = max(0.5, minfrac)
)
xdata <- adjustRtime(xdata, param = pgp)
pdp <- PeakDensityParam(sampleGroups = sample.groups,
minFraction = minfrac, bw = bw.post)
xdata <- groupChromPeaks(xdata, param = pdp)
fpp <- FillChromPeaksParam(expandMz = 0, expandRt = 0, ppm = 0)
xdata <- fillChromPeaks(xdata, param = fpp, BPPARAM = mcpar)
raw_data@featureData@data$msLevel <- orig.msLevel
I'm following this thread closely - I want to process MSe data for MS-FINDER and GNPS
@sgalanie, The script above generates an XCMS object that can be used as input to ramclustR. After clustering ions (MS and MSe), you can run the do.findmain() function in ramclustR, which exports spectra suitable for MSFinder. I would be happy to discuss further if need be (cbroeckl at colostate.edu).
Thanks for the update @cbroeckl . In addition to your workaround I will implement option 1) - I think that would be the cleanest solution, also because all the data is within one single object and aligned the same way.
Thanks! I agree that your way is much better, but I didn't want to assign tasks, and now we have an workaround in the interim.
Problem is we can not add yet another vignette to xcms because the build time is already very long - also, we would need the mzML files - which I guess will be pretty large.
Suggestion: what about a workflow, similar to the xcms-preprocessing.Rmd in https://github.com/jorainer/metabolomics2018/ ? Maybe it would then also make sense to put it under the umbrella of RforMassSpectrometry?
After some discussions I think it might be better if, instead of a common repository with workshops, we have a central index side listing all. Then each workshop is under the responsability of the author.
@cbroeckl , I have now implemented everything you need for option 1) (I hope) in the jomaster branch:
- You can work with the full data now (no need to split MS1 / MS2 into separate files).
findChromPeaks(...)to perform chromatographic peak detection on MS1.findChromPeaks(..., msLevel = 2L, add = TRUE)to perform chromatographic peak detection on MS level 2 and add these to the already detected peaks in MS1.- Optional
refineChromPeaks(..., msLevel = 1L)andrefineChromPeaks(..., msLevel = 2L)to perform peak post-processing on MS1 and MS2 chrom peaks. - alignment of the data as before (e.g.
groupChromPeaksfollowed byadjutRtime) - this will be performed on MS1 data, but MS2 spectra get aligned together with MS1. - Correspondence of MS1 chrom peaks with
groupChromPeaks(...) - Correspondence of MS2 chrom peaks with
groupChromPeaks(..., add = TRUE, msLevel = 2L)to add these features to the already defined MS1 peaks. - You can then use
featureDefinitions(...)andfeatureValues(...)to extract features for all MS level, or with additional parametermsLevelto specify from which MS level you want to get them (e.g.featureValues(..., msLevel = 2L)to just get values for MS2 features). Note that functionchromPeaksalso has now amsLevelparameter to extract chromatographic peaks from a specific MS level. - Peak filling also supports
msLevel: to fill in peaks for MS level 1 features (the default):fillChromPeaks(...)and to fill in peaks for MS2 features:fillChromPeaks(..., msLevel = 2L). Filled-in peaks are always added to the existingchromPeaksmatrix.
I think all tools are now in place for you to run your analysis - let me know if you run into problems.
To install this new code use: devtools::install_github("sneumann/xcms", ref = "jomaster").
@jorainer - THANKS! I will give this a try soon, though will be doing some traveling so it may not not be as soon as I would like. I really appreciate your flexibility and time. I will try to put some sort of tutorial together on this subject, and we can figure out the best place for it.
@stanstrup - do you think that the R for Metabolomics project that you have been working on might be a good place to collect these sorts of things?
@jorainer
issues in installing xcms from your branch - apparently an mzR/Rcpp incompatibility issue. This is a fresh R install. I installed xcms from BioC, with all dependencies and package updates, then tried to install from your github branch on top:
> devtools::install_github("sneumann/xcms",
+ ref = "jomaster",
+ dependencies = FALSE,
+ upgrade = "never")
Downloading GitHub repo sneumann/xcms@jomaster
√ checking for file 'C:\Users\cbroe\AppData\Local\Temp\RtmpWW0R1E\remotes179848a7ceb\sneumann-xcms-d2e0ce4/DESCRIPTION' (346ms)
- preparing 'xcms': (1.4s)
√ checking DESCRIPTION meta-information ...
- cleaning src
- checking for LF line-endings in source and make files and shell scripts (1.4s)
- checking for empty or unneeded directories
- building 'xcms_3.9.3.tar.gz'
Installing package into ‘C:/Users/cbroe/Documents/R/win-library/3.6’
(as ‘lib’ is unspecified)
* installing *source* package 'xcms' ...
** using staged installation
** libs
*** arch - i386
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/xcms_massifquant.cpp -o massifquant/xcms_massifquant.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/TrMgr.cpp -o massifquant/TrMgr.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/Tracker.cpp -o massifquant/Tracker.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/SegProc.cpp -o massifquant/SegProc.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/DataKeeper.cpp -o massifquant/DataKeeper.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/OpOverload.cpp -o massifquant/OpOverload.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/mat.cpp -o obiwarp/mat.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/vec.cpp -o obiwarp/vec.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/xcms_dynprog.cpp -o obiwarp/xcms_dynprog.o
obiwarp/xcms_dynprog.cpp: In member function 'void DynProg::find_path(VEC::MatF&, VEC::VecF&, int, float, float, int, float)':
obiwarp/xcms_dynprog.cpp:1113:9: warning: variable 'bestscore' set but not used [-Wunused-but-set-variable]
float bestscore;
^
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/xcms_lmat.cpp -o obiwarp/xcms_lmat.o
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c xcms_obiwarp.cpp -o xcms_obiwarp.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c fastMatch.c -o fastMatch.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c mzClust_hclust.c -o mzClust_hclust.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c mzROI.c -o mzROI.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c util.c -o util.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c xcms.c -o xcms.o
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -fno-inline -c binners.c -o binners.o
binners.c: In function '_breaks_on_binSize':
binners.c:357:7: warning: unused variable 'idx' [-Wunused-variable]
int idx = 0;
^
C:/Rtools/mingw_32/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o xcms.dll tmp.def massifquant/xcms_massifquant.o massifquant/TrMgr.o massifquant/Tracker.o massifquant/SegProc.o massifquant/DataKeeper.o massifquant/OpOverload.o obiwarp/mat.o obiwarp/vec.o obiwarp/xcms_dynprog.o obiwarp/xcms_lmat.o xcms_obiwarp.o fastMatch.o mzClust_hclust.o mzROI.o util.o xcms.o binners.o -LC:/PROGRA~1/R/R-36~1.3/bin/i386 -lR
installing to C:/Users/cbroe/Documents/R/win-library/3.6/00LOCK-xcms/00new/xcms/libs/i386
*** arch - x64
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/xcms_massifquant.cpp -o massifquant/xcms_massifquant.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/TrMgr.cpp -o massifquant/TrMgr.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/Tracker.cpp -o massifquant/Tracker.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/SegProc.cpp -o massifquant/SegProc.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/DataKeeper.cpp -o massifquant/DataKeeper.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c massifquant/OpOverload.cpp -o massifquant/OpOverload.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/mat.cpp -o obiwarp/mat.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/vec.cpp -o obiwarp/vec.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/xcms_dynprog.cpp -o obiwarp/xcms_dynprog.o
obiwarp/xcms_dynprog.cpp: In member function 'void DynProg::find_path(VEC::MatF&, VEC::VecF&, int, float, float, int, float)':
obiwarp/xcms_dynprog.cpp:1113:9: warning: variable 'bestscore' set but not used [-Wunused-but-set-variable]
float bestscore;
^
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c obiwarp/xcms_lmat.cpp -o obiwarp/xcms_lmat.o
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -mtune=core2 -c xcms_obiwarp.cpp -o xcms_obiwarp.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c fastMatch.c -o fastMatch.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c mzClust_hclust.c -o mzClust_hclust.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c mzROI.c -o mzROI.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c util.c -o util.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c xcms.c -o xcms.o
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-36~1.3/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=core2 -fno-inline -c binners.c -o binners.o
binners.c: In function '_breaks_on_binSize':
binners.c:357:7: warning: unused variable 'idx' [-Wunused-variable]
int idx = 0;
^
C:/Rtools/mingw_64/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o xcms.dll tmp.def massifquant/xcms_massifquant.o massifquant/TrMgr.o massifquant/Tracker.o massifquant/SegProc.o massifquant/DataKeeper.o massifquant/OpOverload.o obiwarp/mat.o obiwarp/vec.o obiwarp/xcms_dynprog.o obiwarp/xcms_lmat.o xcms_obiwarp.o fastMatch.o mzClust_hclust.o mzROI.o util.o xcms.o binners.o -LC:/PROGRA~1/R/R-36~1.3/bin/x64 -lR
installing to C:/Users/cbroe/Documents/R/win-library/3.6/00LOCK-xcms/00new/xcms/libs/x64
** R
** inst
** byte-compile and prepare package for lazy loading
Error: package or namespace load failed for 'mzR':
.onLoad failed in loadNamespace() for 'mzR', details:
call: fun(libname, pkgname)
error: (converted from warning) mzR has been built against a different Rcpp version (1.0.2)
than is installed on your system (1.0.3). This might lead to errors
when loading mzR. If you encounter such issues, please send a report,
including the output of sessionInfo() to the Bioc support forum at
https://support.bioconductor.org/. For details see also
https://github.com/sneumann/mzR/wiki/mzR-Rcpp-compiler-linker-issue.
Error: package 'mzR' could not be loaded
Execution halted
ERROR: lazy loading failed for package 'xcms'
* removing 'C:/Users/cbroe/Documents/R/win-library/3.6/xcms'
* restoring previous 'C:/Users/cbroe/Documents/R/win-library/3.6/xcms'
Error: Failed to install 'xcms' from GitHub:
(converted from warning) installation of package ‘C:/Users/cbroe/AppData/Local/Temp/RtmpWW0R1E/file179834b95832/xcms_3.9.3.tar.gz’ had non-zero exit status
> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] Rcpp_1.0.3 rstudioapi_0.11 magrittr_1.5 usethis_1.5.1
[5] devtools_2.2.2 pkgload_1.0.2 R6_2.4.1 rlang_0.4.5
[9] fansi_0.4.1 tools_3.6.3 pkgbuild_1.0.6 sessioninfo_1.1.1
[13] cli_2.0.2 withr_2.1.2 ellipsis_0.3.0 remotes_2.1.1
[17] assertthat_0.2.1 digest_0.6.25 rprojroot_1.3-2 crayon_1.3.4
[21] processx_3.4.2 BiocManager_1.30.10 callr_3.4.2 fs_1.3.2
[25] ps_1.3.2 curl_4.3 testthat_2.3.2 memoise_1.1.0
[29] glue_1.3.2 compiler_3.6.3 desc_1.2.0 backports_1.1.5
[33] prettyunits_1.1.1
Any tips on making this easy? I fought through it once before, but thought i would ask for guidance before i started the battle again. thanks.
Had the same issue with people from my lab running Windows. This should do the trick:
Sys.setenv(R_REMOTES_NO_ERRORS_FROM_WARNINGS="true")
devtools::install_github("sneumann/xcms", ref = "xcms")
Thanks - changing the settings worked, though i had to change back to ref = "jomaster"
Downloading GitHub repo sneumann/xcms@xcms
Error in utils::download.file(url, path, method = method, quiet = quiet, :
cannot open URL 'https://api.github.com/repos/sneumann/xcms/tarball/xcms'
Ah, yes, sorry, my fault ref = "jomaster" is correct. I misspelled it in the original message.