NeuroML version 2.0 beta
Developments towards NeuroML version 2.0 are well under way, but version 1.8.x should be considered the stable version for now, especially for application/model developers who want maximum compatibility with other tools.
For details of the meetings which have taken place to date where NeuroML v2.0 has been discussed see here.
| The NeuroML schema, examples and libraries have undergone major changes recently for the NeuroML v2.0 beta release, including
a shift of most code development to individual GitHub repositories. For the very latest details see here. |
NeuroML v2beta Schema
A draft specification for NeuroML v2beta has been created. The working structure of NeuroML v2beta is defined by a single XML Schema file: NeuroML_v2beta.xsd.
Most of the work listed below aims to handle XML files valid according to this schema. This should be the target structure for anyone wishing to implement NeuroML 2 support at this stage.
This image shows some of the elements currently defined in NeuroML v2beta. The overall structure is similar to NeuroML version 1.x Level 3 (see figures 4-6 here). Note that there are a greater range of cell models supported (e.g. Izhikevich spiking cell, adaptive exponential integrate & fire) in addition to the multicompartmental conductance based models which were a focus of version 1.x.
Examples of NeuroML 2 files using this schema are available here:
- A simple cell with morphology & segment groups
- A cell with biophysical properties (channel densities, passive electrical properties, etc.)
- A simple HH Na+ channel
- Some of the simplified spiking neuron models which are supported
- Some synapse models (single/double exponential conductances, NMDA-R synapse)
- A network of populations of cells in 3D
- A full NeuroML v2beta network model description with cells, channels, populations and networks
Development of LEMS & mapping to NeuroML 2
LEMS (Low Entropy Model Specification) is a new XML based language with interpreter developed by Robert Cannon for specifying generic models of dynamical systems. ComponentType (ComponentClass has also been used as a name for these, see below) elements which specify Parameters, StateVariables and their dynamical Behaviours can be defined as templates for model elements (e.g. HH ion channels, abstract cells, etc.). Components are instances of these with specific values of Parameters (e.g. HH squid axon Na+ channel, I&F cell with threshold -60mV, etc.).
A Java package, jLEMS, which includes examples of LEMS files together with the interpreter for executing them is available here.
A core set of ComponentTypes describing the behaviour of dynamical elements in NeuroML 2 has been defined in LEMS:
- Cell models: Cells.xml (source in LEMS)
- Network elements: Networks.xml (source in LEMS)
- Ion channels: Channels.xml (source in LEMS)
- Synapse models: Synapses.xml (source in LEMS)
- Mapping of PyNN cells & synapses: PyNN.xml (source in LEMS)
- Dimensions/units allowed: NeuroMLCoreDimensions.xml (source in LEMS)
These serve as the basis for Component definitions in NeuroML 2 files, e.g. izhikevichCell, iafTauCell, ionChannelHH, etc. The behaviour of the model element (e.g. the behaviour of v in terms of threshold, reset, tau in a simple I&F cell) is specified in the ComponentType, and the user only has to supply the name of the ComponentType and give parameter values to create a Component in their NeuroML file.
This image shows the usage of LEMS ComponentTypes & Components in NeuroML
Note that specifying a Component does not imply that an instance of the model is created. Instances will only be instantiated when the cells are created in a population which is present in a network.
Using LEMS to specify the core of NeuroML version 2 has the following significant advantages:
|
NeuroML 2 XML files can be used standalone by applications in the same way as NeuroML v1.x, without using LEMS, easing the transition for v1.x compliant applications
Any NeuroML 2 ComponentType can be extended and will be usable by any application (e.g. the LEMS Reference Implementation) which understands LEMS |
The first point above means that a parsing application does not have to natively read the LEMS type definition for, e.g. an izhikevichCell element, it just has to map the NeuroML element parameters onto its own object implementing that entity. The behaviour should be the same and should be tested against the reference LEMS implementation.
The second point above means that if an application does support LEMS, it can automatically parse (and generate code for) a wide range of NeuroML 2 cells, channels and synapses, including any new ComponentType derived from these, without having to natively know anything about channels, cell models, etc.
Specifications & examples
The table below summarises the current specifications for LEMS & NeuroML 2.
| Specification | Documentation | Examples | |
|---|---|---|---|
| LEMS | LEMS_v0.6.xsd | LEMS element definitions | LEMS examples |
| NeuroML v2beta | NeuroML_v2beta.xsd | NeuroML 2 Core ComponentTypes | NeuroML 2 examples |
Implementations & APIs in Java and Python
The table below summarises the different capabilities of the Java and Python libraries for handling LEMS & NeuroML.
| Java | Python | |
|---|---|---|
| Read, validate & execute LEMS XML files | jLEMS | PyLEMS |
| Read & write NeuroML 2 files | Java API for NeuroML 2 | libNeuroML |
| Everything... | jNeuroML Parse & execute LEMS; validate NeuroML v1/v2; convert LEMS to graphical format, NEURON, Brian, etc.; convert SBML to LEMS... |
What's missing?
A summary of the holes & areas of current work in the current specifications...
- Network connection templates: more advanced options for defining connectivity between populations of cells is required. This is being worked on in collaboration with development for PyNN
- Support for multi compartment modelling in LEMS: While the NeuroML v2beta Schema supports description of multi compartmental conductance based neuronal models, the LEMS interpreter can only execute single compartment cell models at present.
- Better numerical integration in LEMS: At present jLEMS uses a simple forward Euler numerical integration method by default, limiting the size and speed of simulations. Other numerical integration options are in development...