Computational research in biology commonly consists of describing a model system and its parameters, simulating the system with specialized software, and then analyzing the results. Model descriptions often make use of a domain-specific language that is parsed and interpreted by the simulation software. Such languages have the advantage that they are more accessible to researchers than code written in a general-purpose programming language; they also make it easier to discuss and share models with other researchers.
Parsing such languages is mostly straightforward with standard techniques, but these techniques regularly have at least two shortcomings:
- For syntactically incorrect descriptions, e.g. a missing parenthesis, error messages are typically not very helpful and of the form “unexpected symbol at position x”, and
- annotations via comments are usually simply ignored, instead of being used to enrich a model description.
Both of these shortcomings are currently present in the Brian simulator, an open-source simulator for biological spiking neural networks written in Python, developed in our research group and used by researchers world-wide. The Brian simulator describes models with a domain-specific language that uses mathematical notation with additional annotations, e.g. to assure the consistency of physical dimensions.
The goal of this internship is to rewrite the Brian simulator’s parsing code to give clear and helpful error messages for incorrect model descriptions, as well as treating comments in the model descriptions as annotations that are stored for future usage.
Skill level: Advanced
Required skills: Python programming, parser/compiler techniques.
Time commitment: Part-time (175 h)
Lead mentor: Dan Goodman (d.goodman@imperial.ac.uk; d.goodman on NeuroStars)
Project website: GitHub - brian-team/brian2: Brian is a free, open source simulator for spiking neural networks. · GitHub
Backup mentors: Benjamin Evans (B.D.Evans@sussex.ac.uk), Marcel Stimberg (marcel.stimberg@sorbonne-universite.fr; mstimberg on NeuroStars)
Tech keywords: Python, PyParsing, Parsing, Compiler
My name is Korani Lavina, and I am currently pursuing my undergraduate degree in Artificial Intelligence and Machine Learning. I am in the final phase of my second year (4th semester), and my research interests focus on neuroinformatics, brain–computer interfaces, neural signal analysis, and AI-driven healthcare technologies.
Over the past year, I have been actively working at the intersection of AI, neuroscience, and assistive technology. I also participated in Google Summer of Code exploration with the Oppia Foundation and Google DeepMind, which strengthened my interest in contributing to open scientific communities developing impactful technologies.
My current research work focuses on BCI systems and neural signal processing, and I have contributed to literature through the following review papers:
- Myoelectric Control to Biomimetic Dexterity: A Review of the State-of-the-Art in Bionic Upper-Limb Prostheses
- Cognitive Neuroscience Model for Improving Learning Cognitive Ability by Detecting the Learning Index through Brain-Computer Interface Signals
In addition, I am currently developing a research project aimed at improving accessibility for hearing-impaired individuals. The work proposes an algorithm that maps adjacent audio frequencies and multilingual speech signals into accessible patterns, enabling improved interaction with assistive hearing technologies. The algorithmic framework has been designed and is currently undergoing further validation for research publication.
Because of my strong interest in open neuroscience collaboration and neuroinformatics infrastructure,Dan Goodman d.goodman@imperial.ac.uk Brian Simulator – Improved Parser for Brian Model Descriptions The opportunity to redesign the Brian DSL parser with clearer error diagnostics and structured annotations is particularly exciting to me.
I would be grateful for any guidance on:
how I could begin contributing to the repository
beginner issues or tasks suitable for prospective GSoC contributors
Recommended resources to better understand the Brian codebase
I would also be happy to share my GitHub projects (including several EdTech systems) or discuss my ongoing research and conference collaboration with M.Tech students from IIT Bombay if helpful.
Thank you very much for your time and for the impactful work you are doing in advancing computational neuroscience tools.
Hi @KoraniLavina, happy to hear you are interested in this project. I’ve written up some general recommendations for the GSoC application on our website: GSoC 2026 | The Brian spiking neural network simulator
Here’s some more specific guidelines for the parser project: please include in the application a detailed description of the current equation parsing mechanism. The project goals mention error messages: please come up with a number of “realistic” errors a user could make when writing equations, and document the error messages the Brian simulator gives in these situations. Ideally, what kind of error message would the user prefer? In more general terms, what kind of parsing techniques do you know and what are their respective advantages/disadvantages? Finally: another approach to better error messages might be to support something like the friendly-traceback project – in what way would this be different/complementary?
Regarding issues to look at: the most fitting for this project would be Parse and save the comments in model descriptions · Issue #40 · brian-team/brian2 · GitHub Note that since this touches a core part of Brian, this shouldn’t be a feature that we rush. I don’t mind having it take some time and iterative improvements to get right, it doesn’t necessarily need to be in a mergeable state before the application submission deadline.
Dear @mstimberg Sir,
Thank you for your detailed guidance and for sharing the recommendations for the GSoC application. I’ve gone through the materials on the website and found them very helpful.
For the parser project, I will include a detailed explanation of the current equation parsing mechanism in Brian, along with examples of realistic user errors and the corresponding error messages generated by the system. I will also analyze how these messages could be improved from a user’s perspective.
Additionally, I plan to explore different parsing techniques, comparing their advantages and limitations, and discuss how they could be applied in this context. I’m also particularly interested in the idea of integrating approaches similar to the friendly-traceback project, and I will outline how such a system could complement Brian’s existing error handling.
Regarding the issue on parsing and saving comments in model descriptions, I understand that this involves core functionality. I will approach it carefully, focusing on iterative improvements rather than rushing toward a quick solution.
Please let me know if there are any specific aspects you would like me to prioritize in my application. I’m very excited about the opportunity to contribute to this project and learn from the process.
Best regards,
Lavina.
Hi @KoraniLavina, as mentioned in our blog post, don’t hesitate to share a draft application if you want some more specific feedback.
Yes Sir. Actually I have some multiple doubts ..Is their any possibility for gmeet whenever you have some time, Because I want to discuss some issues.
Hi @d.goodman and @mstimberg,
I am an undergraduate student at Shanghai University, applying for Project #3: Improved parser for Brian model descriptions (175h).
Brian’s equation language is compact and researcher-friendly, but two issues still affect day-to-day modeling:
-
Syntax and semantic mistakes can surface as generic or low-level errors.
-
Comments in equations are currently ignored instead of being preserved as structured annotations.
I would like to improve both while keeping Brian2 behavior backward compatible.
Current understanding of the parser
Brian2 equation handling is a layered pipeline:
-
brian2/equations/equations.py: pyparsing grammar builds SingleEquation and Equations.
-
brian2/parsing/sympytools.py and brian2/parsing/rendering.py: RHS expressions are translated into symbolic form.
-
brian2/parsing/expressions.py and brian2/equations/unitcheck.py: semantic and unit validation.
-
brian2/groups/group.py: identifier/function resolution in group namespace.
-
brian2/core/network.py: exception wrapping via BrianObjectException during before_run.
This architecture is strong. The main pain points are diagnostic clarity across layers and loss of comment metadata.
Realistic error cases to improve
The highest-impact cases include:
-
missing : before unit declarations;
-
malformed differential form (dv/d instead of dv/dt);
-
operator misuse such as ^ that can degrade to KeyError: 'BitXor';
-
unresolved identifiers where useful cause details are hidden by top-level wrapping.
Several existing messages are already very good (e.g., duplicate variable definitions and many unit checks), so the work can focus on targeted improvements instead of a full rewrite.
Implementation direction
I propose an incremental plan:
-
Define a consistent error format (what / where / why / how to fix).
-
Patch high-frequency degraded paths first (especially operator-related failures).
-
Improve cause propagation so actionable details are visible at first read.
-
Implement issue #40 by parsing and storing comments as structured annotations with deterministic mapping rules and tests.
175h delivery plan
-
Phase 1: baseline corpus of realistic user errors and current messages.
-
Phase 2: diagnostic formatting utilities and first parser-message upgrades.
-
Phase 3: issue #40 annotation extraction/storage implementation.
-
Phase 4: regression tests, docs updates, and stabilization buffer.
I can start with a focused first PR on operator-error diagnostics and tests, then proceed to annotation support.
GitHub: bluemoon-o2 · GitHub
Best regards,
Lexing Zhang
GSOC PROPOSAL DOCS
Hi everyone,
I’ve gone through Issue #40 and the related discussions, and explored a few possible approaches. I’m proposing a slightly different direction—combining deterministic comment parsing with an AI-based layer for semantic understanding and documentation.
The idea is to extract inline comments, structure them as metadata within the Variables object, and use this to improve documentation, validation, and potential export (e.g., NineML). I’ve also drafted a detailed implementation plan and timeline.
Would love to get your feedback on this approach!
Hello @mstimberg and everyone,
I am Janhavi, and I am currently pursuing my undergraduate studies in computer science. I am particularly interested in compiler design, parsing systems, and developer tooling.
Over the past few months, I have been working on projects involving parsing and language tooling, including experience with compiler related systems and language interoperability. This has given me practical exposure to grammar design, handling edge cases. I have also done projects involving parsing and language tooling, including a carbon aware compiler project where I had to work in python and explored different parsing approaches and had to design user facing messages that explained why certain transformations were made in the codes.
I explored the Brian2 codebase and did my research on it specially related to possible errors users could face. Through this, I also was able to open PRs solving some issues in codebase.
I have created my draft proposal and would really appreciate your feedback and any guidance on it: janhavi_proposal
Thankyou 
Hi @d.goodman and @mstimberg,
I’m Ayush, an undergrad at JIIT, applying for Project #3.
I’ve been contributing to Brian2 over the last few months (mostly working on the parser in PR #1766 and the C++ codegen in PR #1757) and I would really love to keep working on the parser this summer.
I have my draft proposal ready using the INCF template. I wanted to send the draft proposal directly to you for some feedback like the GSoC blog post suggested, but it looks like my forum account is too new to start a DM.
So, I texted you on Brian Discourse.
Github: ayush4874
Thanks!
Dear Sir,
I am currently working on Issue #40 and, before contributing, I have carefully analyzed the codebase, identified the underlying problems, and explored several possible solutions in depth. Over the past two months, I have been consistently working on this project to better understand its structure and challenges.
I have also submitted my GSoC proposal focused specifically on this project, as I am genuinely interested in contributing meaningful improvements. My approach includes not only addressing the existing issue but also exploring potential enhancements and innovative solutions.
I would be very grateful if you could take some time to review my proposal and provide your guidance or feedback. Your insights would greatly help me refine my approach and ensure that my contributions align well with the project’s goals.
Thank you for your time and consideration.
Best regards,
Korani Lavinagsoc proposal pdf