Dear list members, In re-running with GLMM() from the lme4 package a generalized-linear mixed model that I had previously fit with glmmPQL() from MASS, I'm getting a warning of a convergence failure, even when I set the method argument of GLMM() to "PQL":> bang.mod.1 <- glmmPQL(contraception ~ as.factor(children) + cage + urban,+ random=~as.factor(children) + cage + urban|district, + family=binomial, data=Bangladesh) # works!> bang.mod.1 <- GLMM(contraception ~ as.factor(children) + cage + urban,+ random=~as.factor(children) + cage + urban|district, + family=binomial, data=Bangladesh, method="PQL") Warning message: IRLS iterations for glmm did not converge in: GLMM(formula = contraception ~ as.factor(children) + cage + urban, Despite the indicated convergence failure, the two sets of estimates are quite close, as one would expect. I've also played around with various arguments to lmeControl(), but without success. I'm curious about the source of the difference, since (as I understand it), essentially the same algorithm is used by the two functions. I'm using R 2.0.1 under Windows XP with the current version of lme4. For anyone who's interested, the data are at <http://socserv.socsci.mcmaster.ca/jfox/Courses/soc761/Bangladesh.txt>, and are originally from Goldstein, Multilevel Statistical Models, Third Edition. Any suggestions would be appreciated. John -------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox
On Tuesday 23 November 2004 11:14, John Fox wrote:> Dear list members, > > In re-running with GLMM() from the lme4 package a generalized-linear > mixed model that I had previously fit with glmmPQL() from MASS, I'm > getting a warning of a convergence failure, even when I set the > method argument of > > GLMM() to "PQL": > > bang.mod.1 <- glmmPQL(contraception ~ as.factor(children) + cage + > > urban, > > + random=~as.factor(children) + cage + urban|district, > + family=binomial, data=Bangladesh) # works! > > > bang.mod.1 <- GLMM(contraception ~ as.factor(children) + cage + > > urban, > > + random=~as.factor(children) + cage + urban|district, > + family=binomial, data=Bangladesh, method="PQL") > Warning message: > IRLS iterations for glmm did not converge in: GLMM(formula > contraception ~ as.factor(children) + cage + urban,This dataset is also in lme4 as 'Contraception'.> Despite the indicated convergence failure, the two sets of estimates > are quite close, as one would expect. I've also played around with > various arguments to lmeControl(), but without success. > > I'm curious about the source of the difference, since (as I > understand it), essentially the same algorithm is used by the two > functions. I'm using R 2.0.1 under Windows XP with the current > version of lme4.Probably because the convergence criterion is different. glmmPQL has if (sum((eta - etaold)^2) < 1e-06 * sum(eta^2)) break GLMM has crit <- max(abs(eta - etaold)) / (0.1 + max(abs(eta))) ## use this to determine convergence if (crit < controlvals$tolerance) { conv <- TRUE break } I'm not sure why we chose that. Setting control = list(tolerance = 1e-3, PQLmaxIt = 100) converges for me, but that's probably a bit extreme. Deepayan
I was trying to install some more packages and ran into a problem
I hadn't seen before.
Version:
platform sparc-sun-solaris2.9
arch sparc
os solaris2.9
system sparc, solaris2.9
status
major 2
minor 0.1
year 2004
month 11
day 15
language R
Fortran compilers available to me:
f77: Sun WorkShop 6 update 2 FORTRAN 77 5.3 2001/05/15
f90: Sun WorkShop 6 update 2 Fortran 95 6.2 2001/05/15
f95: Sun WorkShop 6 update 2 Fortran 95 6.2 2001/05/15
Package:
gam
In fact I didn't ask for this one specifically, I had
"dependencies=TRUE" in a call to install.packages().
Problem:
Following the installation instructions for R, I had selected F95
as my Fortran compiler.
The f95 compiler complained about nearly every line of
gam/src/bsplvd.f
From the error messages as displayed on the screen, I could see no
reason for complaint. However, looking at the file with a text
editor immediately revealed the problem. The files
bsplvd.f bvalue.f bvalus.f loessf.f
qsbart.f sgram.f sinerp.f sslvrg.f
stxwx.f
all use CR-LF line termination. The files
linear.f lo.f splsm.f
all use LF line termination expected on UNIX.
It turns out that the g77 and f77 compilers don't mind CR at the
end of a line, but f90 and f95 hate them like poison.
Removing the CRs makes f90 and f95 happy again.
Second-order problem:
I know how to fix the immediate problem. What I don't know is how
to intervene in the installation process. What I need to do is
- get and unpack files (steps normally done by install.packages)
- make changes (remove CR, edit configuration, whatever)
- resume whatever install.packages normally does