Informational messages (normal_id_glm_lpdf: Scale vector is inf, but must be positive finite)

I’m trying to work up some ‘basic’ (ha) brms examples for students (see Examples). In the spirit of being careful, I chose priors explicitly (mostly) based on prior predictive simulations rather than using the brms defaults. (For a Gaussian random-slopes model I set the non-intercept fixed effect prior, and the random-effects SD and residual SD, somewhat narrower than the default.)

For a well-behaved problem, I got a number of warning messages about infinite scale vectors (46 over a standard 4-chain, 4000-sample run)

Informational Message: The current Metropolis proposal is about to be rejected because of the following issue:
Chain 1 Exception: normal_id_glm_lpdf: Scale vector is inf, but must be positive finite! (in '/tmp/Rtmp0I0GWI/model-4b4c122824be1.stan', line 76, column 4 to column 55)
Chain 1 If this warning occurs sporadically, such as for highly constrained variable types like covariance matrices, then the sampler is fine,
Chain 1 but if this warning occurs often then your model may be either severely ill-conditioned or misspecified.

Is there something reasonably obvious that I’m doing wrong? I hate to ignore warning messages, and I especially hate to tell students to ignore warning messages.

options(brms.backend = "cmdstanr")
data("sleepstudy", package = "lme4")
form1 <- Reaction ~ Days + (Days|Subject)
b_prior7 <- c(set_prior("normal(0, 20)", "b"),
              set_prior("student_t(10, 0, 10)", "sd"),
              set_prior("student_t(10, 0, 10)", "sigma")
b_reg3 <- 
    brm(form1, sleepstudy, prior = b_prior7,
        seed = 101,   
        control = list(adapt_delta = 0.95)

I was able to run your model with no errors using the following code in brms version 2.17.0. Unfortunately I don’t have cmdstanr on this computer, so I had to run it with rstan backend. I am not exactly sure why you got those errors, but I had not seen code for brms written quite that way before, and also using set_prior threw an error for me.


data("sleepstudy", package = "lme4")

form1 <- bf(Reaction ~ Days + (Days|Subject)) + gaussian()
b_prior7 <- c(prior(normal(0, 20), class=b),
              prior(student_t(10, 0, 10), class=sd),
              prior(student_t(10, 0, 10), class=sigma)
b_reg3 <- brm(form1, data=sleepstudy, prior = b_prior7,
        seed = 101,   
        control = list(adapt_delta = 0.95), cores=4

I can reproduce in cmdstan, but to see these messages, I need to add silent = 0 to my brm call. @bbolker, do you have a global option or something in your rprofile that’s achieving this?

In this case, and cases like it when the message arises only during the earliest stages of warmup, what’s almost certainly occurring are numerical issues that are present in the weird parts of parameter space where initialization lands but–and this is the key thing–that are not present in the region of important probability mass. As long as these messages are restricted to the early part of warmup, they are safe to ignore.

At least for me, these messages are not raised under the default silent = 1, meaning that I think there’s a way to sidestep the issue of telling students to ignore such messages.

1 Like

@jsocolar Interesting. FYI I can’t reproduce those messages even with silent = 0 using rstan backend, but switching computers to use cmdstanr I get the same ‘informational’ messages as @bbolker with silent=0.

Thanks for the useful feedback. FWIW I get these messages running the originally posted code in a clean R session, with no relevant options set in .Rprofile

R Under development (unstable) (2023-05-27 r84465)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

other attached packages:
[1] brms_2.19.0 Rcpp_1.0.10

sapply(ss$loadedOnly[grepl("stan", names(ss$loadedOnly))], \(x) x$Version)
 shinystan      rstan rstantools 
   "2.6.0"   "2.21.8"    "2.3.1" 

huh. My next best guess is that maybe something changed in cmdstan such that these informational messages are classified with a lower level of importance, and therefore are no longer surfaced with the default silent = 1 in brm(). I’ve justed tested on both cmdstan 2.31 and cmdstan 2.32 and I don’t see these messages at silent = 1 but I do see them at silent = 0. @bbolker what cmdstan version are you using, and if different from 2.32 does updating change things? @WardBrian, anything look familiar here that could explain the behavior @bbolker is seeing?

edit: oh and @bbolker what is the output of cmdstanr::cmdstan_make_local()?

cmdstanr::cmdstan_version() says 2.32.2. cmdstanr::cmdstan_make_local() returns character(0)

I do appreciate the help, and am happy to keep digging/diagnosing if you folks want to get to the bottom of the issue, but I also feel this is resolved to my satisfaction/don’t need to pursue it further …

1 Like

I have the same issue.

R version 4.3.0 (2023-04-21)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.4

rstan_2.21.8, StanHeaders_2.26.26

With the same reproducible example?