Dealing with Catalina

coatless · October 9, 2019, 7:41pm

torkar · October 9, 2019, 7:51pm

I think I used make_stancode() and make_standata(). When I get to the hotel I’ll clean everything and make a fresh start :)

janhannig · October 9, 2019, 7:52pm

I have the same problem. I am using default clang (11.0.0) in default /Library/Developer/CommandLineTools/usr/bin

When running 4 chains the first runs through and the second gives me an error:

SAMPLING FOR MODEL ‘pareto_gfi’ NOW (CHAIN 1).
Chain 1:
Chain 1: Gradient evaluation took 0.000434 seconds
Chain 1: 1000 transitions using 10 leapfrog steps per transition would take 4.34 seconds.
Chain 1: Adjust your expectations accordingly!
Chain 1:
Chain 1:
Chain 1: Iteration: 1 / 2000 [ 0%] (Warmup)
Chain 1: Iteration: 200 / 2000 [ 10%] (Warmup)
Chain 1: Iteration: 400 / 2000 [ 20%] (Warmup)
Chain 1: Iteration: 600 / 2000 [ 30%] (Warmup)
Chain 1: Iteration: 800 / 2000 [ 40%] (Warmup)
Chain 1: Iteration: 1000 / 2000 [ 50%] (Warmup)
Chain 1: Iteration: 1001 / 2000 [ 50%] (Sampling)
Chain 1: Iteration: 1200 / 2000 [ 60%] (Sampling)
Chain 1: Iteration: 1400 / 2000 [ 70%] (Sampling)
Chain 1: Iteration: 1600 / 2000 [ 80%] (Sampling)
Chain 1: Iteration: 1800 / 2000 [ 90%] (Sampling)
Chain 1: Iteration: 2000 / 2000 [100%] (Sampling)
Chain 1:
Chain 1: Elapsed Time: 0.312213 seconds (Warm-up)
Chain 1: 0.291195 seconds (Sampling)
Chain 1: 0.603408 seconds (Total)
Chain 1:

SAMPLING FOR MODEL ‘pareto_gfi’ NOW (CHAIN 2).
Chain 2:
Chain 2: Gradient evaluation took 4.3e-05 seconds
Chain 2: 1000 transitions using 10 leapfrog steps per transition would take 0.43 seconds.
Chain 2: Adjust your expectations accordingly!
Chain 2:
Chain 2:
Chain 2: Iteration: 1 / 2000 [ 0%] (Warmup)
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " c++ exception (unknown reason)”
error occurred during calling the sampler; sampling not done
Stan model ‘pareto_gfi’ does not contain samples.

SAMPLING FOR MODEL ‘pareto_gfi’ NOW (CHAIN 1).
Chain 1: empty_nested() must be true before calling recover_memory()
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " empty_nested() must be true before calling recover_memory()”
error occurred during calling the sampler; sampling not done
Stan model ‘pareto_gfi’ does not contain samples.

SAMPLING FOR MODEL ‘pareto_gfi’ NOW (CHAIN 1).
Chain 1: empty_nested() must be true before calling recover_memory()
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " empty_nested() must be true before calling recover_memory()”
error occurred during calling the sampler; sampling not done
Stan model ‘pareto_gfi’ does not contain samples.
Error in { :
task 1 failed - “non-numeric argument to mathematical function”

I tried running only one chain and it ran fine. However, when I ran the chain for the second time I got the same error:

SAMPLING FOR MODEL ‘pareto_gfi’ NOW (CHAIN 1).
Chain 1:
Chain 1: Gradient evaluation took 4.1e-05 seconds
Chain 1: 1000 transitions using 10 leapfrog steps per transition would take 0.41 seconds.
Chain 1: Adjust your expectations accordingly!
Chain 1:
Chain 1:
Chain 1: Iteration: 1 / 2000 [ 0%] (Warmup)
Chain 1: Iteration: 200 / 2000 [ 10%] (Warmup)
Chain 1: Iteration: 400 / 2000 [ 20%] (Warmup)
Chain 1: Iteration: 600 / 2000 [ 30%] (Warmup)
Chain 1: Iteration: 800 / 2000 [ 40%] (Warmup)
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " c++ exception (unknown reason)”
error occurred during calling the sampler; sampling not done
Stan model ‘pareto_gfi’ does not contain samples.
Error in abs(k) : non-numeric argument to mathematical function

bgoodri · October 9, 2019, 7:58pm

My bad. It is make_stancode and make_standata in brms.

bgoodri · October 9, 2019, 8:34pm

Does this from upthread work for you?

torkar · October 9, 2019, 10:16pm

So, I’ve followed @coatless instructions and installed it all step-by-step. When I run the example I showed you before (using the function @bgoodri provided) the same error pops up when the sample starts. See output here:
output2.txt (60.0 KB)

I had to change Makevars to:

cat .R/Makevars 
# clang: start
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
# clang: end

in order for it to compile Armadillo.

coatless · October 9, 2019, 11:22pm

torkar:

I had to change Makevars to:

cat .R/Makevars 
# clang: start
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
# clang: end

in order for it to compile Armadillo.

This was listed inside of R Compiler Tools for Rcpp on macOS | The Coatless Professor

What exactly is new?

buyske · October 10, 2019, 1:58am

FWIW, I unthinkingly installed Catalina today, and, after running the rmacoslib/r-macos-rtools scripts,
library(rstan) # needs 2.19.x
example(stan_model, run.dontrun = TRUE)
works fine.

However, my rstanarm experience is not so happy:
mtcars$mpg10 <- mtcars$mpg / 10
fit <- stan_glm(
mpg10 ~ wt + cyl + am,
data = mtcars,
QR = TRUE,
# for speed of example only (default is “sampling”)
algorithm = “fullrank”
)
gives an
Error in sampler$call_sampler(c(args, dotlist)) :
empty_nested() must be true before calling recover_memory()
error.

bgoodri · October 10, 2019, 3:25am

Did you recompile rstanarm from source or is that the Mac binary from CRAN?

buyske · October 10, 2019, 4:37am

That was from the Mac binary from CRAN, but I just compiled rstanarm from source and had no problems. Thanks to this thread I can sleep easy tonight.

bgoodri · October 10, 2019, 5:27am

Well, that makes one of us.

torkar · October 10, 2019, 6:44am

I’ve recompiled RStan, Rcpp, RcppArmadillo, and brms, and still get this error. Are there any other packages I should try to recompile or any other checks I could make to try to find out what the problem might be?

torkar · October 10, 2019, 9:00am

you’re right, you have it on the page but I confused it with the post above so shot myself in the foot the first time when setting up Makevars. Now all is well and it’s set u with clang 7 and what not… Still doesn’t work though.

torkar · October 10, 2019, 2:55pm

@coatless, I’ve noticed something now when running everything again. Compiling Rcpp all looks well, but this happens when I compile RcppArmadillo:

checking whether g++ version is sufficient... almost
configure: WARNING: Compiler self-identifies as being compliant with GNUC extensions but is not g++.

and

checking LAPACK_LIBS... R-supplied partial LAPACK found
configure: WARNING: Some complex-valued LAPACK functions may not be available

The complete output from configure is here:

* installing *source* package ‘RcppArmadillo’ ...
** package ‘RcppArmadillo’ successfully unpacked and MD5 sums checked
** using staged installation
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether clang++ -std=gnu++11 accepts -g... yes
checking how to run the C++ preprocessor... clang++ -std=gnu++11 -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether clang++ -std=gnu++11 accepts -g... (cached) yes
checking whether g++ version is sufficient... almost
configure: WARNING: Compiler self-identifies as being compliant with GNUC extensions but is not g++.
checking for macOS... found
checking for macOS Apple compiler... not found
checking for clang compiler... found
checking for OpenMP compatible version of clang... found and suitable
checking LAPACK_LIBS... R-supplied partial LAPACK found
configure: WARNING: Some complex-valued LAPACK functions may not be available
checking for OpenMP... found and suitable
configure: creating ./config.status

coatless · October 10, 2019, 3:41pm

The warnings being displayed by the configure script have been around for a while. In short, they are nothing to worry about. The g++ warning is because we’re using clang instead of gcc and the LAPACK version is because we’re by default using a crippled LAPACK that ships with R – unless one compiles R from scratch with a link out to MKL et cetera.

For in-depth remarks, please see:

coatless · October 10, 2019, 3:42pm

How does it “not” work? I’m missing this part. Very difficult for me to troubleshoot if I do not know what isn’t working.

ssp3nc3r · October 10, 2019, 4:10pm

I’m having the same issues after installing Catalina, and after following @coatless instructions for setting up the tool chain. The issue,

[1] "Error in sampler$call_sampler(args_list[[i]]) : " " c++ exception (unknown reason)"

occurs after an apparent successful compile of the code and when in the sampling step.

If it helps, re-running the example post <- stan(...), results in a slightly different error,

Chain 1: empty_nested() must be true before calling recover_memory()
[1] "Error in sampler$call_sampler(args_list[[i]]) : "             
[2] "  empty_nested() must be true before calling recover_memory()"

The error from the example also occurs in my own Stan programs, so probably not unique to the example. Here’s the example in full from the posts above:

library(rstan); library(brms)

output <- c(0.5237868884927709,0.9487179487179488,0.5494563370710159,0.46386348238482383,0.4458125179443009,0.9830952380952381,0.9685185185185186,0.5118241235888294,0.8824457593688363,0.5644325518178729,0.6317411924119242,0.4893159632500718,0.9416071428571429,0.9145833333333333,0.4509011685482273,0.7682445759368836,0.2748216106014271,0.7207063008130081,0.6109249005373036,0.9156547619047619,0.9011574074074074,0.6936423054070112,0.9012820512820513,0.8805895344886171,0.7585789295392954,0.6982066978384808,0.9988095238095238,0.9606481481481481,0.7225985343632402,0.9347140039447732,0.7936459395174992,0.7401422764227643,0.7547029449161232,0.9897619047619047,0.9571759259259259,0.734383046147752,1.0,0.8722222222222221,0.6707232384823848,0.6119692588491038,1.0,1.0,0.5487621311150723,0.8960552268244577,0.6401885830784912,0.7439871273712737,0.6910643533899349,0.9875,0.9847222222222223,0.5955040602099425,0.9396449704142013,0.5083588175331294,0.6947069783197831,0.5883210286698658,0.9872023809523809,0.9643518518518519)
    categs<-as.factor(rep(c("FOO1","FOO2","FOO3","FOO4","FOO5","FOO6","FOO7","FOO8"),each=7));
    blocks <- c(1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7)
df1 <- data.frame(y=output, algorithm=as.integer(categs), block_id=blocks)

post <- stan(model_code = make_stancode(y ~ 1 + (1 | algorithm), data = df1),
                 data = make_standata(y ~ 1 + (1 | algorithm), data = df1), 
                 verbose = TRUE)

In the r environment, I’m using clang7:

> system("clang++ --version")
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /usr/local/clang7/bin

My .R/Makevars:

# clang: start
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
# clang: end

CXX14FLAGS=-O3 -march=native -mtune=native
CXX14FLAGS += -arch x86_64 -ftemplate-depth-256

Though I have also tried removing the CXX14 lines above.

My R version is 3.6.1, and rstan (and brms):

> library(rstan); library(brms)
Loading required package: StanHeaders
Loading required package: ggplot2
rstan (Version 2.19.2, GitRev: 2e1f913d3ca3)
For execution on a local, multicore CPU with excess RAM we recommend calling
options(mc.cores = parallel::detectCores()).
To avoid recompilation of unchanged Stan programs, we recommend calling
rstan_options(auto_write = TRUE)
Loading required package: Rcpp
Registered S3 method overwritten by 'xts':
  method     from
  as.zoo.xts zoo 
Loading 'brms' package (version 2.10.0). Useful instructions
can be found by typing help('brms'). A more detailed introduction
to the package is available through vignette('brms_overview').

Attaching package: ‘brms’

The following object is masked from ‘package:rstan’:

    loo

Here is the verbose dump.txt (61.8 KB) when executing stan() in the example above.

jonah · October 10, 2019, 6:01pm

I haven’t taken the risk to update to Catalina because I’ve needed to be running models on my laptop pretty consistently recently. Mac never used to be a problem for us but now that there have been issues with both Mojave and Catalina we should probably invest in a Mac computer that we can keep updating as soon as there’s a Mac update and just use that machine to test installation and compilation without worrying about messing up personal computers.

bgoodri · October 10, 2019, 6:40pm

@coatless this is affecting RStan and downstream packages because Stan branches on the type of exception being thrown but isn’t specific to RStan. We first encountered it with clang4 back in 2017 where doing

Rcpp::sourceCpp(code = 
'
#include <Rcpp.h>
using namespace Rcpp; 

// [[Rcpp::export]]
int throw_exception() { 
  std::stringstream errmsg; errmsg << "this is an exception";
  throw std::domain_error(errmsg.str()); 
  return 0;
}
'
)

throw_exception()

would yield

Error in throw_exception() : c++ exception (unknown reason)

rather than

Error in throw_exception() : this is an exception

We worked around this problem with clang4 from AT&T in RStan with a variation of a hack from Kevin Ushey that became popular:

github.com

stan-dev/rstan/blob/develop/rstan/rstan/R/cxxfunplus.R#L188


      
              !identical(Sys.getenv("R_PACKAGE_SOURCE"), "") )
          if (!isTRUE(verbose)) {
            sink(type = "output")
            close(zz)
            try(file.remove(tf), silent = TRUE)
            on.exit(NULL)
          }
          dso_last_path <- dso_path(fx)
          if (grepl("^darwin", R.version$os) && grepl("clang", get_CXX(FALSE))) {
            CLANG_DIR = tail(n = 1, grep("clang[456789]", value = TRUE,
                                         x = list.dirs("/usr/local", recursive = FALSE)))
            Rv <- R.version
            GOOD <- file.path("/Library", "Frameworks", "R.framework", "Versions",
                              paste(Rv$major, substr(Rv$minor, 1, 1), sep = "."),
                              "Resources", "lib", "libc++.1.dylib")
            if (length(CLANG_DIR) == 1L && file.exists(GOOD)) {
              cmd <- paste("install_name_tool", "-change", CLANG_DIR, GOOD, dso_last_path)
              system(cmd)
              dyn.unload(dso_last_path)
              dyn.load(dso_last_path)
            }

to relink against XCode’s C++ library. But CRAN was never too happy about that.

I’m pretty sure we confirmed that the problem went away with clang6, but now it seems to be back with clang7 and / or Catalina. Do you have any ideas besides applying our previous hack again?

coatless · October 10, 2019, 6:40pm

From running:

ssp3nc3r:

library(rstan); library(brms)

output <- c(0.5237868884927709,0.9487179487179488,0.5494563370710159,0.46386348238482383,0.4458125179443009,0.9830952380952381,0.9685185185185186,0.5118241235888294,0.8824457593688363,0.5644325518178729,0.6317411924119242,0.4893159632500718,0.9416071428571429,0.9145833333333333,0.4509011685482273,0.7682445759368836,0.2748216106014271,0.7207063008130081,0.6109249005373036,0.9156547619047619,0.9011574074074074,0.6936423054070112,0.9012820512820513,0.8805895344886171,0.7585789295392954,0.6982066978384808,0.9988095238095238,0.9606481481481481,0.7225985343632402,0.9347140039447732,0.7936459395174992,0.7401422764227643,0.7547029449161232,0.9897619047619047,0.9571759259259259,0.734383046147752,1.0,0.8722222222222221,0.6707232384823848,0.6119692588491038,1.0,1.0,0.5487621311150723,0.8960552268244577,0.6401885830784912,0.7439871273712737,0.6910643533899349,0.9875,0.9847222222222223,0.5955040602099425,0.9396449704142013,0.5083588175331294,0.6947069783197831,0.5883210286698658,0.9872023809523809,0.9643518518518519)
    categs<-as.factor(rep(c("FOO1","FOO2","FOO3","FOO4","FOO5","FOO6","FOO7","FOO8"),each=7));
    blocks <- c(1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6,7)
df1 <- data.frame(y=output, algorithm=as.integer(categs), block_id=blocks)

post <- stan(model_code = make_stancode(y ~ 1 + (1 | algorithm), data = df1),
                 data = make_standata(y ~ 1 + (1 | algorithm), data = df1), 
                 verbose = TRUE)

I’m getting:

CHECKING DATA AND PREPROCESSING FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW.

COMPILING MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW.

STARTING SAMPLER FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW.

SAMPLING FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW (CHAIN 1).
Chain 1: 
Chain 1: Gradient evaluation took 2.5e-05 seconds
Chain 1: 1000 transitions using 10 leapfrog steps per transition would take 0.25 seconds.
Chain 1: Adjust your expectations accordingly!
Chain 1: 
Chain 1: 
Chain 1: Iteration:    1 / 2000 [  0%]  (Warmup)
Chain 1: Iteration:  200 / 2000 [ 10%]  (Warmup)
Chain 1: Iteration:  400 / 2000 [ 20%]  (Warmup)
Chain 1: Iteration:  600 / 2000 [ 30%]  (Warmup)
Chain 1: Iteration:  800 / 2000 [ 40%]  (Warmup)
Chain 1: Iteration: 1000 / 2000 [ 50%]  (Warmup)
Chain 1: Iteration: 1001 / 2000 [ 50%]  (Sampling)
Chain 1: Iteration: 1200 / 2000 [ 60%]  (Sampling)
Chain 1: Iteration: 1400 / 2000 [ 70%]  (Sampling)
Chain 1: Iteration: 1600 / 2000 [ 80%]  (Sampling)
Chain 1: Iteration: 1800 / 2000 [ 90%]  (Sampling)
Chain 1: Iteration: 2000 / 2000 [100%]  (Sampling)
Chain 1: 
Chain 1:  Elapsed Time: 0.227319 seconds (Warm-up)
Chain 1:                0.108264 seconds (Sampling)
Chain 1:                0.335583 seconds (Total)
Chain 1: 

SAMPLING FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW (CHAIN 2).
Chain 2: 
Chain 2: Gradient evaluation took 1.4e-05 seconds
Chain 2: 1000 transitions using 10 leapfrog steps per transition would take 0.14 seconds.
Chain 2: Adjust your expectations accordingly!
Chain 2: 
Chain 2: 
Chain 2: Iteration:    1 / 2000 [  0%]  (Warmup)
Chain 2: Iteration:  200 / 2000 [ 10%]  (Warmup)
Chain 2: Iteration:  400 / 2000 [ 20%]  (Warmup)
Chain 2: Iteration:  600 / 2000 [ 30%]  (Warmup)
Chain 2: Iteration:  800 / 2000 [ 40%]  (Warmup)
Chain 2: Iteration: 1000 / 2000 [ 50%]  (Warmup)
Chain 2: Iteration: 1001 / 2000 [ 50%]  (Sampling)
Chain 2: Iteration: 1200 / 2000 [ 60%]  (Sampling)
Chain 2: Iteration: 1400 / 2000 [ 70%]  (Sampling)
Chain 2: Iteration: 1600 / 2000 [ 80%]  (Sampling)
Chain 2: Iteration: 1800 / 2000 [ 90%]  (Sampling)
Chain 2: Iteration: 2000 / 2000 [100%]  (Sampling)
Chain 2: 
Chain 2:  Elapsed Time: 0.207346 seconds (Warm-up)
Chain 2:                0.114258 seconds (Sampling)
Chain 2:                0.321604 seconds (Total)
Chain 2: 

SAMPLING FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW (CHAIN 3).
Chain 3: 
Chain 3: Gradient evaluation took 1.2e-05 seconds
Chain 3: 1000 transitions using 10 leapfrog steps per transition would take 0.12 seconds.
Chain 3: Adjust your expectations accordingly!
Chain 3: 
Chain 3: 
Chain 3: Iteration:    1 / 2000 [  0%]  (Warmup)
Chain 3: Iteration:  200 / 2000 [ 10%]  (Warmup)
Chain 3: Iteration:  400 / 2000 [ 20%]  (Warmup)
Chain 3: Iteration:  600 / 2000 [ 30%]  (Warmup)
Chain 3: Iteration:  800 / 2000 [ 40%]  (Warmup)
Chain 3: Iteration: 1000 / 2000 [ 50%]  (Warmup)
Chain 3: Iteration: 1001 / 2000 [ 50%]  (Sampling)
Chain 3: Iteration: 1200 / 2000 [ 60%]  (Sampling)
Chain 3: Iteration: 1400 / 2000 [ 70%]  (Sampling)
Chain 3: Iteration: 1600 / 2000 [ 80%]  (Sampling)
Chain 3: Iteration: 1800 / 2000 [ 90%]  (Sampling)
Chain 3: Iteration: 2000 / 2000 [100%]  (Sampling)
Chain 3: 
Chain 3:  Elapsed Time: 0.193264 seconds (Warm-up)
Chain 3:                0.112713 seconds (Sampling)
Chain 3:                0.305977 seconds (Total)
Chain 3: 

SAMPLING FOR MODEL '4bd718ce37045da5116c1e4a2933dbfb' NOW (CHAIN 4).
Chain 4: 
Chain 4: Gradient evaluation took 1.3e-05 seconds
Chain 4: 1000 transitions using 10 leapfrog steps per transition would take 0.13 seconds.
Chain 4: Adjust your expectations accordingly!
Chain 4: 
Chain 4: 
Chain 4: Iteration:    1 / 2000 [  0%]  (Warmup)
Chain 4: Iteration:  200 / 2000 [ 10%]  (Warmup)
Chain 4: Iteration:  400 / 2000 [ 20%]  (Warmup)
Chain 4: Iteration:  600 / 2000 [ 30%]  (Warmup)
Chain 4: Iteration:  800 / 2000 [ 40%]  (Warmup)
Chain 4: Iteration: 1000 / 2000 [ 50%]  (Warmup)
Chain 4: Iteration: 1001 / 2000 [ 50%]  (Sampling)
Chain 4: Iteration: 1200 / 2000 [ 60%]  (Sampling)
Chain 4: Iteration: 1400 / 2000 [ 70%]  (Sampling)
Chain 4: Iteration: 1600 / 2000 [ 80%]  (Sampling)
Chain 4: Iteration: 1800 / 2000 [ 90%]  (Sampling)
Chain 4: Iteration: 2000 / 2000 [100%]  (Sampling)
Chain 4: 
Chain 4:  Elapsed Time: 0.184546 seconds (Warm-up)
Chain 4:                0.110832 seconds (Sampling)
Chain 4:                0.295378 seconds (Total)
Chain 4: 
Warning: There were 5 divergent transitions after warmup. Increasing adapt_delta above 0.8 may help. See
http://mc-stan.org/misc/warnings.html#divergent-transitions-after-warmup
Warning: Examine the pairs() plot to diagnose sampling problems

Maybe the data is bad?

Topic		Replies	Views
Update MacOS to Catalina or Mojave for least problems with Stan-based software? RStan installation	20	1580	December 13, 2020
Installing RStan on Mojave Mac OS X -missing step on C++ toolchain General	4	969	February 20, 2019
Dealing with Mojave RStan rstan	5	2713	October 7, 2019
MacOS RStan	10	1578	November 2, 2022
Problem with C++ Compiler on Mac RStan	2	2278	October 27, 2018

Dealing with Catalina

Related Topics