Tutorials › Generalized Linear Mixed Models (GLMM) › Choosing GLMM Software for a Model Specification

Software and Case Studies · Tutorial 672 of 698

Choosing GLMM Software for a Model Specification

Learn how outcome type and required model features guide a practical choice among lme4, glmmTMB, and ordinal.

Intermediate 9 min read

What You'll Learn

  • Match binary and standard Poisson GLMM specifications to lme4.
  • Identify when glmmTMB features such as zero inflation or negative-binomial counts matter.
  • Recognize when an ordered response calls for ordinal’s cumulative-link mixed model.
  • Compare packages by outcome family and model features rather than by fitted results.
  • Check that the chosen package’s model matches the design and assumptions.

Choose the Model First, Then the Package

Choosing GLMM software is not a contest between packages. Start by specifying the response and the conditional distribution, link, and random-effects structure required by the scientific question. Then check which package implements that specification. A package being able to fit a model does not establish that the model is appropriate for the data.

The comparison here is limited to lme4, glmmTMB, and ordinal. It concerns the kinds of model each is suited to express, not which package produces a more favorable coefficient, p-value, or interval. Those are inferential results, and they are not a basis for choosing software.

Definition: A generalized linear mixed model (GLMM) specifies a conditional distribution for each response \(Y_{ij}\), given random effects \(b_j\), with a linear predictor that includes fixed effects and random effects. A common form is $$ g\{E(Y_{ij}\mid b_j)\} = x_{ij}^{\mathsf T}\beta + z_{ij}^{\mathsf T}b_j,\qquad b_j\sim N(0,\Sigma). $$ Here \(i\) indexes observations, \(j\) indexes clusters, \(g\) is the link function, \(\beta\) is the vector of fixed-effect coefficients, and \(\Sigma\) is the random-effects covariance matrix. The distribution, link, and random-effects structure are parts of the model specification, not merely software settings.

This general form assumes that the chosen conditional outcome distribution and link are suitable, that the random-effects distribution is adequately represented, and that observations are conditionally independent given the modeled effects and predictors, unless the model explicitly represents additional dependence. The data must also support estimating the requested terms. For example, a random slope requires meaningful within-cluster variation in its predictor; having software syntax for that slope does not guarantee it is estimable.

What the Three Packages Are Designed to Express

The packages overlap on some common models, but they are not interchangeable for every response family or model feature. The table is a practical orientation; package capabilities can depend on the particular model and software version, so verify the relevant documentation when a specification relies on a specialized feature.

PackageTypical fitUseful distinctionDo not assume
lme4Common binary and count GLMMs with random effects; also grouped binomial responsesA direct choice for standard specifications such as logistic or Poisson mixed modelsThat it provides dedicated zero-inflated or ordinal cumulative-link mixed models
glmmTMBCommon binary and count GLMMs, including negative-binomial and zero-inflated count specificationsUseful when the model needs features such as a zero-inflation component or a modeled dispersion structureThat every family or additional model component is appropriate for the data simply because it is available
ordinalCumulative-link mixed models for ordered categorical responsesDesigned for ordinal response modeling with random effects and a specified linkThat it is a general-purpose replacement for binary and count GLMM workflows

For lme4, the familiar function glmer expresses many standard generalized mixed models. Binary responses commonly use the binomial family and a logit link; counts commonly use the Poisson family and a log link. Grouped binomial data can be represented using successes and failures. The package is often a straightforward choice when these standard families and the required random-effects structure match the question.

glmmTMB also expresses common binary and count models, and is a natural candidate when a count specification requires features such as a negative-binomial family or a separate zero-inflation component. Such flexibility is not a diagnostic shortcut: a zero-inflated model, for example, asserts a particular two-part structure for the response and needs substantive and data-based justification.

ordinal provides cumulative-link mixed models for ordered categorical responses. For a logit link, a usual interpretation relies on a proportional-odds structure: predictor effects shift the cumulative log odds across outcome thresholds in a common way. This makes an ordered factor such as pain severity a different modeling target from an unordered set of labels. A binary outcome can be represented as ordered, but a standard binary GLMM is commonly handled directly with a binomial model instead.

A Practical Selection Rule

The package choice follows from the model specification in a simple sequence. First, identify whether the response is binary, a count, or ordered categorical. Second, identify the conditional distribution and link appropriate to that response. Third, list required features beyond the basic GLMM, such as zero inflation or a cumulative-link structure. Finally, check that the package implements those features together with the planned random effects.

1
Classify the response.
A binary outcome, event count, and ordered response encode different information and generally call for different conditional distributions.
2
Write the intended model.
State the family, link, fixed effects, random effects, and any additional component before choosing a function.
3
Check package support.
Use lme4 for a suitable standard GLMM, glmmTMB when its additional family or model components are needed, and ordinal for a cumulative-link mixed model.
4
Check fit and assumptions.
Confirm the response coding, convergence, data support, and model diagnostics; software availability is not evidence that assumptions hold.

This sequence is justified by the conditional likelihood the model needs to represent. For example, a count model with a separate zero-inflation component specifies more than a Poisson mean model: it allows a distinct process for structural zeros as well as a count process. An ordinal cumulative-link model instead represents probabilities of falling at or below ordered thresholds. A package choice that cannot express the required likelihood cannot implement the stated model, regardless of how convenient its syntax may be.

Worked Example: Binary Response with a Random Intercept

Suppose a hypothetical study records whether each of 360 patients experienced a binary event during follow-up. Patients are treated at 24 clinics, with 15 patients per clinic. The planned model has treatment group as a fixed predictor and a clinic random intercept. The outcome is coded 1 for event and 0 for no event.

The target is a conditional binomial model with a logit link:

$$ Y_{ij}\mid b_j\sim \operatorname{Bernoulli}(p_{ij}),\qquad \operatorname{logit}(p_{ij})=\beta_0+\beta_1\operatorname{Treatment}_{ij}+b_j,\qquad b_j\sim N(0,\sigma_b^2). $$

The package choice is lme4, using a binomial-family mixed model such as glmer(event ~ treatment + (1 | clinic), family = binomial, data = dat). The 24 clinics define the clustering for the random intercept, and the 360 patient-level rows define the binary responses. The arithmetic is \(24\times15=360\), consistent with the described balanced dataset.

This choice is appropriate if the binary coding is correct, the logit link and conditional Bernoulli model suit the question, and clinic-level clustering is the dependence structure being represented. Before fitting, check that treatment varies as intended and that the dataset has one valid outcome record per patient. If the response were instead a count, or the planned model needed a zero-inflation component, this would no longer be the same specification. No fitted coefficient or inferential result is needed to make this software decision.

Worked Example: Count Response Requiring a Zero-Inflation Component

Consider a hypothetical dataset with 80 participants observed monthly for 6 months, giving \(80\times6=480\) participant-month records. The response is a nonnegative event count per month. The investigators specify a negative-binomial count process and, for a substantive reason, a separate process that can produce additional zeros. Participant is included as a random intercept.

One possible model specification is

$$ Y_{ij}\mid b_j \sim \text{zero-inflated negative binomial},\qquad \log\{E(Y_{ij}\mid b_j,\text{count component})\} =\beta_0+\beta_1\operatorname{Exposure}_{ij}+b_j. $$

The package choice is glmmTMB, because the required specification includes both a negative-binomial count component and a zero-inflation component. A schematic formula is glmmTMB(count ~ exposure + (1 | participant), ziformula = ~ 1, family = nbinom2, data = dat). The model formula identifies the count predictor and participant intercept; the separate zero-inflation formula specifies an intercept-only zero-inflation component.

The choice depends on the stated model, not merely on observing many zeros. The analyst must check that the count outcome is nonnegative and correctly recorded, that the additional-zero process has a defensible interpretation, and that the repeated observations are represented appropriately. If excess zeros are not supported by the scientific setup or diagnostics, a simpler count model may be preferable. A zero-inflation option is not a remedy for any mismatch between model and data.

Worked Example: Ordered Response with a Clinic Random Effect

In a hypothetical pain study, 210 participants at 18 clinics report pain at a visit on an ordered four-level scale: none, mild, moderate, or severe. The planned analysis uses treatment as a fixed predictor and a clinic random intercept. The response is not a count of pain events; the ordering of the four categories is meaningful.

A cumulative-logit mixed model can be written as

$$ \operatorname{logit}\{P(Y_{ij}\leq k\mid b_j)\} =\theta_k-\{\beta_1\operatorname{Treatment}_{ij}+b_j\}, \qquad k=1,2,3,\qquad b_j\sim N(0,\sigma_b^2). $$

Here the three thresholds separate the four ordered categories. The package choice is ordinal, using a cumulative-link mixed model such as clmm(pain ~ treatment + (1 | clinic), data = dat, link = "logit"), with pain stored as an ordered factor in the intended level order.

The choice follows from the response structure: the outcome has ordered categories, and the planned model concerns cumulative probabilities at ordered thresholds. Check that the levels really are ordered as specified, that missing or invalid codes are handled before fitting, and that the proportional-odds structure is defensible for the intended interpretation. The 210 records across 18 clinics are consistent with the stated sample description; no coefficient estimates or package-specific inferential comparisons are needed to select the modeling framework.

Diagnostics, Alternatives, and Limitations

Package selection is only one part of a reliable analysis. First verify that the response has the representation required by the model. A binary outcome coded as text labels, a count imported as a continuous measurement, or an ordinal response whose levels are alphabetized rather than ordered can lead to an unintended analysis. Earlier material on response coding and family/link specification is directly relevant to these checks.

Then examine whether the model fit is behaving properly. Warning messages, nonconvergence, singular random-effects fits, or implausible parameter estimates call for investigation rather than automatic acceptance. Check whether there is adequate information for the fixed and random effects, whether the modeled distribution is plausible, and whether residual or predictive diagnostics reveal systematic mismatch. For a zero-inflated model, in particular, ask whether the extra-zero component addresses a plausible feature rather than masking a poor count model. For an ordinal model, check that category ordering and the cumulative-link assumptions match the scientific question.

The main alternative is often a simpler model within a package that already supports the response: for example, a standard binomial model rather than a more elaborate binary specification, or a standard count model rather than a model with extra components. Simplicity is useful when it matches the data-generating assumptions; it is not a reason to omit a required feature. Conversely, a more flexible package is not automatically a better choice. This tutorial does not compare estimates or inferential procedures across packages; the decision is based on whether the software can express the prespecified model.

All three packages have limitations. No package can compensate for a weak study design, inadequate cluster replication, incorrect outcome coding, or unsupported assumptions. Available syntax and defaults may also change across versions. When a model depends on specialized functionality, consult the package documentation and record the software details as part of the analysis workflow.

Common Mistakes

  • Choosing by habit alone. Familiarity matters for a reproducible workflow, but it does not justify using a package that cannot express the required outcome model.
  • Treating many zeros as proof of zero inflation. A high zero count is a reason to investigate model fit and the data-generating process, not sufficient justification for a separate zero-inflation component.
  • Ignoring the ordering of categories. An ordinal model needs a substantively correct order; a factor with accidental level order changes the model’s meaning.
  • Assuming package availability validates assumptions. A model fitting successfully does not prove its distribution, link, random-effects structure, or dependence assumptions are correct.
  • Selecting software by the most favorable result. Choosing a package after comparing p-values or estimates turns software selection into result shopping. Specify the model and selection criteria before examining fitted results.
Key takeaway: Match the software to a model specification made in advance. lme4 is a practical choice for many standard binary and count GLMMs, glmmTMB is useful when additional count-model components or families are needed, and ordinal is designed for cumulative-link mixed models with ordered responses.

Check Your Understanding

Answer each question by identifying the model feature that drives the software choice. Solutions follow the questions.

  1. A binary patient outcome is modeled with a logit link and a hospital random intercept. Which of the three packages is a straightforward choice, and what must be checked before fitting?
  2. A count outcome has a prespecified negative-binomial count component and a substantively justified separate zero-inflation component. Which package matches this specification?
  3. A response has four meaningful ordered categories, and the planned model uses cumulative logits with a site random intercept. Which package is designed for this model?
  4. Explain why a large observed number of zeros alone does not establish that a zero-inflated model is needed.
  5. Why should analysts avoid choosing a package by comparing which one gives the smallest p-value?

Solutions. (1) lme4 is a straightforward choice for a standard binary GLMM. Check response coding, the binomial-logit specification, clustering, and whether the random-intercept model is supported by the design. (2) glmmTMB, because the model requires both a negative-binomial count component and a separate zero-inflation component. (3) ordinal, which is designed for cumulative-link mixed models; verify the category order and the cumulative-link assumptions. (4) Many zeros may arise under a simpler count model or from other forms of model mismatch. A separate zero process needs substantive and diagnostic justification. (5) P-value-based selection uses inferential outcomes to choose the analysis after fitting, rather than selecting software to implement a prespecified model; it can encourage result-driven choices and does not establish model suitability.

Clinical Biostats