Brian is a clock-driven spiking neural network simulator which is easy to learn and use, highly flexible and easy to extend. It is written in Python and allows describing and running arbitrary neural and synaptic models without having to write code in any other programming language. It is built on a code-generation framework that transforms the model description into efficient low-level code. WebAssembly is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web.
Brian’s code generation pipeline can generate C++ code, and the emscripten toolchain can compile this code into WebAssembly. This makes it possible to run simulations directly in a web browser, requiring no installation on the client side. We have recently created a proof-of-concept, brian2wasm (GitHub - brian-team/brian2wasm), showing the feasibility of this approach.
The aim of this project is to turn this proof-of-concept into a convenient tool for the wider community. In particular, the aims of this project are to:
Improve the general workflow (e.g. detection/configuration of emscripten toolchain)
Implement efficient data transfer between the WebAssembly simulation and the JavaScript code that displays the results
Provide convenient tools for website customization and plot display
Document the package and its usage
Additional goals for a 350-h project:
Set up an automatic test suite for brian2wasm
Provide convenient tools for setting parameters at the start of the simulation (big project)
Provide components for real-time interaction with Brian scripts, e.g. providing microphone or camera input to the Brian simulation and returning spikes or other data from the Brian simulation to the website (big project)
Skill level: Novice/Intermediate
Required skills: HTML, JavaScript, basic C++ and Python
@Marcel Stimberg @Dan Goodman
I came across the Brian2Wasm project recently and I must say I am highly intrigued by its potential. The idea of leveraging WebAssembly to run simulations directly in web browsers without the need for installation is both innovative and promising.
After going through the project description and goals outlined on GitHub, I am eager to express my interest in contributing to the development of Brian2Wasm. The prospect of improving the general workflow, implementing efficient data transfer, and providing convenient tools for website customization aligns perfectly with my skills and interests.
Before I proceed further, I have a few questions regarding the project:
Could you please provide more details about the existing codebase and any specific areas that need immediate attention or improvement?
Are there any preferred tools or libraries for implementing efficient data transfer between WebAssembly simulation and JavaScript?
Could you suggest some initial tasks that I could work on to familiarize myself with the project and contribute effectively?
Additionally, I would like to inquire about drafting a proposal for this project. Would you recommend preparing a formal proposal outlining my intended contributions, timeline, and milestones?
I am eager to dive into this project and contribute meaningfully to its success. I look forward to your guidance and feedback.
Hi @Sauradip07, glad to hear you are interested in the project!
Here are a few pointers:
I’d say the most important area for now is to make it actually easy to use! As you can see, the README doesn’t even explain what is necessary to do. In particular, installing the emsdk, and activating is a bit of a manual process and needs at least to be clearly documented. In the current code (https://github.com/brian-team/brian2wasm/blob/main/brian2wasm/device.py), I made some attempts to automatically source the emsdk_env script, but this didn’t quite work in all cases. So, trying to actually run of the examples and document the necessary steps would be a great first contribution!
No library is necessary, but for now we push all results from the WebAssembly side to JS (https://github.com/brian-team/brian2wasm/blob/main/brian2wasm/templates/pre.js), while most of the time only a few of them are needed. When you define the simulation, you can use the transfer_only function to state that only a few variables should be pushed over, but a better implementation would do this on the JS side, i.e. the JS side has to ask for specific results.
As mentioned above, I think for now the most important thing to do would be to try to actually get one of the examples to run, and to have a look at the generated files and try to understand where they come from. Documenting all this would be a very valuable contribution!
@mstimberg Sir, as you mentioned above the most important thing now to do would be to try to actually get one of the examples to run. So I picked an example and reviewed the documentation and identified areas where it can be clearer about installing and activating the emsdk. I attempted to run one of the provided examples.(https://github.com/brian-team/brian2wasm/blob/main/examples/brunel_hakim1999.py), and after running the example in my local system I am facing this kind of error.
@mstimberg Sir, The error I’m encountering seems to be related to the generate_objects_source method in the WASMStandaloneDevice class of the brian2wasm module. The method is being called with an incorrect number of arguments. To address this issue, we might need to modify the generate_objects_source method in the WASMStandaloneDevice class to accept the correct number of arguments. Based on the error message, the method is currently defined to take 6 positional arguments, but 7 were given. You can modify the method definition in the device.py file of the brian2wasm module to match the correct number of arguments.
Here's how we can do it:
Open the device.py file located in the brian2wasm module directory.
Locate the generate_objects_source method within the WASMStandaloneDevice class.
Modify the method definition to accept the correct number of arguments. Based on our use case, it might need to add or remove arguments as necessary to match the expected number.
Hi @Sayan_Mandal (and everyone else), sorry about that, asking you to run the example wasn’t supposed to be a trick question! You are right about the generate_objects_source method, but there are actually other issues that need fixing. The reason for the failure is that brian2wasm was developed alongside brian2 and needed a very specific development version of brian2 to work correctly. I just fixed it so that it works with the latest release of Brian 2.6.0, so please update brian2wasm from github and try running the example again. My apologies, I should have checked this earlier…
Hi @Sayan_Mandal. Great to hear. The next steps would be to get a deeper understanding what happens when you run the example (what code gets generated, how does it get compiled, etc.), and to compile all this information into something that you can include in the GSoC application.
We don’t have any Slack group, our main discussion places are:
neurostars, mostly for discussing GSoC applications
The discourse forum at https://brian.discourse.group for general discussions and support, and also its chat feature for more ephemeral questions
GitHub issues and pull requests for everything that is technical
I’d be happy to discuss further here, or don’t hesitate to send me a direct message, contact me in the Discourse chat or via mail (marcel.stimberg@sorbonne-universite.fr).
Dear prospective candidates, please be aware that the submission deadline for application proposals is Apr 2nd. Unfortunately (well, not for me ), I will be away for a break over the Easter weekend and can therefore not give extensive feedback close to the deadline date. Please send me a draft before Wed 27th for detailed feedback. I will still be reachable after that date, but most likely not be able to look into your document in detail. Thanks for your understanding and happy proposal writing !
Dear prospective candidates, please be aware that the submission deadline for application proposals is Apr 2nd. Unfortunately (well, not for me 
), I will be away for a break over the Easter weekend and can therefore not give extensive feedback close to the deadline date. Please send me a draft before Wed 27th for detailed feedback. I will still be reachable after that date, but most likely not be able to look into your document in detail. Thanks for your understanding and happy proposal writing 
!