memory allocation error with ggeffect, ggpredict about ggeffects

[emjonaitis]

Thanks for the reminder - I’ll check when I get into work today.

…

On Fri, Jun 29, 2018 at 6:17 AM Daniel ***@***.***> wrote: I'd be happy if someone who still had problems with memory allocation errors, could check the current GitHub-version. It automatically should calculate a reasonable pretty range of predicted values and should be much more memory efficient when calculating SE/CI for predictions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABgtYp6SI1SXVu2Gmq1FuXvJx2WbtGSNks5uBgzEgaJpZM4TIy2R> .

[richardneilbelcher]

I just had a similar issue with the ggpredict function. Setting ci.lvl = NA made it work without the vector allocation error (although ggeffect worked for me). With other lme4 prediction tools they can use some intensive methods for degrees of freedom calculations so that may be it.

[strengejacke]

If one of the terms is continuous, try to specify some values, e.g. terms = "cont_var [10, 20, 30, 40, 50]", if cont_var ranges from 10 to 50. I use expand.grid() on all possible values, and computation of CI might be very memory consuming in such cases. The effects package, by default, does not compute effects and CI for all possible values, but for a selection only.

[strengejacke]

Could you please check if this issue still exists in the current dev-version? I have added a pretty argument, which creates a sequence of "pretty" numbers for predictor terms with many unique values.

[strengejacke]

Since pretty does not plot splines nicely, I've changed the default to pretty = FALSE. So, if possible, please check if ggpredict(..., pretty = TRUE) solves your issue.

[vspinu]

I am having same issue with ggeffects::ggalleffects which blows to 15GB for 64k row x 9col data set. ggeffects::predict doesn't work for me because I have sales(forecast) term in my formula:

> labels(terms(M))
 [1] "error"               "scale(forecast)"     "error2"             
 [4] "waste1"              "waste2"              "sales"              
 [7] "family"              "scale(transactions)" "cluster"            
[10] "aweek"               "year"                "holid_nat"          
> ggeffects::ggpredict(M, labels(terms(M)), pretty = T)
`terms` must have not more than three values. Using first three values now.
Error in scale(forecast, center = 276.325019004872, scale = 375.963889410209) : 
  object 'forecast' not found

The above works just fine with the effects package.

[strengejacke]

Try to standardise the variable before you fit the model, does this work?

[vspinu]

they are standardized. Sorry, I haven't provided the model formula:

waste ~ error + scale(forecast) + error2 + waste1 + waste2 + 
    sales + family + scale(transactions) + cluster + aweek + 
    year + holid_nat

I expect this error has something to do with the inline scale(forecast).

[strengejacke]

Yes, please standardize before, and don't use "inline" calls to functions. And it's preferred to use sjmisc::std(), because scale() changes the input type.

[vspinu]

Yes, please standardize before, and don't use "inline" calls to functions.

Yerh, one too many restriction; I guess I would stay away then. All other standard R software works with "inline" functions and doesn't require standardization (effects package including). But well, every package is different ;)

As a side note, subsampling or pretty=TRUE should be the default. The splines issue is really not an excuse to blow people's R sessions during basic plotting (especially with small data sets).

[strengejacke]

Actually, ggpredict() should work with the the inline-use of functions, however, the term-argument must use the original term names. So term = "forecast" should work, while labels(terms(M)) returns scale(forecast).

Your argument is translated to predict(M, newdata = data.frame('scale(forecast)' = ...)), which causes the error.

[strengejacke]

@emjonaitis and @richardneilbelcher do you still have the memory allocation issues if you set pretty = TRUE? I think I will indeed make this as default option, and print a message if prettifying was done, so the user is not too curious about less smoothed plots.

[emjonaitis]

Hi Daniel - thanks for your patience. I finally made time to test this -- it's taking a very long time to chug through, so although I don't have a definitive answer I'm going to tentatively say, "not really." I'll write more Monday if this pessimism turns out to be unwarranted.

…

On Wed, May 2, 2018 at 9:38 AM, Daniel ***@***.***> wrote: @emjonaitis <https://github.com/emjonaitis> and @richardneilbelcher <https://github.com/richardneilbelcher> do you still have the memory allocation issues if you set pretty = TRUE? I think I will indeed make this as default option, and print a message if prettifying was done, so the user is not too curious about less smoothed plots. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABgtYpHyfTewuSdzcP_04sPoxKAIlXh_ks5tucTcgaJpZM4TIy2R> .

[emjonaitis]

Ah - it finally stopped chugging and indeed, the problem was not solved. Erin

…

On Fri, May 4, 2018 at 4:21 PM, Erin Jonaitis ***@***.***> wrote: Hi Daniel - thanks for your patience. I finally made time to test this -- it's taking a very long time to chug through, so although I don't have a definitive answer I'm going to tentatively say, "not really." I'll write more Monday if this pessimism turns out to be unwarranted. On Wed, May 2, 2018 at 9:38 AM, Daniel ***@***.***> wrote: > @emjonaitis <https://github.com/emjonaitis> and @richardneilbelcher > <https://github.com/richardneilbelcher> do you still have the memory > allocation issues if you set pretty = TRUE? I think I will indeed make > this as default option, and print a message if prettifying was done, so the > user is not too curious about less smoothed plots. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#22 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABgtYpHyfTewuSdzcP_04sPoxKAIlXh_ks5tucTcgaJpZM4TIy2R> > . >

[strengejacke]

I revised the calculation for CI for mixed models, which now should be more efficient. When you now either use:

ggpredict(model, term = "myterm", pretty = TRUE)

or

ggpredict(model, term = "myterm [range]") # should really be "range", this is no placeholder

does one of these two options solve your issue? This requires the current GitHub-version of ggeffects.

[strengejacke]

@vspinu If you want to plot effects for all model terms, you can now simply leave the terms argument missing or NULL, so just calling ggeffects::ggpredict(M) should work, and is comparable (regarding the effort) to allEffects(M).

[strengejacke]

I'd be happy if someone who still had problems with memory allocation errors, could check the current GitHub-version. It automatically should calculate a reasonable pretty range of predicted values and should be much more memory efficient when calculating SE/CI for predictions.

[strengejacke]

bump

[emjonaitis]

Hi Daniel - yes, I am still getting out of memory errors ("Error: cannot allocate vector of size 84619.5 Gb"). To clarify, do I need to be working with a branch of the code other than master? Currently I'm just running devtools::install_github("strengejacke/ggeffects") with no other arguments set but please let me know if I need to be doing something different. Erin

…

On Wed, Jul 18, 2018 at 4:48 AM, Daniel ***@***.***> wrote: *bump* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABgtYnBG51Fm0lEi_UdxwxhmalDv1hqZks5uHwRrgaJpZM4TIy2R> .

[strengejacke]

No, it's the correct version you are using, either the master branch or the current GitHub version should be more memory efficient.
When you run ggpredict(), does it display a message about prettifying the values?

[emjonaitis]

Yes, it does display that message. Actually, if I save the output of ggpredict() as an object I am now able to plot that object and modify it using ggplot2 commands. So we're part of the way there. I definitely still can't get ggeffect() working, though. I've now modified my code to work with a limited set of the grouping and faceting variables (using the [meansd] shortcut) and that works with ggpredict() but still not ggeffect(). Hope that helps clarify the issue, Erin

…

On Thu, Jul 19, 2018 at 2:09 AM, Daniel ***@***.***> wrote: No, it's the correct version you are using, either the master branch or the current GitHub version should be more memory efficient. When you run ggpredict(), does it display a message about prettifying the values? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABgtYlJ3jGZ39EgNa9nvBNIyaW15KQyeks5uIDCYgaJpZM4TIy2R> .

[strengejacke]

Thanks for looking into this. ggeffect() calls effects::effect(), so it might be an issue of the effects package. I'll try to find out where the issue is located.

[strengejacke]

I just realized that ggeffect() is not optimized, it only applies to ggpredict(). ggeffect() was a bit neglected by me, and I was always thinking of ggpredict() when talking about this issue. 🙄

[strengejacke]

Ok, memory allocation problems with ggeffect() should also be solved now.

[emjonaitis]

Just closing the loop on this - it works like a charm now. Thanks for all your work on this project. I have been wanting/needing modifiable effects plots and I think this will be my answer. Erin Jonaitis

…

On Tue, Jul 24, 2018 at 8:14 AM, Daniel ***@***.***> wrote: Ok, memory allocation problems with ggeffect() should also be solved now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABgtYtG72DfT5qWx6CMG0ELl28FfNRbcks5uJx2YgaJpZM4TIy2R> .