I am attempting to install CmdStan via CmdStanR on a AWS Graviton2 instance running Ubuntu 20.04. install_cmdstan() happily runs until trying to compile one of the examples, failing with:
Shoot, Nix shouldn’t be giving any trouble. I don’t recognize that error. I can look into it tomorrow morning. The non-Nix instructions should also work but I don’t use them myself.
Thanks for taking a look. Unfortunately setting up dependencies via setup_dev_env.sh also fails:
[ERROR] The compilation of core failed at “/home/ubuntu/.opam/opam-init/hooks/sandbox.sh build jbuilder build -p core -j 31”.
Fatal error: exception (runtime-lib/runtime.ml.E “comparison failed”
((switch true) vs (switch false) (Loc src/config/discover.ml:205:15)))
Raised at file “src/configurator.ml”, line 511, characters 13-22
Called from file “src/config/discover.ml”, line 136, characters 2-1023
appears to have been more successful than nix-build. However, when compiling my Stan program, the compiler runs for some time and eventually ends with a seg fault. I guess running Stan on ARM is not an easy feat. This would be great to investigate further given the low cost of Graviton2 and Stan’s new within-chain parallelization.
The easiest fix here is to use stanc2. This won’t give you the latest features, but that compiles from the c++ sources. I think setting STANC2=true In make local suffices.
Thanks. Unfortunately the motivation for doing this on ARM/Graviton2 was to take advantage of the large multi-core setup and reduce_sum. Since reduce_sum was introduced in Stan 2.23 and stanc2 ended with the 2.22 release, I am assuming it is not available there.
reduce_sum is not available in stanc2. stanc2 is there to insure that models developed before 2.22 will be able to be compiled as before; it is slated for deprecation.
interesting idea - you’d need to build the exe file directly from the command line (i.e., using the CmdStan makefile outside of cmdstanr) - at which point you’d have a .stan and .exe file where latter is newer than the former and so it would skip the compile. might work - but what a PITA!
I set up a test with two AWS instances, one ARM and one x86. nix-build did fail on ARM, so I’ll have to work on that, but nix-shell “dune build” worked as you said.
But, after building with Nix, I was not able to replicate the segfault in stanc3 on ARM. I’m betting that issues was downstream of stanc3, is that possible @asceles? Unfortunately that would eliminate the hpp-copying solution.
It’s certainly possible. I am not using stanc3 directly but via CmdStan/CmdStanR. FWIW, the exact same model file compiles and works well on x86. It could be some interaction between CmdStan/CmdStanR and stanc3 causing the issue though.
stanc3 is a program which given a Stan program as an input file, parses the file and produces a C++ output file. e.g. stanc3 translates bernoulli.stan to bernoulli.hpp. that’s it. that C++ file is the same regardless of whatever platform is used to do the compilation, and is the same if you’re using CmdStan or any of the interfaces.
if you’ve got CmdStanR installed on AWS, then there should be a hidden folder $HOME/.cmdstanr - you’ll find the CmdStan install there - either $HOME/.cmstanr/cmdstan or $HOME/.cmdstanr/cmdstan-2.24.1 or similar. cd to this directory, and then try to compile from the command line. cf. example in the CmdStan manual here: 14 Parallelization | CmdStan User’s Guide
what exactly do you mean by x86 ? does it run multi-threaded?