Fitted Stan object is shown as <Object with null pointer> after the rstan and R update

Dear Stan folks,

I have errors such that the fitted Stan object is shown as <Object with null pointer> in the Environment tab after I update the rstan and R. The subsequent problem is that if I use other packages that exploit the Stan object fitted from the stan() function, the R session is aborted, immediately. Therefore, I would like to get some help to solve this issue.

As an example, I used the bridgesampling package that uses the Stan fit object. The R code to first fit the Stan object comes below.

library(rstan)
options(mc.cores = parallel::detectCores())
rstan_options(auto_write = TRUE)
library(bridgesampling)
data("turtles")
### H0 (model without random intercepts) ###
H0_code <-
  "data {
int<lower = 1> N;
int<lower = 0, upper = 1> y[N];
real<lower = 0> x[N];
}
parameters {
real alpha0_raw;
real alpha1_raw;
}
transformed parameters {
real alpha0 = sqrt(10.0) * alpha0_raw;
real alpha1 = sqrt(10.0) * alpha1_raw;
}
model {
// priors
target += normal_lpdf(alpha0_raw | 0, 1);
target += normal_lpdf(alpha1_raw | 0, 1);
// likelihood
for (i in 1:N) {
target += bernoulli_lpmf(y[i] | Phi(alpha0 + alpha1 * x[i]));
}
}"
### H1 (model with random intercepts) ###
H1_code <-
  "data {
int<lower = 1> N;
int<lower = 0, upper = 1> y[N];
real<lower = 0> x[N];
int<lower = 1> C;
int<lower = 1, upper = C> clutch[N];
}
parameters {
real alpha0_raw;
real alpha1_raw;
vector[C] b_raw;
real<lower = 0> sigma2;
}
transformed parameters {
vector[C] b;
real<lower = 0> sigma = sqrt(sigma2);
real alpha0 = sqrt(10.0) * alpha0_raw;
real alpha1 = sqrt(10.0) * alpha1_raw;
b = sigma * b_raw;
}
model {
// priors
target += - 2 * log(1 + sigma2); // p(sigma2) = 1 / (1 + sigma2) ^ 2
target += normal_lpdf(alpha0_raw | 0, 1);
target += normal_lpdf(alpha1_raw | 0, 1);
// random effects
target += normal_lpdf(b_raw | 0, 1);
// likelihood
for (i in 1:N) {
target += bernoulli_lpmf(y[i] | Phi(alpha0 + alpha1 * x[i] + b[clutch[i]]));
}
}"
set.seed(1)
### fit models ###
stanfit_H0 <- stan(model_code = H0_code,
                   data = list(y = turtles$y, x = turtles$x, N = nrow(turtles)),
                   iter = 15500, warmup = 500, chains = 4, seed = 1)
stanfit_H1 <- stan(model_code = H1_code,
                   data = list(y = turtles$y, x = turtles$x, N = nrow(turtles),
                               C = max(turtles$clutch), clutch = turtles$clutch),
                   iter = 15500, warmup = 500, chains = 4, seed = 1)

If I finish this part, there appear two Stan fit objects in the Environment tab. For me, they are shown as <Object with null pointer>. I then used the bridge_sampler() function to calculate the log marginal likelihoods, which uses the Stan fit object.

set.seed(1)
### compute (log) marginal likelihoods ###
bridge_H0 <- bridge_sampler(stanfit_H0)
bridge_H1 <- bridge_sampler(stanfit_H1)

Immediately, the R session is aborted. Therefore, could anyone help me get out of this error swamp? I attach the session information of my machine.

sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19041)
Matrix products: default
locale:
[1] LC_COLLATE=Korean_Korea.949 LC_CTYPE=Korean_Korea.949
[3] LC_MONETARY=Korean_Korea.949 LC_NUMERIC=C
[5] LC_TIME=Korean_Korea.949
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] compiler_4.0.3 parallel_4.0.3 tools_4.0.3

Thanks for your time and consideration!

Runs ok on my laptop with OS X, but I haven’t run stanfit_H1 since that will take forever. But running bridge_sampler() on stanfit_H0 works for me:

> set.seed(1)
> bridge_H0 <- bridge_sampler(stanfit_H0)
Iteration: 1
Iteration: 2
Iteration: 3
Iteration: 4

stanfit_H0 is listed as an <object with null pointer>, but I can examine it in my environment using attributes(stanfit_H0). Here’s my session info:

> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7

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

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

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

other attached packages:
[1] bridgesampling_1.0-0 rstan_2.21.2         ggplot2_3.3.2       
[4] StanHeaders_2.21.0-6

loaded via a namespace (and not attached):
 [1] Brobdingnag_1.2-6  tinytex_0.27       tidyselect_1.1.0   xfun_0.19         
 [5] purrr_0.3.4        lattice_0.20-41    V8_3.4.0           colorspace_2.0-0  
 [9] vctrs_0.3.5        generics_0.1.0     stats4_4.0.3       loo_2.3.1.9000    
[13] rlang_0.4.8        pkgbuild_1.1.0     pillar_1.4.6       glue_1.4.2        
[17] withr_2.3.0        matrixStats_0.57.0 lifecycle_0.2.0    stringr_1.4.0     
[21] munsell_0.5.0      gtable_0.3.0       mvtnorm_1.1-1      coda_0.19-4       
[25] codetools_0.2-18   inline_0.3.16      callr_3.5.1        ps_1.4.0          
[29] curl_4.3           parallel_4.0.3     fansi_0.4.1        Rcpp_1.0.5        
[33] scales_1.1.1       RcppParallel_5.0.2 jsonlite_1.7.1     gridExtra_2.3     
[37] stringi_1.5.3      processx_3.4.4     dplyr_1.0.2        grid_4.0.3        
[41] cli_2.1.0          tools_4.0.3        magrittr_2.0.1     tibble_3.0.4      
[45] crayon_1.3.4       pkgconfig_2.0.3    ellipsis_0.3.1     Matrix_1.2-18     
[49] prettyunits_1.1.1  assertthat_0.2.1   rstudioapi_0.13    R6_2.5.0          
[53] compiler_4.0.3 
1 Like

The stanfit objects should still work as normal even with that display title (i.e., calls to summary and such will still work). I suspect that the crash when calling bridgesampling is due to running out of memory. Can you try again with the task manager open and keeping an eye on RAM usage?

2 Likes

@torkar Thanks for your reply! It is weird that my machine produces error whereas yours don’t. We have exactly the same version of R (4.0.3) and rstan (2.21.2).

But as @andrjohns says, I have a feeling this is a memory issue. Bridgesampling can swallow a lot of mem…

2 Likes

@andrjohns Thanks for your reply! I do not think the memory is an issue. When I simultaneously checked the RAM usage on the task manager, I could still use about 8 GB out of 16 GB. Do you have any other ideas?

@torkar Could be… Do you mind if I ask you the memory of your machine?

I have 16 GB. But it you run your example and only sample the first model (H0_code), and run bridge_sampler() on that model does it still abort?

1 Like

If you’re able to call other Stan functions on the stanfit object, and only the bridgesampler call crashes, then you may want to open an issue on the bridgesampling github: https://github.com/quentingronau/bridgesampling

Also, can you try running options(mc.cores=1) before the bridgesampling call?

1 Like

@torkar Following your suggestion, I quickly sampled the first model (H0_code) only. The R session is still aborted.

@andrjohns

  1. I already contacted Quentin about this issue. He said that the bridgesampling package works fine since the bridge_sampler() function worked when the target was JAGS instead of Stan. So he suggested me to figure out problems with regard to Stan.
  2. No, I didn’t I will try, now.

In this case, if there are no issues with running and summarising the model through RStan, then the issue is in how the bridgesampling package is interacting with the stanfit object, and that’s something that the authors will need to debug.

I also can’t replicate the crashing on a linux system, but I’ll be able to test with windows tomorrow

1 Like

@andrjohns

  1. With options(mc.cores=1), it works totally fine! How can this happen? Why it does not work when I do with multiple cores?
  2. Okay, maybe I should contact the authors, again, for this issue.

One possibility is a memory issue, since it copies the workspace to each parallel thread. If you have a CPU with a large number of threads, this can take up too much memory. If it’s not a memory issue, then it could be the parallelisation itself, since Windows using a different parallelisation mechanism than Linux/Mac.

To rule out memory issues, you could try running the stan model for drastically fewer iterations or using a small number of cores (i.e., options(mc.cores=2))

1 Like

To check memory issues again, I ran the Stan model with a smaller number of cores (options(mc.cores=2)). The R session, then, is immediately aborted. In other words, the bridge_sampler() worked only when I used the single core. Does this mean I have the parallelization issue instead of the memory issue (please apologize me if I did not completely get your point…)?

Yes, it looks like this is an issue with bridge sampler’s parallelism on Windows. This should help their devs debug from here

2 Likes

Thanks a lot, @andrjohns! I will contact the authors about this issue.

I can replicate this bug on Windows if core > 1 and you are using RStudio. It does not happen if you just use regular R (i.e., not RStudio) or cores = 1. Please also note that the bridgesampling documentation states:

Due to the way rstan currently works, parallel computations with stanfit and stanreg objects only work with forking (i.e., NOT on Windows).

Of course, bridgesampling checks if the OS is appropriate and sets cores = 1 otherwise, so it is a complete mystery to me why it crashes on RStudio. I have tried a few things and it does not make much sense to me. In regular R it works as expected and gives the following warning on Windows:

cores > 1 only possible on Unix/MacOs. Uses ‘core = 1’ instead.

We (i.e., bridgesampling developers) might try a few more things, but it seems a rather weird bug. In any case, the easiest solution is using cores = 1 on Windows as described in the documentation or do not use RStudio.

4 Likes

Interesting! Thanks for reporting back, it’s very helpful to know

1 Like

Thanks for checking the error!