Brian running locally in the browser via Javascript using pyodide

Check out this cool demo of Brian running in the browser using Javascript. It uses the Pyodide package. For the moment it’s a bit clunky but we think this could be a cool low maintenance tool for teaching Brian or computational neuroscience.

4 Likes

I’ve been thinking quite a bit about python in the browser recently! Mostly for teaching and applications that would benefit from a lot of interactivity / iteration.

Patrick Mineault had this great blogpost recently:

which mentions pyodide and starboard.

If anyone wants to "Brian"storm this further, feel free to message or tag me

2 Likes

I am very much interested in this topic. It seems that jupyterlite has a lot of momentum right now, so this might soon replace our usual notebook + binder solution for the examples/tutorials. When I tested it, it had quite a few issues, though, and installing/importing big packages took ages. But I am sure this will all improve very soon. From Brian’s side, it might also help to refactor the code a bit and make more dependencies optional – in the browser, we only want the numpy code generation, we don’t care about Cython etc. (IIRC, I stripped out a lot of stuff for the demo that is linked above).

For simple interactions in visualizations (e.g. tooltips, highlighting lines/points linked across subplots, etc.), I fell in love with vega-lite + altair (to use it from Python) a while ago. I am planning on using this more and more in (HTML-based) scientific presentations and websites.

1 Like

PS: Love your interactive visualization of dynamic systems – teaching (and learning of course :wink: ) will be so much more fun with such approaches.

2 Likes

altair / vega looks great for data exploration! I ended up watching this 5 minute video:
Altair: Declarative Visualization in Python and being able to quickly filter and color-code data seems very useful

1 Like

[edited]
thank you! I used p5.js for interactivity for that application, mostly because it’s what i was familiar with.


I suppose it’s useful to think of multiple use-cases for Brian in the browser:
1. Script Exploration: Allowing students to interactively change parameters within a “standard” python script / notebook
- this is mostly to facilitate “oh that’s what effect that value has” and understand the script and the parameters better
2. Data Viz/Exploration: Allowing researchers to dig deeper into factors affecting a simulation, perhaps as a prototyping step before launching a large automated parameter sweep. Or data vis / exploration after a sweep is complete.

Both of these start from a script and want to add interactivity to certain pieces. I think these could be partially addressed with interactive plotting libraries (altair, d3, bokeh) within standard jupyter notebooks, but I suppose the benefits of moving to the browser are:

  • reducing the install / setup burden for the student
  • easier hosting / distribution
  • potentially richer interactivity
    Solutions like jupyterlite / starboard / observable seem like promising solutions to move in that direction.

But use case 3 starts from one central interactive element first, then add the Brian2 / python scripting pieces to support it:

3. System Exploration / Showcase: A demonstration of an interactive neural system either to demonstrate concepts in a way that abstracts away the code implementation, or break the inputs and outputs from the confines of a jupyter cell.
This would be less useful for teaching people how to write code with Brian, but could demonstrate bigger concepts well. I think of the dynamics visualizer as falling under this category, but without the python.
I think this use case requires a somewhat different implementation where python / Brian is being called from within a larger html + js canvas (likely using pyodide)


I think a minimal-dependency “lite” version of Brian2 would be useful for sure. The other feature which would be useful would be to pull outputs from a simulation as it’s running. It looks like based on the discussion here:

there are some ways to achieve this already, but I might need to follow up with you about how best to do that without writing to files

1 Like

I have to run but very quickly in case you are not aware of it: we have a two little interactive notebook examples (one with matplotlib, one with plotly) in the repo for the examples from our paper: GitHub - brian-team/brian2_paper_examples
You can run them on binder (but running them on jupyterlite or something similar would be even better): Binder

The interactive eye tracking demo is great! And is a good example for showing how to use the network operation to read out data mid-simulation.

With jupyterlite that matplotlib/plotly interactivity could be turned into a p5 canvas cell for more complex inputs / rendering (although I think the current solution works well for this application)

I’ve been revisiting the interactive examples in the examples folder, and trying to make something similar with bokeh as the plotting library.

I followed the same approach with starting brian using threading.Thread() and setting data in

@network_operation
def plot_output(t)

but I’m having an issue where the accessed data changes sizes between lines (presumably because of the threading) which is making it difficult to access and register the time vector to the data.

Is this something you bumped into with the matplotlib and plotly examples? I’m wondering whether it has to do with the bokeh server I’m running or something I’m missing from how the originals are implemented, so later this week I’ll do a more in-depth analysis and post some code

You mean the data changes while you are inside the plot_output function? This is odd, this function is executed by Brian and therefore running in the same thread, I don’t see how data could change. Maybe you can reduce everything to a minimal example and post some code?

I haven’t had time to get back to my interactive bokeh example,
but seeing the announcement of PyScript reminded me of how cool it would be to have more examples of Brain2 running in the browser!
Ultimately PyScript looks to be built of Pyodide, so that should mean it shouldn’t be too difficult to make the current Pyodide example work with it… but also, that the same Pyodide caveats apply (i.e. not all packages are supported, may take a long time to import dependencies).

If anyone else is particularly interested in interactive visualizations, I ended up putting together an ad-hoc list of tools (mostly python, some javascript), and a basic quiz to help you decide which tool is right for you
you can check that out here:
awillats/interactive-visualization-resources-and-advice

2 Likes

I am also excited about all that is happening in that space! For Brian, I have two things in mind for the future (if anyone is looking for an internship to work on this, please contact me :smiley: ):

  1. making Brian available as a package for Pyodide in some maintainable way (stripped down to the numpy code generation target for simplicity, probably)
  2. Using emscripten to turn our C++ standalone target into a WASM target.

The first approach would be great for documentation and examples, since a user can try out models and change them without the need to install anything. The second approach would be great for presentations/blog posts/interactive papers, since you could run a predefined model in a very efficient way (no need to download the full Python stack, etc.).
We proposed both projects for this year’s Google Summer of Code, let’s see whether we’ll have a student working on either of them :crossed_fingers:

PS: Great comparison of tools on your webpage!

2 Likes