Algebraic Solver Problems on Windows?

Developers
1

Windows users in my courses have had problems with the following model crashing RStudio,

functions {
  // Difference between one-sided Gaussian tail probability and target probability
  vector tail_delta(vector y, vector theta, real[] x_r, int[] x_i) {
    vector[1] deltas;
    deltas[1] = 2 * (normal_cdf(theta[1], 0, exp(y[1])) - 0.5) - 0.99;
    return deltas;
  }
}

transformed data {
  vector[1] y_guess = [log(5)]'; // Initial guess of Gaussian standard deviation
  vector[1] theta = [15]';       // Target quantile
  vector[1] y;
  real x_r[0];
  int x_i[0];

  // Find Gaussian standard deviation that ensures 99% probabilty below 15
  y = algebra_solver(tail_delta, y_guess, theta, x_r, x_i);

  print("Standard deviation = ", exp(y[1]));
}

generated quantities {
  real sigma = exp(y[1]);
}

I haven’t had anyone testing it on PyStan on Windows, but it works in RStan and PyStan on OS X and at least some versions of Linux.

Can anyone who has access to Windows verify a problem and/or help isolate what the issue might be? I fear a bug in the algebraic solver that’s manifesting only in Windows.

2

I had weird results running this model on windows. At first it worked fine, then without changing anything it crashed RStudio a few times in a row. Now it’s back to working fine. Also, when it caused R to crash it looked like the model was able to run and return the print statement.

image
image.png1714Ă—957 109 KB

Here’s the code and options I was using

library(rstan)
options(mc.cores = parallel::detectCores(FALSE))
rstan_options(auto_write = TRUE)
stan("model.stan", chains = 1, iter=1, warmup=0, algorithm = "Fixed_param")

And here’s my sessionInfo()

R version 3.5.1 (2018-07-02)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17134)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C                          
[5] LC_TIME=English_United States.1252    

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

other attached packages:
[1] rstan_2.18.2       StanHeaders_2.18.0 ggplot2_3.1.0     

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.0         pillar_1.3.0       compiler_3.5.1     plyr_1.8.4        
 [5] bindr_0.1.1        prettyunits_1.0.2  base64enc_0.1-3    tools_3.5.1       
 [9] pkgbuild_1.0.2     tibble_1.4.2       gtable_0.2.0       pkgconfig_2.0.2   
[13] rlang_0.3.0.1      cli_1.0.1          rstudioapi_0.8     parallel_3.5.1    
[17] loo_2.0.0          bindrcpp_0.2.2     gridExtra_2.3      withr_2.1.2       
[21] dplyr_0.7.8        knitr_1.20         stats4_3.5.1       grid_3.5.1        
[25] tidyselect_0.2.5   glue_1.3.0         inline_0.3.15      R6_2.3.0          
[29] processx_3.2.0     purrr_0.2.5        callr_3.0.0        magrittr_1.5      
[33] codetools_0.2-15   matrixStats_0.54.0 scales_1.0.0       ps_1.2.1          
[37] assertthat_0.2.0   colorspace_1.3-2   lazyeval_0.2.1     munsell_0.5.0     
[41] crayon_1.3.4

I also want to mention that I’ve had problems with the ODE solvers crashing Rstudio on windows as well. I brought it up in this thread. When i encountered those problems it was very inconsistent. At one point I had a RK45 solver working fine; then, when I added one more parameter to the ODE system the model would compile but crash RStudio during sampling. I also couldn’t get the BDF solver to work at all. Not sure if any of this is related to the algebra solver.

3

This does resemble the problem we have been having on Windows with ODEs, although with ODEs I could eventually reproduce the crash (although haven’t been able to do anything to solve it) by running it a few times. With the algebraic_solver example, I have been able to run it 100 times in a loop without crashing by calling

for (j in 1:100) test <- stan("crash.stan", algorithm = 'Fixed_param', refresh = 0)

with just

CXX14=$(BINPREF)g++ -m$(WIN)
CXX11FLAGS = -O3

in ~/.R/Makevars.win . This is on an older desktop running Windows 10 now. Is there any obvious difference on a machine that crashes with that example?

1 Like
4

Just for reference, in this case I was working with pretty fresh Windows 10 installs (in a computer lab with a collection of older and new iMac hardware oddly enough). I installed R, RStudio, Rtools (through the RStudio popup), and then RStan on each so the machines should have been pretty consistent. I then set Makevars as instructed in the RStan Quick Start page.

The algebraic solver model crashed on only a few of the computers, but the crashes were consistent. It crashed when run in RStudio as well as R and with chains = 1 to avoid parallelization issues. This is the same behavior I’ve encountered in the past - some Windows users are fine while some have consistent crashes of this model.

There were other issues as well. I had some exercises with a series of evolving models but the same generated quantities, and one user would experience a crash if he ran one of the models. The crash would go away if he removed the generated quantities block, but the same block would work fine in another program. Then another user had the same issue but with a different model in the sequence. In other words, the problems were consistent on one computer but varied from one computer to another.

5

cc: @charlesm93.

@betanalpha, have you seen it crash with CmdStan on Windows? It’d be good to narrow whether this is a bug in the Math library or if it’s some interaction with an interface.

6

One of the students in the course was able to reproduce the crashing behavior, but in an unexpected way.

On Windows 10, 64-bit, with R version 3.5.2, rstan_2.18.2 both models seem to run fine (they have intermittently failed in the past, but that failure can’t be reproduced). On Windows 7, 64-bit, with R version 3.5.2, rstan_2.18.2 the “not_working.stan” starts, deploys child processes for each chain, and then crashes RStudio reproducibly.

I have no idea why vectorization would trigger the bug, but hopefully this provides something that can be tested on other systems.

not_working.stan (1.7 KB)
working.stan (1.9 KB)

1 Like