-
Notifications
You must be signed in to change notification settings - Fork 61
HBP SGA2 KPIs
Note that we contributed to over-achieving relative to the KPI aims for the number of features merged+released+prototyped in SGA2. This could be for a few reasons:
- development teams were particularly efficient (e.g., the Arbor devs have been very focussed)
- multiple software products contributed, who might have different definitions of "feature".
- it was the first time we had used this metric, and we didn't have a good baseline to compare to.
These tables list the features that are in experimental state, merged in master and in official releases.
The PRs that implemented the feature in master or a release can be looked up here.
https://github.com/arbor-sim/arbor/pulls?q=is%3Aclosed
Note: A table with details about each feature is below these summaries.
| period | features |
|---|---|
| M1-6 | 3 |
| M7-12 | 3 |
| M13-18 | 1 |
| M19-24 | 2 |
| period | features added | total features |
|---|---|---|
| M1-6 | 11 | 11 |
| M7-12 | 9 | 20 |
| M13-18 | 5 | 25 |
| M19-24 | 4 | 29 |
In the last 6 months a lot of work was invested in porting user models, ease of use and documentation, which are not really features.
| period | features added | total features |
|---|---|---|
| M1-6 | 0 | 0 |
| M7-12 | 20 | 20 |
| M13-18 | 3 | 23 |
| M19-24 | 6 | 29 |
Note: v0.3 of Arbor was released in M24. Note: v0.2.1 and v0.2.2 of Arbor were released in M17 Note: v1.0 of NSuite was released in M12, which contributed 3 features. Note: v0.1 and v0.2 of Arbor were released in M7 and M12 respectively.
| period | systems added | total systems |
|---|---|---|
| M1-6 | 3 | 3 |
| M7-12 | 1 | 4 |
| M13-18 | 0 | 4 |
| M19-24 | 0 | 4 |
Note: See the bottom of this page for a detailed list of systems. Note: Support for all features on all 4 systems was added in M12. In M12-M24 the focus
Each feature has a status that indicates its readiness on each target system:
| Value | Meaning |
|---|---|
| 0 | Not implemented. |
| 1 | Functional implementation. |
| 2 | Optimized implementation. |
| - | Not applicable. |
A feature is marked not applicable on a system if it does not require a hardware-specific implementation. For example, the online documentation does not require a hardware-specific implementation.
We assign an overall "Status" to each feature, describing the quality of the implementation of the feature as described in the following table. Features with no hardware-specific component will have a status of 1 (functional, but requires performance optimization) or 3 (functional and optimized).
| Status | Meaning |
|---|---|
| 1 | Functional implementation on at least one platform. |
| 2 | Functional implementation on all platforms. |
| 3 | Optimized (if relevant) implementation on all platforms. |
| Feature | mc | gpu | Status | Description | PR | Month |
|---|---|---|---|---|---|---|
| 1 Abstract mech backends | 2 | 2 | 3 | Support user mechanisms and seperate back ends | #484 , #487 | M2 |
| 2 Optimised SIMD | 2 | - | 3 | Partition loops to optimize SIMD memory access patterns | #494 | M3 |
| 3 Generalised time sequences | - | - | 3 | implement a single interface for time sequences to replace ad-hoc implementations | #496 | M3 |
| 4 Benchmark cell | - | - | 3 | Proxy cell type for benchmarking simulation infrastructure | #500 | M3 |
| 5 C++14 support | - | - | 3 | Move from C++11 to C++14 | #522 | M4 |
| 6 Task-stealing thread pools | - | - | 3 | Replace different threading back ends with optimized task-stealing thread pools | #528 | M4 |
| 7 Installable target | - | - | 3 | Large refactoring to define public API and make installable target | #506, #508, #518, #531 | M4 |
| 8 Execution contexts | 2 | 2 | 3 | Flexible run time selection of MPI, thread pool and GPU resources | #537, #555, #566, #576 | M5 |
| 9 General "dry run" | 2 | 2 | 3 | Dry run mode for benchmarking simulator scaling with reproducable results | #582 | M5 |
| 10 Threading exceptions | - | - | 3 | Correct propogation of exceptions from thread pool to calling code | #595 | M6 |
| 11 OS X in CI | - | - | 3 | Update Travis CI to test gcc+clang on OS X, add clang to Linux tests | #601 | M6 |
| 12 GPU fine-matrix solver | - | 2 | 3 | GPU-optimized for neuron matrices that parallelizes over cell branches | #631, #638 | M8 |
| 13 User library | 2 | 2 | 3 | Provide a library with useful helper functions for users (e.g. gpu detection, scope guards, MPI intialization) | #679 | M10 |
| 14 GPU Assignment | - | 2 | 3 | Detection and assign GPUs to MPI ranks on multi-gpu systems. | #659, #654 | M9 |
| 15 Gap Junctions | 2 | 2 | 3 | Support for electrical gap junctions in models | #661, #686 | M11 |
| 16 Benchmark & Validation suite | 2 | 2 | 3 | A framework for automated benchmarking and validation oh HBP systems | github.com/nsuite | M11 |
| 17 busyring benchmark | 2 | 2 | 3 | Benchmark with configurable computation and communication workloads | github.com/nsuite | M11 |
| 18 RC+synapse validation test | 2 | 2 | 3 | Validation test of voltage trace from single compartment RC cirtuit+expsyn model | github.com/nsuite | M11 |
| 19 synapse collapsing | 2 | 2 | 3 | Automaticly combine synapses with linear responses in the same compartment | #680 | M12 |
| 20 ARM NEON support | 2 | - | 3 | Support for generating ARM NEON instrinsics via the SIMD back end | #698 | M12 |
| 21 Consistent ion species | - | - | 3 | User defined and built in ion species with consistent implementation when used by multiple mechanisms (e.g. method for calculating reversal potential) | #781, #786, #777, #823 | M16 |
| 22 Python front end | 2 | 2 | 3 | Python wrapper of the C++ API for user-friendly model development | #799 | M16 |
| 23 Per-branch/cell parameters | - | - | 3 | Interface for definining mech/electrical parameters at cell and branch level | #817, #823 | M16 |
| 24 Flat mechanism placement | - | - | 3 | Rich flat descriptions of morphology regions & locations for placement of ion channels and synapses | #834, #860, #864, #865 | M18 |
| 25 modcc features | 2 | 2 | 3 | NMODL features required for realistic models, incl. nonlinear kinetics, conserve & linear blocks | #879, #846, #840, #829 | M18 |
| 26 Flat morphology back end | - | - | 3 | Full back end support for building models from flat descriptions | #941 | M22 |
| 28 Python single cell workflow | - | - | 3 | Optimized workflow for building cell models using Python | #948 | M23 |
| 27 Python installation | - | - | 3 | Support for easy Pythonic installation using pip and setuptools | #977 #971 | M23 |
| 29 Rich sampling | 2 | 2 | 3 | Sampling if mechanism variables, who cell samples, voltage interpolation | #TBD | M24 |
At the end of SGA2 there are 2 large features in development/prototype branches:
An extension to the simulator API for feeding spikes from another simulator into Arbor. This feature will be continued in SGA3, as part of multi-scale simulator interaction in WP 5.
https://github.com/arbor-sim/arbor/tree/spike-external
Is used in a prototype coupling between Nest and Arbor
https://github.com/apeyser/nest-arbor-proxy
This hasn't been merged yet, because we are considering how to make it more general, so that it accomodates more flexible coupling between simulators.
https://github.com/arbor-sim/arbor/issues/626
SONATA is an open exchange format for network models of neurons:
https://github.com/AllenInstitute/sonata/blob/master/docs/SONATA_DEVELOPER_GUIDE.md
In SGA2 we developed a stand-alone adaptor that loads SONATA models and presents them to Arbor as recipes:
https://github.com/arbor-sim/arbor-sonata
This work will continue in SGA3, where SONATA will be a key format for input of models into workflows in SGA3 T5.2.
Arbor has been ported to four systems:
- Piz Daint: multicore partition (Broadwell Xeon CPUs) @ CSCS
- Piz Daint: gpu partition (Haswell Xeon CPus and P100 GPUs) @ CSCS
- Juwels: Xeon cluster module nodes (Skylake Xeon CPUs) @ JSC
- Tave: gpu partition (Intel KNL CPUs) @ CSCS
We define ported as:
- Has target-specific optimizations
- AVX2 Haswell & Broadwell CPUs
- AVX512 for Skylake Xeon and KNL CPUs
- CUDA for NVIDIA GPUs.
- Compiles and passes all unit tests
- Can run the nsuite benchmark and validation suite.