Am I interested?
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 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:
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.
|This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here.|