modular {lme4} | R Documentation

## Modular Functions for Mixed Model Fits

### Description

Modular functions for mixed model fits

### Usage

    lFormula(formula, data = NULL, REML = TRUE, subset,
        weights, na.action, offset, contrasts = NULL,
        control = lmerControl(), ...)

    mkLmerDevfun(fr, X, reTrms, REML = TRUE, start = NULL,
        verbose = 0, control = lmerControl(), ...)

    optimizeLmer(devfun,
                 optimizer    = formals(lmerControl)$optimizer,
                 restart_edge = formals(lmerControl)$restart_edge,
                 boundary.tol = formals(lmerControl)$boundary.tol,
                 start = NULL, verbose = 0L,
                 control = list(), ...)

    glFormula(formula, data = NULL, family = gaussian,
        subset, weights, na.action, offset, contrasts = NULL,
        mustart, etastart, control = glmerControl(), ...)

    mkGlmerDevfun(fr, X, reTrms, family, nAGQ = 1L,
                  verbose = 0L, maxit = 100L, control = glmerControl(), ...)

    optimizeGlmer(devfun, optimizer = "bobyqa",
        restart_edge = FALSE,
        boundary.tol = formals(glmerControl)$boundary.tol,
        verbose = 0L, control = list(),
        nAGQ = 1L, stage = 1, start = NULL, ...)

    updateGlmerDevfun(devfun, reTrms, nAGQ = 1L)

### Arguments

`formula` | a two-sided linear formula object describing both the fixed-effects and random-effects parts of the model, with the response on the left of a `~` operator and the terms, separated by `+` operators, on the right. Random-effects terms are distinguished by vertical bars (`"|"`) separating expressions for design matrices from grouping factors.
`data` | an optional data frame containing the variables named in `formula`. By default the variables are taken from the environment from which `lmer` is called. While `data` is optional, the package authors strongly recommend its use, especially when later applying methods such as `update` and `drop1` to the fitted model (such methods are not guaranteed to work properly if `data` is omitted). If `data` is omitted, variables will be taken from the environment of `formula` (if specified as a formula) or from the parent frame (if specified as a character vector).
`REML` | (logical) indicating to fit restricted maximum likelihood model.
`subset` | an optional expression indicating the subset of the rows of `data` that should be used in the fit. This can be a logical vector, or a numeric vector indicating which observation numbers are to be included, or a character vector of the row names to be included. All observations are included by default.
`weights` | an optional vector of ‘prior weights’ to be used in the fitting process. Should be `NULL` or a numeric vector.
`na.action` | a function that indicates what should happen when the data contain `NA`s. The default action (`na.omit`, inherited from the 'factory fresh' value of `getOption("na.action")`) strips any observations with any missing values in any variables.
`offset` | this can be used to specify an a priori known component to be included in the linear predictor during fitting. This should be `NULL` or a numeric vector of length equal to the number of cases. One or more `offset` terms can be included in the formula instead or as well, and if more than one is specified their sum is used. See `model.offset`.
`contrasts` | an optional `list`. See the `contrasts.arg` of `model.matrix.default`.
`control` | a list giving for `[g]lFormula`: all options for running the model, see `lmerControl`; for `mkLmerDevfun,mkGlmerDevfun`: options for the inner optimization step; for `optimizeLmer` and `optimizeGlmer`: control parameters for nonlinear optimizer (typically inherited from the ... argument to `lmerControl`).
`fr` | A model frame containing the variables needed to create an `lmerResp` or `glmResp` instance.
`X` | fixed-effects design matrix
`reTrms` | information on random effects structure (see `mkReTrms`).
`start` | starting values (see `lmer`)
`verbose` | print output?
`maxit` | maximal number of Pwrss update iterations.
`devfun` | a deviance function, as generated by `mkLmerDevfun`
`nAGQ` | number of Gauss-Hermite quadrature points
`stage` | optimization stage (1: nAGQ=0, optimize over theta only; 2: nAGQ possibly >0, optimize over theta and beta)
`optimizer` | character - name of optimizing function(s). A character vector or list of functions: length 1 for `lmer` or `glmer`, possibly length 2 for `glmer`. The built-in optimizers are `"Nelder_Mead"` and `"bobyqa"` (from the minqa package). Any minimizing function that allows box constraints can be used provided that it takes input parameters `fn` (function to be optimized), `par` (starting parameter values), `lower` (lower bounds) and `control` (control parameters, passed through from the `control` argument) and returns a list with (at least) elements `par` (best-fit parameters), `fval` (best-fit function value), `conv` (convergence code) and (optionally) `message` (informational message, or explanation of convergence failure). Special provisions are made for `bobyqa`, `Nelder_Mead`, and optimizers wrapped in the optimx package; to use optimx optimizers (including `L-BFGS-B` from base `optim` and `nlminb`), pass the `method` argument to `optim` in the `control` argument. For `glmer`, if `length(optimizer)==2`, the first element will be used for the preliminary (random effects parameters only) optimization, while the second will be used for the final (random effects plus fixed effect parameters) phase. See `modular` for more information on these two phases.
`restart_edge` | see `lmerControl`
`boundary.tol` | see `lmerControl`
`family` | a GLM family; see `glm` and `family`.
`mustart` | optional starting values on the scale of the conditional mean; see `glm` for details.
`etastart` | optional starting values on the scale of the unbounded predictor; see `glm` for details.
`...` | other potential arguments; for `optimizeLmer` and `optimizeGlmer`, these are passed to internal function `optwrap`, which has relevant parameters `calc.derivs` and `use.last.params` (see `lmerControl`).

### Details

These functions make up the internal components of an [gn]lmer fit.

- `[g]lFormula` takes the arguments that would normally be passed to `[g]lmer`, checking for errors and processing the formula and data input to create a list of objects required to fit a mixed model.

- `mk(Gl|L)merDevfun` takes the output of the previous step (minus the `formula` component) and creates a deviance function

- `optimize(Gl|L)mer` takes a deviance function and optimizes over `theta` (or over `theta` and `beta`, if `stage` is set to 2 for `optimizeGlmer`

- `updateGlmerDevfun` takes the first stage of a GLMM optimization (with `nAGQ=0`, optimizing over `theta` only) and produces a second-stage deviance function

- `mkMerMod` takes the environment of a deviance function, the results of an optimization, a list of random-effect terms, a model frame, and a model all and produces a `[g]lmerMod` object.

### Value

`lFormula` and `glFormula` return a list containing components:

fr

  model frame

X

  fixed-effect design matrix

reTrms

  list containing information on random effects structure: result of `mkReTrms`

REML

  (lFormula only): logical indicating if restricted maximum likelihood was used (Copy of argument.)

`mkLmerDevfun` and `mkGlmerDevfun` return a function to calculate deviance (or restricted deviance) as a function of the theta (random-effect) parameters. `updateGlmerDevfun` returns a function to calculate the deviance as a function of a concatenation of theta and beta (fixed-effect) parameters. These deviance functions have an environment containing objects required for their evaluation. CAUTION: The `environment` of functions returned by `mk(Gl|L)merDevfun` contains reference class objects (see `ReferenceClasses`, `merPredD-class`, `lmResp-class`), which behave in ways that may surprise many users. For example, if the output of `mk(Gl|L)merDevfun` is naively copied, then modifications to the original will also appear in the copy (and vice versa). To avoid this behavior one must make a deep copy (see `ReferenceClasses` for details).

`optimizeLmer` and `optimizeGlmer` return the results of an optimization.

### Examples

    ### Fitting a linear mixed model in 4 modularized steps

    ## 1.  Parse the data and formula:
    lmod <- lFormula(Reaction ~ Days + (Days|Subject), sleepstudy)
    names(lmod)
    ## 2.  Create the deviance function to be optimized:
    (devfun <- do.call(mkLmerDevfun, lmod))
    ls(environment(devfun)) # the environment of 'devfun' contains objects
                            # required for its evaluation
    ## 3.  Optimize the deviance function:
    opt <- optimizeLmer(devfun)
    opt[1:3]
    ## 4.  Package up the results:
    mkMerMod(environment(devfun), opt, lmod$reTrms, fr = lmod$fr)

    ### Same model in one line
    lmer(Reaction ~ Days + (Days|Subject), sleepstudy)

    ### Fitting a generalized linear mixed model in six modularized steps

    ## 1.  Parse the data and formula:
    glmod <- glFormula(cbind(incidence, size - incidence) ~ period + (1 | herd),
    data = cbpp, family = binomial)
    names(glmod)
    ## 2.  Create the deviance function for optimizing over theta:
    (devfun <- do.call(mkGlmerDevfun, glmod))
    ls(environment(devfun)) # the environment of devfun contains lots of info
    ## 3.  Optimize over theta using a rough approximation (i.e. nAGQ = 0):
    (opt <- optimizeGlmer(devfun))
    ## 4.  Update the deviance function for optimizing over theta and beta:
    (devfun <- updateGlmerDevfun(devfun, glmod$reTrms))
    ## 5.  Optimize over theta and beta:
    opt <- optimizeGlmer(devfun, stage=2)
    opt[1:3]
    ## 6.  Package up the results:
    mkMerMod(environment(devfun), opt, glmod$reTrms, fr = glmod$fr)

    ### Same model in one line
    glmer(cbind(incidence, size - incidence) ~ period + (1 | herd),
          data = cbpp, family = binomial)

[Package lme4 version 1.1-12 Index]