Vertical Integration Across Biological Scales

A New Framework for the Systematic Integration of

Models in Systems Biology

University College London

CoMPLEX

DTI Beacon Project

Talk Outline

1. The Need for a new Computational Framework in Systems Biology

2. Main Features of our suggested Framework

3. An example: Neta’s sleeping and feeding patterns

4. Framework proposal in detail

5. Next steps(Items 3 and 4 only if time permits)

Status of biological modelling

Cornucopia of models Different paradigms Different assumptions Based on different experimental evidence Created in ‘foreign’ languages

Documented without standardisation “Manual integration”, often at the code

level No repository of models

Two Main Challenges The Processing Challenge

Model Integration Tool Support

Visualization Automatic model generation

The Information Management Challenge Cataloguing existing models Linking to experimental results and previous

modeling results

Requirement Survey Diversity of biological processes to be modeled Biological Organization Different modeling Schemes

ODE’s, Stochastic, Process algebra Many different tools for available for each scheme

Iterative Modelling Process Model verification: One should be able to use the

model to make predictions, which would later be verified by further experiments

The model would then be modified, in light of the new experimental results.

Requirements Survey - ConclusionThe main features of the new modeling

approach should be: Modularity – probably through componentization

Modularity also serves to support gradual, piece wise development

Heterogeneity - Integration of models created in different schemes.

Support for Meaningful Integration Care for Semantics (Probably through use of

Ontologies) Representation and observance of assumptions

and constraints

Suggested Component Based, MiddleWare Framework Consists of a component middleware and a set

of supporting services Context/Interpretation Repository, Model Repository

Models are executed in their original language, using their native environment, in a distributed manner

Instantiated models are exposed as components, having well defined interfaces.

A new language enables one to create composite models.

An orchestrator executes a composite model, by calling the different engines to execute the submodels it is composed of, and integrating the computational results

Proposed Middleware Architecture

Orchestrator

Interpretation Service

Context Service

CompounderEngine

WrapperMathematica

(Running model C)

Engine Wrapper

Xppaut(running model B)

1

3

5

6 5

Engine Wrapper

C++(Running model A)

2

4

77

8

9

9

Neta’s Sleeping and feeding patterns

Neta’s Sleeping and Feeding Patterns – A

modelAssume: x(t) - Neta’s sleepiness at any given time (1- very alert, 10 very

sleepy), y(t) - Neta’s hunger level at any given time (1 – bottle rejected

in disgust, 10 – had been screaming for a bottle for the last 10 minutes)

z(t) - Neta’s interest level in the current activity provided her, at any given time (1 – not interested, up to 10, very interested)

a and b are parameters for the model: a is Neta’s daily nutritional requirement, and b is Neta’s daily sleep requirement.

Then:dx/dt = bx(t) - y(t) – z(t)dy/dt = -x(t)+ay(t) + z(t)

One Model, Different Interfaces: A single model can support a diverse

range of functionality, or interfaces: Each possible interface has its own

required context “If you provide me with …. , I will be able to

tell you …. Thus, each model’s meta-data, should

specify a context/provided interface table

The context/provided interface table for Neta’s model:

Required Context

Provided interface

a,b, polytrack z(t) Solve_x_y(out polytrack x(t), out polytrack y(t))

Polytrack z(t) Find_null_clines(out Vector of null clines) Find_bifurcation_points(out Vector of points)

a,b Iter_solve_x_y(in polytrack z(t), out polytrack x(t), out polytrack y(t) ) current_rate(in z, in dt, out x, out y) sensitivity_analysis(out z_sensitivity(x,y))

Proprietry and Standard Engines Models are interpreted using

engines. The engine actually implements the interfaces (functionality), according to the model specs.

An engine can be seen as a Model Instance Factory

Engine – A Model Instance Factory

Model Instance Factory

O. Margo Neta’s Model

Context 1(a,b,polytrack z(t))

Model Instance ‘yellow’(supports yellow methods)

Creates

Engine – A Model Instance Factory

Model Instance Factory

O. Margo Neta’s Model

Context 2(a,b)

Model Instance ‘green’(supports green methods)

Creates

Proprietary & Standard Engines How does one exploit a model’s functionality -

How does one communicate with the model? Usually this is done in a proprietary, specific way,

provided and specified by the engine on which the model is interpreted.

But we would like this communication, or model usage, to be performed in a standard way, in order to enable model integration

The solution: Use wrappers. Wrappers also expose the Engine’s Model Instance

Factory functionality in a standard way We have already written such wrappers for Xppaut

and Mathematica.

Standard Engines and Engine Wrappers

Proprietry Engine

Very_weird_call1(input in proprietry format, output in proprietry format)

WrapperStandard_call1(input, output in standard format)

Outside World

Standard Engine

The Orchestrator The Orchestrator is an Engine, that can

interpret composite models It is mainly a coordinator, or a workflow

execution service. May run models either sequentially or

concurrently May use a compounder to solve concurrently

two or more models, which form a feedback loop Composite Models are specified in the

Composite Models Language – BeCMolla(Beacon Composite Models Language)

A Simple Example(1)

Assume we also have : Liat’s Neta model, depicting Neta’s

interest level in the current activity:

dz/dt = C(i) – k*(a*x(t-t0)+y(t-t0)) The NHS standard feeding calculator

When provided when Neta’s age and weight, gives you Neta’s daily feeding requirements (a) and hours of sleep required (b)

A Simple Example (2) We can now create a composite model,

to predict Neta’s feeding, sleeping, and interest level patterns:

This composite model would provide the following functionality:

Required Context

Provided interface

age,weight, k, C(i) Solve_x_y_z(out polytrack x(t), out polytrack y(t), out polytrack z(t))

A Simple Example(3)This model is composed, and will be solved, as

follows:The NHS model would be run first, and then Ofer and

Liat’s model would be solved together, using a compounder

NHS

Ofer Liat

A Simple Example (4)

Orchestrator

Interpretation Service

Context Service

CompounderEngine

WrapperMathematica

(Running model C)

Engine Wrapper

Xppaut(running model B)

1

3

5

6 5

Engine Wrapper

C++(Running model A)

2

4

77

8

9

9

Where now? We need to define the ‘model components’ interface

language Select an underlying middleware architecture we

would like to use: Web Services? Web Services + (OGSA|BEPL|XLANG|W3C Choreography)? Java objects? CCA? SBW?

Devise the numerical algorithms which can be used to integrate models together

Actually build a framework (an implementation)