Entering edit mode
Hello,
I used the combat to reduce the batch effect in the expression data. If I run using the parametric model, the output is right. however, if I run using the non parametric, the output is NaN.
df_combat <- ComBat(dat=datap,batch=batch,mod=mod,par.prior=TRUE,prior.plots=FALSE,mean.only=TRUE)
the output is correct.
df_combat <- ComBat(dat=datap,batch=batch,mod=mod,par.prior=FALSE,mean.only=FALSE)
the output is NaN.
# include your problematic code here with any corresponding output
# please also include the results of running the following in an R session
> sessionInfo()
R version 4.2.1 (2022-06-23)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.5 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=zh_CN.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=zh_CN.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=zh_CN.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=zh_CN.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] sva_3.50.0 BiocParallel_1.30.4 genefilter_1.78.0
[4] mgcv_1.9-0 nlme_3.1-163
loaded via a namespace (and not attached):
[1] Rcpp_1.0.11 compiler_4.2.1 GenomeInfoDb_1.35.16
[4] XVector_0.36.0 zlibbioc_1.42.0 bitops_1.0-7
[7] tools_4.2.1 bit_4.0.5 annotate_1.74.0
[10] RSQLite_2.3.1 memoise_2.0.1 lattice_0.21-8
[13] png_0.1-8 rlang_1.1.1 Matrix_1.6-1
[16] DBI_1.1.3 cli_3.6.1 parallel_4.2.1
[19] fastmap_1.1.1 GenomeInfoDbData_1.2.9 httr_1.4.7
[22] Biostrings_2.64.1 S4Vectors_0.36.2 vctrs_0.6.3
[25] IRanges_2.32.0 locfit_1.5-9.8 stats4_4.2.1
[28] bit64_4.0.5 grid_4.2.1 Biobase_2.56.0
[31] R6_2.5.1 AnnotationDbi_1.58.0 survival_3.5-7
[34] XML_3.99-0.14 limma_3.52.4 edgeR_3.38.4
[37] blob_1.2.4 matrixStats_1.0.0 codetools_0.2-19
[40] splines_4.2.1 BiocGenerics_0.44.0 KEGGREST_1.36.3
[43] xtable_1.8-4 RCurl_1.98-1.12 cachem_1.0.8
[46] crayon_1.5.2
> q()
Thank you for finding this issue. It must be that one of the batch effect weights becomes so small (computationally 0) that it blows up the whole algorithm. I think I could put a check in to make sure that doesn't happen. It would be much more helpful if you sent me actual data (a smaller version of your data, or your data without identifying meta data) so I could properly diagnose the problem? w.evan.johnson at rutgers.edu Alternatively you could do a deeper dive if sharing your data is not reasonable.
Thank you. I have sent a tony data to you. Please contact to me if you have any question about it.