Error: No tidy methods for objects of class glmerMod

[tomdrake]

When pooling glmer objects using mice 3.11, R produces an error:

Error: No tidy methods for objects of class glmerMod

Has been working in previous versions and just installed this fork of version 2.23:

devtools::install_github("bbolker/mice")

That works perfectly.

Reprex:

#1. Make data
data = data.frame(x1=c(rep("1",0.1*1000), rep("0",0.5*1000), 
                       rep("1",0.3*1000), rep("0",0.1*1000)), 
                  x2=c(rep("fact1",0.55*1000), rep("fact2",0.1*1000), 
                       rep(NA,0.05*1000), rep("fact3",0.3*1000)),
                  centre=c(rep("city1",0.1*1000), rep("city2",0.2*1000), 
                           rep("city3",0.15*1000), rep("city1",0.25*1000), 
                           rep("city2",0.3*1000)                          ))

# 2. set factors
data = sapply(data, as.factor)

# 3. mice imputation 
library(mice)
imp.data = mice(data, m=5, maxit= 5) 

# 4. apply the glmer function
library(lme4)
mice.fit = with(imp.data, glmer(x1~x2+(1|centre), family='binomial'))

# 5. pool imputations together
pooled.mi = pool(mice.fit)

[prockenschaub]

My suspicion is that at somepoint in the change from mice 2.x to mice 3.x, the pool function started relying on the tidy method from the broom package to get a nice tabular summary of the model coefficients and their uncertainties. tidy functions for multilevel mixed models like glmer are not part of the standard broom package, though, but instead live in broom.mixed.

Quick fix: install broom.mixed and run library(broom.mixed) before calling pool. This should load the necessary tidy.glmerMod function and fix the error.

Longterm: @stefvanbuuren @gerkovink could this be fixed with a conditional loading of broom.mixed if and only if a model is a multilevel model, or would your prefer to introduce a hard dependency on broom.mixed (or let the user deal with it like the quickfix above)?

[gerkovink]

Related #244 #245 #187

[gerkovink]

Technically, this issue is not related to mice, but to glmer.

@tomdrake Please be aware that Ben Bolker's mice fork of mice v2.23 is very outdated.

[prockenschaub]

For someone unfamiliar with how CRAN exactly works, is there a reason why a fix that was introduced in 3.9 hasn't made it into the CRAN version of 3.11 (as per #244) or did you choose not to add by default (as #245 might suggest). If the latter, does it make sense to document that somewhere in pool or capture that warning and suggest the fix as part of the warning?

[tomdrake]

Thanks for replies. I'm aware the fork is outdated, but it'd be good if mice loaded in the required packages if library(broom.mixed) is the issue

[gerkovink]

I am not sure if I agree. mice is imputation software and provides a means of collecting the parameter estimates for pooling via broom. If the developer for e.g. glmer - or anyone else - decides to provide these methods, then it is indeed easier to apply these methodologies on multiple imputed data.

The issue is not with mice in this case. This is quite often misunderstood. broom.mixed provides tidy and glance methods to convert fitted objects from various R mixed-model packages. These methods allow for the pooling of glmer models with mice through the broom convention.

I firmly believe that development of such methods should not be our job if we don't know these analysis methods and the implications of their assumptions for drawing valid inferences by heart. I am certainly not a fan of forcing mice users towards specific methodologies that we neither develop nor maintain.

[gerkovink]

I would propose to close this issue as it is not an issue with the code of mice.

@stefvanbuuren leaving this issue open for now because of @prockenschaub's questions:

For someone unfamiliar with how CRAN exactly works, is there a reason why a fix that was introduced in 3.9 hasn't made it into the CRAN version of 3.11 (as per #244) or did you choose not to add by default (as #245 might suggest). If the latter, does it make sense to document that somewhere in pool or capture that warning and suggest the fix as part of the warning?

I've given my $0.02 in the comment above

[stefvanbuuren]

Issue #244 solved a problem with broom.

I have put broom.mixed into Suggests: rather than Imports: because I need minimise the number of dependencies. My impression is that users of mixed models are technically quite advanced, and most will be able to figure out that they need library(broom.mixed) before pooling.

Automatic loading when the user fits a mixed model will put an extra task on my shoulders to keep track of changes of broom.mixed. I'd rather not have that.