Can't get Stan to run in MRO 4.0.2

Hi - I recently got a new Win10 pc and install R etc., but struggled to get RStan running. There seems to be quite a few threads around this, and I’ve tried the suggested methods but to no avail.

(see: Problems getting Stan to run after upgrading to R 4.0.2,
New error: cleanup_makevar(old) : argument “RMU” is missing, with no default Interfaces RStan rstan bug compiler windows
Can’t get stan() to run with R 4.0.2 despite hours of messing with Makevars.win Interfaces RStan

My setup is as follows:

  • Windows 10
  • Microsoft R Open 4.0.2
  • RStudio 1.3.1093
  • RStan 2.21.2
  • RTools 4
  • Checkpoint 0.4.4

After following the instructions and installing RTools 4 per: RTools 4 and R4.0, all the checks returned their supposed values.

I did have a Makevars.win file created with:

dotR <- file.path(Sys.getenv("HOME"), ".R")
if (!file.exists(dotR)) dir.create(dotR)
M <- file.path(dotR, ifelse(.Platform$OS.type == "windows", "Makevars.win", "Makevars"))
if (!file.exists(M)) file.create(M)
cat("CXX14FLAGS += -O3 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2",file = "~/.R/Makevars.win", sep = "\n", append = FALSE)

But when I ran

library(rstan)
options(mc.cores = parallel::detectCores())
rstan_options(auto_write = TRUE)

example(stan_model,run.dontrun = TRUE)

I got the error message:

Error in cleanup_makevar(old) : 
  argument "RMU" is missing, with no default
In addition: Warning message:
In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr = TRUE) :
  'C:/rtools40/usr/mingw_/bin/g++' not found

As per the other thread, when I deleted the Makevars.win file, the model ran a bit more, but still got stuck in the end with the following:

Compilation ERROR, function(s)/method(s) not created!
Error in compileCode(f, code, language = language, verbose = verbose) : 
  C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file4b842a773f.o:file4b842a773f.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D1Ev[_ZN3tbb8internal26task_scheduler_observer_v3D1Ev]+0x14): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file4b842a773f.o:file4b842a773f.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D0Ev[_ZN3tbb8internal26task_scheduler_observer_v3D0Ev]+0x1c): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file4b842a773f.o:file4b842a773f.cpp:(.text$_ZN4stan4math16ad_tape_observerD1Ev[_ZN4stan4math16ad_tape_observerD1Ev]+0x15): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rtools40/mingw

Also tried down-versioning the withr package to 2.2.0 but the error messages remain the same.

I did notice that Sys.which("g++") returns

Sys.which(“g++”)
g++
“”

but

Sys.which(“make”)
make
“C:\rtools40\usr\bin\make.exe”

Recreating a Makevars.win file with the following doesn’t help either

CXX14FLAGS = -O3 -g0 -Wno-ignored-attributes -Wno-deprecated-declarations
CXX14 = C:\rtools40\mingw64\bin\g++ -m$(WIN)

I’ve tried multiple uninstall/reinstall/delete all R folders and .R files but still no luck. I’m pretty stumped at this stage. Would appreciate any help in getting RStan up and running again. Thanks in advance!

Unfortunately there are compatibility issues with R Open that still haven’t been ironed out. At the moment your only option for running Stan through R Open is the cmdstanR package: https://mc-stan.org/cmdstanr/

Sorry for all the trouble!

Someone with MRO might try rstan from GitHub

Sys.setenv("R_REMOTES_NO_ERRORS_FROM_WARNINGS" = "true")
remotes::install_github("stan-dev/rstan", ref = "develop", subdir = "rstan/rstan")

Great - managed to get CmdStanR working with brms on MRO4.0.2 after a bit of back and forth on the PATH environment variable. Thanks both!

Just out of interest - is it possible to have RStan with R 4.0.3, and CmdStanR with MRO 4.0.2 both installed on the same machine just to pass Stanfit objects between the two? I really like the threading/reduce_sum option in brms with cmdstanr but I don’t think the latter supports the loo comparisons just yet…

There shouldn’t be an issue with brms + cmdstanr and loo comparisons, see below for an example using the models from the documentation:

library(brms)
#> Loading required package: Rcpp
#> Loading 'brms' package (version 2.14.5). Useful instructions
#> can be found by typing help('brms'). A more detailed introduction
#> to the package is available through vignette('brms_overview').
#> 
#> Attaching package: 'brms'
#> The following object is masked from 'package:stats':
#> 
#>     ar
options(mc.cores=4)

# model with population-level effects only
fit1 <- brm(rating ~ treat + period + carry,
            data = inhaler, backend="cmdstanr",
            threads=threading(2),refresh=0)
#> Compiling Stan program...
#> Start sampling
#> Running MCMC with 4 parallel chains, with 2 thread(s) per chain...
#> 
#> Chain 1 finished in 0.2 seconds.
#> Chain 2 finished in 0.2 seconds.
#> Chain 3 finished in 0.3 seconds.
#> Chain 4 finished in 0.3 seconds.
#> 
#> All 4 chains finished successfully.
#> Mean chain execution time: 0.3 seconds.
#> Total execution time: 0.4 seconds.
(loo1 <- loo(fit1))
#> 
#> Computed from 4000 by 572 log-likelihood matrix
#> 
#>          Estimate   SE
#> elpd_loo   -529.4 25.9
#> p_loo         6.2  1.0
#> looic      1058.9 51.9
#> ------
#> Monte Carlo SE of elpd_loo is 0.0.
#> 
#> All Pareto k estimates are good (k < 0.5).
#> See help('pareto-k-diagnostic') for details.

# model with an additional varying intercept for subjects
fit2 <- brm(rating ~ treat + period + carry + (1|subject),
            data = inhaler, backend="cmdstanr",
            threads=threading(2), refresh=0)
#> Compiling Stan program...
#> Start sampling
#> Running MCMC with 4 parallel chains, with 2 thread(s) per chain...
#> 
#> Chain 1 finished in 2.1 seconds.
#> Chain 2 finished in 2.1 seconds.
#> Chain 3 finished in 2.1 seconds.
#> Chain 4 finished in 2.0 seconds.
#> 
#> All 4 chains finished successfully.
#> Mean chain execution time: 2.1 seconds.
#> Total execution time: 2.1 seconds.
(loo2 <- loo(fit2))   
#> Warning: Found 4 observations with a pareto_k > 0.7 in model 'fit2'. It is
#> recommended to set 'moment_match = TRUE' in order to perform moment matching for
#> problematic observations.
#> 
#> Computed from 4000 by 572 log-likelihood matrix
#> 
#>          Estimate   SE
#> elpd_loo   -522.8 26.3
#> p_loo        86.0  7.7
#> looic      1045.6 52.6
#> ------
#> Monte Carlo SE of elpd_loo is NA.
#> 
#> Pareto k diagnostic values:
#>                          Count Pct.    Min. n_eff
#> (-Inf, 0.5]   (good)     549   96.0%   232       
#>  (0.5, 0.7]   (ok)        19    3.3%   129       
#>    (0.7, 1]   (bad)        4    0.7%   34        
#>    (1, Inf)   (very bad)   0    0.0%   <NA>      
#> See help('pareto-k-diagnostic') for details.

# compare both models
loo_compare(loo1, loo2)  
#>      elpd_diff se_diff
#> fit2  0.0       0.0   
#> fit1 -6.7       4.5

Created on 2020-11-09 by the reprex package (v0.3.0)

It outputs this error after the loo(fit1) line:

> loo1 <- loo(fit1)
Error in checkForRemoteErrors(val) : 
  4 nodes produced errors; first error: could not find function "get_dpar"

Edit: just checked my brms version - it’s 2.14.4 from CRAN where as I noticed yours is 2.14.5?

Can you try installing the github version of brms (that’s why mine is 2.14.5):

remotes::install_github("paul-buerkner/brms")

No luck - same error message…

> sessionInfo("brms")
R version 4.0.2 (2020-06-22)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19041)

Matrix products: default

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

attached base packages:
character(0)

other attached packages:
[1] brms_2.14.5

loaded via a namespace (and not attached):
 [1] magrittr_1.5         grDevices_4.0.2      pkgload_1.1.0        R6_2.5.0             rlang_0.4.8          RevoUtilsMath_11.0.0 fansi_0.4.1          tools_4.0.2         
 [9] utils_4.0.2          pkgbuild_1.1.0       parallel_4.0.2       pacman_0.5.1         cli_2.1.0            withr_2.3.0          remotes_2.2.0        stats_4.0.2         
[17] ellipsis_0.3.1       datasets_4.0.2       checkpoint_0.4.4     assertthat_0.2.1     digest_0.6.27        rprojroot_1.3-2      base_4.0.2           crayon_1.3.4        
[25] processx_3.4.4       callr_3.5.1          graphics_4.0.2       ps_1.4.0             curl_4.3             testthat_3.0.0       memoise_1.1.0        glue_1.4.2          
[33] compiler_4.0.2       methods_4.0.2        RevoUtils_11.0.2     desc_1.2.0           backports_1.2.0      prettyunits_1.1.1

I can’t reproduce the error on either Windows or Linux (assuming you’re using the same code I posted above). Is this on R Open?

Can you try running options(mc.cores=1) before the loo call?

Success with options(mc.cores=1) - thanks!

> loo_compare(loo1, loo2)
     elpd_diff se_diff
fit2  0.0       0.0   
fit1 -8.0       4.6   

Yes this is with R Open 4.0.2 on Win10 machine

Why would mc.cores have an impact…?

Great!

If mc.cores is set to greater than 1, the loo package will spawn multiple threads. A tricky thing with R’s parallelisation on Windows is that any functions and data need to be explicitly exported to each thread. For some reason with R Open, the functions in the brms package (or some other parts of the workspace) are not getting properly exported (one of which is the get_dpar function). By running with mc.cores=1, everything stays in the current workspace which has all of the necessary functions available.

2 Likes