Create monty model

Create a monty_model from a dust_likelihood object.

Usage

dust_likelihood_monty(
  obj,
  packer,
  initial = NULL,
  domain = NULL,
  failure_is_impossible = FALSE,
  save_state = FALSE,
  save_trajectories = FALSE
)

Arguments

obj

A dust_likelihood object, created from dust_filter_create or dust_unfilter_create

packer

A parameter packer, which will convert between an unstructured vector of parameters as used in an MCMC into the list of parameters that the dust system requires.

initial

Optionally, a function to create initial conditions from unpacked parameters.

domain

Optionally, domain information to pass into the model. If given, this is a two column matrix with row names corresponding to the parameter names in packer, the first column representing the lower bound and the second column representing the upper bound. You do not need to specify parameters that have a domain of (-Inf, Inf) as this is assumed. We use monty::monty_domain_expand to expand logical parameters, so if you have a vector-valued parameter b and a domain entry called b we will expand this to all elements of b.

failure_is_impossible

Logical, indicating if an error while computing the likelihood should be treated as a log-density of -Inf (i.e., that this point is impossible). This is a big hammer to use, and you would be better off using the domain (with reflecting boundaries) or the priors to control this if possible. However, sometimes you can have integration failures with very high parameter values, or just other pathological parameter sets where, once you understand the model, giving up on that parameter set and continuing is the best option.

save_state

Logical, indicating if the state should be saved at the time series.

save_trajectories

Logical, indicating if particle trajectories should be saved. This can also be a character vector indicating the logical compartments, or an integer vector being an index into the state.

Value

A monty::monty_model object

Random number streams

This section is only relevant if your likelihood object is a particle filter, and therefore uses random numbers.

The short version: the seed argument that you may have passed to dust_filter_create will be ignored when using a dust_likelihood_monty model with algorithms from monty. You should generally not worry about this, it is expected.

When you initialise a filter, you provide a random number seed argument. Your filter will use n_groups * (n_particles + 1) streams (one for the filter for each group, then for each group one per particle). If you run the filter directly (e.g., with dust_likelihood_run then you will advance the state of the filter). However, if you use the filter with monty (which is why you're using dust_likelihood_monty) we will ignore this seeding.

When running MCMC with n_chains chains, we need n_chains * n_groups * (n_particles + 1) random number streams - that is enough streams for every chain to have a filter with its own set of chains. monty will look after this for us, but the upshot is that the random number state that you may have previously set when building the filter will be ignored as we need to create a series of suitable seeds.

The seeds provided by monty will start at some point in the RNG state space (2^256 possible states by default). In an MCMC, each chain will have a seed that is created by performing a "long jump", moving 2^192 steps along the chain. Then within each chain we will take a series of "jumps" (2^128 steps) for each of the streams we need across the groups, filters and particles. This ensures independence across the stochastic components of the system but also the reproducibility and predictability of the system. The initial seeding performed by monty will respond to R's RNG (i.e., it will follow set.seed) if an explicit seed is not given.