My model runs in Jags take >10h to complete and my lab faces electrical
failures -> is there any way to save jags outputs regularly?
I've tried by updating my model by short number of iterations and saving my R
session, yet if I close/reopen the session and want to rerun the model it
seems that it has to be recompiled - and thus I guess all the previous updates
are lost, right?
I also guess that running short chains (~1000 it) with jags.samples() and
combine subsequently all the chains into a single one is methodologically
absurd isn't it?
Is there a solution (apart from praying for no power failure for 20h or
running the model on a laptop?
many thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also guess that running short chains (~1000 it) with jags.samples() and
combine subsequently all the chains into a single one is methodologically
absurd isn't it?
That doesn't sound absurd to me. But it would have to be after the adaptation
stage.
I don't think it makes a difference to say that you have 10k samples from each
of 3 chains vs. 3k samples from each of 10 chains.
Note that you'd have to have a function that combines mcarray objects (in
which case, please share).
If you have multiple pieces of the same chain, then it's fine to combine
them sequentially. However, if you're having to recompile the model, then I
think you're making multiple different chains, each from a different set of
initial values. In this latter case, you probably don't want to combine chains
sequentially. During the first part of a chain, the sampler is converging on
the proper distribution, this is the burnin-period. You want to be able to
clip this out. If you combine different chains in a sequential manner, then
you'll have your burnin-samples mixed in with your converged-samples. If you
really wanted, you could clip out the burnin section from each chain, and then
combine the remaining portions sequentially, but I think there are easier ways
to do this.
If you generate samples from within R, using coda.samples(), then the result
is an mcmc.list object. This is essentially a list of chains that were run
with the same parameters. As such, you can add chains to the list using the
c() function. You can then plot the combined mcmc.list using the coda package,
see where the burnin period ends, and use the window() function (also in coda)
to clip the burnin section out from each chain. Like this:
##give three mcmc.lists, out1, out2, out3, each generated from coda.samples in the same way
output.combo = c(out1, out2, out3)
plot(output.combo, ask=TRUE)
output.combo.keep = window(output.combo, start={length of burnin}, stop = {# samples in each chain})
Many short chains can be less efficient than one long chain. Say it takes 500
iterations for chains to converge
) If you have 10K samples from each of 3 chains, then you lose the first 500
iterations from each chain, and end up with 10K3 - 5003 = 28.5K converged-
samples.
) If you have 3K samples from each of 10 chains, then you again lose the first
500 iterations from each chain, and end up with 3K10 - 50010 = 25K
converged-samples.
This may or may not be important, depending on the particulars of your model.
Have you considered renting computing time from the cloud? Those people (e.g.
Amazon) usually have backup systems to ensure uninterrupted computing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My impression was that samples from the adaptation phase were automatically
omitted from jags.samples output (which is also used by coda.samples). No need
for manual clipping. If you see from the traceplot that you need a longer
burn-in period, just increase the adaptation phase.
At that point you have to figure out whether you prefer to combine mcarray
objects or mcmc.list objects. Both are totally feasible.
Otherwise, I'm in full agreement with Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all
My model runs in Jags take >10h to complete and my lab faces electrical
failures -> is there any way to save jags outputs regularly?
I've tried by updating my model by short number of iterations and saving my R
session, yet if I close/reopen the session and want to rerun the model it
seems that it has to be recompiled - and thus I guess all the previous updates
are lost, right?
I also guess that running short chains (~1000 it) with jags.samples() and
combine subsequently all the chains into a single one is methodologically
absurd isn't it?
Is there a solution (apart from praying for no power failure for 20h or
running the model on a laptop?
many thanks!
That doesn't sound absurd to me. But it would have to be after the adaptation
stage.
I don't think it makes a difference to say that you have 10k samples from each
of 3 chains vs. 3k samples from each of 10 chains.
Note that you'd have to have a function that combines mcarray objects (in
which case, please share).
You could also look into parallelizing your JAGS
runs.
But the easiest thing to do may be to run on a remote machine not subject to
power failures, like, say, AWS.
If you have multiple pieces of the same chain, then it's fine to combine
them sequentially. However, if you're having to recompile the model, then I
think you're making multiple different chains, each from a different set of
initial values. In this latter case, you probably don't want to combine chains
sequentially. During the first part of a chain, the sampler is converging on
the proper distribution, this is the burnin-period. You want to be able to
clip this out. If you combine different chains in a sequential manner, then
you'll have your burnin-samples mixed in with your converged-samples. If you
really wanted, you could clip out the burnin section from each chain, and then
combine the remaining portions sequentially, but I think there are easier ways
to do this.
If you generate samples from within R, using coda.samples(), then the result
is an mcmc.list object. This is essentially a list of chains that were run
with the same parameters. As such, you can add chains to the list using the
c() function. You can then plot the combined mcmc.list using the coda package,
see where the burnin period ends, and use the window() function (also in coda)
to clip the burnin section out from each chain. Like this:
##give three mcmc.lists, out1, out2, out3, each generated from coda.samples in the same way output.combo = c(out1, out2, out3) plot(output.combo, ask=TRUE) output.combo.keep = window(output.combo, start={length of burnin}, stop = {# samples in each chain})Many short chains can be less efficient than one long chain. Say it takes 500
iterations for chains to converge
) If you have 10K samples from each of 3 chains, then you lose the first 500
iterations from each chain, and end up with 10K3 - 5003 = 28.5K converged-
samples.
) If you have 3K samples from each of 10 chains, then you again lose the first
500 iterations from each chain, and end up with 3K10 - 50010 = 25K
converged-samples.
This may or may not be important, depending on the particulars of your model.
Have you considered renting computing time from the cloud? Those people (e.g.
Amazon) usually have backup systems to ensure uninterrupted computing.
My impression was that samples from the adaptation phase were automatically
omitted from jags.samples output (which is also used by coda.samples). No need
for manual clipping. If you see from the traceplot that you need a longer
burn-in period, just increase the adaptation phase.
At that point you have to figure out whether you prefer to combine mcarray
objects or mcmc.list objects. Both are totally feasible.
Otherwise, I'm in full agreement with Tim.