Why does tab_model (sjPlot) re-run MCMC with rstanarm model?

Question

I am creating a table with tab_model from the package sjPlot (https://cran.r-project.org/web/packages/sjPlot/vignettes/tab_model_estimates.html).

However, when I use a negative binomial rstanarm model object, tab_model re-runs MCMC chains. My actual model takes many hours to run, so this is not ideal for tab_model to be doing this, but it doesn't seem to do it for other models (such as with glmer in lme4).

library(rstanarm)
library(lme4)

dat.nb<-data.frame(x=rnorm(200),z=rep(c("A","B","C","D"),50),
                y=rnbinom(200,size=1,prob = .5))

mod1<-glmer.nb(y~x+(1|z),data=dat.nb)

options(mc.cores = parallel::detectCores())
mod2<-stan_glmer.nb(y~x+(1|z),data=dat.nb)

Now to create the model tables:

library(sjPlot)
tab_model(mod1)

The output is quick, and as expected (although the original model also ran quick, so it is possible that tab_model is re-running the model here too).

Now when I try

tab_model(mod2)

It begins re-running MCMC. Is this normal behavior, and if so, is anyone familiar with a way to turn this off, and just use the model object already created, rather than re-running the model?

Answer 1

tl;dr I think this is going to be hard to avoid without hacking both the insight package and this one, or asking the package maintainer for an edit, unless you want to forgo printing the ICC, R^2, and the random-effects variance. Here, tab_model() calls insight::get_variance(), which tries to compute variances for the null model so it can compute the ICC and R^2. Computing these variances requires re-running the model. (When it does it for the glmer.nb, it goes via lme4:::update.merMod() and is quick enough that you don't notice the computation time.)

So

tab_model(mod2,show.r2=FALSE,show.icc=FALSE,show.re.var=FALSE)

doesn't recompute anything. In theory I think it should be possible to skip the resampling/recomputation step with just show.r2=FALSE, show.icc=FALSE (i.e. it shouldn't be necessary to get the RE var), but this would take some hacking/participation by the maintainer.

---

Digging in (by using debug(rstan::sampling) to stop inside the Stan sampling function, then where to see the call stack ...

• tab_model() calls insight::get_variance() here
• the insight::get_variance.stanreg() method calls insight:::.compute_variances()
• ... which calls insight:::.compute_variance_distribution()
• ... which (for a log-link count distribution) calls insight:::.variance_distributional()
• ... which calls null_model
• ... which calls .null_model_mixed()
• ... which calls stats::update()