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@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@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
> >>
> >>
> >>
> >>
> >>
> >
>
>

	[[alternative HTML version deleted]]

