seems stan returns the same error message regardless of where the bug occurs and whatever the bugs is. It looks like
rror in stanc(file = file, model_code = model_code, model_name = model_name, :
c++ exception (unknown reason)
Calls: stan -> stan_model -> stanc -> .Call
Execution halted
If I have a very extended model with hundreds of line spread over 10s of functions, is there a better way to find the bug like in a regular code development process?
ok, cmdstan does give me good compilation messages. The way I been doing it is like the tutorials where the model is embedded into an R code as a string, and I simply run the whole file in R. There, even the sessionInfo() doesn’t tell me anything about the stan compilation error.
Embedding in a string is a bad idea if you want to be able to line up error messages with the input program.
RStan 2.15 is broken in that it’s swallowing error messages if there’s a rejection/failure in evaluation of a block, and also swallowing all error messages during warmup. This is all fixed in Stan 2.16, and CmdStan 2.16 is out, but I don’t think RStan 2.16 has been released yet.
The other thing to be careful of is running in parallel. A lot of messages seem to get swallowed there, too, in RStan (I don’t think the RStan devs consider that a bug). So try to run in just one chain not in parallel (I can’t remember how to turn parallelism off, but I think it’s a global flag like a lot of things in R rather than a flag on the call to stan() or sampling()).
@Bob_Carpenter: these are Stan compilation errors that aren’t being reported, not the runtime errors. I’ve had this happen to me once and I reinstalled some combination of things and it went away. (I really should have tracked what I had installed at the time, but didn’t think to do it at the time.)
@bhomass, sessionInfo() is for us to help you figure out what’s wrong. Not to help get messages out. Mind pasting the result of that call here and we can file a bug report? Thanks!
You don’t need to rely on make. If you add to the path the location of stanc (inside the CmdStan home, then the bin folder), you can call the compiler directly. If you’re just looking for Stan syntax errors, then you won’t even need to compile the C++. An example use could be something like
stanc foo.stan
and it’ll translate the Stan program or tell you there are syntax errors. stanc is documented in the CmdStan manual and if you call stanc --help
that defeats the purpose of the post. To run make, I have to do it from the cmdStan install directory, which is what I want to avoid. I want to have some executable I can run from default path. maybe I have to create my own script then.
Why can’t you run make once using -n/–dry-run to find the command, and then use that command in your own script? The exact command that is used by a make file can depend on your system setup.
I don’t think anyone ever figured out how to get make to work from anywhere other than the base CmdStan directory. The file you’re compiling doesn’t have to be in the base directory, but you have to run from there.
@seantalts—feel free to try to sort this out! It’d be great if we could build from elsewhere.
I do not really use CmdStan, but these functions (put under .bashrc/.bash_profile) could do what is needed.
stan_make assumes that the last argument is the path where compiled model goes. stan_summary and stan_stanc also assume that they are compiled. stan_cmd can do make stuff without relative path real_path is really for osx that is missing the realpath function.
Then these functions can be called as stan_make ./bernoulli
Edit. I have not tested how this behaves if there are spaces in paths. If it will fail then the code needs some "".
real_path() {
[[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"
}
stan_path="<full_path_here>/cmdstan-2.16.0"
stan_make() {
local output_relative=${@: -1}
local head_args=${@:1:$#-1}
local output=$(real_path $output_relative)
make -C $stan_path $head_args $output
}
stan_summary() {
local summary="bin/stansummary"
local path=$stan_path/$summary
$path $@
}
stan_stanc() {
local stanc="bin/stanc"
local path=$stan_path/$stanc
$path $@
}
stan_cmd() {
make -C $stan_path $@
}
This just happened to me too. It would not surprise me if I have an error in the Stan code (I’m trying to modify Mitzi’s IAR example), but last time I used rstan my stupid mistakes gave useful errors rather than
Error in stanc(file = file, model_code = model_code, model_name = model_name, :
c++ exception (unknown reason)"
I then re-installed rstan from source and got the expected behaviour.
Session info (that generated the initial error) below.
sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.5
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.4/Resources/lib/libRlapack.dylib
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rstan_2.16.2 StanHeaders_2.16.0-1 ggplot2_2.2.1
loaded via a namespace (and not attached):
[1] Rcpp_0.12.11 grid_3.4.0 plyr_1.8.4 gtable_0.2.0
[5] stats4_3.4.0 scales_0.4.1 rlang_0.1.1 lazyeval_0.2.0
[9] tools_3.4.0 munsell_0.4.3 parallel_3.4.0 compiler_3.4.0
[13] inline_0.3.14 colorspace_1.3-2 gridExtra_2.2.1 tibble_1.3.3