Sampler won't start if adapt_delta is used: why?

Modeling
, ,
1

I’m having a super weird problem when trying to use adapt_delta in a brms model. If I run the model without adapt_delta, it converges. But if I add this parameter, I get an error message that says that there is a sampling problem:

SAMPLING FOR MODEL '8905f3b5c84488b617ca68a8e8087228' NOW (CHAIN 1).
[1] "Error in sampler$call_sampler(args_list[[i]]) : "                   
[2] "  VECTOR_ELT() can only be applied to a 'list', not a 'externalptr'"
error occurred during calling the sampler; sampling not done

A reproducible example is below.

Has anyone experienced this sort of problem? According to the brms documentation, the code for adapt_delta is ok.

  • Operating system: BigSur (M1 chip)
  • brms 2.15.0
# Create dataframe.
(dat_long <- data.frame(
  subj = rep(1:10, each = 100),
  item = rep(1:10, each = 10),
  cond = c(-.5,.5),
  pTarget = rbinom(1000, 1, .6)
))

# Regular model (converges without issues)
m <- brm(formula = pTarget ~ cond,
         iter = 1000,
         family = bernoulli(),
         chains = 1,
         data =  dat_long)

# Model  with adapt_delta (gives weird error about the sampler)
m_with_delta <- brm(formula = pTarget ~ cond,
                    iter = 1000,
                    family = bernoulli(),
                    control = list(adapt_delta = 0.9),
                    chains = 1,
                    data =  dat_long)

SAMPLING FOR MODEL '8905f3b5c84488b617ca68a8e8087228' NOW (CHAIN 1).
[1] "Error in sampler$call_sampler(args_list[[i]]) : "                   
[2] "  VECTOR_ELT() can only be applied to a 'list', not a 'externalptr'"
2 Likes
2

Sorry for the slow response.

I cannot reproduce locally, running the development version of brms and the experimental version of rstan. I also cannot reproduce running with the cmdstanr backend. Can you confirm whether the problem persists for you after upgrading to the development versions of everything?

3

I found this also. I was bot able to make Brms work with control statements. My workaround was rstanarm.

Rstanarm do a not seem to have anything like the lognormal family for positive responses.when I need such, I use an older non-M1 Mac and save the results as an Rds file.

4

Just to reiterate, I have access to an M1 and I cannot reproduce this using development versions of brms and rstan or cmdstanr. To get the latest development versions, do
remotes::install_github('stan-dev/rstan/rstan/rstan@experimental')
and
remotes::install_github('paul-buerkner/brms')
@tedw5 Can you confirm whether the problem persists for you after upgrading to the development versions?

5

Hi there, and sorry for the delayed reply!

I updated brms to the development version and I can confirm that the problem disappeared for me.

It’s frustrating that I can’t figure out why it was happening. I tried multiple things, and my best guest is that it has something to do with running chains in parallel. My hunch is that somehow the Apple OS (with M1) shuts down the process when it is perceived as too big, and then the actual error that appears on the console is not very diagnostic, because it just corresponds to the whatever step that failed when the process was shut down (my reasons for thinking this is that I found that the error message keeps changing for different models… it doesn’t seem to be systematic).

6

I have this problem with rstan. When I give adapt_delta R just crashes. Works without it.

  Model Name: MacBook Pro
  Model Identifier: MacBookPro15,2
  Processor Name: Quad-Core Intel Core i5
  Processor Speed: 2,3 GHz
  Number of Processors: 1
  Total Number of Cores: 4
  L2 Cache (per Core): 256 KB
  L3 Cache: 6 MB
7

I think this is a known problem. I’m fairly sure I saw this on the forum a few days back.

1 Like