rpt.remlLMM(y, groups) causes R to crash

Hi Ben,

Thank you again for the response and I apologize for my delay getting
back to you.  I tried running the example data from 'rptR' and got my
computer to crash by increasing npermut and nboot a bit, so it doesn't
seem it's necessarily an issue with my data, other than the fact that my
data might make it happen quicker.  I ran my data using rpt.anova and
mcmc instead of remlLMM and those run fine, so who knows what is going on.

I suppose I don't know what you mean by "Do you have the same kinds of
problems if you run from a batch file rather than from the Windows
GUI?"  I'm not overly competent in R, so I apologize for my lack of
understanding.


Jacob

On Fri, Jun 6, 2014 at 2:00 PM, Ben Bolker <bbolker at gmail.com
<mailto:bbolker at gmail.com>> wrote:

    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

    <mailto: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
    >>
    >>
    >>
    >>
    >>

    >