Resuming chains

[Mike Lawrence]

Hi folks,

This was discussed back in 2014 (https://groups.google.com/d/topic/stan-users/A52PqqdYNks/discussion), but wondering if there's any updated thinking on resuming chains that have been prematurely terminated (power failure, for example). These days I always run with the sample_file and diagnostic_file arguments to stan::sampling() specified, so presumably I have lots of info on the state of the chain before it was stopped. Thoughts?

Mike

--
Mike Lawrence
Graduate Student
Department of Psychology & Neuroscience
Dalhousie University

~ Certainty is (possibly) folly ~

[Andrew Gelman]

I've heard that in the forthcoming Stan 3 refactor it will be possible to pass all the tuning information to Stan and then it can continue running chains, or run them 1 iteration at a time, or whatever is desired.

A

--
You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+...@googlegroups.com.
To post to this group, send email to stan-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bob Carpenter]

Indeed, but there's still no ETA for when that will
land. We're hoping soon. Daniel has put together a prototype
on a branch in stan-dev/stan, and he's working with Allen and
Ben on getting things pushed through PyStan and RStan.

Having said that, we're all pretty overwhelmed with a combination
of teaching, writing, users list replying, adding features/functions,
fixing bugs, and raising funding (not to mention that everyone other
than Daniel and I have a day job focused on something other than
Stan) that it's slow going. One of the bigger bottlenecks is that
Daniel and I are involved in reviewing and/or writing most of
the low-level code in Stan, the math library, and CmdStan (not
in RStan or PyStan), so we're real chokepoints as we've tried to
get more serious about doc and testing.

Not an excuse---we should've had this done ages ago if we'd been
able to decide and execute a design; just an explanation of where
we're at and what the challenges will be going forward.

As an example, we've put a lot of time recently into making
matrix operations faster, adding stiff differential equation solving,
updating the language syntax, and squashing longstanding issues,
that we haven't had much time for refactoring.

- Bob