The NeuroML software ecosystem supports all stages of the model development life cycle.

NeuroML is a modular, hierarchical format that supports multi-scale modeling. Elements in NeuroML are formally defined, independent, self-contained building blocks with hierarchical relationships between them. (a) Models of ensembles of ionic conductances can be defined as a composition of gates, each with specific voltage (and potentially [Ca2+]) dependence that controls the conductance. (b) Morphologically detailed neuronal models specify the 3D structure of the cells, along with passive electrical properties, and reference ion channels that confer membrane conductances. (c) Network models contain populations of these cells connected via synaptic projections. (d) A truncated illustration of the NeuroMLv2 core element hierarchy. The standard includes commonly used model elements/building blocks that have been pre-defined for users in a hierarchical representation: Cells: neuronal models ranging from simple spiking point neurons to biophysically detailed cells with multicompartmental morphologies and active membrane conductances; Synapses and ionic conductance models: commonly used chemical and electrical synapse models (gap junctions), and multiple representations for ionic conductances; Inputs: to drive cell and network activity, e.g. current or voltage clamp, spiking background inputs; Networks: of populations (containing any of the aforementioned cell types), and projections between them, form the core of a NeuroML model description. The full list of NeuroML elements can be found in Appendix 1 Tables 4 and 5.

Step by step guides for using NeuroML, illustrating the various stages of the model development lifecycle. An updated list is available at http://neuroml.org/gettingstarted.

The ecosystem of NeuroML complaint tools and their relation to the model life cycle. The inner circle shows the core NeuroML tools that are maintained directly by the NeuroML developers. These provide core functionality to read, modify, or create new NeuroML models, as well as to analyze, visualize and simulate the models. The outermost layer shows NeuroML compliant tools which have been developed independently to allow various interactions with NeuroML models. These complement the core tools by facilitating model creation, validation, visualization, simulation, fitting/optimization, sharing and reuse. Further information on each of the tools shown here can be found in Appendix 1 Tables 1 and 2.

The core NeuroML software stack, and an example NeuroML model created using the Python NeuroML tools. (a) The core NeuroML software stack consists of Java (blue) and Python (orange) based applications/libraries, and the LEMS model ComponentType definitions (green), wrapped up in a single package, pyNeuroML. Each of these modules can be used independently or the whole stack can be obtained by installing pyNeuroML with the default Python package manager, Pip: pip install pyneuroml. (b) An example of how to create a simple NeuroML model is shown, using the NeuroMLv2 Python API (libNeuroML) to describe a model consisting of a population of 10 integrate and fire point neurons (IafTauCell) in a network. The IafTauCell, Network, Population, and NeuroMLDocument model ComponentTypes are provided by the NeuroMLv2 standard. The underlying dynamics of the model are hidden from the user, being specified in the LEMS ComponentType definitions of the elements (see Methods). The simulator-independent NeuroML model description can be simulated on any of the supported simulation back-ends. (c) XML serialization of the NeuroMLv2 model description shows the correspondence between the Python object model and the XML serialization.

Workflow showing how to create and simulate NeuroML models using Python. The Python API can be used to create models which can include elements built from scratch from the core NeuroML standard, re-use elements from previously created models, or create new components based on novel model definitions expressed in LEMS (red). The generated model elements are saved in the default XML-based serialization (blue). The NeuroML core tools (orange) include modules to import model descriptions expressed in the XML serialization, and supports multiple options for how simulators can execute these models (green). These include native execution of the NeuroML models by core simulators (1) and others such as EDEN (2) and generation of helper Python scripts allowing direct importation of the NeuroML model by simulators which support this (3). For other simulators, the fully expanded LEMS description of the models can be generated, which can be mapped to simulator specific formats to generate scripts to run in the target simulators (4). Finally, a number of other standardized formats are supported (5), to which the loaded model can be mapped.

NeuroML model development incorporates multi-level validation of models. Checks are performed on the model descriptions (blue) before simulation using validation at both the NeuroML and LEMS levels (green). After the models are simulated (yellow), further checks can be run to ensure the output is in line with expected behavior (brown). The OSB Model Validation (OMV) framework can be used to ensure consistent behavior across simulators, and comparisons can be made of model activity to their biological equivalents using SciUnit.

Visualization of detailed neuronal morphology of neurons and networks together with their functional properties (results from model simulation) enabled by NeuroML. (a) interactive 3-D (VisPy (Campagnola et al., 2023) based) visualization of an olfactory bulb network with detailed mitral and granule cells (Migliore et al., 2014), generated using pyNeuroML. (b) Visualization of an inhibition stabilized network based on Sadeh et al. (2017) using Open Source Brain (OSB) version 1 (Gleeson et al., 2019). (c) Visualization of network of simplified multicompartmental neurons together with spiking properties using NetPyNE’s GUI (Dura-Bernal et al., 2019), which is embedded in OSB version 2.

Analysis and visualization of network connectivity from NeuroML model descriptions prior to simulation. Network connectivity schematic (a) and connectivity matrix (b) for a half scale implementation of the human layer 2/3 cortical network model (Yao et al., 2022) generated using pyNeuroML.

Examples of analysis functions available for a NeuroML model neuron. (a) Electrophysiological analysis features provided by the NeuroML-DB web based platform (Birgiolas et al., 2023). Plots show four superimposed voltage traces in the top panel and corresponding current injection traces below). (b) Example plots of steady states of activation (na_channel na_m inf) and inactivation (na_channel na_h inf) variables and their time courses (na_channel na_m tau and na_channel na_h tau) for the Na channel from the classic Hodgkin Huxley model (Hodgkin and Huxley, 1952). (c) The distribution of the peak conductances for the Ih channel over a layer 5 Pyramidal cell (Hay et al., 2011). Both (b) and (c) were generated using the analysis features in pyNeuroML, and similar functionality is also available in OSB (Gleeson et al., 2019).

Example model description of a HindmarshRose1984Cell NeuroML component. (a) XML serialization of the model description containing the main hindmarshRose1984Cell element, with a set of parameters which result in regular bursting. A current clamp stimulus is applied using a pulseGenerator, and a population of one cell is added with this in a network. This XML can be validated against the NeuroML Schema. (b) Membrane potentials generated from a simulation of the model in (a). The LEMS simulation file to execute this is shown in Fig. 14.

Type definitions taken from the NeuroMLv2 schema, which describes the structure of NeuroMLv2 elements. Top: “simple” types may not include other elements or attributes. Here, the Nml2Quantity_none and Nml2Quantity_voltage types define restrictions on the default string type to limit what strings can be used as valid values for attributes of these types. Bottom: example of a “complex” type, the HindmarshRose cell model (Hindmarsh et al., 1984), that can also include other elements of other types, and extend other types.

LEMS ComponentType definition

of the HindmarshRose cell model (Hindmarsh et al., 1984).

Example model description of a HindmarshRose1984Cell NeuroML component in Python, using parameters for regular bursting. This script generates the XML in Fig. 10.

An example simulation of the HindmarshRose model description shown in Fig. 13, with the LEMS serialization shown at the bottom.

Documentation for the HindmarshRose1984Cell NeuroMLv2 ComponentType generated from the XSD schema and LEMS definitions on the NeuroML documentation website, showing its dynamics. More information about the ComponentType can be obtained from the tabs provided.

NeuroML software core tools, with a description of their scope, the main programming language they use (or other interaction means, e.g. Command Line Interface (CLI)), and links for more information.

Tools in the wider NeuroML software ecosystem, with a description of their scope, the main programming language they use (or other interaction means, e.g. through a web browser, Graphical User Interface (GUI) or Command Line Interface (CLI)), and links for more information.

Listing of validation tests run by NeuroML

Index of standard NeuroMLv2 ComponentTypes

Index of standard NeuroMLv2 ComponentTypes (continued)

Listing of NeuroML models and example repositories