Skip to content

lme4 question

2 messages · Francis, David, Ben Bolker

#
I have an R/lme4 question that is vexing me, and I am hoping that you can provide some direction (even a hint at where I should look would be fine).

We have been using R and lme4 to extract variance components and BLUPs for quality traits from field trials of tomato.
There is a data set that I have been using for teaching purposes in my plant breeding class.  The data set is unbalanced and has some missing data such that 
there is only 1 level for one term in the model. 

When we first started using lme4, we were using R version 2.15.0

the model y  = lmer(BRIX~ (1|LINE) + (1|LOC) + (1|YEAR) + (1|REP%in%LOC:YEAR) + (1|LINE:LOC) + (1|LINE:YEAR))

was used to generate the variance components and to extract BLUPs for lines (different inbred lines, or varieties).

However with newer core packages, the model leads to an error (with the same data set as used above...)

Error in checkNlevels(reTrms$flist, n = n, control):
grouping factors must have > 1 sampled level


This error suggests that the model is over-parametrized; and if I drop the interaction REP%in%LOC:YEAR, I can again generate 
variance components and extract BLUPs.  The variance components for the remaining terms are identical to those obtained using 
R version 2.15.0.

If I reload R version 2.15.0 Plus adding the following 3 work packages to the library; lme4_0.999902344-0.zip; minqa_1.2.1.zip; Rcpp_0.9.10.zip the model works and estimates are the same as when 
we first started using the data set and R in class back in 2011.

The simple question (which probably isn't): what has changed with the core-package and or lme4 that the same data set is leading to an error in newer versions?

Thanks for any direction that you can provide.

Yours,

David
1 day later
#
On 14-05-08 08:34 PM, Francis, David wrote:
I thought I had answered this, but it must have slipped through the
cracks.
  If you look at the ?lmerControl manual page, you'll see the
check.nobs.vs.nlev (you may need check.nobs.vs.nRE as well, I don't
remember) which will allow you to override/bypass this check.

  The reason for this default is that, although there _are_ use cases
(such as yours) where the unidentifiability of the variance-covariance
matrix doesn't matter, people who specify these models most often (in my
experience) don't know they are doing it, and usually don't want to.

  hope that helps,
    Ben Bolker