Question

Error in GSVA: Error in dimnames(x) <- dn

0

Entering edit mode

ElaM • 0

@elam-24316

Last seen 4.2 years ago

Hi, I want to apply GSVA on my RNAseq data, data are normalized with deseq2 (median of ratios normalization) and low count filtered. The geneset is downloaded from Msigdb (All genesets). I get the following error and I don't know what is the problem.

gsva_path <- gsva(Xdata,genesets,method= "gsva",min.sz=10, max.sz=500, verbose=TRUE) Estimating GSVA scores for 23978 gene sets. Computing observed enrichment scores Estimating ECDFs with Gaussian kernels Using parallel with 40 cores |======================================================================| 100% Error in dimnames(x) <- dn : length of 'dimnames' [1] not equal to array extent

I appreciate any suggestions for solving the problem.

software error • 1.9k views

ADD COMMENT • link 4.2 years ago ElaM • 0

0

Entering edit mode

hi, could you show us the output of the calls to:

BiocManager::version()
sessionInfo()

ADD REPLY • link 4.2 years ago Robert Castelo ★ 3.4k

0

Entering edit mode

BiocManager::version() [1] ‘3.8’ sessionInfo() R version 3.5.2 (2018-12-20) Platform: x86_64-pc-linux-gnu (64-bit) Running under: CentOS Linux 7 (Core)

Matrix products: default BLAS/LAPACK: /bmt-data/genomics/apps/intelmkl2019.1.114/compilersandlibraries2019.1.144/linux/mkl/lib/intel64lin/libmklgflp64.so

locale: [1] LCCTYPE=enUS.UTF-8 LCNUMERIC=C
[3] LCTIME=fiFI.UTF-8 LCCOLLATE=enUS.UTF-8
[5] LCMONETARY=fiFI.UTF-8 LCMESSAGES=enUS.UTF-8
[7] LCPAPER=fiFI.UTF-8 LCNAME=C
[9] LCADDRESS=C LCTELEPHONE=C
[11] LCMEASUREMENT=fiFI.UTF-8 LC_IDENTIFICATION=C

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

other attached packages: [1] GSVA1.30.0 annotate1.60.1 XML3.99-0.3
[4] org.Hs.eg.db3.7.0 AnnotationDbi1.44.0 IRanges2.16.0
[7] S4Vectors0.20.1 Biobase2.42.0 BiocGenerics_0.28.0

loaded via a namespace (and not attached): [1] Rcpp1.0.3 BiocManager1.30.10 compiler3.5.2
[4] later1.1.0.1 RColorBrewer1.1-2 bitops1.0-6
[7] digest0.6.25 bit4.0.4 RSQLite2.2.1
[10] memoise1.1.0 pkgconfig2.0.3 rlang0.4.7
[13] graph1.60.0 shiny1.5.0 DBI1.1.0
[16] fastmap1.0.1 vctrs0.3.4 bit644.0.5
[19] grid3.5.2 GSEABase1.44.0 R62.4.1
[22] geneplotter1.60.0 blob1.2.1 magrittr1.5
[25] shinythemes1.1.2 promises1.1.1 htmltools0.5.0
[28] mime0.9 xtable1.8-4 httpuv1.5.4
[31] RCurl_1.98-1.2

ADD REPLY • link 4.2 years ago ElaM • 0

score 0 · Answer 1 · 2020-10-11

0

Entering edit mode

ElaM • 0

@elam-24316

Last seen 4.2 years ago

The problem was the memory issue. The gsva took 40 cores when doing the calculation in parallel, and therefore, the memory size was not enough. So adding the suitable number of cores in gsva solved the problem.

gsva_paths <- gsva(Xdata,genesets ,method= "gsva",min.sz=10, max.sz=500,parallel.sz= 4, verbose=TRUE)

ADD COMMENT • link 4.2 years ago ElaM • 0

0

Entering edit mode

hi,

yes, so until the former release version of GSVA, the software had this default behavior by which unless a number of cores were specified, GSVA would take all that were available, causing potential problems as the one you have experienced. Since the last release of the software (BioC 3.11, GSVA 1.36.x) the way in which parallelism was done has been complete refactored, using the package BiocParallel to provide more flexibility in using different parallel backends, through a new argument BPPARAM, and to enforce that default calculations are done in a single core unless specified otherwise (through arguments parallel.sz and/or BPPARAM, please consult the manual page of gsva for further information). Moreover, thanks to Alexey Sergushichev, the implementation of the method ssgsea is now about one order of magnitude faster. For all this, I strongly recommend you to update your version GSVA and Bioconductor to the last release.

ADD REPLY • link 4.2 years ago Robert Castelo ★ 3.4k