The Sbml Ode Solver Library Support Requests 10 Build
Motivation: This article presents libRoadRunner, an extensible, high-performance, cross-platform, open-source software library for the simulation and analysis of models expressed using Systems Biology Markup Language (SBML). SBML is the most widely used standard for representing dynamic networks, especially biochemical networks.
LibRoadRunner is fast enough to support large-scale problems such as tissue models, studies that require large numbers of repeated runs and interactive simulations. Results: libRoadRunner is a self-contained library, able to run both as a component inside other tools via its C and C bindings, and interactively through its Python interface. Its Python Application Programming Interface (API) is similar to the APIs of MATLAB ( www.mathworks.com) and SciPy ( making it fast and easy to learn.
LibRoadRunner uses a custom Just-In-Time (JIT) compiler built on the widely used LLVM JIT compiler framework. It compiles SBML-specified models directly into native machine code for a variety of processors, making it appropriate for solving extremely large models or repeated runs. LibRoadRunner is flexible, supporting the bulk of the SBML specification (except for delay and non-linear algebraic equations) including several SBML extensions (composition and distributions). It offers multiple deterministic and stochastic integrators, as well as tools for steady-state analysis, stability analysis and structural analysis of the stoichiometric matrix. Availability and implementation: libRoadRunner binary distributions are available for Mac OS X, Linux and Windows. The library is licensed under Apache License Version 2.0.
LibRoadRunner is also available for ARM-based computers such as the Raspberry Pi. Provides online documentation, full build instructions, binaries and a git source repository.
Contacts: or Supplementary information: are available at Bioinformatics online. 1 Introduction Dynamic network models of metabolic, gene regulatory, protein-signaling and electrophysiological networks require the specification of components, interactions, compartments and kinetic parameters.
The Systems Biology Markup Language (SBML) has become the de facto standard for declarative specification of these types of model (; ). Popular tools for the development, simulation and analysis of models specified in SBML include COPASI , Systems Biology Workbench (SBW) , The Systems Biology Simulation Core Algorithm (TSBSC) , Jarnac , libSBMLSim , SOSLib , iBioSim , PySCeS and VirtualCell. Some of these applications are stand-alone packages designed for interactive use, with limited reusability as components in other applications. Few are reusable libraries. Currently, none is fast enough to support emerging applications that require large-scale simulation of network dynamics. For example, multi-cell virtual-tissue simulations often require simultaneous simulation of tens of thousands of replicas of dynamic network models residing in their cell objects and interacting between cells. In addition, optimization methods require generation of time-series for tens of thousands of replica networks to explore the high-dimensional parameter spaces typical of biochemical networks.
We designed libRoadRunner to provide: (i) Efficient time-series generation and analysis of large or multiple SBML-based models; (ii) A comprehensive and logical Application Programming Interface (API); (iii) Interactive simulations in the style of IPython and MATLAB and (iv) Extensibility. Most existing SBML simulation engines use built-in interpreters to parse and execute SBML model specifications. Interpreted execution is simple and flexible, but much slower than execution of compiled code. Other simulation engines generate compiled executables from SBML by first converting SBML-specified models into a general-purpose-language representation. The engines then call an external compiler to translate the general-purpose-language into an executable shared library to load at run time.
E.g., SBW-roadRunner in the SBW suite converts SBML into C# see § 1.4 of , then compiles the C# using the built-in compiler from the.NET distribution. This approach generates relatively fast executables.
However, it requires distribution of a separate compiler or a redistributable runtime, reducing portability. A more efficient approach to SBML-to-executable compilation uses a specialized just - in - time (JIT) compiler, to compile SBML into an optimized Intermediate Language (IL) representation and the IL code into native executable machine code directly in-memory. Used JIT compilation to generate CUDA code from SBML and execute it on an Nvidia GPU. LibRoadRunner and the Stochastic Simulation Compiler (SSC) both compile dynamic network-model specifications into executables, SSC focusing on stochastic simulation of rule-based models and libRoadRunner on SBML-specified models.
LibRoadRunner supports execution of a broad range of SBML models on CPUs using a custom-built JIT compiler based on the LLVM JIT compiler framework which translates SBML into highly optimized executable code for a broad range of processors. LLVM-based compilers are small, so all JIT operations occur in memory, without external file or compiler access, ensuring fast, self-contained simulations and a relatively small distribution package. 2.2 Portability Because new hardware platforms appear frequently, a modern simulator must be portable. LibRoadRunner has no run-time dependencies beyond standard system libraries and it supports any processor LLVM supports. LLVM future-proofs libRoadRunner, ensuring that we need not change the front end of the compiler to support new processor architectures. LibRoadRunner is written in C, so it interfaces easily with other C-based software.
LibRoadRunner also provides a C language wrapper for cross-language support and uses SWIG to provide a customized native-Python API. The use of SWIG will allow future support for additional native language bindings, such as JavaScript, R or Octave, depending on demand. (1) where x is the state vector of the model, and p is a vector of time-independent parameters. SBML-specified models can also include events, discontinuous state changes, which trigger under specified conditions. LibRoadRunner correctly handles SBML-specified events and extends the SBML specification by allowing an SBML event to call an arbitrary user-defined function. Declarative specification languages, like SBML, define component objects and their interactions, rather than defining procedural control flow (i.e.
The sequence in which computational operations proceed on execution). An SBML specification lists only the network component objects, their interactions and rate relations and events which change these interactions and rates, all of which are intrinsic abstractions in SBML. Thus, an author writing a model specification in SBML can focus on the underlying biology or chemistry of the model rather than on how to implement the model as a simulation. Because SBML does not specify the computational operations to implement a model, the control flow, the solvers to use, or how to store the model’s elements, an SBML compiler or interpreter must generate them appropriately from the SBML specification. Thus, compiling an SBML model specification is more complex than compiling a functionally equivalent model specification in a procedural language. SBML model specifications are easier to share than procedural specifications of equivalent models because they are not implementation dependent; any of the numerous SBML compliant tools can process any SBML model specification.
This portability allows model archiving (e.g. In exchange repositories such as BioModels and reuse and the relatively simple assembly of multiple SBML-specified sub-models into larger models.
It also simplifies the scientific validation of SBML-specified models and ensures that SBML-specified models remain usable, even if the specific software tools that generated them fall out of use. 2 Architecture libRoadRunner is a self-contained, easily embedded library with an object-oriented API natively accessible in C, C and Python (SWIG allows easy extension to other languages). LibRoadRunner’s component-oriented design specifies a small number of standardized software interfaces (protocols) and how they interact, implemented using standard C data types. Component-orientation separates the implementation of a component from its interface, so components are easy to add or replace and component swapping requires no changes to existing code. E.g., we can add new integrators, steady-state solvers or SBML compilers to the libRoadRunner library via the Integrator, SteadyStateSolver and ExecutableModel interfaces, respectively. LibRoadRunner includes three implementations of the Integrator interface: two deterministic integrators one based on the CVODE integrator from the Sundials suite and the other a standard fourth-order Runge–Kutta method and a standard Gillespie Direct Method SSA stochastic integrator. LibRoadRunner implements the SteadyStateSolver interface as a class which uses the NLEQ solver, and we are currently developing additional methods.
LibRoadRunner implements the ExecutableModel interface as a class which uses our SBML-to-CPU JIT compiler (see § 3). LibRoadRunner statically links to the third-party libraries LLVM , libSBML , CVODE, NLEQ2, LAPACK (and POCO (http://pocoproject.org/).
4.1 Performance Simulation engines which interpret SBML models , are inherently slower, sometimes much slower, than engines which generate and execute complied code. LibRoadRunner uses JIT compilation to generate particularly fast simulations. We benchmarked libRoadRunner and Jarnac , a popular interpreter-based network simulator, for a variety of network model types (; ). LibRoadRunner’s faster execution speed is particularly evident when solving large models, such as BIOMOD14 , a mass-action model including a large number of states.
We also checked the scaling of the execution time ( t) in the number of replicas ( N) of a Brusselator model, approximating the use of libRoadRunner in a virtual-Tissue simulation with thousands of cells, with each cell including its own replica of an SBML-specified network model. The run time for libRoadRunner scales as t ∼ N, whereas the run time for Jarnac scales as t ∼ N 2.6. Thus libRoadRunner is more suitable than Jarnac for use in Virtual-Tissue simulations or other simulations requiring many replicas of one or more networks. The present the full benchmark comparisons. 4.2 Python bindings libRoadRunner’s Python API employs a simple, concise object model, and follows the style and conventions of the widely used SciPy library for ease of learning. The API provides high performance, low-overhead access to the libRoadRunner library.
The API only communicates using standard Python data types such as lists, dictionaries and NumPy arrays, which simplifies integration with existing applications. The NumPy array type is a data structure which wraps a Python interface around a standard C numeric array. Even large NumPy arrays have low overhead, since they return only pointers to internal arrays owned by the libRoadRunner library, with no copying of memory. To provide the functionality of the Pandas (DataFrame object, libRoadRunner extends the NumPy array to contain row and column name information, to support access to rows and columns by name, and to format this name information for console output. Unlike the Pandas DataFrame, which replaces the Numpy array and requires conversion to work with Python and Numpy functions, the libRoadRunner array is a standard Numpy array which any SciPy function can use. The libRoadRunner array requires only a single line to display the components and interaction names in the stoichiometry matrix.
M = r.simulate(0, 12, 100, ‘time’, ‘p’, ‘ S1’) A variety of other built-in symbols access reaction rates, rates of change, eigenvalues, etc. Like a MATLAB top-level function, the libRoadRunner simulate method provides a consistent front end to all libRoadRunner’s integration engines.
Because MATLAB is familiar to many scientists, the MATLAB-like architecture reduces the effort to learn the libRoadRunner API. To simplify generation of simulation documentation, libRoadRunner methods support internal pydoc strings, which interactive Python environments such as IPython or Tellurium (make available as pop-up hints. The libRoadRunner API uses dynamic Python object properties to simplify access to SBML model values.
Loading an SBML-specified model via libRoadRunner automatically adds the SBML model’s symbol names to the RoadRunner object, allowing dynamic introspection and modification of the object. If a model contains parameters and species ‘x’, ‘y’, ‘S1’, ‘S2’, the RoadRunner object will include these names as properties, which a user can read or set. E.g., # load a model that has ids ‘x’, ‘y’ and ‘ S1’ r = RoadRunner( ‘ somemodel.xml’) r.x = 1.5 # set the ‘ x’ parameter to 1.5 r.y = 2.0 # set the ‘ y’ parameter to 2.0 print (r.S1) # print the ‘ S1’ species concentration. 4.4 Identification of conserved quantities Many biochemical network computations require identification of conserved quantities ( moieties in biochemical usage) and elimination of linearly dependent species to avoid inversion of singular Jacobian matrices. LibRoadRunner implements a libSBML plug-in which performs this reduction on SBML Document objects, first identifying conserved quantities and dependent species, then adding the conserved quantities to the document as set of global parameters and replacing the dependent species with assignment rules.
The user can modify these conserved quantities, which behave as parameters, to investigate their effect on the dynamics of the model. 5.1 The tellurium interactive network solver Tellurium is a cross-platform integrated Python environment based on the Spyder IDE (Tellurium combines libRoadRunner, libSBML, Antimony , libSEDML (and other packages to provide a comprehensive development and analysis environment for Antimony-specified models.
LibRoadRunner’s concise syntax and intuitive Python API are essential to Tellurium’s support for interactive creation, simulation and analysis of dynamic network models. 5.2 Integrating SBML-model specifications into multi-cell virtual-tissue models simulated in CompuCell3D CompuCell3D (CC3D), a simulation environment for multi-scale, multi-cell virtual-tissue model development and simulation, was the first tool to adopt libRoadRunner as a core engine. CC3D defines a cell object class and behavior methods to allow cell objects to grow, divide, die, secrete/absorb chemicals, move, etc. LibRoadRunner integration with CC3D allows the state of an SBML-specified model inside a cell object to control the CC3D parameters describing the cell object’s behaviors, and vice versa. E.g., in a model of changes in cell–cell adhesion leading to invasive tumor phenotypes, the CC3D cell objects have a CC3D parameter adhesion-molecule density, which controls the CC3D behavior cell – cell adhesion.
An SBML-specified model relates the level of the transmembrane adhesion receptor E-cadherin in each cell to the cells’ level of β-catenin. The CC3D-model specification uses the libRoadRunner Python API to connect the CC3D adhesion-molecule density to the SBML-model’s transmembrane E-Cadherin level. At run-time, libRoadRunner time evolves the network models inside cells, while a specialized CC3D engine handles the evolution of the cell objects. Another use of SBML models in virtual-tissue modeling is simulation of Delta-Notch patterning during embryonic development. Delta and Notch are heterophilic transmembrane receptors whose signaling is mutually inhibitory within a cell. The level of signaling depends on both the amount of Delta on the membrane of a cell and the amount of Notch on the surfaces of neighboring cells and vice versa. Thus, the dynamics of the signaling network depends not only the model within the cell, but the cell’s pattern of contacts with neighboring cells and their levels of Delta and Notch.
To model this situation, we create CC3D cell objects and arrange them in an epithelium (a quasi-2D sheet). Each cell contains an SBML-specified model that describes how the cell’s levels of membrane-bound and cytosolic Delta and Notch change, for a particular input level of transmembrane Delta and Notch signaling. A Python layer uses the libRoadRunner API to calculate the strength of Delta and Notch signaling each cell experiences from the amount of Delta on the membrane of each cell, the amount of Notch on the membrane of each adjacent cell (adjacency is a CC3D model parameter) and the CC3D model’s area of contact between each pair of cell neighbors. LibRoadRunner then updates cells’ Delta–Notch signaling and regulatory networks using these signaling strengths as boundary conditions, while CC3D updates the cell shapes, positions adjacencies and contact areas. Together, these interactions produce the checkerboard pattern typical of embryonic Delta–Notch signaling. 5.3 Multi-scale virtual-tissue modeling of liver metabolism The Virtual Liver Network has developed an organ-level model of human galactose clearance which includes single-cell metabolism of hepatocytes, the ultra-structure and micro-circulation of hepatic tissues, and the structure of the entire organ (The liver model includes an SBML-specified model of the sinusoid, the smallest functional unit of the liver, consisting of a perfused capillary surrounded by hepatocytes.
This is what happened to my client’s computer.
This model contains a biochemical network describing galactose metabolism in individual hepatocytes. Coupling via SBML-specified discretized transport equations for convection and diffusion results in a model with several thousand components and interactions. The sinusoid model uses SBML events to describe the time-varying supply of galactose to the liver. Accounting for heterogeneity in blood flow and tissue architecture requires simulation of more than 2 × 10 5 replicas of the model with varying tissue and flow parameters. This number of replicas was feasible because of libRoadRunner’s fast time-series generation and support for variable step sizes, which dramatically reduced output file size.
Using the CVODE solver, single simulation runs of the liver model take around 5–7 s on RoadRunner, resulting in a total simulation time of 4 h for 10 5 simulations on a cluster with 40 cores. LibRoadRunner’s Python API supported rewrite-free integration of the SBML models into a complex pre-existing modeling workflow, which included data management using Django, model annotation using Python bindings to libSBML, model prototyping using Python bindings to Antimony and visualization of results using the Python REST interface to Cytoscape with CySBML and CyFluxViz. 5.4 Modeling of synaptic, neuronal and neuron network dynamics in the MEMORY platform The MEMORY platform Multi-scale intEgrated Model Of the neRvous sYstem, formerly EONS simulates the function and dynamics of elements ranging from single channels or receptors ( elementary models), to synapses, which include many elementary models, to neurons, which themselves may include a large number of synapses. MEMORY depends on libRoadRunner’s flexibility and ease of use to assemble such complex hierarchical models. E.g., an SBML-specified neuron model may include many SBML-specified synapse models, each of which includes many SBML-specified neurotransmitter release and diffusion, AMPA receptor and NMDA-receptor models (both ionotropic receptors for the glutamate neurotransmitter). Neuronal models may be large, e.g.
Representing 10 ionotropic synapses in a CA1 neuron model (Izhikevich, 2003) requires 73 events, 290 reactions, 414 rules and 1459 parameters, so libRoadRunner’s fast time-series generation is essential for MEMORY to solve complex neuronal models quickly. To ensure that a neuronal model quantitatively predicts biological functions like membrane potentials or intracellular molecular concentrations, MEMORY can optimize the model’s parameters by fitting between multiple simulation and experimental time-series for characteristics including changes in receptor conductance, desensitization properties and spiking patterns. MEMORY uses evolutionary multi-objective optimization from the EMOO framework , which requires large numbers of simulation replicas.
E.g., elementary-model optimization of an NMDA-receptor model with respect to eight distinct experimental results for dynamical changes in receptor-channel conductance following paired-pulse stimulation, required 15 000 generations with 400 individuals per generation, i.e. 6 million simulation replicas (corresponding to 13 000 h of simulated time). LibRoadRunner took 66 h to run the entire optimization on a 400-node computer cluster, orders of magnitude faster than other SBML simulators. 6 Conclusions libRoadRunner’s speed and ease of integration allow researchers to solve very large models, include models embedded in multi-scale systems and run large ensembles of smaller models. LibRoadRunner’s Python API makes simulations easy to learn, while its C and C APIs are attractive to developers wishing to integrate libRoadRunner capabilities into existing simulation frameworks.
The Sbml Ode Solver Library Support Requests 10 Builds
LibRoadRunner runs on ×86 and ARM architectures and Windows, Mac OS X, Linux, Raspberry Pi, NVIDIA Jetson TK1 and ADAPTEVA Parallella boards. LibRoadRunner’s speed and ARM support will make tablet-based network applications practical despite tablets’ relatively slow CPU speeds. LibRoadRunner’s support for inexpensive processor boards such as the Raspberry Pi-2 allows individual researchers and students to more easily study cluster parallelization options.
Funding E.T.S., M.H.S. Acknowledge support from NIH grants R01 GM077138;, U01 GM111243;, R01 GM076692; and EPA RD83500101. Acknowledges support from the Federal Ministry of Education and Research (BMBF, Germany) within the Virtual Liver Network ( VLN grant 0315741). Acknowledges support from NIH grants P41 EB001978; and U01 GM104604. Acknowledges support from NIH grant R01 GM081070.
The content is solely the responsibility of the authors and does not necessarily represent the views of the National Institutes of Health. We acknowledge Totte Karlsson for the original C# to C translation, C compiler backend and C API, Stanley Gu for testing the library as a web service, Lucian Smith for developing part of the test suite, Michael Galdzicki for writing detailed build instructions and testing for developers. Conceived the project and helped with documentation, design and testing.
Designed the overall architecture of the libRoadRunner, developed the LLVM-based JIT compiler and wrote documentation. We thank Wilbert Copeland for bug fixing, testing and redesigning the integrator interface.
Conducted Linux testing and builds, M.K., J.A.G. Tested the code in simulations. KM ported the code to ARM processors and carried out the performance testing. We thank Holly Sawyer for proofreading the final draft. Conflict of Interest: none declared.