For the past years Arbor has been released without a schedule, mostly as a fuzzy function of the merger of new features. As of today, we’ve decided to change to a 3 month release cycle, both to get new features in a new release faster and to create more clarity on what users can expect the next Arbor.
The next Arbor release is planned for 19 January 2022.
Part of this change is the introduction of the Arbor Developer Meeting. This meeting takes place 10 weeks before the release, and is open to everyone. In this meeting, a proposed list of features (see “Next Release” column) is proposed for delivery in the next release. This meeting is the right place to make your own priorities known, and any filed Issues can be added for inclusion in the next (or one after) release. Please do join if you have research that depends on the delivery of features in Arbor releases, or if you’re interested in Arbor development! If you’d like to bring anything to our attention in the meeting, make it’s filed as an issue.
Our Kanban board lets you follow all of this outside of the developer meetings. At a glance you can see what’s cooking in Arbor. We plan to use Github’s Milestone feature to plan Issues for specific releases, so with time, the Milestone overview shall also give you some insight in what’s planned for and what’s already merged in Arbor.
The next developer meeting is planned for 24 November 2021, from 10:00-13:00 CEST. The meeting will be held here; downloadable as ICS file. Any changes to the scheduling of this meeting will be advertised here and through our Gitter.
Issues are not just for bugs, we use them also for Feature Requests. An example feature you want Arbor to have is file format X support. You want this feature because you have found a fantastic model of something you’re writing a publication on in model database Y. Model database Y makes their stuff available in format X, hence you needing this feature. You want this feature rather quickly, because you have a submission deadline in 3 months! How do you file that issue?
The Feature Request Issue is pre-filled with the following template:
**Describe the feature you need**
<!-- Example: I want Arbor to support file format X -->
**Explain what it is supposed to enable**
<!-- Example: Model database Y can export in format X, which means I could use their models in Arbor. -->
<!-- Example: I'm writing a paper on the olfactory bulb and database Y has a model ready to go! -->
There’s a few sections here with the above example pre-filled in HTML comment tags (you can replace that with your actual issue). Try to make this description elaborate enough such that others can understand the what and the why, and what, if anything, you have tried in terms of how. Don’t worry if you’ve not tried anything; the idea of a Feature Request is not that you’re on the hook for writing the code that will address it. Rather, the idea is that you together with others will find a good approach for an implementation before too much time is spent on writing one that possibly needs to be discarded, because it turns out that someone else knew of an important reason or edge-case why that particular implementation would never work. The Feature Request is meant to communicate your need, and a signal for all Arborians to sit down and cooperate on the best solution for that need.
When you file an Issue, and a Feature Request in particular, make sure you add or remove relevant labels, which help others roughly understand what the request pertains to. There are also two priority labels, which you can use to signal your urgency and desire for a timeline on addressing the issue. Although we try to have timely replies to all Issues, those labelled with a priority will get, you guessed right, priority.
We aim to design a high-level, declarative specification of network connectivity
for use in simulations of morphologically detailed neurons . Many simulators and
network data formats use lists of 1:1 connections to describe and instantiate
networks. Sometimes features exist to describe randomized connections and
parameters in these connectivity descriptions. We seek to formulate and implement
a domain-specific language (DSL), informed by prior art [2,3,4], that can describe
such higher level connectivity. The project includes a study of the design space
simulators and the requirements of neuroscientists. From this a model should be
developed that captures practical users’ needs while building upon a composable
structure. The end result is inclusion of this network DSL in Arbor , and
and perhaps eventual (partial) inclusion in other formats .
We are estimating this to be a 6-12 month project, suitable for a Master student
looking for a thesis-project, or with a optionally increased scope suitable as a side-project for a PhD student or Postdoc with some prior experience. Depending on
the candidate and available time we could change the scope as needed. A background in
neuroscience, especially in modeling, and experience with other simulation tools
is helpful. We require a working knowledge of C++.
At the 2021 edition of the CNS conference, Arbor is present with a tutorial. We have a 3-hour timeslot with an introduction and a hands-on session on July 1st. Starting time: 06:00 Los Angeles, 09:00 New York, 15:00 Berlin, 23:00 Sydney.
Arbor is a performance portable library designed to handle very large and computationally intensive simulations of networks of multi-compartment neurons. At the same time, Arbor is designed to be easy to use and understand, so that also beginners to computational neuroscience can get up to speed quickly. Furthermore, Arbor aims to prepare computational neuroscientists to take advantage of HPC architectures. Whether your model is large or small, Arbor is able to optimize and compute your result on almost any current and future hardware.
In this session, we’ll first introduce the Arbor simulator library. We will go into questions such as:
What is portability and why is it relevant to a computational neuroscientist?
What is performance portability and why is it relevant to a computational neuroscientist?
How did the above considerations impact Arbors design?
How did it impact Arbors API design, which is to say: how easy to use is all this?
What’s new in Arbor? Current developments include performance improvements for gap junctions, file format compatibility, the Arbor GUI and more!
After the introduction, it is time for a hands-on session where Arbor is used to:
construct a morphological cell,
construct a network,
configure how the simulation is run (single core, multi core, GPU, or MPI, up to you!),
Participating in the tutorial assumes that attendees are comfortable using the Python programming language. No prior knowledge of Arbor or constructing neuroscientific simulations is required.
Although preparation is not required, having a look through the Arbor documentation beforehand can help you get the most out of this tutorial. If you wish to run the tutorial on your own machine, make sure you have Python installed (v3.6 or higher) and have installed the arbor and seaborn packages through pip, e.g. pip install arbor seaborn.
Note: Windows users are supported through WSL and WSL only at this time.