# Convergence issues with lme4 1.1-20 for models that converged when using earlier version of lme4

I am encountering convergence problems with some models after updating to lme4 1.1-20 that I did not encounter with earlier versions of lme4 (in particular, lme4 1.1-15). I am encountering these new convergence issues for some, but not all models, but the models with convergence issues are generally simple models. Therefore I do not understand why they are not converging.

Here is an example:

Dataset:

library(data.table)
d <- as.data.frame(
fread("curl http://www.intensivelongitudinal.com/ch4/ch4R.zip | tar -xf- --to-stdout *time.csv")
)


Model:

library(lme4)
fit <- lmer(intimacy ~ time * treatment + (time | id), data = d)


This throws a warning, which reads:

Model failed to converge with max|grad| = 0.00398684 (tol = 0.002, component 1)


This model previously converged without issue when using lme4 1.1-15. In addition, it is able to converge when using a rescaled version of the time variable (time01 in the dataset, which changes the range from 0 to 1 instead of 1 to 15).

Any insight into what lme4 1.1-20 is doing differently?

Thanks.

Session Info:

R version 3.5.2 (2018-12-20)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: OS X El Capitan 10.11.6

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] lme4_1.1-20       Matrix_1.2-15     data.table_1.12.0

loaded via a namespace (and not attached):
[1] Rcpp_1.0.0      lattice_0.20-38 digest_0.6.18   MASS_7.3-51.1   grid_3.5.2      nlme_3.1-137
[7] evaluate_0.13   minqa_1.2.4     nloptr_1.2.1    rmarkdown_1.12  splines_3.5.2   tools_3.5.2
[13] xfun_0.5        yaml_2.2.0      compiler_3.5.2  htmltools_0.3.6 knitr_1.22


tl;dr this is a false positive; you can fix it by switching optimizers back to the old default or tightening tolerances slightly.

The lme4 NEWS file shows for version 1.1-20

• changed default optimizer to "nloptwrap" (BOBYQA implementation from the nloptr package) for lmer models. To revert to the old default, use control=lmerControl(optimizer="bobyqa")

(this is the only change relevant to this question).

The ?convergence man page points out that for the new nloptwrap optimizer,

• Changing ftol_abs and xtol_abs to stricter values (e.g. 1e-8) is a good first step for resolving convergence problems, at the cost of slowing down model fits.

Let's try these two approaches to check that this is a false-positive warning:

library(lme4)
## default settings (1.1-20)
fit <- lmer(intimacy ~ time * treatment + (time | id), data = d)
## switch back to pre-1.1-20 default optimizer
fit2 <- update(fit, control=lmerControl(optimizer="bobyqa"))
## tighten tolerances
fit3 <- update(fit, control=lmerControl(optCtrl=list(ftol_abs=1e-8,xtol_abs=1e-8)))


Neither of the latter two examples give convergence warnings.

How much do the estimates differ? Fixed effects:

cbind(fixef(fit2),fixef(fit3))-fixef(fit)
# [,1]          [,2]
# (Intercept)    -9.325873e-15 -4.618528e-14
# time            5.294376e-15  1.942890e-15
# treatment       1.398881e-14  2.489675e-14
# time:treatment -6.196432e-15 -6.106227e-16


The RE standard deviations and correlations differ much more, but probably still not enough to worry about:

ff <- function(x) {as.data.frame(VarCorr(x))\$sdcor}
cbind(ff(fit2),ff(fit3))-ff(fit)
# [,1]          [,2]
# [1,] -4.871044e-05 -2.082594e-05
# [2,]  8.250232e-06  5.907501e-06
# [3,] -5.482109e-05 -4.694410e-05
# [4,]  9.775125e-07  2.717170e-08


PS See ?troubleshooting, ?convergence, and ?allFit for more suggestions about dealing with lme4 problems.

PPS There's a good chance that we will tighten the default nloptwrap tolerances in a future release of lme4.

• Thank you so much, very helpful! I was able to reproduce these fixes no problem on my end. Thanks again.
– kz1
Apr 1, 2019 at 0:34