Am I interested?
  • SystemML facilitates the sharing between workers of complex computational models consisting of multiple unrelated parts (a bit of GENESIS, a bit of MATLAB, a bit of bespoke algorithm, a bit of robot control).
  • SystemML, the file format, allows the representation of such models in an open and extensible way, placing no constraints on the representations of the component parts (GENESIS, MATLAB, etc.).
  • SystemML, the infrastructure, supports the distribution of resources required to run these models (e.g. bespoke algorithms).

If you construct models of this type, and you do not work entirely on your own (or even if you do), you may find that SystemML can reduce your work-load, whilst allowing others to take advantage of (or admire, or find flaws in) your work much more easily.

For details of what was working sufficiently badly that we felt it was worth investing substantial time in this and associated projects, see The Integration Problem.


SystemML is actively in use and under active development. It is not currently considered mature, but as far as we know it is the only completely general proposal of its kind.

What is SystemML?

SystemML forms the interface both between software tools (model execution tools like GENESIS as well as model design tools like NodeWeaver) and between people (workers in a single group, in wider consortia, and beyond).

SystemML is both an open file format and an infrastructure facilitating the sharing of computable systems between computational researchers. Thus, a researcher can run somebody else's model out of the box, or modify it, or integrate all of it or just parts of it into their own work. SystemML can be said to delineate between Parametrized Models (p-models) and Unparametrized Models (u-models). p-models are SystemML documents and are distributed amongst researchers using whatever means is appropriate (e.g. ModelDB). Implementations of u-models on which such documents hinge may be distributed through the SystemML infrastructure.

A SystemML File Format document "project.xml" might hold a representation of a p-model consisting of three parts: brain, robot, and world. "brain" may be a NeuroML p-model of sensorimotor loops and decision making, designed to execute on the u-model GENESIS. "robot" may be a RobotML p-model representing legs and wheels, sensors and actuators, designed to run on the u-model ROBOT (bespoke software for this project). "world" is perhaps a WorldML parametrization of the Webots 3D world simulator. Each part is written in a different format, understood only by its target u-model. Yet the three are fitted together into a system that can be computed by any SystemML-ready execution client that can find the appropriate plug-ins for GENESIS, ROBOT, and Webots (the job of the execution client, then, is to provide resource allocation, synchronization, and data marshalling for and between the included u-models). In addition, a researcher can extract just the p-model "brain", and take it away for modification, examination in another environment, or for inclusion in their own project.

SystemML, the infrastructure, is a way of distributing the u-models that underlie the p-model documents, both as unambiguous specifications and as implementations for particular execution clients. It is implemented as a set of SystemML Namespace servers and a collection of tools for interacting with those. The expandable collection of servers, focussed around one public server which carries the public parts of the Namespace, serve u-model specifications and implementations in response to requests constructed by the tools. In addition, the servers offer various web interfaces to the information they hold, allowing humans (or the tools) to browse what is available or to obtain reference information, for example. Together, the tools and the servers allow your local machine to maintain a library of u-models for execution by a SystemML-ready execution client, such as BRAHMS.

SystemML is general: it was born in Computational Neuroscience, but from the outset has been fashioned to support unconstrained types of model. Whilst a lot of early SystemML documents represent neuroscience models, this is because neuroscience researchers are using it right now, not because it is a neuroscience tool.

What is SystemML not?

To illustrate what SystemML is, we consider what it is not.

SystemML is not ModelDB
ModelDB is an infrastructure for the distribution of Parametrized Models (p-models). These are only useful to the reader of a publication if they can be computed on a publically available piece of software, and they are much more useful if they can be reused (e.g. included in systems built by the reader). A SystemML system document is a prime candidate for distribution over an infrastructure such as ModelDB.
SystemML is not GENESIS
GENESIS, for example, is a u-model (though it may be many other things besides): it solves the problem of efficiently computing a particular class of model. As such, it is a prime candidate for inclusion in a SystemML system document as the u-model of some component.
SystemML is not NeuroML
NeuroML is an example of a specification language for a particular class of p-model. NeuroML may be an excellent way of representing neural models, but it will never represent models of tractors or galaxies, and will never specify the way that these connect together with neural models to form universal systems. NeuroML is a prime candidate for inclusion in a SystemML system document as the parametrization of some particular u-model (e.g. GENESIS).


SystemML attempts to fill the gap between these existing technologies, providing an infrastructure for the distribution of u-model specifications and implementations, and an open language in which any p-model can be represented. A p-model can, thus, be obtained and computed by anyone, even if associated u-models were bespoke to the piece of work. Furthermore, the reader can build a larger system around the p-model, or connect it, or parts of it, with his or her own p-models in a straightforward way.

Thus, a publication of a p-model representing a system utilizing SystemML might include:

  • An in-print publication, describing the p-model, and any novel u-models.
  • The p-model system in SystemML published at ModelDB, or through some equivalent facility (e.g. by including the p-model as supplementary data on the website of the print publisher).
  • All u-model components necessary to run that p-model and that have not been previously published, published within the SystemML infrastructure. Thus, the infrastructure fosters u-model reuse by encouraging availability.

Note that any p-model can be published in this way, not just multi-process systems, with the advantage that the software needed to execute it both as it stands, as well as within any wider system that someone may wish to include it in, can be made available automatically on the target system. Therefore, there is a strong argument for publishing all p-models as SystemML documents. However, this approach entails a little extra work for the model developer who isn't already using SystemML, and they may not understand what this time investment buys them if they haven't read this documentation, so we won't be pushing this part of the agenda. We feel that enough models will be found to be better represented as systems (rather than single processes) that the systems advantage alone will sell the infrastructure effectively. If the infrastructure is adopted for distribution of p-model systems, adoption for distribution of single-process p-models can be expected to follow.