rprocess and dprocess slots for a pomp model.
There are options for discrete- and continuous-time Markov processes.onestep.sim(step.fun, PACKAGE)
euler.sim(step.fun, delta.t, PACKAGE)
discrete.time.sim(step.fun, delta.t = 1, PACKAGE)
gillespie.sim(rate.fun, v, d, PACKAGE)
onestep.dens(dens.fun, PACKAGE)Csnippet.
The latter is the preferred option.
It should be written tCsnippet, or the name of a compiled, dynamically loaded native function that computes the transition rates.
If it is an Rfunction, it should be of the form ratenvar x nevent, where nvar is the number of state variables and nevent is the nuCsnippet, or a compiled, dynamically loaded native function containing the model transition log probability density function.If it is an R function, it should be o
step.fun, onestep.sim takes a single step to go from any given time $t_1$ to any other time $t_2$ ($t_1 < t_2$).
Thus, this plugin is only useful if a closed-form solution to the process exists. To go from $t_1$ to $t_2$, euler.sim takes $n$ steps of equal size, where $n = ceiling((t_2-t_1)/delta.t)$.
discrete.time.sim assumes that the process evolves in discrete time, where the interval between successive times is delta.t.
Thus, to go from $t_1$ to $t_2$, discrete.time.sim takes $n$ steps of size exactly $delta.t$, where $n = floor((t_2-t_1)/delta.t)$.
onestep.sim is the appropriate choice when it is possible to simulate the change in state from one time to another, regardless of how large the interval between them is.
To use onestep.sim, you must write a function step.fun that will advance the state process from one arbitrary time to another.
euler.sim is appropriate when one cannot do this but can compute the change in state via a sequence of smaller steps.
This is desirable, for example, if one is simulating a continuous time process but is willing to approximate it using an Euler approach.
discrete.time.sim is appropriate when the process evolves in discrete time. To use euler.sim or discrete.time.sim, you must write a function step.fun that will take a single Euler step, of size at most delta.t.
The functions euler.sim and discrete.time.sim will create simulators that take as many steps as needed to get from one time to another.
See below for information on how euler.sim chooses the actual step size it uses.
gillespie.sim allows exact simulation of a continuous-time, discrete-state Markov process using Gillespie's algorithm.
This is an gillespie.sim, you must write a function rate.fun that computes the rates of each elementary kind of event and specify two matrices (d,v) that describe, respectively, the dependencies of each rate and the consequences of each event.
onestep.dens will generate a suitable dprocess function when one can compute the likelihood of a given state transition simply by knowing the states at two times under the assumption that the state has not changed between the times.
This is typically possible, for instance, when the rprocess function is implemented using onestep.sim, euler.sim, or discrete.time.sim.
[NB: currently, there are no high-level algorithms in dprocess.
This function is provided for completeness only, with an eye toward future development.]
If step.fun is written as an Rfunction, it must have at least the arguments x, t, params, delta.t, and ....
On a call to this function, x will be a named vector of state variables, t a scalar time, and params a named vector of parameters.
The length of the Euler step will be delta.t.
If the argument covars is included and a covariate table has been included in the pomp object, then on a call to this function, covars will be filled with the values, at time t, of the covariates.
This is accomplished via interpolation of the user-supplied covariate table.
Additional arguments may be given: these will be filled by the correspondingly-named elements in the userdata slot of the pomp object (see pomp).
If step.fun is written in a native language, it must be a function of type pomp_onestep_sim as specified in the header
If rate.fun is written as an Rfunction, it must have at least the arguments j, x, t, params, and ....
Here, j is the an integer that indicates for which of the elementary events the current rate is desired.
x is a named vector containing the value of the state process at time t, and
params is a named vector containing parameters.
If the argument covars is included and a covariate table has been included in the pomp object, then on a call to this function, covars will be filled with the values, at time t, of the covariates.
This is accomplished via interpolation of the covariate table.
If rate.fun is a native function, it must be of type pomp_ssa_rate_fn as defined in the header dens.fun, you must assume that no state transitions have occurred between t1 and t2.
If dens.fun is written as an Rfunction, it must have at least the arguments x1, x2, t1, t2, params, and ....
On a call to this function, x1 and x2 will be named vectors of state variables at times t1 and t2, respectively.
The named vector params contains the parameters.
If the argument covars is included and a covariate table has been included in the pomp object, then on a call to this function, covars will be filled with the values, at time t1, of the covariates.
If the argument covars is included and a covariate table has been included in the pomp object, then on a call to this function, covars will be filled with the values, at time t1, of the covariates.
This is accomplished via interpolation of the covariate table.
As above, any additional arguments will be filled by the correspondingly-named elements in the userdata slot of the pomp object (see pomp).
If dens.fun is written in a native language, it must be a function of type pomp_onestep_pdf as defined in the header
pomp and the tutorials on the