[R-sig-ME] rpt.remlLMM(y, groups) causes R to crash
bbolker at gmail.com
Fri Jun 6 20:00:35 CEST 2014
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?
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 ...
> 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
>>> 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
>>> 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
>>> 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:
>>> Has anyone come across this issue or have any suggestions?
>> (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:
>> Can you run the examples in ?rpt.remlLMM successfully? What if you
>> take those examples and bump up the number of permutation/bootstrap
>> Ben Bolker
More information about the R-sig-mixed-models