We are missing two major parts of the NeuroML (NML) specification that seems to be used heavily by our
partners and would thus be a major selling point for Arbor
Network descriptions
Ion channel dynamics
As Arbor's way of describing network is still quite primitive, I propose to postpone 1. until we have a
more solid understanding of the Arbor way.
However, 2. is a major pain point as the current route of getting NML mechanisms into Arbor is to
use jNML to export the mechanisms to NMODL and compiling them through modcc into an Arbor catalogue.
This neccessitates hand-editing of the output to adjust to Arbor-flavoured NMODL, which is also approximately
an order of magnitude slower than hand-written NMODL. This further hindered by the readability of jNML's output
and needs to be done every time an .nml file changes.
Therefore, we should have native support of NML mechanisms in Arbor. I propose to work in these stages:
Parsing nml, selecting, and configuring mechanisms from a pre-built catalogue.
Using jLEMS to compile LEMS to Arbor.
Full LEMS support in Arbor.
This is made feasible due to the MechABI and might tie into ArbLang or its compiler in stage 3.
Update November 2021
After spending time with the NML2 specifications and building a prototype reader for .nml, we must
discard option 1. from the list. It is simply not feasible due to the nature of NML. Example
This ion channel can -- in principle -- have an arbitrary number of gateHHrates, each with a forward
and a backward rate chosen from multiple implementations of baserate.
Traversing the implementation and building custom instantiations is the only viable path forward.
Introduction
We are missing two major parts of the NeuroML (NML) specification that seems to be used heavily by our partners and would thus be a major selling point for Arbor
As Arbor's way of describing network is still quite primitive, I propose to postpone 1. until we have a more solid understanding of the Arbor way.
However, 2. is a major pain point as the current route of getting NML mechanisms into Arbor is to use jNML to export the mechanisms to NMODL and compiling them through modcc into an Arbor catalogue. This neccessitates hand-editing of the output to adjust to Arbor-flavoured NMODL, which is also approximately an order of magnitude slower than hand-written NMODL. This further hindered by the readability of jNML's output and needs to be done every time an
.nml
file changes.Therefore, we should have native support of NML mechanisms in Arbor. I propose to work in these stages:
nml
, selecting, and configuring mechanisms from a pre-built catalogue.This is made feasible due to the MechABI and might tie into ArbLang or its compiler in stage 3.
Update November 2021
After spending time with the NML2 specifications and building a prototype reader for
.nml
, we must discard option 1. from the list. It is simply not feasible due to the nature of NML. ExampleThis ion channel can -- in principle -- have an arbitrary number of
gateHHrates
, each with a forward and a backward rate chosen from multiple implementations ofbaserate
.Traversing the implementation and building custom instantiations is the only viable path forward.