BRAHMS (like any Modular Execution Framework) is itself only responsible for supporting the execution you request. The actual computation of the System is done by software plug-ins, one plug-in (Process) implementing each Process class (SystemML Class, in BRAHMS). In addition, Data plug-ins form interfaces between Process classes, and Utility plug-ins perform services for either Process or Data (usually, Process) plug-ins. To add computing functionality to BRAHMS, therefore, you will need to develop one or more of these Components. This is the subject of this section of the User Guide.
BRAHMS is a SystemML Execution Client: SystemML defines a global namespace containing specifications for Components (Process, Data or Utility). SystemML Execution Clients are able to execute Systems built from these Components (in fact, built only from Processes - it is Processes themselves that use Datas and Utilities). BRAHMS can execute a given System if a BRAHMS implementation exists for every Component that is needed. In BRAHMS, these implementations are built into BRAHMS Modules (for native Components, these are compiled from source into dynamic
Authoring a Component in BRAHMS can be separated into two parts: (i) performing tasks that all Components need to do to play nice with the Engine; (ii) performing the actual work you want your Component to do. (i) is a case of performing a list of operations whilst servicing events, and we aim to list in this section comprehensive examples of how to do everything, so you shouldn't have to work very hard to get this done. (ii) is your own business.
Why Develop a Process?
If you want to add something to your model that is just a new parametrization of an existing Process (e.g. a particularly leaky Leaky Integrator Network), you just need to Design that parametrization, rather than develop a new Component. However, if you want to implement a new computation (e.g. a Spiking Neuron Network), you will need to develop a new Process for BRAHMS. That consists of deciding on a specification, and then implementing that specification in accordance with the interfaces defined by BRAHMS.
We make every effort to change the Process interface as little as possible in each release. However, all releases are currently requiring a recompile of native processes, and some releases are requiring minor updates to the code of native processes (but not non-native processes, Matlab and Python). No guarantee of complete compatibility will be made until version 1.0 is released, at which point we can safely begin to populate the public Namespace.
Why Develop a Utility?
If you want to add functionality that can be shared amongst processes, or you want to modularise your process itself. For instance, a Utility in the Standard Library is
It is not recommended that you develop a Utility unless you consider yourself an advanced developer, not least because there is no documentation of the process. Also, don't create a utility unless you are willing to maintain your code to keep up-to-date with possible changes to the interface before version 1.0.
Why Develop a Data?
Don't. User-developed data objects are not supported currently, since it's just too difficult to tie down the data interface at this stage of development. At version 1.0, this advice will be rescinded. In the meantime, if you really can't get the performance you need from the existing data classes, please let us know why and we may be able to create and maintain a new Standard Library data class to fill the gap.
Before you start
The following information applies to development of a Process in any language. You should review these points before you start developing a Process for BRAHMS, if they sound relevant - it may save you debugging or rewriting effort later.
|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.|