Parallelisation issue (?)

[lauzikaite]

Hi,

I am running optimizeXcmsSet() on LC-ToF-MS dataset - only on 5 pooled sample mzML files - and receive the following error after around ~10min, during which 5 independent R processes were successfully initiated:

starting new DoE with: min_peakwidth: c(1, 5) max_peakwidth: c(5, 10) ppm: 20 mzdiff: -0.001 snthresh: 10 noise: 600 prefilter: 3 value_of_prefilter: 100 mzCenterFun: wMean integrate: 2 fitgauss: FALSE verbose.columns: FALSE

Error in checkForRemoteErrors(val) : 3 nodes produced errors; first error: cannot open the connection

xcmsSet() on these files works perfectly fine. I am able to run xcmsSet() through both parallel (using PSOCK cluster) and BiocParallel packages (using BPPARAM).

The script for IPO optimisation:

ppparam <- getDefaultXcmsSetStartingParams('centWave')
ppparam$min_peakwidth <- c(1,5)
ppparam$max_peakwidth <-c(5,10)
ppparam$ppm <-20 
ppparam$noise <- 600 
ppparam$integrate <- 2
ppparam$mzdiff <- (-0.001)

opp <- optimizeXcmsSet(files = files, 
                      params = ppparam, 
                      BPPARAM = MulticoreParam(workers = 5),
                      subdir = output_dir)

> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.5

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] IPO_1.2.0           CAMERA_1.32.0       rsm_2.8             xcms_1.52.0         MSnbase_2.2.0       ProtGenerics_1.8.0 
 [7] mzR_2.10.0          Rcpp_0.12.11        BiocParallel_1.10.1 Biobase_2.36.2      BiocGenerics_0.22.0

loaded via a namespace (and not attached):
 [1] vsn_3.44.0             splines_3.4.0          foreach_1.4.3          Formula_1.2-1          affy_1.54.0           
 [6] stats4_3.4.0           latticeExtra_0.6-28    RBGL_1.52.0            impute_1.50.1          backports_1.1.0       
[11] lattice_0.20-35        limma_3.32.2           digest_0.6.12          RColorBrewer_1.1-2     checkmate_1.8.2       
[16] colorspace_1.3-2       sandwich_2.3-4         htmltools_0.3.6        preprocessCore_1.38.1  Matrix_1.2-10         
[21] plyr_1.8.4             MALDIquant_1.16.2      XML_3.98-1.9           zlibbioc_1.22.0        xtable_1.8-2          
[26] mvtnorm_1.0-6          scales_0.4.1           RANN_2.5.1             affyio_1.46.0          lsmeans_2.26-3        
[31] htmlTable_1.9          tibble_1.3.3           IRanges_2.10.2         ggplot2_2.2.1          TH.data_1.0-8         
[36] nnet_7.3-12            lazyeval_0.2.0         MassSpecWavelet_1.42.0 survival_2.41-3        magrittr_1.5          
[41] estimability_1.2       doParallel_1.0.10      nlme_3.1-131           MASS_7.3-47            foreign_0.8-68        
[46] graph_1.54.0           BiocInstaller_1.26.0   tools_3.4.0            data.table_1.10.4      multcomp_1.4-6        
[51] stringr_1.2.0          S4Vectors_0.14.3       munsell_0.4.3          cluster_2.0.6          pcaMethods_1.68.0     
[56] compiler_3.4.0         mzID_1.14.0            rlang_0.1.1            grid_3.4.0             iterators_1.0.8       
[61] htmlwidgets_0.8        igraph_1.0.1           base64enc_0.1-3        gtable_0.2.0           codetools_0.2-15      
[66] multtest_2.32.0        gridExtra_2.2.1        zoo_1.8-0              knitr_1.16             Hmisc_4.0-3           
[71] stringi_1.1.5          rpart_4.1-11           acepack_1.4.1          coda_0.19-1     

What could went wrong with optimizeXcmsSet()?

Thank you in advance for you help!

[rietho]

Hi!

It's very difficult to identify the source of your error from here. There error might result from a reading error. Anyway the error should not be related to IPO, as IPO itself does not accesses the files. This is done by xcms. So you can confirm, that all your files together work with xcmsSet() with and without parallelisation?

Maybe those two Stackoverflow-question give you some helpful hint?

• https://stackoverflow.com/questions/8218525/cannot-open-the-connection-hpc-in-r-with-snow
• https://stackoverflow.com/questions/24169387/cannot-open-the-connection-error-with-parlapply

Otherwise: Can you make your files available? Then I can offer to try to reproduce your error.

[lauzikaite]

Thanks for your reply!

Yes, all tested files work with xcmsSet() both with (through BPPARAM setting) and without parallelisation.

Regarding Stackoverflow suggestions, parallel::parSapply() with FUN= xcmsRaw() via PSOCK cluster works fine with these files. Which suggests that file reading is not the problem?

Sample mzML files are in dropbox here (too large to upload to github).

Is there anything else I could try?

[rietho]

Thank you for the files. I'll have a look as soon as possible.

[rietho]

Can you confirm, that optimizeXcmsSet works with BPPARAM = MulticoreParam(workers = 1)?

[rietho]

At the moment I assume that there is a problem with the combined use of IPO's nSlaves argument and xcms BPPARM argument. Above suggestion to set workers = 1 suppresses xcms parallelisation.

Can you additionally try setting nSlaves = 1 as in the following code (thus only using xcms parallelisation)?

opp <- optimizeXcmsSet(files = files, 
                      params = ppparam, 
                      BPPARAM = MulticoreParam(workers = 5),
                      nSlaves = 1,
                      subdir = output_dir)

[lauzikaite]

Thank you for the suggestions.

At the moment I can confirm that optimizeXcmsSet works with BPPARAM = MulticoreParam(workers = 1).

I will check whether setting nSlaves = 1, while retaining BPPARAM = MulticoreParam(workers = 5) works and will get back to you.

[lauzikaite]

I run few more tests of optimizeXcmsSetto check which nSlaves and workers settings don't work together: +, function was executed; -, function was halted.

What is the default setting for nSlaves? When nSlaves is not specified, the function behaves differently from nSlaves = 1, which I assumed is the default. Apologies for a naive question, but how it can be 0?

[rietho]

Thank you very much for your tests. The error seems to come from an interaction between the parallel-package and the BiocParallel-package. I'll check that and turn back to you also with answers to your questions.

[rietho]

Ok. It really seems that the problem arises from using the package parallel (so IPO nSlaves argument > 1) and BiocParallel (so BPPARAM argument with workers > 1) together. To answer one of your questions, the default value for nSlaves is 4. I cannot say why it was chosen that way, but I tend to keep it for compatibility reasons. So on using the BPPARAM-argument (without setting nSlaves) the parallelisation crashes.

I wonder why an nSlaves argument of NA works for you in any case, as IPO should crash. I'll add a warning message and fix to that. Regarding your questions: NA does not mean not specifying nSlaves. It's setting nSlaves to have the value NA. I'm not sure about your question regarding 0, as NA is different from 0. Anyway IPO treats all numeric values of nSlaves <= 1 the same, which is "do not use parallelisation". Some more argument checking would be nice, but there's no urgent reason. You can create an enhancement issue, if you would like me to remind it for the future.

I'll update IPO here and on Bioconductor the next days to close this issue. In the meantime the quick solution is: Either set nSlaves = 1 or use BPPARAM with workers = 1.

[lauzikaite]

Thank you for looking into this, I will use the simpler version of the function until package is updated.

[rietho]

ok, the check for nSlaves argument is adressed by dcaba57f5dcc5afe49b1dd8a1ef99b59374bc077 and the issue itself by 355c240954c7cce7f21f5cd52c38b3fa10119e7e

The changes are also pushed to Bioconductor release and development version. It might take some time to show up there.

@lauzikaite Thank you very much for your help