[Vp-integration-subgroup] Standards for simulation interoperability

[William Waites]

Starting a new thread because this is not especially about the paper.

I was a little confused by the recent exchange on standards because it seems to mix up a few different things.

It seems to me that for composing models we need to pay attention to the interface between them and not to the internal workings. James Glazier is right that we often run into situations where the boundary isn’t clear. By forcing a clear boundary, we introduce error in the composed model. This is probably unavoidable and a big part of what we need to be able to do is quantify this error.

Re-reading the exchange, I don’t think that James Sluka meant that a particular programming language should be considered a standard — please correct me if I am wrong. I think the point was about using annotation to document the interface of programs. This is a good idea and is independent of the implementation details. 

It would be a bad idea for several reasons to mandate a specific programming language. First of all, most programming languages do not have well-defined semantics (denotational or operational) so the foundation is shaky. Second of all, we probably do not want to gratuitously constrain research into modelling techniques which might be more convenient to implement in one language than another. I think we should stay well clear of prescribing particular programming languages apart perhaps from insisting that we should use only ones with freely available compilers or interpreters.

It is a good idea to try to specify what behaviour a model must have in order to be able to compose it. We probably want to say something about classes of model whose compositional properties are somewhat better understood. We know how to take two ODE models and compose them together in a way that we can understand what kind of error to expect. We know how to compose chemical reaction networks and rule-based models and derive ODE or stochastic simulations from them. We might know what to expect if we throw equilibrium processes such as FBA models into the mix. We do not especially know what to expect if we compose an arbitrary program with any of these, though Jonathan Karr showed that it can, miraculously, work in some circumstances at least.

The distinction between syntax and semantics is important too. Syntax means things like XML or JSON or packed byte arrays in memory that we need to make sure the input and output of models (or simulations, or, better, propagators as I described in an earlier message) is well-formed. These are low-level things that need to be standard for practical reasons. The higher level is semantics, or meaning. When a simulation produces an integer, the low-level standard says what the syntax of this is, how it is represented in bits, but we also need to know what it means. Maybe it is the copy number of a certain protein or the number of recovered individuals.

I think there are several things to think about:

  - Distinction between what happens within a model and what happens between models
  - Low-level plumbing, syntax at the interface of simulations
  - Semantics of models and annotation
  - Semantics of simulation and composition
  - Properties of composite models that can be derived from the constituent models
  - Properties of composite models that can be derived from the composition method 
  - Just because a model produces well-formed output with documented semantics doesn’t mean that it is correct. 
  - Just because individual models are correct doesn’t mean that a composite model made by combining them is.

Best wishes,
-w