Error in run.RCTD(), could not find function "solveIRWLS.weights"

[luoyufei]

Hi,

I'm trying to annotate cell type of my spatial transcriptomics data, generated by VISIUM HD. When i ran RCTD <- run.RCTD(RCTD, doublet_mode = "doublet") , i got the following error:

Loading required package: spacexr Error in { : task 1 failed - "could not find function "solveIRWLS.weights""

I digged deeper trying with the 3 functions : RCTD <-fitBulk(RCTD) RCTD <- choose_sigma_c(RCTD,) RCTD <- fitPixels(RCTD, doublet_mode = "doublet") It output the same error at choose_sigma_c(RCTD) step.

Could you help me to work this out please? Many thanks

[luoyufei]

Oh, my problem is just resolved when i specify max_cores = 1 instead of 4 in the previous function create.RCTD(query, reference, max_cores = 1). Maybe due to the multicores configuration on my cloud posit.

[Liuy12]

I encountered the same issue when setting max_cores higher than 1. For me it's caused by the parallel backend with parallel::makeCluster not working properly. I created a repo here (https://github.com/Liuy12/spacexr), and commented out the parallel backend registering steps within spacexr. After installing this version, it worked for me.

To use multi-core, you can try something like:

library(spacexr)
library(future)
library(doFuture)
registerDoFuture()
plan("multicore", workers = 10)

[daccachejoe]

@Liuy12 Thank you very much for doing this as it worked when installing from your fork. It's a simple error that wasn't compatible with my HPC set up and you commenting it out worked perfectly.

[simonhoellerer]

Another way would be to e.g. set echo 'R_LIBS_USER=/home/username/R/x86_64-pc-linux-gnu-library/4.4.2' >> ~/.Renviron This solved the issue for me, since now also HPC workers have access to the user's R environment.

[dmcable]

Thank you all for pointing out this issue and solution.

If the issue is with the doParallel / foreach packages, then I'm not sure there is anything we can do to solve the issue from our end.

If this continues to be a persistent issue, then we can consider switching to future / doFuture on our version.

Best, Dylan