Metabolomics Society Forum

Thanks edmandsw,

I currently am using a custom script for feature grouping which simply assumes that if retention times overlap and mass windows (plus a given ppm error) overlap, the represent the same compound.  After each iteration, I apply a retention time adjustment  as well.  The tried-and-true XCMS functions are just much more well used and validated than my internal tools, so I was hoping there would be a way to utilize them that I had missed.   I will look at the package you are developing - it does look interesting! Are you aware of the skyline/panorama tool sets?  I know they are also working on vendor neutral QC monitoring.  Interested to see how yours compares.  

Corey

As far as I'm aware this isn't possible. The retention time correction using the obiwarp method for example has to be reassessed with a new centre sample.
See the help file

?retcor.obiwarp
#center	
#the index of the sample all others will be aligned to. If center==NULL, the sample with the most peaks is chosen as default

So the retention time deviation for each file has to be re-calculated.
Additionally for grouping the minfrac and minsamp arguments will be affected by additional samples in each group as you concatenate.

?group.density
#minfrac	
#minimum fraction of samples necessary in at least one of the sample groups for it to be a valid group
#minsamp	
#minimum number of samples necessary in at least one of the sample groups for it to be a valid group

It shouldn't be (computationally speaking) too much of a big deal to re-do the retention time correction and grouping each time you peak-pick an additional file(s). The most time-consuming part is definitely the xcmsSet function.

Got now an explanation from Martin Morgan (https://support.bioconductor.org/p/96856/). Basically, you could use the progressbar, but you have to increase the number of tasks, so that the progress bar will be updated more frequently. Note however that a) the number of tasks should not be larger than the number of files you're processing and b) there might be a performance decrease with too many tasks.
So, in your case you could:

library(faahKO)
library(xcms)
library(BiocParallel)
library(snow)

## The directory with the NetCDF LC/MS files
cdfpath <- file.path(find.package("faahKO"), "cdf")

setwd(cdfpath)

## Register the parallel processing setting - will be used by default by all xcms methods
## Set tasks to a reasonable number
register(SnowParam(tasks = 10, progressbar = TRUE))

peakmatrix <- xcmsSet()

Now, for your 400 file experiment you might want to increase the number of tasks to get more frequent callbacks and updates of the progress bar.

Hope this helps.

cheers, jo

Hi,

It is probably something minor/trivial but since updating to xcms3 (v1.50.1) (and the deprecation of the nSlaves argument change to BPPARAM of BiocParallel) I am no longer receiving lovely reassuring progress messages printed to the R console. The strange thing is in previous versions of xcms the progress messages would appear soon after initiation of the xcmsSet function regardless of the number of mzXML files in the directory.
I have tried the progressBar argument of the SnowParam function but it was stuck at 0% for over an hour.
With the ~200 mzXML files I am currently peak-picking I did not receive any console message for over two hours:
metabForum_20170608.PNG
Then all of a sudden there were messages previously typical of a single-threaded process:
metabForum_20170608_2.PNG
However I was able to check the multi-threaded process was running by monitoring the CPU usage.

When the dataset size is small as is the case for faahKO, the progress messages appear much sooner. Here is a reproducible but perhaps not very useful example:

library(faahKO)
library(xcms)
library(BiocParallel)
library(snow)

## The directory with the NetCDF LC/MS files
cdfpath <- file.path(find.package("faahKO"), "cdf")

setwd(cdfpath)

snowparam <- SnowParam(workers = parallel::detectCores(), type = "SOCK")

peakmatrix <- xcmsSet(BPPARAM = snowparam)

Is is necessary to DIY/Jerry-rig your own progressCallBack function now?

cdffiles <- list.files(cdfpath, recursive = TRUE)
progress <- function(n) cat(paste0(n, ' of ', length(cdffiles),
                                   ' complete (', basename(cdffiles)[n],
                                   ').\n'))
peakmatrix <- xcmsSet(BPPARAM = snowparam, progressCallback = progress)

Although this didn't work as expected either.

Many thanks in advance,

Will

>sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

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] parallel  stats    graphics  grDevices utils    datasets  methods  base    

other attached packages:
[1] snow_0.4-2          BiocParallel_1.8.1  faahKO_1.14.0      xcms_1.50.1        Biobase_2.34.0    
[6] ProtGenerics_1.6.0  BiocGenerics_0.20.0 mzR_2.8.1          Rcpp_0.12.10      

loaded via a namespace (and not attached):
[1] RANN_2.5              lattice_0.20-34        codetools_0.2-15      MASS_7.3-45          
[5] MassSpecWavelet_1.40.0 grid_3.3.2            plyr_1.8.4            stats4_3.3.2          
[9] S4Vectors_0.12.1      Matrix_1.2-8          splines_3.3.2          RColorBrewer_1.1-2    
[13] tools_3.3.2            survival_2.40-1        multtest_2.30.0      

I have done filtering for peak width: 

    orig<-xset@peaks
    good<-which((orig[,"rtmax"]-orig[,"rtmin"])<(3*maxpw))
    filt<-orig[good,]
    xset@peaks<-filt

No reason it could not be adapted for shape descriptors.  It has to be done before grouping.
Corey