`check_convergence()`

provides an alternative convergence
test for `merMod`

-objects.

check_convergence(x, tolerance = 0.001, ...)

x | A |
---|---|

tolerance | Indicates up to which value the convergence result is
accepted. The smaller |

... | Currently not used. |

`TRUE`

if convergence is fine and `FALSE`

if convergence
is suspicious. Additionally, the convergence value is returned as attribute.

Convergence problems typically arise when the model hasn't converged to a solution where the log-likelihood has a true maximum. This may result in unreliable and overly complex (or non-estimable) estimates and standard errors.

lme4 performs a convergence-check (see `?lme4::convergence`

),
however, as as discussed here
and suggested by one of the lme4-authors in
this comment,
this check can be too strict. `check_convergence()`

thus provides an
alternative convergence test for `merMod`

-objects.

Convergence issues are not easy to diagnose. The help page on
`?lme4::convergence`

provides most of the current advice about
how to resolve convergence issues. Another clue might be large parameter
values, e.g. estimates (on the scale of the linear predictor) larger than
10 in (non-identity link) generalized linear model *might* indicate
complete separation.
Complete separation can be addressed by regularization, e.g. penalized
regression or Bayesian regression with appropriate priors on the fixed effects.

if (require("lme4")) { data(cbpp) set.seed(1) cbpp$x <- rnorm(nrow(cbpp)) cbpp$x2 <- runif(nrow(cbpp)) model <- glmer( cbind(incidence, size - incidence) ~ period + x + x2 + (1 + x | herd), data = cbpp, family = binomial() ) check_convergence(model) }#>#>#>#> [1] TRUE #> attr(,"gradient") #> [1] 8.444895e-05