Truly independent groups of chains

[fkrauer]

Hi,

I was trying to fit a model with DEzs (θsnooker=0.1, generate_proposal=random_gamma) and 3 independent groups of chains (n_groups = 3 and Np=3). I set α=0.0 so that there would be no exchange between the groups, and I expected the three groups to be independent samples. However, the trace looks like they are not truly independent. How is this possible? This was fit with nthreads=3. Thanks for your insight.

[itsdfish]

Hi,

My understanding is that snooker is usually accompanied with resampling of previous states of the chains (see section 2.2 below). The groups will be dependent to some degree because their proposals are sampled from the same history. However, the groups should not have the same exact samples because past states are selected at random before proposals are generated.

https://link.springer.com/content/pdf/10.1007/s11222-008-9104-9.pdf

[itsdfish]

If you want the groups to be independent, the easiest approach would be to modify this for your use case:

mapreduce(g -> sample(model_fun, sampler, 1000), chainscat, 1:num_groups)

which is based on the Turing documentation. If you want to run each group on a separate thread, you could use tmapreduce in ThreadedIterables. Based on prior experience, I found ThreadedIterables to be very user friendly.

[fkrauer]

So I need ThreadedIterables.jl for multithreading? I thought MCMCThreads() in the sample() call already results in multithreaded fitting if I start the julia session with multiple threads.

[itsdfish]

That is correct. When you use sample with MCMCThreads the conventional way, all of the past states are stored in a single array. This is where the dependence comes from. In order to sample from a separate history arrays, you will have to run separate instances of sampler with either mapreduce or tmapreduce and remove the call to MCMCThreads. I would use deepcopy to ensure that the de objects are distinct: des = [deepcopy(de) for _ in 1:n_threads()]. You might consider the same for your model object if it is mutable in someway. That being said, I'm not sure whether this will result in better sampling.

[itsdfish]

I can't remember what problem you had with NUTS. Typically, it is more robust compared to DEMCMC. The main downside is that NUTS can have lots of overhead due to automatic differentiation. I suppose DiffEq models might be computationally intensive.

[fkrauer]

Ah good to know, thanks. I am still fitting with NUTS (the mixing is much better), but while waiting for a fit I wanted to do some exploration with DEMCMC to see whether it might be a multimodal posterior. Having several truly independent groups of chains would be a good way to explore this, but I don't really need it for the final results.

[itsdfish]

Ah I see. I have encountered multimodal posteriors with DEMCMC and NUTS. Detecting multimodality can be tenuous. Sometimes you will see a divergence and in other cases you won't. FWI, if you find multimodality, you will want to use MCMCTempering once it is available. Unfortunately, there is a blocking PR. Hopefully that will be resolved soon.

[fkrauer]

Yeah I have seen it, but it is not implemented yet. Will check with Tor. Thanks anyway!