Windows 7
brms: development version 2.9.0
R version 3.6.0
RStudio version 1.1.442
Rtools version 3.5
Rstan version 2.19.1
StanHeaders version 2.18.1-9
This is a maximally simple mock dataset, designed to exemplify how varying-intercept logistic models work:
require(brms)
set.seed(2019)
d <- data.frame(id = letters[1:20], TrueLogit = rnorm(20), y = NA, n = round(runif(20, min = 5, max = 20)))
d$y <- round(plogis(d$TrueLogit) * d$n)
mix.b <- brm(y|trials(n) ~ (1|id), family = binomial("logit"), prior = prior(uniform(0,10), class = sd), data = d, iter = 11000)
Compiling the C++ model
Then, as soon as the model has compiled and sampling is due to begin, the R session crashes with the following pop-up error window:
R Session Aborted
R encountered a fatal error.
The session was terminated.
[Start New Session]
Interestingly, more complex models do tend to fit without crashing. The author of brms suggested that this might be a Stan problem rather than a brms one.
I’m on brms 2.8 and rstan 2.18 but I was able to reproduce the crash with your code. It also went away when I removed the prior.
The Stan wiki article on priors advises against your choice:
-
Don’t use uniform priors, or hard constraints more generally, unless the bounds represent true constraints (such as scale parameters being restricted to be positive, or correlations restricted to being between -1 and 1). Some examples:
-
You think a parameter could be anywhere from 0 to 1, so you set the prior to uniform(0,1). Try normal(.5,.5) instead.
-
A scale parameter is restricted to be positive and you want to give it a vague prior, so you set to uniform(0,100) (or, worse, uniform(0,1000)). If you just want to be vague, you could just specify no prior at all, which in Stan is equivalent to a noninformative uniform prior on the parameter. Or you could give a weak prior such as exponential with expected value 10 (that’s exponential(0.1), I think) or half-normal(0,10) (that’s implemented as normal(0,10) with a <lower=0> constraint in the declaration of the parameter) or half-Cauchy(0,5) or even something more informative such as half-normal(0,1) or half-t(3,0,1).
Source
I get the same crash regardless of prior. Omitting the parameter did not help, nor did setting the prior to exponential(1).
(Also, as I’m sure Paul will agree, crashing R is not the desired behavior in response to a badly chosen prior. Warning messages and/or lack of convergence would surely be enough.)
Something strange appears to be going on with this Windows version.
The problem appears to have been due to RStudio. Updating it to 1.2.1335 stopped the crashing.
This was a good reminder since for me Rstudio 1.1 had been consistently crashing on routine package updates of one of “bayesplot”, “brms”, “dbplyr”, “JuliaCall”, “rmarkdown”, or “tibble”. The update to 1.2 fixed that issue and everything is updated included brms.