Project Status: Active – The project has reached a stable, usable state and is being actively developed. R build status CodeFactor

odin implements a high-level language for describing and implementing ordinary differential equations in R. It provides a “domain specific language” (DSL) which looks like R but is compiled directly to C. The actual solution of the differential equations is done with the deSolve package, giving access to the excellent Livermore solvers (lsoda, lsode, etc), or with dde for use with delay differential equations.

In addition, the same machinery can be used to generate discrete-time models that proceed over a set of steps (rather than through continuous time). These may be stochastic and make use of any of R’s random number functions.

odin works using code generation; the nice thing about this approach is that it never gets bored. So if the generated code has lots of tedious repetitive bits, they’re at least likely to be correct (compared with implementing yourself).


The “deSolve” package for R is the de-facto way of solving differential equations in R; it provides excellent solvers and has remained stable for over a decade. However, users must implement equations in R and suffer a large speed cost, or implement their equations in C which is (depending on the complexity of the system) either routine and a bit boring, or complicated and error prone. This translation can be especially complicated with delay differential equations, or with models where the variables are more naturally stored as variable sized arrays.

Apparently not many people know that deSolve can use target functions written in C rather than just in R. This is described in detail in the excellent “compiledCode” vignette (vignette("compiledCode") or online.

While the deSolve authors are bearish on the benefits of this, I have often seen performance improvements of over 100x. Where an ODE is being used in application where it is called repeatedly (e.g., an optimisation or MCMC) the cost of rewriting the system pays itself back.

For simple systems the rewriting is essentially mechanical. The lorenz attractor could be implemented in R as:

lorenz <- function(t, y, parms) {
  sigma <- parms[1]
  R <- parms[2]
  b <- parms[3]
  y1 <- y[1]
  y2 <- y[2]
  y3 <- y[3]
  list(c(sigma * (y2 - y1),
         R * y1 - y2 - y1 * y3,
         -b * y3 + y1 * y2))

and in C as

void initmod(void (* odeparms)(int *, double *)) {
  int N=3;
  odeparms(&N, parms);
void lorenz(int *n, double *t, double *y, double *dydt, double *yout, int *ip) {
  double sigma = parms[0];
  double R = parms[1];
  double b = parms[2];
  double y1 = y[0];
  double y2 = y[2];
  double y3 = y[3];
  dydt[0] = sigma * (y2 - y1);
  dydt[1] = R * y1 - y2 - y1 * y3;
  dydt[2] = -b * y3 + y1 * y2;

The connection between the two languages should be fairly obvious. As systems get more complicated much of the difficulty of writing the systems in C becomes the tedium of book keeping as parameters and state vectors are unpacked, rather than any deep programming challenges. Modifying large systems is a particular challenge as technical debt can accrue quickly.

The core job of odin is to simplify this transition so that models can be both developed and solved rapidly.


The Lorenz attractor above can be implemented as:

lorenz <- odin::odin({
  ## Derivatives
  deriv(y1) <- sigma * (y2 - y1)
  deriv(y2) <- R * y1 - y2 - y1 * y3
  deriv(y3) <- -b * y3 + y1 * y2

  ## Initial conditions
  initial(y1) <- 10.0
  initial(y2) <- 1.0
  initial(y3) <- 1.0

  ## parameters
  sigma <- 10.0
  R     <- 28.0
  b     <-  8.0 / 3.0

The connection to the R and C versions in the section above should be fairly clear. The code above is never actually evaluated though; instead it is parsed and used to build up C code for the model.

Note that this includes initial conditions; all odin models include specifications for initial conditions because the ordering of the variables is arbitrary and may be re-ordered.

This generates an object that can be used to integrate the set of differential equations, by default starting at the initial conditions specified above (though custom initial conditions can be given). The equations are translated into C, compiled, loaded, and bundled into an object. lorenz here is a function that generates an instance of the model.

mod <- lorenz()
t <- seq(0, 100, length.out = 50000)
y <- mod$run(t)

For more complicated examples, check out an age structured SIR model, and for more details see the main package vignette


Writing this has given me a much greater appreciation of the difficulties of writing compiler error messages.

This does not attempt to generally translate R into C (though very simple expressions are handled) but only a small subset that follows the stereotyped way that R+C ODE models tend to be written. It tries to do things like minimise the number of memory allocations while preventing leaks. The generated code is designed to be straightforward to read, leaving any really funky optimisation to the compiler.

Because this relies on code generation, and the approach is partly textual, some oddities will appear in the generated code (things like n + 0). Over time I’ll remove the most egregious of these. It’s probable that there will be some unused variables, and unused elements in the parameters struct.

Prior work

ODEs seem particularly suitable for code generation, perhaps because of the relative simplicity of the code. As such, there is a lot of prior work in this area. Many of these tools are heavily tailored to suit a particular domain.

In R:

In other languages:


Install odin from CRAN with


Alternatively, you can install a potentially more recent version of odin from the mrc-ide drat repository

# install.packages("drat") # -- if you don't have drat installed

You will need a compiler to install dependencies for the package, and to build any models with odin. Windows users should install Rtools. See the relevant section in R-admin for advice. Be sure to select the “edit PATH” checkbox during installation or the tools will not be found.

The function odin::can_compile() will check if it is able to compile things, but by the time you install the package that will probably have been satisfied.

The development version of the package can be installed directly from github if you prefer with:

devtools::install_github("mrc-ide/odin", upgrade = FALSE)


MIT © Imperial College of Science, Technology and Medicine