There are a number of examples around of using the doParallel library and the "foreach" construct to parallelise JAGS from rjags.
However, in all of the examples that I have seen, each core worker gets sent a workstream which includes the model creation and adaptation via jags.model, and then sampling via coda.samples.
This seem to me to be duplicated effort, particularly if the adaptation phase is time consuming, and also if I want to call coda.samples multiple times with different variable names (I don't want to have to re-do the adaptation).
What I would like to do is be able to initialise the model on a single core (happy to use one chain only here if needed), and then call coda.samples from multiple cores to get the samples.
I don't understand the internal working well enough, but is it possible to copy the model state into a list, then modify the internal RNG state to ensure that when coda.samples is called each worker will produce different output?
For instance, I could produce a JAGS model "JAGSmodel".
I can then do:
JAGSmodel_mult <- list()
for (i in 1:ncores) JAGSmodel_mult[[i]] <- JAGSmodel
If I then modify JAGSmodel_mult[i]$state(internal=TRUE)$.RNG.state and JAGSmodel_mult[i]$state(internal=TRUE)$.RNG.name to appropriate values, and then pass the ith model to coda.samples, will this have the desired effect?
The necessary values can be obtained from a call to parallel.seeds("base::BaseRNG", 4) for instance.
"I don't understand the internal working well enough, but is it possible to copy the model state into a list, then modify the internal RNG state to ensure that when coda.samples is called each worker will produce different output?"
Last I checked this was not possible because the complete state of the model is not enough. You also need the complete state of the samplers to avoid redoing adaptation. We would really like this feature as well, because 1) adaptation can take as long as sampling; 2) if you loose an rjags session due to having to close JAGS, you need to redo-adaptation even if you know all the correct starting parameters; 3) the state of samplers for model A might be a good starting point for model B and it would be nice to take advantage of that; and 4) I might have outside values for tuning a sampler which I would like JAGS to use. Adaptation can take a week on some of our larger models so it's a real issue for us.
All that said, Martyn is the keeper of Martyn's to-do list and I'm writing this so you know it's been requested before, not to prod him along! I don't know if something like this is in the plans for a future version...?
Log in to post a comment.