Functional anatomy of BRAHMS: Components are marked with orange tags, framework parts with yellow tags.

(1) Supervisor calls Process and Data components through their Events Interfaces, and moves Data components around in Links.
(2) Process components call Data components (to access their content) through their Events Interfaces.
(3) Process and Data components may additionally call Utility components through their Events Interfaces.

BRAHMS Execution Client

Framework

Core

The interface that allows the different parts of BRAHMS to communicate with each other; the heart of BRAHMS. New Components and new Supervisors may follow, but the Core will remain. Major revisions to the Core may require recompiling (and, possibly, modifying) all other Parts, so these are to be avoided.

Supervisor

Responsible for instantiating processes and passing them their initialisation parameters, connecting them together, then leading them all together along the simulation timeline, passing data objects amongst them as required, and ensuring that they remain in step. Can run in two modes: "Solo" runs in a single shared-memory space and takes advantage of multiple processors using multi-threading; "Concerto" runs across multiple shared-memory spaces, leveraging multiple processors in each space using multi-threading, and leveraging multiple spaces by inter-process communications (over TCP/IP or MPI).

Components

Process

The computation engines that take zero or more inputs and generate zero or more outputs. Examples would be std/math/esum which adds its numeric inputs and generates a single numeric output, and std/source/spikes which takes no inputs but generates one spikes output.

Data

The data containers that are passed between processes. Examples are std/data/numeric which contains an N-dimensional array of numeric primitives, and std/data/spikes which contains a list of streams which are in a spiking (logic high) state.

Utility

Additional components that provide library functionality (e.g. computation services) within the SystemML framework. That is, they are dynamically linked libraries, but they are subject to version tracking in the same way as any SystemML component. An example is std/util/rng which implements random number generators.

A Wider Context

Here, we see the whole BRAHMS/SystemML software suite as it fits together into an integrated system. BRAHMS itself (the BRAHMS Execution Client) is the large green part to the right, driven entirely by flat text (XML) files. The other software provided are the Matlab Bindings for BRAHMS and SystemML, providing read/write access to the Execution File and the System File (SystemML), and the SystemML Cache Manager (not yet implemented) which updates the local cache from the SystemML Server.

Currently, green and blue (BRAHMS and SystemML Toolbox) are packaged together in the all-in BRAHMS releases.