Join the project

We are seeking collaborators to help us with the Brian project. If you are interested in joining the educational team (writing tutorials and examples), the testing team (writing tests and benchmarking) or the development team (working on job scheduling and visualization modules, developing the library), please contact us by email. You should also have a look at our developers mailing list.

Educational team

  • Write tutorials.
  • Write examples. We are especially interested in examples adapted from published papers.

Testing team

The testing team consists of testers and profilers:

  • Tester: write tests that verify that all components of Brian work as expected. The package currently contains a number of tests that we run regularly to make sure that we haven’t broken anything. This is extremely important to make Brian reliable.
  • Profiler: write benchmarks to evaluate Brian’s speed. We are particularly interested in finding the efficiency bottlenecks that we should be working on.

Development team

There are several projects for which we welcome contributors:

  • Parallel computing: this is a major project within Brian. We are currently considering 4 subtasks:
    • Job scheduling: currently, Brian can run independent simulations on multiple processors and computers by using parallelpython, but it is limited. We would like to make this type of distributed simulations simple. This might simply involve using existing (free) tools such as Condor and writing specific tutorials and usage examples.
    • GPU computing: we have started working on using the GPU as a coprocessor to run the state updates in Brian simulations, which could result in considerable speed-ups. We are welcoming collaborators on this project. Have a look at our mailing list on GPU development if you are interested.
    • Multicore and cluster computing: we have not developed this aspect yet, but please send us an email if you are interested in helping us.
  • Library:we would like to include a library of ionic channels; any other type of predefined models would be welcome too.
  • Plotting and visualisation: currently, Brian relies almost entirely on Pylab for the graphics. We would like to develop more specific tools, both for creating publication-ready figures/movies and for online visualisation (visualising model activity as the simulation runs).
  • Analysis: Brian currently includes a module for simple spike train statistics. It would be good to have more analysis functions (for example porting the Spike Train Analysis Toolkit).
  • C++ code: we are considering writing some of the key classes (such as connection structures) in C++ to increase Brian’s speed. This could use SWIG for example.
  • Error catching: errors in Brian scripts can sometimes be mysterious. The idea here is to write more useful error messages, possibly by defining new exception types and catching errors at relevant points in the code.