suppress all output from RStan #49
Comments
|
Thank you for posting this, Bob. --Avraham |
|
Those error messages are from Stan's c++ code. Which one of standard output and standard error output ( |
|
@maverickg, it's now piped to Rcpp::Rcout. Let me find the lines that we control that. |
|
@aadler, do you have a simple example script that I can try? I have the latest and greatest RStan installed and could see if the refactoring fixed this issue. |
|
Let me see what I can extract from my .Rnw. I'll send it to you offline once I have something. |
|
The optimizing() function in RStan also has this issue -- even with verbose=FALSE, it still prints out a stream of progress messages and parameter settings. I have an application in which I typically run around 1000 calls to optimizing(), each of which takes a few seconds; the voluminous output this produces is a real annoyance. |
|
Personally, I've resorted to just kniting the .Rnw and then open the resulting .tex file in Winedt and deleting all those statements. As things go, it's a minor annoyance which I can live with, although I certainly would appreciate damping them. Dr. Denwood of runjags was able to dampen all output after I asked a while ago, maybe he has an idea? Then again, runjags is MUCH simpler than stan and lives completely within R, so there probably isn't much comparison. Avi |
|
We'll get this fixed soon. We're taking it on The problem is not in RStan, but in the C++ API for Stan itself.
|
|
PR #154 partly addresses the issue. |
|
this is my reminder to fix this after the refactor. |
|
hi, AMPLING FOR MODEL 'test_par_est' NOW (CHAIN 1). Chain 1, Iteration: 1 / 10000 0% Camlionur |
|
@camlionur You can just set refresh to zero. Like below. |
|
@jscamac Do you know how I can suppress the sampling message in rstan::sampling()? |
|
@cathyleeyy I'm presuming you are referring to the types of diagnostic messages that occur during sampling. The same messages that @bob-carpenter and @aadler are referring to at the start of this issue? If so then no... this is still a work in progress I think. |
|
refresh=-1 will suppress those updates, but there's still a bit We should get the rest suppressed soon.
|
|
Thank you so much for your help. Date: Wed, 13 Apr 2016 09:26:33 -0700 refresh=-1 will suppress those updates, but there's still a bit of output trickling through. We should get the rest suppressed soon.
— |
|
Thanks a lot for your help. Date: Tue, 12 Apr 2016 15:08:08 -0700 You can just set refresh to zero. Like below. i.e. fit <-list(stan_data = stan_data, — |
|
Hi, |
|
What I do is run the code live in my Rmd file, I set the model fitting chunk to For instance: |
|
Or you can do results = "hide", cache = TRUE in the chunk header
…On Jun 27, 2017 8:32 PM, "Anders Goncalves da Silva" < ***@***.***> wrote:
What I do is run the code live in my Rmd file, I set the model fitting
chunk to eval=FALSE, save the output to an Rdata object, and in a hidden
chunk I load it back. That way, I don't have to wait for the model to run
when knitting the file.
For instance:
```{r, fit_stan, eval = FALSE}
model_code <- "model code goes here"
model_data <- list( model data )
model_fit <- rstan::stan(...)
save(model_fit, "model_fit.Rdata")
```
```{r, load_model_fit, echo = FALSE}
load("model_fit.Rdata")
```
```{r, model_summary}
print(model_fit, digit_summary=3)
```
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADOrqn0Y0-4RaNb21UznEyM4owiG7W_mks5sIUrWgaJpZM4BjPMs>
.
|
|
Are there any updates on this (and for pystan rather than rstan)? I'm trying to use FB Prophet in custom code where stdout is directly streamed to a Hive table, and therefore I need to suppress only the pystan output (rather than suppressing all stdout). Any updates on this would be greatly, greatly appreciated!! |
|
@bgoodri or @ariddell --- any idea if this is Is this an RStan issue in particular or is there something we need to do down at the Stan level? I know we'll tackle this in Stan 3, but it'd be nice to get a temporary fix in through the low-level services if that's where it needs to be done. If so, this issue should be moved to |
|
@isabelmgao Streaming stdout to a table seems dicey in any situation. I'm not sure if PyStan (or Prophet) lets you stream the draws to a CSV file, but it'd be safer to take that stream as output. |
|
This is a configuration issue at the RStan / PyStan level. We should be
able to write a logger that doesn't output anything and that'll do it. It's
a matter of how to specify that option in the interface, then creating an
appropriate logger with that configuration.
If there is anything getting printed directly outside the logger, then it's
a Stan issue and we'll need to fix it.
…On Thu, Jul 27, 2017 at 10:37 AM, Bob Carpenter ***@***.***> wrote:
@isabelmgao <https://github.com/isabelmgao> Streaming stdout to a table
seems dicey in any situation. I'm not sure if PyStan (or Prophet) lets you
stream the draws to a CSV file, but it'd be safer to take that stream as
output.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZ_Fw-Ktgc14tyaPnVyYnPmxi1V3U1cks5sSKCggaJpZM4BjPMs>
.
|
|
I'm having issues with this using rstan::optimizing. My use case involves fitting ~ a million small models so even one line of output becomes troublesome. I can wrap everything in sink()s but then I miss any actual useful output (and if I just wrap the optimizing() call I get issue with opening too many file handles). |
|
@davidaknowles Which output do you consider useful and which do you want to turn off? |
|
I want to be able to turn everything off. The stuff that leaks through for me even with |
|
Thanks---we will eventually sort out how to really turn everything off in RStan. I'm confused about the message before last, where you were worried about losing useful output. If we have a mode to turn everything off, everything will get turned off. My question was more whether there is some output you did not want to turn off? |
|
Ah sorry, I wasn't very clear. It's not output from stan I'm worried about losing. My current solution to getting two much stdout from rstan::optimizing is to wrap everything using sink, e.g. This is a hack because anything that I print() in the loop gets lost, including warnings/errors. The former issue I could deal with by logging to file rather than console, but it doesn't help with seeing warnings/errors. |
|
I'm afraid I still don't understand exactly what you're asking for. Concrete examples help of *what you want to see in the output*, not just what you say going in. Presumably you want to do this without sink() or you wouldn't be on this issue. So that makes me think you don't want everything to be removed. So if not everything, then what? And if everything, why doesn't sink() do what you want?
… On Sep 21, 2017, at 3:43 PM, David A. Knowles ***@***.***> wrote:
Ah sorry, I wasn't very clear. It's not output from stan I'm worried about losing. My current solution to getting two much stdout from rstan::optimizing is to wrap everything using sink, e.g.
zz <- file( "/dev/null", open = "wt")
sink(zz)
sink(zz, type = "message")
# my big loop containing rstan::optimizing calls
sink(type="message")
sink()
This is a hack because anything that I print() in the loop gets lost, including warnings/errors. The former issue I could deal with by logging to file rather than console, but it doesn't help with seeing warnings/errors.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
So if I do this for example: I will not see the output from |
|
Got it. Thanks for bearing with me. |
|
It would be nice if compilation errors / notes could use the message feature of R, as messages can be easily suppressed. |
|
I am having a problem similar to those of people above in that some output is still leaking through. Is there a way to suppress the gradient information and elapsed time in addition to the updates that are suppressed with library(rstanarm)
#> Loading required package: Rcpp
#> rstanarm (Version 2.17.4, packaged: 2018-04-13 01:51:52 UTC)
#> - Do not expect the default priors to remain the same in future rstanarm versions.
#> Thus, R scripts should specify priors explicitly, even if they are just the defaults.
#> - For execution on a local, multicore CPU with excess RAM we recommend calling
#> options(mc.cores = parallel::detectCores())
#> - Plotting theme set to bayesplot::theme_default().
data(kidiq)
kidiq$rand <- rnorm(nrow(kidiq))
post1 <- stan_glm(kid_score ~ mom_hs, data = kidiq,
family = gaussian(link = "identity"), chains = 4, iter = 2000, refresh = -1)
#>
#> Gradient evaluation took 4.5e-05 seconds
#> 1000 transitions using 10 leapfrog steps per transition would take 0.45 seconds.
#> Adjust your expectations accordingly!
#>
#>
#>
#> Elapsed Time: 0.238801 seconds (Warm-up)
#> 0.223752 seconds (Sampling)
#> 0.462553 seconds (Total)
#>
#>
#> Gradient evaluation took 4.5e-05 seconds
#> 1000 transitions using 10 leapfrog steps per transition would take 0.45 seconds.
#> Adjust your expectations accordingly!
#>
#>
#>
#> Elapsed Time: 0.245983 seconds (Warm-up)
#> 0.224522 seconds (Sampling)
#> 0.470505 seconds (Total)
#>
#>
#> Gradient evaluation took 3.2e-05 seconds
#> 1000 transitions using 10 leapfrog steps per transition would take 0.32 seconds.
#> Adjust your expectations accordingly!
#>
#>
#>
#> Elapsed Time: 0.294125 seconds (Warm-up)
#> 0.240587 seconds (Sampling)
#> 0.534712 seconds (Total)
#>
#>
#> Gradient evaluation took 5.5e-05 seconds
#> 1000 transitions using 10 leapfrog steps per transition would take 0.55 seconds.
#> Adjust your expectations accordingly!
#>
#>
#>
#> Elapsed Time: 0.306703 seconds (Warm-up)
#> 0.223262 seconds (Sampling)
#> 0.529965 seconds (Total)In my ideal world, there would be no output printed when calling the function. |
|
No, you have to use capture.output().
…On Sun, Jun 3, 2018 at 3:56 PM, Jake Thompson ***@***.***> wrote:
I am having a problem similar to those of people above in that some output
is still leaking through. Is there a way to suppress the gradient
information and elapsed time in addition to the updates that are suppressed
with refresh = -1. For example:
library(rstanarm)#> Loading required package: Rcpp#> rstanarm (Version 2.17.4, packaged: 2018-04-13 01:51:52 UTC)#> - Do not expect the default priors to remain the same in future rstanarm versions.#> Thus, R scripts should specify priors explicitly, even if they are just the defaults.#> - For execution on a local, multicore CPU with excess RAM we recommend calling#> options(mc.cores = parallel::detectCores())#> - Plotting theme set to bayesplot::theme_default().
data(kidiq)kidiq$rand <- rnorm(nrow(kidiq))post1 <- stan_glm(kid_score ~ mom_hs, data = kidiq,
family = gaussian(link = "identity"), chains = 4, iter = 2000, refresh = -1)#> #> Gradient evaluation took 4.5e-05 seconds#> 1000 transitions using 10 leapfrog steps per transition would take 0.45 seconds.#> Adjust your expectations accordingly!#> #> #> #> Elapsed Time: 0.238801 seconds (Warm-up)#> 0.223752 seconds (Sampling)#> 0.462553 seconds (Total)#> #> #> Gradient evaluation took 4.5e-05 seconds#> 1000 transitions using 10 leapfrog steps per transition would take 0.45 seconds.#> Adjust your expectations accordingly!#> #> #> #> Elapsed Time: 0.245983 seconds (Warm-up)#> 0.224522 seconds (Sampling)#> 0.470505 seconds (Total)#> #> #> Gradient evaluation took 3.2e-05 seconds#> 1000 transitions using 10 leapfrog steps per transition would take 0.32 seconds.#> Adjust your expectations accordingly!#> #> #> #> Elapsed Time: 0.294125 seconds (Warm-up)#> 0.240587 seconds (Sampling)#> 0.534712 seconds (Total)#> #> #> Gradient evaluation took 5.5e-05 seconds#> 1000 transitions using 10 leapfrog steps per transition would take 0.55 seconds.#> Adjust your expectations accordingly!#> #> #> #> Elapsed Time: 0.306703 seconds (Warm-up)#> 0.223262 seconds (Sampling)#> 0.529965 seconds (Total)
In my ideal world, there would be no output printed when calling the
function.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADOrqvMLr8gi5le4B2AoS6r8EfcHq12iks5t5D9XgaJpZM4BjPMs>
.
|
Requested by Avraham Adler on stan-users:
Firstly, as a medium-term lurker but first-time poster, I would like to thank the entire Stan development team for the creation and maintenance of Stan.
I am using Stan as part of a paper I am trying to write, and I am struggling with trying to suppress diagnostic messages. For example, when I have used JAGS, R2jags, and knitr, once I set echo, messages, and warnings to FALSE, I can have the model run every time I knit the paper, and only have the results I want displayed through \Sexpr{}. Using Stan, I am having much more of a problem. I have searched the group and have found the following threads:
I have verbose set to FALSE and refresh set to -1. I have used suppressMessages/Warnings as suggested in the thread (1), and that does not seem to do anything more than setting messages and warnings settings in the knitr chunk. I have wrapped my stan() call in sink() calls, as discussed in thread (2) as such:
Regardless, my knitted output looks like:
While I can always knit the Rnw, edit the resulting tex file to remove these lines, and re-texify that file, I would appreciate knowing if there is any way to prevent the need for such post-processing.
The text was updated successfully, but these errors were encountered: