Closed athowes closed 4 months ago
So this exists to make it easier to run models at scale and was part of the pipeline code we needed for the paper. I agree we should keep the output of epidist as simple/as close to brms
as possible.
course it's possible to do yourself it is a little bit tricky and you can do it wrong.
I think this is likely true. I think the main kicker here is the running in a fault tolerant manner which large pipelines often need. I think we could largely get around this by adding some documentation or an example somewhere?
epidist_diagnostics
Good idea. This or something like it should take the output of epidist I think like the standard cmdstan tools do for directly fitted models.
I'd prefer for the output of epidist::epidist to be ammenible to standard brms methods so I wouldn't want to have like output$fit and output$diagnostics particularly.
I strongly agree if we can manage - we can make a diagnostic function take this as an input and then return diagnostics.
I think we agree we should
epinowcast
it is a custom wrapper around sample etc vs being multiple tools. Having a FAQ about how to do things that you could do e.g. purrr::safely
.
If we have different opinions about diagnostics then we could implement that into epidist_diagnostics
. We do have users less familiar with Bayesian methods.
Add documentation for safely and about timings somewhere.
My current thinking on this is:
purrr::safely
part (https://github.com/epinowcast/epidist/issues/174)epidist_diagnostics
(including time) it should probably be S3 or use some way to make sure that it gives the right diagnostics for the particular inference method (only NUTS really, don't think it's applicable for others, so just write a warning message or something for those)epidist
roxygen that you can call epidist_diagnostics
and try to debug? Let me know.Closed via #181 and #175.
We have the function
sample_model
which does various things on top of fitting abrms
model.These things are:
purrr::safely
. If there is an error keep the error.I think that we should decide on which of these features to keep, implement them into
epidist::epidist
, then delete this function.My opinion about what to keep:
safely = FALSE
which ifTRUE
will do this for someone. I guess our use-case is that we pass tobrms
, so perhaps some safety is warranted.epidist_diagnostics
or similar to house the functionality and call it withinepidist
ifdiagnostics = TRUE
There's also a question here about how to return these objects. The
brms
output is already a complicated object, so in some sense feels like it would't hurt much to add more elements onto its list. I'd prefer for the output ofepidist::epidist
to be ammenible to standardbrms
methods so I wouldn't want to have likeoutput$fit
andoutput$diagnostics
particularly.