![]() ![]() BRAHMS
Introduction » What is BRAHMS
This documentation is offline - click here to go online
Index | Search: Go online to use Search
| ||
![]() Example system, consisting of processes (rectangles), outputs (circles), and links (arrows). The rules of this connectivity are pretty standard: each process takes zero or more inputs, generates zero or more outputs, and each process output can be linked to zero or more process inputs. What is BRAHMS?BRAHMS is a Modular Execution Framework (MEF) for executing integrated systems built from component software processes (a SystemML-ready execution client). Its operation is conceptually similar to that of Simulink, for example. Such tools allow the connection of processes together into systems, by linking the outputs of some processes into the inputs of others (see Figure). In this way, the design and implementation of a system is separated from the design and implementation of each process is separated from the design and implementation of the framework that facilitates their connection. Thus, they solve the problem of connecting pieces of software written by different researchers (who are generally not software engineers). An MEF effectively encapsulates the specification and implementation of a particular model engine (be it spiking neural network or time-invariant filter), allowing it to be shared between complex system models without the respective authors having to intuit each other's (usually undocumented) interfaces or port/modify each other's code. The modules compute mathematical models, whilst the MEF takes charge of synchronization, data transport and various infrastructure facets such as data logging, performance analysis, etc. Modular ComputationThe concept we are working with is very similar to that supported by Simulink or Labview: the linking together of separate software modules into a single meaningful (computable) "system". If you are wondering why we should be using such tools at all, we aren't going to rehearse all the arguments here, but here are the main points...
Specific Benefits
Potential for parallelisationThe granular size of modules needs to be balanced between too small (introduce computational overhead) and too large (gain no modular advantage). So far, and in line with previous work in this area, this has given us modules that act as engines for particular processes (filter, sum, network). Project-bespoke engines (e.g. a physical world model) may not suffer further granulation. However, network engines, our workhorses, lend themselves to it, since the individual nodes generally have the same conditions of independence given above, so a large network can still be efficiently computed if broken up into smaller pieces. This fact gives us granulation of network models when those models are otherwise monolithic, allowing us to gain the parallel computation advantage even when the model being computed does not naturally break into modules. Why BRAHMS?Assuming you're sold on modular computation: why BRAHMS rather than Simulink or Labview, say?
BRAHMS and youDeveloping SystemsThe simplest relationship you can have with BRAHMS is that of someone who wishes to execute a System, where that System is built of Processes that already exist. You specify the required Process classes (e.g. source, sum, product), the parameters of those processes (configuration, initial state), the connectivity between them (which outputs go to which inputs), and the parameters of the Execution itself (stop time, parallelisation, which data objects are being logged). You then call BRAHMS with this Execution, the System is executed, and the logged outputs are returned to you. To get started on this track, look at the section Developing Systems in the User Guide. Developing ProcessesWhat this relationship does not offer is the development of bespoke computation. The effectiveness, then, of this relationship hinges on the flexibility designed into the processes. For instance, a spiking neuron network simulator exists, but currently it does not support shunting inhibition. To perform a simulation involving shunting inhibition under BRAHMS, then, we will have to modify an existing process, or develop a new one. BRAHMS is written in C++, but processes can be developed in a variety of languages (at time of writing, C, C++, Matlab and Python). To get started on this track, look at the section Developing Processes in the User Guide. Developing BRAHMSFinally, if you are on the BRAHMS development team, you may be getting involved in developing the framework itself. This is currently by invite only, though we welcome detailed bug reports and suggested source-code patches from anyone who wants to get involved at this level. Alternatively, you may want to modify BRAHMS slightly for your particular application. For either of these uses, you should look at the section Framework in the Reference Manual. Notes
|
||
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. |