Mentors: Marcel Stimberg <marcel.stimberg@inserm.fr>, Dan Goodman <d.goodman@imperial.ac.uk>, Benjamin Evans <B.D.Evans@sussex.ac.uk>
Skill level: Intermediate/Advanced
Required skills: Python, C++
Time commitment: Full time (350 hours)
Forum for discussion
About: Brian is a clock-driven spiking neural network simulator that is easy to learn, highly flexible, and simple to extend. Written in Python, it allows users to describe and run arbitrary neural and synaptic models without needing to write code in any other programming language. It is built on a code-generation framework that transforms model descriptions into efficient low-level code. In Brian’s “runtime mode”, the generated code can interact with Python code by accessing the same data structures in memory. To make this work seamlessly, Brian makes use of Cython. This approach comes with two major disadvantages: 1) Cython compilation is slow (it generates a lot of code for error checking, etc.). For Cython, this is not a big downside, since it is commonly used to compile libraries once, but for Brian it matters since it needs to compile dynamically generated code frequently 2) We need to maintain a third code generation target besides Python and C++, with small but non-trivial differences to both of them.
Aims: The aims of this project are to:
- Replace the Python data structures that are currently used from within Cython code (dynamic arrays and the “spike queue”) by C++ equivalents
- Research solutions to call the compiled C++ code from Python and make it directly access the memory in the shared data structures storing the simulation variables. This could build upon existing just-in-time compilation technologies such as numba, or a package such as scipy-weave.
- Implement the above solution, and refactor the current code to make use of it
Project website: GitHub - brian-team/brian2: Brian is a free, open source simulator for spiking neural networks.
Tech keywords: Python, C++, compilation, JIT
Hello!
I love this project!
I’m really love computational neuroscience and want to build my career in this space. I’ve been working with NeuroML and have experience with spiking neural networks, particularly in modeling and simulation. Given my background, I’d love to contribute to this project. What areas should I focus on to best prepare myself? Would a deeper dive into JIT compilation techniques (maybe Numba?) or a stronger understanding of C++ memory management for neural simulations be most beneficial? What do you suggest?
Dear @namita-ach, many thanks for your interest in the project. This project is a bit different from the others we propose, in that there will be a significant “exploratory” component where we figure out what the best approach will be. Therefore, in addition to getting an idea of how Brian works, it would be good to get an overview of existing solutions to interface C/C++ and Python (Cython, ctypes, cffi, …). Regarding the way Brian’s runtime code generation currently works with Cython, I invite you to run the code posted below. It will simulate a (very simplified and not very interesting) neuron model and record its activity over time. You can find its generated code in the directory that gets printed out. Hopefully that should give you a bit of an idea of what the generated code looks like at the moment, and how it links between Python and Cython/C++. Please include a (not too detailed) “walkthrough” through these files, and in particular how the final C++ code accesses memory that was allocated on the Python side, in your application (in case you decide to apply, of course 
)
Don’t hesitate to ask any questions you will most likely have about this.
from brian2 import *
from brian2.codegen.runtime.cython_rt.extension_manager import get_cython_cache_dir
try:
clear_cache("cython") # Just to make sure that we start with a clean slate
except Exception:
pass # there might be nothing to clear
prefs.codegen.target = "cython"
prefs.codegen.runtime.cython.delete_source_files = False
# A not-so-interesting example of a neuron simulation
neurons = NeuronGroup(10, "dv/dt = -v / (10*ms) : 1", method="exact")
neurons.v = "rand()"
state_monitor = StateMonitor(neurons, "v", record=True)
run(25*ms)
print("Generated code in:", get_cython_cache_dir())
# Just to show that the simulation worked, not generating any Cython code
plt.plot(state_monitor.t/ms, state_monitor.v.T)
plt.show()
Please also see our general guidelines for GSoC applications here: GSoC 2025 | The Brian spiking neural network simulator
Thank you for the insights! I’ll explore the existing solutions for interfacing C/C++ with Python and go through the code to understand how Brian’s runtime code generation works.
and there is typo in the guidelines url you provided it shoude be 2025 after posts/
i.e GSoC 2025 | The Brian spiking neural network simulator 
Thank you, @mstimberg, for all the details!
I hope all the Brain projects get selected by Google. But if Brain gets only one slot, which project would be your top priority out of the 3?
Hello @mstimberg, I am Karthik Sathish, a junior year student from IIT Roorkee. I would like to work on this project. This would be my work flow for the next 2 days:
Understand the current Just in Time architecture that Brain follows (I want to know which part of the architecture is making it run slow.)
Once I figure out the actual problem, I will look for the possible alternatives.
If I face any problem in the journey, I will write it down here.
Indeed, sorry about that! I edited my post to fix the link.
We don’t have a priority project as such. If we only get one slot, we’d select the participant/project combination that we estimate to have the highest chance of achieving the aims of the project.