Goodman and Brette The Brian simulator * Correspondence: Romain Brette obtained a Ph.D. in Computational Neuroscience from the Paris VI University in France. He did post-doctoral studies in Alain Destexhe’s group in Gif-sur-Yvette (France) and Wulfram Gerstner’s group in Lausanne (Switzerland). He is now an Assistant Professor of Computational Neuroscience at Ecole Normale Supérieure, Paris. His group investigates spike-based neural computation, theory and simulation of spiking neuron models, with a special focus on the auditory system. romain.brette@ens.fr models are deﬁned directly in the main script in their mathematical form (differential equations and discrete events). This design choice addresses the three issues mentioned earlier: ﬂexibility, as the user can change the model by changing the equa- tions; readability, as equations are unambiguous and do not require any speciﬁc knowledge of the Brian simulator to understand them; and simplic- ity of the syntax, as models are expressed in their original mathematical form, with little syntax to learn that is speciﬁc to Brian. Computational efﬁ- ciency is achieved using vector-based computa- tion techniques. We expect that the availability of this new tool will have the strongest impact in two areas: ﬁrstly in systems neuroscience, by making it easy to explore spiking models with custom architectures and properties, and secondly in teaching com- putational neuroscience, by making it possible to write the code for a functional neural model within a single tutorial, and without strong pro- gramming skills required. In this review, we start by describing the core principles of Brian, then we discuss a few concrete examples for which Brian is particularly useful. Finally, we outline directions for future research. Brian can be downloaded from http:// briansimulator.org. It is open source and freely available under the CeCILL license (compatible with the GPL license). THE SPIRIT OF BRIAN The main goal of the Brian project is to minimise the development time for a neural model, and in particular the time spent writing code, so that sci- entists can spend their time on the details of their model rather than the details of its implementa- tion. The development time also includes the time spent learning how to use the simulator. Ease of learning is important because it opens the pos- sibility for people who would not previously have considered computational modelling to try it out. It is also helpful for teaching (see Teaching). More generally, it is desirable to minimise the time it takes to read and understand someone else’s code. It helps peers to verify and evaluate research based on computational modelling, and it makes it eas- ier for researchers to share their models. Finally, in order to minimise the time spent on writing code, the translation of the model deﬁnition into code should be as direct as possible. Execution speed and memory usage of the code is also an issue, but only inasmuch as it puts a constraint on what can be done with it. It is therefore most important in the case of large neural networks. These goals led us to make the following two choices: ﬁrstly, to use a standard programming language that is both intuitive and well established, and secondly, to let users deﬁne models in a form that is as close as possible to their mathemati- cal deﬁnitions. As in other simulation projects, we identiﬁed Python as an ideal choice for the programming language. Python is a well estab- lished language that is intuitive, easy to learn and beneﬁts from a large user community and many extension packages (in particular for sci- entiﬁc computing and visualisation). While other simulators use Python as an interface to lower level simulation code, the Brian simulator itself is written in Python. The most original aspect of Brian is the emphasis on deﬁning models as directly as possible by providing their mathemati- cal deﬁnition, consisting of differential equations and discrete events (the effect of spikes) written in standard mathematical notation. One of the sim- plest examples is a leaky integrate-and-ﬁre neu- ron, which has a single variable V which decays to a resting potential V over time according to 0 the equation τdV/dt = −(V − V0). If this variable reaches a threshold V > V the neuron ﬁres a T spike and then resets to a value VR. If neuron i is connected to neuron j with a synaptic weight Wij then neuron i ﬁring causes Vj to jump to V + W . j ij This is represented in Brian with the following code for a group of N neurons with all-to-all connectivity: equations = ‘‘’ dV/dt = -(V-V0)/tau : volt ‘’’ G = NeuronGroup(N, equations, threshold=’V>VT’, reset=’V=VR’) C = Connection(G, G, ‘V’) As can be seen in this code, the thresholding condition and the reset operation are also given in standard mathematical form. In fact it is pos- sible to give arbitrary Python expressions for these, including calling user-deﬁned functions. This gives greater generality, but using only math- ematical expressions improves clarity. In addition to the mathematical deﬁnitions, the physical units are speciﬁed explicitly for all variables, enforc- ing dimensional consistency (here variable V has units of volts). In order to avoid ambiguities and make the code more readable, there is no stand- ard scale for physical quantities (e.g. mV for volt- ages) and the user provides the units explicitly. For example, the potential of the neurons is set to −70 mV by writing G.V=-70*mV or equivalently G.V=-.07*volt. Making differential equations the basis of models in Brian may seem like a fundamental Frontiers in Neuroscience www.frontiersin.org September 2009 | Volume 3 | Issue 2 | 193