The Brian source code repository is broken into the following directories:
The main package, documented above, with the following additional directories:
- For code that is no longer up to date, but that we keep for backwards compatibility.
- Package for storing experimental code that can be used but whose syntax and functionality may change.
- Modules where specific models are defined (e.g. neuron and synaptic models).
Package for storing tests, composed of:
- Package for tests of mathematical correctness of algorithms, etc.
- Package for tests of individual Brian modules. Module names are the names of the module being tested prepended by ‘test’.
- Old stuff
- Modules that are not Brian-specific, for example circular.py defines circular arrays used for storing spiking events.
The main development folder, for works in progress, debugging stuff, tools, etc. Consists of:
- Code for benchmarking performance against other languages and simulators.
- The Brian Enhancement Proposals.
Dumping ground for files used for debugging a problem.
- Used for debugging problems from the
- For ideas for new features, incomplete implementations, etc. This is
where new things go before going into the main Brian package or the
- The Brian logo in various sizes.
- Ideas for making Brian faster.
- A sort of testing framework which tracks, over time, the speed of various Brian features.
- A few scripts to run Brian’s tests.
The main folder for developer tools.
- Scripts for invoking Sphinx and building the documentation. Includes script to automatically generate documentation for examples and tutorials, and to build index entries for these.
- Tools for creating a new public release of Brian.
- Some tools for doing global changes to the code (e.g. syntax changes).
- Automatically generated distribution files.
- Automatically generated documentation files in HTML/PDF format.
- Sources for Sphinx documentation.
- Examples of Brian’s use. Documentation is automatically generated from all of these examples.
- Source files for the tutorials, documentation is automatically generated
from these. Each tutorial has a directory, possibly containing an
introduction.txtSphinx source, followed by a series of files in alphabetical order (e.g. 1a, 1b, 1c, etc.). Multi-line strings are treated as Sphinx source code (take a look at a few examples to get the idea).