search

facebook / prophet

Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
https://facebook.github.io/prophet
MIT License
18.32k stars 4.52k forks source link

R prophet on MacOS Catalina #1639

Closed Kucharssim closed 3 years ago

Kucharssim commented 4 years ago

Hello,

tldr; tip for users of prophet on Catalina who cannot run prophet but their rstan is working: try install.packages("prophet", type = "source")

I am having issues with running prophet on Catalina - they are related to issues like https://github.com/facebook/prophet/issues/300, https://github.com/facebook/prophet/issues/1554, https://github.com/facebook/prophet/issues/1325, etc. Basically all the issues that seem somehow related to the recent problems of MacOS Catalina with RStan. However, I think I found some additional info (which I have not seen in the related issues yet). I hope it's useful.

Problem

library(prophet)
ds <- seq(as.Date('2005-04-01'), as.Date('2005-09-03'), by='day')
x <- (1:length(ds))/length(ds)
y <- rnorm(length(ds), x * (1 - x) + 0.5, 0.1)
m <- prophet(data.frame(ds = ds, y = y), daily.seasonality=TRUE, mcmc.samples = 0)
m <- prophet(data.frame(ds = ds, y = y), daily.seasonality=TRUE, mcmc.samples = 1000)

The MAP estimation gives me Error in sampler$call_sampler(c(args, dotlist)): empty_nested() must be true before calling recover_memory(), whereas MCMC gives me Error in matrix(m$params[[name]], nrow = n.iteration): 'data' must be of a vector type, was 'NULL'.

If I run:

m <- prophet(data.frame(ds = ds, y = y), daily.seasonality=TRUE, fit = FALSE)
debug(prophet::fit.prophet)
prophet::fit.prophet(m, data.frame(ds = ds, y = y), mcmc.samples = 1000)

and proceed until I get to fitting the model, I got the infamous Error in sampler$call_sampler(c(args, dotlist)) : c++ exception (unknown reason).

Some additional info

I had problems with rstan previously, but this has been solved on my computer for a while (and the test program at https://github.com/stan-dev/rstan/wiki/Catalina-problems works), so it was weird to see these issues.

So I exported the object that is used as the data argument inside fit.prophet() (the code to recreate the object is attached - create_stan_data.zip) and try to fit the model directly with rstan:

library(rstan)
source("create_stan_data.R")
stan_model <- prophet:::stanmodels$prophet
samples <- rstan::sampling(stan_model, stan_data, iter = 1000)

only to get c++ exception (unknown reason) again.

But again, my rstan is currently working fine with my models, not experiencing these exceptions issues, so I tried to recompile the model and run it:

library(rstan)
writeLines(prophet:::stanmodels$prophet@model_code, con = "prophet.stan")
stan_model <- rstan::stan_model("prophet.stan")
samples <- rstan::sampling(stan_model, stan_data, iter = 1000)

which worked just fine. So this lead me to believe there is something in the precompiled prophet model that causes these issues.

Solution and suggestion

Reinstalling prophet with install.packages("prophet", type = "source") solves the problem on my computer.

Now I am not sure whether this is stupid or not, but would it make sense to ensure that the prophet package is shipped with a freshly precompiled model? Perhaps that would solve this problem for people who do not have issues with rstan/Rcpp, but prophet does not work them?

sessionInfo

R version 3.6.3 (2020-02-29)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Catalina 10.15.4

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] prophet_0.6.1        rlang_0.4.7          Rcpp_1.0.5           rstan_2.19.3         ggplot2_3.3.0        StanHeaders_2.21.0-5

loaded via a namespace (and not attached):
 [1] pillar_1.4.6       compiler_3.6.3     prettyunits_1.1.1  tools_3.6.3        packrat_0.5.0      pkgbuild_1.1.0     lifecycle_0.2.0   
 [8] tibble_3.0.3       gtable_0.3.0       pkgconfig_2.0.3    cli_2.0.2          rstudioapi_0.11    parallel_3.6.3     loo_2.2.0         
[15] gridExtra_2.3      withr_2.2.0        dplyr_1.0.1        generics_0.0.2     vctrs_0.3.2        stats4_3.6.3       grid_3.6.3        
[22] tidyselect_1.1.0   glue_1.4.1         inline_0.3.15      R6_2.4.1           processx_3.4.3     fansi_0.4.1        purrr_0.3.4       
[29] callr_3.4.3        magrittr_1.5       codetools_0.2-16   scales_1.1.0       ps_1.3.4           ellipsis_0.3.1     matrixStats_0.56.0
[36] assertthat_0.2.1   colorspace_1.4-1   RcppParallel_5.0.1 munsell_0.5.0      crayon_1.3.4
bletham commented 4 years ago

Thanks for the really helpful analysis of the issue!

There have been some recent issues around upgrading package versions and having to install Prophet from source. For future reference with this class of issues, @seanjtaylor had some package version issues and found devtools::clean_dll() was helpful, and #1628 provided another possible workaround. More broadly, I'm not really sure what the broader solution is. We don't build the Mac OS binary ourselves, CRAN builds it. There's probably something we can do to avoid this issue besides requiring a source install, but we'll have to figure out still what that is.