wrap BNP cluster samplers so only used if cluster has observations

[paciorek]

Do not merge: for @danielturek to review @paciorek approach to not running MCMC samplers for BNP cluster parameters when a given cluster has no constituent observations.

This work builds off @perrydv reversible jump sampler, extending it to wrap whatever sampler is assigned to the cluster parameter by configureMCMC.

[paciorek]

@danielturek ignore the line

clusterNodeInfo <- list(clusterVars = 'muTilde', clusterNodes = list( paste0('muTilde[', 1:50, ']')))

in configureMCMC.R. That is only there because there is some work on a separate branch that would need to get merged in for us to be able to automatically create clusterNodeInfo. At the moment, I'm just hard-coding in what clusterNodeInfo looks like for a specific example model I was using when developing this.

In case you want to actually be able to run the code, here is the example model:

code <- nimbleCode({
    xi[1:n] ~ dCRP(conc0, n)
    for(i in 1:n){
        mu[i] <- muTilde[xi[i]]  
        y[i] ~ dnorm(mu[i], 1)
    }
    for(i in 1:n) {
        muTilde[i] ~ dnorm(mu0, sd = s0)
    }
})

n = 50
model <- nimbleModel(code, constants = list(n=n), data = list(y=rnorm(n)), inits = list(xi = rep(1,n),
                                                                                        conc0 = 1, muTilde = c(1:n), mu0=0, s0=1))
conf <- configureMCMC(model)
mcmc = buildMCMC(conf)
cmodel = compileNimble(model)
cmcmc <- compileNimble(mcmc,project=model)

[paciorek]

Also, @danielturek just flagging that this is now multiple times that I've revised configureMCMC such that I ignore your work on samplerAssignmentRules. I wanted to mention that as I'm not sure where that stands and want to make sure I am not messing anything up.

[danielturek]

@paciorek Thanks for flagging this for review.

I've taken a pretty careful look over it, and the approach looks sound, only one thing I wasn't sure if it's correct. Could a model have more than one dCRP node, and hence the code you added for clusterNodInfo, etc, would all be invoked twice? In which case, the additional code for modifying the samplers to "wrap" these (beginning on line 271 of MCMC_configuration.R), since this appears outside of the main loop beginning on line 201, that would only catch one of the occurrences of the dCRP node, right? Since closterNodeInfo and depNode would have been overwritten. Is that right? Is this situation possible?

If it's right, then I understand why the "wrapping" code must appear later, to remove the samplers from all the clusterNodes. But still, could easily be fixed by maintaining clusterNodeInfo as a list of lists, where each element contains the clusterNodeInfo of one dCRP node.

Of course, please disregard this if I'm missing some part of the big picture, and this situation isn't possible.

Thanks for the heads up about not maintaining samplerAssignmentRules. That's fine. If that system ever comes into use, I would need to bring it up-to-date anyway.

I pushed one commit to this PR, only with stylistic changes.

[paciorek]

Thanks @danielturek I think you are right that we need to handle the possibility of two dCRP nodes. I will fix that when I come back to this (hopefully soon).

[paciorek]

Ok, I am fixing the issue with possibility of having two dCRP nodes in one model and also making use of nimbleFunctionList in wrapped sampler in case one model has two types of wrapped samplers. For reasons not worth going into, I'm removing this branch and replacing with nosample_empty_clusters2.