1
Messages
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 - edmandsw
2
XCMS / Re: sequential addition of files to an xcms object
See the help file
Code: [Select]
?retcor.obiwarpSo the retention time deviation for each file has to be re-calculated.
#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
Additionally for grouping the minfrac and minsamp arguments will be affected by additional samples in each group as you concatenate.
Code: [Select]
?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.
3
XCMS / Re: No console messages xcmsSet (xcms v1.50.1)
4
XCMS / No console messages xcmsSet (xcms v1.50.1)
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:
Code: [Select]
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?
Code: [Select]
cdffiles <- list.files(cdfpath, recursive = TRUE)Although this didn't work as expected either.
progress <- function(n) cat(paste0(n, ' of ', length(cdffiles),
' complete (', basename(cdffiles)[n],
').\n'))
peakmatrix <- xcmsSet(BPPARAM = snowparam, progressCallback = progress)
Many thanks in advance,
Will
Code: [Select]
>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
[attachment deleted by admin]