rpt.remlLMM(y, groups) causes R to crash
On 14-06-06 12:28 PM, AvianResearchDivision wrote:
Hi Ben, Thanks for the response. I'm sorry I didn't give you the heads up about r-forge. I messed around with 'nboot' and 'npermut' by decreasing from their defaults of 1000 to 10 and that allowed me to run it just fine. In general, what is the harm in straying away from these default parameters? Jacob
I don't think you've actually solved your problem this way, but you
have demonstrated that it's something having to do with a
computationally intensive workload, and not something intrinsic about
the code. That is, there's not something about running a single
bootstrap or permutation that will make your computer crash. (The other
thing to try is using small values of nboot/npermut, but re-running the
command many times to see if you can trigger a crash.) On the other
hand, computer-crashing bugs are usually *not* deterministic in this way
-- they often depend on some haphazard or not-easily-repeatable sequence
of interactions with the operating system ...)
My more basic question is whether you can make R crash by using the
examples with large values of nboot/npermut (in which case this is a
general issue) or not (in which case it seems like an interaction
between some quirk of your data and the software). I haven't looked
into what npermut/nboot are doing, but they're presuming computing some
sort of simulation-based p-values/confidence intervals; if you only run
a small number of replicates, then your estimates will be very coarse.
I'm guessing that the small values of nboot/npermut in the examples are
there so that people aren't accidentally running long/slow jobs when
they try out the examples, not that these values are really recommended
for production use. It *might* be possible to get the same answers by
running a large number of commands that each run a small number of
permutation/bootstrap samples and then assembling them, but that's
likely to be tricky.
Do you have the same kinds of problems if you run from a batch file
rather than from the Windows GUI?
I *was* going to say that we do know of a few memory-access issues
with lme4, but now that I remember that rpt.remlLMM uses lme and not
lmer, I can't see why that would matter ...
cheers
Ben Bolker
On Fri, Jun 6, 2014 at 10:54 AM, Ben Bolker <bbolker at gmail.com> wrote:
On 14-06-06 10:31 AM, AvianResearchDivision wrote:
Hi all, After running mixed models using 'lme4', I have moved on to calculating repeatabilities using the package 'rptR' on my data set. I have 879 observations over 59 individuals. I am using the calll rpt.remlLMM(y,groups) to obtain repeatabilities, but after about 15
seconds
I get a error stating: R for Windows GUI front-end has stopped working A problem caused the program to stop working correctly. Windows will
close
the program and notify you if a solution is available. I am running Windows 7 with a i3 processor and 4 gb of memory so I
wouldn't
expect this error to be computer performance related. I should note that I can run the rpt.aov(y,groups) call just fine. When running the following mixed model, I don't have any convergence issues: lmer(Response~Predictor+(Predictor|Individual)) Has anyone come across this issue or have any suggestions? Best, Jacob
(It would help to specify that rptR is available from r-forge: it took
me a few extra minutes to dig around and find it.)
For what it's worth, rpt.remlLMM appears to use nlme::lme (not
lme4::lmer) internally. There doesn't seem to be anything particularly
scary in the guts of the function (e.g. no calls to compiled code), so I
really haven't much of a clue. A reproducible example would probably be
helpful. (Probably worth checking with the package maintainer as well:
maintainer("rptR")).
Can you run the examples in ?rpt.remlLMM successfully? What if you
take those examples and bump up the number of permutation/bootstrap
replicates?
Ben Bolker