Our research group (the ABRG) is a Computational Neuroscience group, so a major facet of our work is the design and analysis of models of neural systems. For some models, off-the-shelf software exists for efficiently computing the algorithms. For example, GENESIS solves compartmental neuron models. But for some other models we have to resort to building bespoke software.
Since software design is not an entirely trivial task, we spend substantial fractions of our time on this task. Sometimes we build our bespoke models in Matlab, sometimes we build them in C or C++ (usually for execution within Matlab as mex files), and sometimes we build them in other environments (Python, Webots, to give recent examples). The choice in each case is influenced by the complexity of the computation that needs to be performed and the ease and efficiency with which it can be represented in a particular language.
If off-the-shelf software does not exist, and since we are not in the business of software development, we do just enough to get the job done by building a small piece of code to solve the model and nothing else. This approach has served satisfactorily in the past, so what is the problem? Recent developments within the group and within the field have changed our environment.
In summary, we wish to share our work with each other (and outside the group), we want to be able to connect our models into computable integrated systems, and we want to deploy those systems effectively in diverse environments.
One solution is to use an existing model integration tool: Simulink, for example. Simulink suffers from some drawbacks, however. First, it is proprietary (i.e. not free in either sense). Second, it has a large resource footprint (a Matlab installation) which renders it unusable in constrained environments. Third, it offers no support for parallelisation. In addition, connection to third-party software is not straightforward (e.g. existing solvers like GENESIS). Other existing solutions similarly lack generality.
So we did what any organisation would do in such a situation - we went right ahead and formed a committee. The Integration Working Group (IWG) was tasked with finding solutions to the problems outlined above. Its first finding was that no existing tool solved all these problems in a general and extensible way. The remainder of the IWG's work has been in specifying our own solution.
At first, this solution is intended to benefit our group. However, we have worked hard from the outset to make the solution sufficiently general to solve the same types of problems experienced by other researchers and, crucially, to solve the problems of integration across organisation boundaries. If we're working hard in Sheffield to code a low-level neural model, should they be repeating exactly the same work in Edinburgh? This is not a sensible use of funding. Uptake amongst other groups in the consortiums in which we are involved will be a good measure of whether we have succeeded in this wider aim.
Our proposed solution, BRAHMS, was born to solve the connect and deploy problems within the context of the WhiskerBot project. Almost accidentally, BRAHMS solved the share problem on a within-group basis, too. However, our final proposal is substantially more general, and BRAHMS, as an independent part of that proposal, is a much more complete creature than when it began. Our proposal has the following facets:
|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.|