|Welcome to The Neuromorphic Engineer|
|Brian: a simple and flexible simulator for spiking neural networks|
PDF version | Permalink
Neurons communicate with stereotypical electrical impulses called action potentials or spikes. This fact has been known for about 150 years, but most neural network theories in the 20th century have described neural activity in terms of firing rates. Spikes have been seen as simply the biological elements that the brain used in order to communicate and compute with these analog rates, in the same way as the intensity of light is encoded by the arrival rate of photons. However, over the last 15 years, neurons have been found to be more deterministic than previously thought and the coordination of spikes now seems to play a major role in sensory coding and computation. Consequently, many neuroscientists are now interested in modeling neural computation at the spike level. Unfortunately, simulating spiking models is much more difficult and time consuming than standard analog models, which has caused many scientists to refrain from making this switch.
Several systems have been developed in the past to simulate neuron models efficiently.1 Some of them have been successful in the computational neuroscience community, but their complexities and steep learning curves have limited their audience. In many practical cases, it takes considerably more time to write the code than to run the simulations. While previous simulators addressed the issue of computational efficiency, we developed the Brian neural network simulator2 with a different goal in mind: to minimize the time users spend on writing the code of neuron models so that they can spend more time on the science. The motto of the Brian project is ‘a simulator should not only save the time of processors, but also the time of scientists’. Minimizing development time rather than simulation time implies different choices, putting more emphasis on flexibility, simplicity and readability.
These goals led us to make two choices: firstly to use a standard programming language that is both intuitive and well established, and secondly to let users define models in a form that is as close as possible to their mathematical definitions. The Brian simulator is written in Python, a well-established language that is intuitive, easy to learn and benefits from a large user community and many extension packages (in particular for scientific computing and visualization). Models are defined directly by providing their mathematical definition, consisting of differential equations and discrete events (the effect of spikes). This original approach has crucial benefits: it makes the code easy to read and share, it minimises the amount of simulator-specific syntax that needs to be learned, and makes simulating custom models as simple as simulating standard models.
A simulation using Brian is a Python program executed either from a script or interactively from a Python shell. Figure 1 shows a Brian script that implements a model of prey localization in the sand scorpion.3 Only the definition of the parameters and plotting commands are not shown. The movement of the prey causes a surface wave (function
Python is an interpreted language, and although it is very fast there is an overhead for every Python operation. Brian can achieve very good performance by using the technique of vectorisation, similar to that familiar to Matlab users. The idea is to replace loops by operations on large vectors, so that the interpretation overhead becomes negligible. Brian uses vectorisation for both the simulation and the construction of the model (e.g., initialisation of synaptic weights), and for large networks it can achieve speeds comparable to that of code written directly in C.4
To sum up, Brian is a convenient simulation tool for exploring new spiking neural models, modeling complex neural models at the systems level, and teaching computational neuroscience. We are currently working on distributed simulation technologies for Brian, focusing on using graphics processing units, an inexpensive piece of hardware consisting of a large number of parallel processing cores. Finally, we would like to mention that Brian is an open source project and we warmly welcome external contributions.
Tell us what to cover!
If you'd like to write an article or know of someone else who is doing relevant and interesting stuff, let us know. E-mail the editor and suggest the subject for the article and, if you're suggesting someone else's work, tell us their name, affiliation, and e-mail.