Please also provide the following information in addition to your question:
Operating System: Windows 10 64 bit up-to-date
rstanarm Version: 2.19.2
I have run a stan_jm model that runs forever and ends with multiple warnings about non-convergence, excessive tree depth, divergent transitions, etc., and I would like to be able to use shinystan to be able to figure out where the problem(s) is(are). The longitudinal part of the model runs with stan_nlmr runs without problems. There is no reason to think that the dependent variable is correlated with failure. Other models differing only in that the dependent variable is different run perfectly well with no warnings, and there is nothing pathological about the dependent variable in the pathological model. But when I try to run launch_shinystan() with the pathological model, I am told that shinystan doesn’t know how to handle a stan_jm object. Is there any way to extract something out of the stan_jm model that shinystan (and I) can use to figure out what is going wrong?
Thanks in advance for any help. Larry Hunsicker
Thanks, Sam. I actually worked that approach out when I looked at the components of the JM object. Unfortunately the variables are named in a way that makes very little sense to me. However, I figured out what the problem was. The dependent variable was almost flat over time, and most of the error in the slope was due to random variation of the intercept. That is to say, the intercept in the slope were highly negatively correlated, as they often are when the slope is quite flat. So I worked out another way to get it the questions I was asking.
Many thanks for your help. You have been consistently very helpful over the past several months as I’ve worked with stan_jm. I really appreciate your kindness. Happy new year! Larry Hunsicker
I would put it in shinystan as that’s what’s affected. If on investigation it turns out to be a bug in rstanarm we can move it or open a new one there. In the mean time it’s enough not to lose track of it.
@jonah and me are currently developing version 3 of shinystan and are about ready to test it. I’ve just added the stanjm type to the class which should fix the problem. At least it now works for me, if you would like to test it you could use:
if (!require("devtools")) {
install.packages("devtools")
}
devtools::install_github("stan-dev/shinystan", ref = "v3-alpha", build_vignettes = TRUE)
library(rstanarm)
library(shinystan)
f1 <- stan_jm(formulaLong = logBili ~ year + (1 | id),
dataLong = pbcLong,
formulaEvent = Surv(futimeYears, death) ~ sex + trt,
dataEvent = pbcSurv,
time_var = "year",
# this next line is only to keep the example small in size!
chains = 1, cores = 1, seed = 12345, iter = 1000)
launch_shinystan(f1)
Hopefully it works for your models too. If you want to use the shinystan version that you are used to you can do so by changing the final line into launch_shinystan(f1, old_version = T).
Hope this helps and any feedback you have on the new version is very welcome.
@ducoveen Awesome cheers! I wonder if we should just add the stanmvreg (for rstanarm::stan_mvmer()) and the stansurv (for rstanarm::stan_surv()… for if/when it gets released in a future version of rstanarm) classes as well while we are at it? They all inherit the stanreg class so I thought a launch_shinystan.stanreg() method would work for them, but perhaps not…
sso gets created but sso2 not. I’ll read up on the r methods a bit so maybe I can get as.shinystan to do this more efficiently. Otherwise I’ll add the classes by themselves.
Oh interesting. Ok, I’m not familiar enough to know how the method calling works (are these S3 methods in shinystan?).
stanmvreg objects are in the current stable release of rstanarm and can be returned by calling for example:
library(rstanarm)
f1 <- stan_mvmer(
formula = list(
logBili ~ year + (1 | id),
albumin ~ sex + year + (year | id)),
data = pbcLong,
# this next line is only to keep the example small in size!
chains = 1, cores = 1, seed = 12345, iter = 1000)
Whereas stansurv objects are only in the survival development branch you mentioned (i.e. https://github.com/stan-dev/rstanarm/tree/feature/survival). So you could not bother with stansurv at the moment, if you wanted to avoid the hassle of having to somehow add tests for them prior to their inclusion in a stable version of rstanarm.
In this case it is an S4 method. Anyway, I’ve added the options for the stanmvreg objects too in the v3-alpha branch now. I’ll add the stansurv at a later point.