Reconsider R implementations of ODE models

[pratikunterwegs]

This issue is to propose that the R-only implementations of ODE models (default, Vacamole) should be removed given new understanding of the use case of {epidemics}, and planned changes to the API (see also #160).

We have previously discussed this same question at length, resulting in these implementations being added in #89.

It is expected that users would want to compare outcomes of multiple intervention scenarios against a baseline while accounting for uncertainty in potentially multiple infection parameters (e.g. $\beta$, $\sigma$), which would require running a model function some 100s - 1000s of times.

A new API is being discussed in #160, and involves a two-level setup where an exported, user-facing function handles parameter combinations, and is coupled to an internal one which runs the ODE solver code, which would increase the size of the codebase and reduce maintainability.

The R-only versions of ODE models are slower than their C++ implementations and may not be performant for some users (see #62 and #84). The R-only ODE code is also relatively complex compared to code used to teach ODE epidemic modelling, so is unlikely to be a suitable teaching tool. In addition it is deeply buried (1 level down; but not as deep as the C++ code, 2 levels down). This dual implementation also doubles maintenance required for ODE models.

This issue does not (as yet) apply to the R-only Ebola model as the C++ implementation was found not to offer substantial speed gains. If the function prob_discrete_erlang() could be implemented in C++ (ideally without adding dependencies such as GSL) this issue should be revisited for the Ebola model too.

[adamkucharski]

Would there be any advantage in integrating with odin, either in terms of development speed/scale for translating existing models to faster implementation, or user-friendliness for training? My understanding is that it uses deSolve to target faster functions in C but with nicer user syntax?

Others will have better sense of what's in the Epiverse stack (and corresponding flexibility in {odin}), so may well not be a priority (or even that feasible for our target use cases).

[pratikunterwegs]

{odin} is a DSL for specifying ODE models in R for conversion to C and then use by {deSolve}. We did have this idea of {epidemics} allowing users to code their own models and run them, but that would be an {odin} reimplementation.

See this example of an age structured model in {odin} - the {epidemics} tradeoff is we limit users to the model structures defined in {epidemics} models, but make adding age structure and social contact heterogeneity, or interventions and vaccinations, easier.

We previously tried implementations where the matrix operations were in Rcpp using Eigen, but the function was passed to {deSolve} - this doesn't gain much speed. The current implementation uses C++ solvers directly which is faster (the benchmarking vignette shows how much exactly).

[adamkucharski]

Thanks, that makes sense – agree there's a lot of value to users in having easy ability to define interventions and incorporate external parameters/social contact data (even if means core model has to be hidden to easy access to some extent)

[pratikunterwegs]

Closing this issue as {epidemics} has moved away from R implementations of the ODE models exposed to the user, while retaining the ODE functions for developer reference. The Ebola model remains in R.