From Model Specification to Simulation of Biologically Constrained Networks of Spiking Neurons
- First Online:
- Cite this article as:
- Richmond, P., Cope, A., Gurney, K. et al. Neuroinform (2014) 12: 307. doi:10.1007/s12021-013-9208-z
- 1.4k Downloads
A declarative extensible markup language (SpineML) for describing the dynamics, network and experiments of large-scale spiking neural network simulations is described which builds upon the NineML standard. It utilises a level of abstraction which targets point neuron representation but addresses the limitations of existing tools by allowing arbitrary dynamics to be expressed. The use of XML promotes model sharing, is human readable and allows collaborative working. The syntax uses a high-level self explanatory format which allows straight forward code generation or translation of a model description to a native simulator format. This paper demonstrates the use of code generation in order to translate, simulate and reproduce the results of a benchmark model across a range of simulators. The flexibility of the SpineML syntax is highlighted by reproducing a pre-existing, biologically constrained model of a neural microcircuit (the striatum). The SpineML code is open source and is available at http://bimpa.group.shef.ac.uk/SpineML.
KeywordsXML Simulation Translation Interoperability Spiking neurons Neuronal networks
There is currently no clear consensus on the appropriate biological abstraction level for capturing the information processing aspects of the brain. Consequently there is a wide range of simulation tools and languages within the domain of computational neuroscience focusing on differing biological levels from networks of artificial neurons to molecular modelling of individual ion channels. In the context of specification and simulation of networks of spiking point neurons it is important that modelling tools provide a level of abstraction w is computationally efficient to simulate but while still allowing a sufficient degree of flexibility to describe a wide range of neuronal phenomena.
Conceptually and practically, it is also now recognised that it is desirable to separate the functions of a model specification and model simulation. The model specification should be easily human readable, unambiguous, and comprehensive, but also facilitate translation into executable code. Additionally, the model specification should be easily translated to multiple simulation platforms, both existing and new. Consider, for example, the microcircuit model described in (Humphries et al. 2009b) described by a mixture of hand written C and Matlab code. This is an anatomically accurate model of the striatum - the main input nucleus to the basal ganglia (a group of interconnected subcortical nuclei). The model uses 2-variable point neurons with physiologically realistic attributes such a dopaminergic modulation (Humphries et al. 2009a) and gap junctions (Humphries et al. 2009b). Translating this model into a higher level modelling description facilitates sharing, portability, repeatability and collaboration. Representation in a high-level format requires the flexibility to specify modified Izhikevich neuron body dynamics, enabling the behaviour resulting from differing ion currents to be captured. Similarly, to model inter-cell communication via gap junctions, support for neural components to communicate without using typical ‘synaptic’ connectivity is also essential.
An ideal modelling format to describe biologically constrained models would be simulator independent. Aside from specification clarity, simulator independent formats allow a developer to cross-check models through execution on a range of simulator engines (assuming simulator support is available). A number of simulator independent tools are available for describing a neural network models at various abstraction levels (Davison et al. 2009; Gleeson et al. 2010; Raikov et al. 2011). For the modelling requirements of the striatum, NineML (Raikov et al. 2011; Gorchetchnikov et al. 2011) was found to be the most suitable format. NineML was initiated by the INCFs Multiscale Modelling Program to address the limitations of both PyNN and NeuroML v.1. More specifically, it bridges the gap between the fixed library of standard neuron types in PyNN and the focus of conductance-based compartmental cell models in NeuroML by allowing neurons with arbitrary dynamics and networks with arbitrary connectivity to be expressed in a declarative simulator independent format. A library ‘libNineML’ exists for loading, saving and manipulating the NineML abstraction layer components as well as providing some translation of components to common simulators (NEST, Neuron and Brian). Unfortunately the current NineML format and simulator integration is incomplete, making it difficult to simulate complete network models described entirely in NineML.
This paper first outlines the design goals of the SpineML object format and toolchain before introducing examples of the syntax. Results from a benchmark model are presented in addition to results from reproducing a biologically constrained model of the striatum. The flexibility and the modelling syntax, code generation details and a description of the supported simulators are then presented. The paper concludes by discussing the advantages of the SpineML format in comparison with alternative notations.
To support the declarative specification of a wide range of (neuronal) dynamics and network connectivity.
To improve the ease and speed of model design and implementation.
To improve the understanding of model definitions through a clear descriptive format.
To facilitate and promote the sharing of models.
In order to meet these aims the following design goals are proposed;
A separation of implementation from model description
minimises implementation error by reducing the modelling task to that of simply describing the biological system. This ensures models can be easily reproduced from mathematical and diagrammatic descriptions which are common in journal publications. This design goal is highlighted as the main benefit of the NineML format. SpineML embraces this design goal by following the same layered specification which allows modular components describing neural dynamics to be expressed as differential equations rather than as solutions (i.e. implementations of equations using a given numerical solver) and by ensuring experimental details of a simulation (i.e. the numerical solver, duration, inputs and outputs and parameter changes) are specified separately from other aspects of the model description.
A platform independent model description format
promotes collaborative working and meets the aim of facilitating the sharing of model data. Reducing external software dependencies allows model development to take place without access to simulation tools. SpineML uses a declarative XML syntax to describe all aspects of models and simulation experiments. The use of XML ensures models are represented in a stand alone plain text form achieving the maximum level of independence from external tools e.g. simulators or graphical modelling tools.
A self explanatory syntax
ensures that models can be easily understood and interpreted without the addition of either ambiguous plain text descriptions or assumed knowledge of procedural programming languages. To achieve this goal, SpineML uses a high-level and highly structured model representation with an expressive syntax ensuring that the aims of improving model clarity and ease of creation are fulfilled.
An unambiguous model description
requires a succinct form with a guarantee of syntactical correctness. SpineML ensures models follow a structured and syntactically valid format through the use of a declarative syntax governed by XML Schemas. A well structured syntax is essential for automated code generation as it ensures that simulation code can be generated which is free from errors. Most importantly, an unambiguous format ensures that independent tools can be used to create or simulate models. Finally schema integration within common XML editors (e.g. Eclipse, Visual Studio) encourages the use of content assistance and auto completion aiding the speed and ease of model creation.
Allowing a wide range of biological phenomena to be represented
requires that model designers can go beyond a limited (library) set of pre-selected neuron and synapse implementations by providing equations to describe behaviour. Furthermore, model designers should not be constrained by the functional limitations of any particular simulator which would require hand-written code (which is considered the least portable and understandable form of representation). SpineML allows the description of such models by providing a clear separation between ‘components’ which describe behavioural (i.e. neurons and synapses) and the network which describes how components are connected.
Good integration with existing simulators
should be demonstrated. It is inevitable that not all simulators will be able to provide support for all aspects of any proposed specification, particularly with respect to network connectivity. It is therefore proposed that there should be an extendible network description format for the SpineML specification. Primarily the network layer should consist of a ‘high-level’ format to describe populations and projections, concepts supported by the majority of point neuron simulators and a ‘low-level’ network format extension that allows communication other than through chemical synapses between components (e.g. gap junctions and neuromodulators) for a smaller subset of simulators which support this functionality.
Object Model and Examples
The following three sections of this paper describe each of the layers in detail using an example of a network of inhibitory and excitatory neurons (Vogels and Abbott 2005) to highlight the XML modelling syntax. The example has been selected because it has been subjected to extensive benchmarking (Brette et al. 2007) for a range of simulators.
The Component Layer
Cellular level ‘ComponentClass’ definitions provide the building blocks of neural dynamics within a complete network model description. The ‘component’ level syntax of SpineML is directly derived from the NineML ‘abstraction’ layer which shares a number of features and common goals with LEMS1 and NeuroML 2.0.2 A complete object model for this layer is described on the NineML website and a complete Schema for SpineML is available on the SpineML website. The SpineML ‘component’ level and NineML ‘abstraction’ level differ only with respect to the syntax describing ports (shown in the subsequent examples) and that within SpineML dimensionality and unit are specified as a single SI attribute.
The Network Layer
The WeightUpdate (line 9) and PostSynapse (line 14) element definitions follow the same property syntax as that of a neuron body. A url and name attribute must be specified however size is omitted as it is dynamically derived by either the connectivity pattern or the destination population size respectively.
Additional attributes within WeightUpdate and PostSynapse describe the dynamics connectivity of component ports to form a chain consisting of the pre-synaptic population, the weight update, the post-synapse and the post-synaptic neuron models. Within the WeightUpdate element the input source attribute (line 11) and input destination attribute (line 12) name the ports in which the pre-synaptic neuron (source) component connects to the weight update component (destination). Weight update input ports are typically linked by event ports which transmit instantaneous spike events. Within the PostSynapse element the input source attribute (line 16) and input destination attribute (line 17) name the ports in which the weight update component (source) connects to the post-synapse component (destination). Post-synapse input ports are typically linked by impulse event ports which, in the worked example, injects a current into the post-synaptic model following a spike event. The output source (line 18) and output destination (line 19) attributes within the PostSynapse element name the ports which link the post-synapse (source) to the post-synaptic population (destination). Analogue ports typically are used to emit current values from a post-synaptic model. An analogue reduce port within the post-synaptic neuron allows multiple post-synapse values to be summed. The WeightUpdate element has an additional, optional feedback source and destination port enabling information to be channelled from the post-synaptic neuron back to the weight update for learning (not required in the example). As with neuron bodies, both a weight update and post-synapse definition are used to specify properties (not shown). The full benchmark model including fully specified weight update and post-synapse properties is available from the tool-chain website.
Extending the Network Layer
The use of high-level conceptual constructs such as populations and projections simplifies the processes of describing traditional point-based network descriptions. In particular the implied fan-out and fan-in of connectivity between neurons, weight update and the post-synapse items makes the high-level network description particularly compact and intuitive. Additionally the concept of a projection is shared by many neural simulators, simplifying the mapping processes during the code generation stage. Unfortunately, sole use of projection based connectivity is not suitable for describing communication other than chemical synapses (e.g. gap junctions and neuro-modulators). Consequently the ‘high-level’ object model is extended to form a ‘low-level’ object model (also shown in Fig. 5) which allows the direct connection of components via Inputs and Groups of component instances which do not specifically represent neuron bodies. The implications for simulators needing to support the ‘low’ level schema is that a generic (communication other than chemical synapses) method of connecting components must be available.
Within the low level network format, a Group object inherits AbstractComponentInstance and represents a set of component instances with a fixed size. Functionally a group is equivalent to a population with no projections, however the term group is used to distinguish between populations which do not represent neuron objects. The connection of a Group within a network is provided through the use of a generic Input. An Input uses a connectivity type to describe a remapping of an analogue, impulse or event value from a named source component. For worked examples of the low level network syntax, readers are directed to the Striatal modelling example which demonstrates gap junctions connected via inputs, available in full on the SpineML website.
The Experimental Layer
The final phase of specifying a model is describing a simulation, to be conducted. The syntax of the experimental layer is similar to the SEDML experiment design language (Waltemath et al. 2011) but adds essential support for experiment inputs. It consists of details including the network model to be simulated, the period of simulation and the numerical integration scheme to be used. In addition to specifying model outputs, the experimental layer also supports the definition of model inputs, both of which interact directly with the dynamics of a model by logging or sending data to named component ports (shown in Fig. 2).
Simulation Toolchain and Results
Reproducing a Model of the Striatum
The flexibility of the SpineML Syntax and the robustness of the XSLT code generation tool-chain are demonstrated by implementing three complete sets of templates for each of the three supported simulator back ends. Each set of translation templates varies from generation of a simulator configuration files (BRAHMS), to the generation of simulator API code (PyNN and BRAHMS), through to the generation of low-level C like code (DAMSON) for simulation on neuromorphic hardware. Because the range of code generation outputs for each of the supported simulators is different, specific code templates are required for each simulator (without shared templates). The advantage of unique simulator templates is that optimisations for each simulator level ensure optimal performance. Adding support for a new simulator requires that a suitable XSLT template (or set of templates) is constructed to map the dynamics or the component layer models, the structure of the network layer and the simulation details of the experimental layer. Simulators which have a close correlation with the SpineML object model (such as PyNN) require simpler code generation templates. The range (in terms of simulator architecture) of currently supported simulators also provides a good starting point for adding new simulator support.
The following sub-sections describe the design of the SpineML Schemas with particular emphasis on the extension mechanisms used to differentiate between low and high-level network descriptions and to add new network layer functionality. The XSLT code generation strategy is also presented with examples, followed by a description of the implementation of code generation templates, including any limitations, of each of the three supported simulators.
Flexible XML Schemas
Various techniques can be used to design XML Schemas which range in their simplicity and flexibility. The simplest of these is often referred to as a ‘Russian Doll’ design and comprises a highly nested set of elements where only the root element has a global scope. Whilst very compact, this design technique is highly self-contained and changes made to types within the narrow local scope are not propagated to other Schemas or global definitions. The ridged structure offers similar functionality to Document Type Definition (DTD) validation but is unable to take advantage of type reuse. In contrast, the ‘Flat’ model (or sometimes known as the Salami Slice design) is highly reusable and consists of entirely globally defined elements which may be referenced by other element definitions within a Schema (or within Schemas which import it). The Flat model offers the ability to exploit substitution groups which offer similar functionality to object oriented polymorphism. This capability is desirable as new extensions can be easily integrated without daisy chaining changes in a schema. The final schema design type, the ‘Complex Type’ model (or Venetian Blind design) consists of a hierarchy of globally defined complex types with a single root element. This schema design method allows type extensions or restrictions offering functionality similar to object oriented inheritance. Consequently, this design type is used within NineML, NeuroML and LEMS and provides a sound method for designing schemas to describe hierarchies of increasingly complex neuron types. Its limiting factor is that it does not support the use of substitution. Therefore, new additions require the original schema to be changed.
The above method provides an extension mechanism that allows a core schema to remain unchanged whilst new schemas are proposed to add new functionality such as connection types. This method is used to enable the addition of Groups with the low level schema and to ensure that the low level schema forms an extension of the high-level schema, adding new functionality in the form of inputs for all types of component instances (e.g. Neuron, WeightUpdate and PostSynapse).
XSLT Code Generation
The mapping of a SpineML model to a simulation engine requires translation of the model using code generation (Goodman 2010). Code generation for SpineML has been provided through the use of XSLT templates. XSLT is used widely in the translation of XML documents to other HTML or other XML document formats on the web. Nevertheless, there is no restriction on the type of file that can be generated from an XSLT template and it is hence suitable for the generation of native simulator source code. XSLT standards are well defined and a number of compliant processors are available which can be used to generate identical output (e.g. XSLTProc, Saxon, Xalan and Visual Studio). In all cases, an XSLT processor works by recursively querying XML nodes through XPath expressions and applying a template to process the content of each node. In the case of generating simulator code, a model is processed by querying experiment, network layer and component layer documents recursively using the branching and control elements of XSLT to generate plain text.
BRAHMS is described as middleware for integrated systems computation which has roots in the domain of biological modelling. Internally it contains a modular based execution framework (MEF) which links a number of software components with varying levels of abstraction. It has been used extensively for the simulation of spiking neural systems (Sullivan et al. 2012; Fox et al. 2009). As a result of its modular design, there is a straightforward conceptual mapping from the SpineML modelling syntax. BRAHMS supports both the high and low-level network format without any restrictions and serves as a reference simulator.
Translation of a PyNN model to SpineML has not yet been implemented. However PyNN stores a model description by building an internal ‘flat’ model representation within memory. Any procedural techniques used within Python to generate properties or connections within PyNN can be converted to explicit lists and exported to the SpineML network layer format.
Given the scale and power efficiency of the SpiNNaker hardware system, aimed at a million ARM processing cores supporting up to a billion real-time neurons, translation of SpineML to a suitable SpiNNaker format is highly desirable. The DAMSON3 language is an event-driven version of C with both SpiNNaker hardware support and functional emulation. Templates for generating DAMSON code map individual populations to SpiNNaker processors and create functions for handling simulation events (either spike based or analogue) which are routed between SpiNNaker cores as broadcast messages. In the case of large population sizes, an additional splitting stage (beyond the scope of this paper) can be used to aid parallelisation by evenly distributing the model across processing cores. Owing to the limited functionality of SpiNNaker ARM processing cores, all arithmetic within DAMSON is performed using an integer fixed-point format. The simulation results within this paper and from previous work (Sharp et al. 2012) demonstrate that this resolution is sufficiently accurate if scaling is handled carefully. The flexibility of the DAMSON language allows full implementation of both the high and low-level network layer formats with a few restrictions relating to weight update dynamics which are imposed by the requirement of real-time simulation. The first of these restrictions is that weight update components must (currently) be entirely event-based to reduce computational load. This constraint requires that the weight update component model communicates only via event or impulse ports and does not contain any time derivative within any of its regimes. For the same reason weight updates are not able to have generic inputs. Although it is possible to circumvent both restrictions by splitting a projections weight update and post-synapse into separate generic components (which will be allocated to different cores) future work will examine more effective ways of reducing the computational load per processing core in order to handle non event-based weight updates.
In this paper, SpineML, a declarative XML syntax extending the NineML format has been presented. The proposed extensions to NineML allow complete specification of complex biologically constrained point neuron network models, demonstrated in this paper through the specification of a model of the striatum. A code generation tool chain demonstrates the completeness of the syntax and its suitability for code generation with respect to point neuron networks of varying complexity.
Flexibility of modelling, in order to allow a wide range of biological phenomena to be represented, has been addressed within the SpineML network layer. The modular design provides a separation of the post-synaptic model and the model of a neural cell. The extension point mechanism allows a distinction between models containing only projection-based connectivity (high-level) and models which contain additional non-neural components and communication through mechanisms other than chemical synapses. The separation of the post-synaptic response is an important factor in reproducing biologically constrained models. For example, within the Striatal model, different post-synaptic dynamics are required for the NMDA component of the glutamatergic synapses of Medium Spiny Neurons (MSNs) compared to the GABAergic synapse and AMPA component which require a term to reproduce the effect of a blocking Magnesium current. Similarly, the post-synaptic currents have differing effects on AMPA and NMDA receptors in D2 MSNs and D1 MSNs respectively.
Both the PyNN API and NeuroML provide an alternative approach to model standardisation for simulator independent point neuron modelling. PyNN uses the high-level Python programming language to unify a range of simulators which have Python interfaces (Hines and Carnevale 1997; Eppler et al. 2009; Goodman and Brette 2008). The drive towards Python as a common language for simulators is understandable. As a high-level language it is open source, has a simple yet powerful syntax and supports extensive libraries for scientific computing data analysis and visualisation. NeuroML v1.0 is a declarative XML based description language for model specification and exchange with a focus on morphological neural systems. NeuroML v2.04 has extended its remit to also include the specification of point neuron networks. It has been developed alongside the Low Entropy Model Specification (LEMS) for specifying generic models of dynamical systems. The NeuroML v2.0 schemas provide a hierarchical structure of cell and synapse models which make reference to LEMS components (called ComponentTypes). A NeuroML v2.0 model description can therefore be used to either map a cell description to native simulator parameters or be used in conjunction with LEMS for code generation.
A comparison of SpineML can be made with PyNN and NeuroML both with respect to specification of neural components and networks. In terms of component specification, the SpineML component layer makes relatively few changes to the NineML abstraction layer; the two are largely compatible and have some degree of overlap with LEMS (and hence NeuroML). SpineML differs from PyNN in that there is a focus on more flexible (biologically constrained) model specification (e.g. allowing specification of new neuron, learning or post-synaptic response models), rather than on extensive simulator support. As a result, PyNN is unable to provide the functionality for describing new neural components in a simulator independent fashion. Some initial attempt at integrating LEMS and the NineML abstraction layer with PyNN have however been made. The integration relies on non-standard PyNN neurons being translated to simulator specific implementations through code generation with only the network described by PyNN. The NeuroML v2.0 schema defines support for point neurons with a strong overlap with standard PyNN neuron types. Both PyNN and NeuroML v2.0 descriptions of PyNN standard cell types utilise a combined post synapse and neuron cell models (the disadvantages to this approach have been covered in section “PyNN”).
Both SpineML and NeuroML v2.0 present a large degree of flexibility in that LEMS can be used to describe new dynamics. Where NeuroML v2.0 and SpineML differ with respect to network specification in that a new LEMS model requires the additional specification of a compatible schema (extending one of the core NeuroML v2.0 model types) in order to provide XML validation of a parametrised (LEMS) model description. Within NeuroML v2.0 a parametrised model description can then be referenced by a population object with the advantage that the parametrised model may be reused by multiple populations. In contrast, SpineML does not require any additional schema specifications to allow XML validation for paramaterisation of new ‘component’ model. Neuron, synapse, post synapse (and groups) are instantiated directly within a network layer model description by referencing a component layer object directly. The underlying schema remains unchanged, simplifying the XSLT code generation process. Although SpineML is not currently able to reuse parametrised components, the decision to omit this functionality is based on the need to be able to visually represent the networks of instantiated components within graphical editing tools. How parametrised but unused components would be represented within a conventional visual design tool is not immediately clear but will be considered in future work. PyNN’s lack of support for connectivity through mechanisms other than chemical synapses within a network description has already been documented. Aside from differences in the specification of synapses, SpineML and PyNN differ in that PyNN utilises a procedural programming language. Although Python code can be written in a declarative way, the procedural nature of the Python language can make it more difficult to infer the overall structure of a model and discovering the value of a modelling parameter can often be less intuitive than in a purely declarative specification.
Considering model storage, XML is advantageous in terms of readability and portability but can perform poorly in file size. Models containing large explicit lists of properties of connectivity can easily become unwieldy due to the mark up notation used. XML tags contain large data redundancy although compression techniques work well in reducing file sizes. Alternatively, binary file formats for explicit lists will be added to the high-level network schema format at a later date. Additional distance based connectivity primitives would also help to alleviate file size for models such as the Striatal example where complex distance based connectivity functions (Humphries et al. 2010) are currently described as explicit lists, contributing to over 99 % of the total file size.
Performance of the XSLT processor in translating a model to native simulator format is dependent on the simulator specific templates. XSLT stores both a model and the template entirely in memory (within a DOM tree) ensuring that XPath queries are fast, restricting models to those which fit entirely in memory. Although the benchmark model presented within this paper has been scaled to gigabyte network layer model sizes and has been used for code generation, beyond this scale, the use of streaming templates may be necessary to reduce memory usage. Alternatively a combination of XSLT to generate native simulator ‘programs’ with a more optimised streaming code generation method for native simulator ‘data’ is entirely feasible.
The main focus for future work will be in advancing the development of graphical user tools for declarative model specification. Current prototype tools require the addition of a layout layer for saving layout of neurons and populations within 3D space for use in both generating complex spatially-based connectivity patterns and visualisation. Integration between SpineML and NineML will be pursued via community driven discussions. Translation to a range of other simulator formats including NEST and NEURON which each offer support for custom components will also be considered as will support for GPU based simulation.
Information Sharing Statement
The model layer schemas and example models presented within this paper (namely the benchmark model and Striatal model) are available in complete form from the SpineML website (http://bimpa.group.shef.ac.uk/SpineML). Additional documentation and additional simulator configurations are also available to aid users in reproducing the experiments and results presented.
This work was supported by ESPRC via the Biologically-Inspire Massively Parallel Architectures (BIMPA) grant (EP/G015627/1) and via EPSRC Delivery Plan ‘Kickstart’ funding.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution License which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the source are credited.