Interaction between PSICS and NeuroML

Significant development effort has been devoted towards making PSICS compatible, as far as possible, with other systems. In particular, this involves supporting emerging standards such as ChannelML and MorphML, and more generally XML data formats under the NeuroML banner.

The approach has not, however, been to take the NeuroML specifications as defining the model space and to write a simulator for them. Instead, the PSICS input specifications were developed independently of existing specifications or simulators and are driven purely by the need to express what the modeler who uses PSICS needs.

This therefore presents a useful test case for the expressiveness and ease-of-use of NeuroML. This document details our experiences of working with NeuroML and makes a number of suggestions of ways the standard could be further developed to improve its usefulness as a model storage and trasfer format for projects such as PSICS.

This section first presents a couple of caveats concerning difficulties of using NeuroML with PSICS, then presents the general issues between the two systems that are not related to particular formats. Separate sections cover the details of the degrees of compatibility between PSICS and MorphML, ChannelML and the NeuroML biophysics specification.

Caveats

The overall conclusion is that NeuroML as it stands is some way from being suitable as a means to port models into PSICS, and significantly further from being suitable as a lossless model storage format. These observations however, should be qualified in two ways:

1. The domain of application of PSICS does not ovelap exactly with those of other simulators for which NeuroML has been developed. For example, PSICS has individual kinetic scheme ion channels with exact locations on the cell rather than current densities.
2. NeuroML is designed to be written by software, not written by hand. But there is no machine written model output stage in PSICS where such a format is required. PSICS takes hand written XML (techically, this means it is "well formed" but not "validated"; in appearance it should be much more concice and readable than machine-generated XML). PSICS does have a model output stage where the pre-processed model is written as a text file full of tables for processing by the core calculations, but this is very much an internal format for communication between the model processing stage and the calcluation stage.

The consequence of the second point above is that any automatic NeuroML-to-PSICS import is likely to be rather difficult. It may be compared with the problem of taking the HTML output generated by a program such as MS Word (full of embeded font specifications, exact positioning etc) and generating the equivalent markup that might have been written by hand (with aextensively reused styles for example). It is typically not a fully defined process because some of the information originally supplied by the user has been irretrievably lost in the machine-generate markup.

An example of the problem for simulating neurons is what happens when a user labells a section of a dendritic tree for specifying channel densities. In a user interface they might pick a start and end point on the dendrite and say that all points between them are part of "dendrite1". A modeling system would typically write this out either by adding the "dendrite1" label to all corresponding points in the structure, or as a mapping of a "dendrite1" label to a list of the IDs of all those points. In either case the entropy has been increased and the minimal description of the region "points between selected start and end points" has been lost. The input formats for PSICS, however, a aim to capture the minimally redundant version and would require the start and end points for its region definition. In this case they could be deduced from the labelled regions but htis is not always the case. It is not always possible to recover such structures in a sufficiently clean form from machine generated output that they can still be edited by hand. Since PSICS has no user interface, hand editing is the only option for modifying a model, so the retrieval of clean and simple XML is essential for an import to be useful.

General observations

There are two main grounds for comparison: what can be expressed in NeuroML and how it is expressed. The former is obviously important for its suitability for use by a modeling system. The latter primarily concerns ease-of-use by developers since NeuroML is not intended to be written by hand. However, in an environment where developers are largely self-motivated, elegance and ease of use are very important for a standard to gain acceptance and adoption.

Most discussion of what can be expressed is deferred to the separate sections on channels, morphology and biophysics, but, from a PSICS perspective, NeuroML is currently heavily rooted in historical ways of making models. This is understandable in a format developed to facilitate exchange of existing models, but the consequence is that NeuroML provides scope for expressiong a wide range of things that PSICS does not support, and that it omits a number of things that are essential to PSICS. It also sometimes encodes a particular way of handling simulations that is not always system-independent.

For example, the original specification of PSICS included only one parameterized form of voltage-gated transition - the modified Boltzmann type equation with extra time constants for saturation of forward and reverse rates. This is widely used by biophysicists and has been introduced for whole cell models in the 1980's (Graham[1], Destexe[2]). It effectively supercedes the phenomoenological fits with sigmoids, linoids, exponentials etc. For validation purposes, support for the phenomenological forms had to be introduced so that results could be compared with existing models, but such forms are deprecated in PSICS. Unfortunately these are the only parameterized forms offered in ChannelML. The heroic attempts in ChannelML to proivide declarative forms for some of the more baroque expressions that have occured in the literature (such as the Kdr channel in the ChannelML section) risk significantly complicating the standard to allow things to be expressed in ways that are not necessary. These forms were convenient to express in code in a procedural modelling system and served a useful purpose at the time but there are almost certainly functionally equivalent parameterized versions with the standard transition form that could now be used. Creating a declarative representation for everything that used to be expressed in code risks making a very large and complex specification with high support costs for minimal gains.

Another example is in the use of segments and cables in MorphML. This seems to be rooted in the way Neuron allocates channels to cells rather than the requirements of morphologists. Cables are more an electrical concept than a morphological one. Indeed, most digitized neurons simply give a set of connected points with radii so even segments are not fundamental. Inddeed PSICS uses neither segments nor cables internally. Although it is in general possible to get back to a point-based representation from segment-and-cable morphologies this looks rather like the standard being driven by the internal representations used by a particular simulator rather than a choice of the most elegant, expressive and platform neutral structures.

It should be noted, however, that, from a developer's perspective, the above is not necessarily a criticism. It is a criticism of the assertion that this representation should become the universal standard, but from a pragmatic perspective it may be the best approach. If, say, the developer of PSICS and the developer of Neuron wish to make the development effort necessary so that a Neuron user can save a cell with its channel density specifications in such a way that a PSICS user can import them losslessly then there is a debate to be had about how much work each developer does and where they place the dividing line that sets the format of the file that is actually transferred. It is not a priori obvious that the best solution is to put the dividing line symetrically in the middle between the two and aim for some universal standard. Indeed, the normal situation is that ther are two dividing lines, in different places, for the two directions: typically the importing application (which has more to gain) makes much more effort than the exporting one. The optimal situation could well be that on export an application writes a declarative specification that is clean and complete but also fairly close to its own internal representation. On import, an application does the extra work to get from there to its own internal format. The same occurs for transfers in the other direction. In neither case is a universal standard used. The separate developers can each work more or less independently to import a format that they trust to be complete.

This assymetric import scenario breaks down, of course, when there are many players. In such cases (eg SBML) there is a much greater benefit to having a universal standard, although it comes at considerable cost in that most transfers become lossy. The bottom line from this discussion is that for importing models from Neuron it is fine, may even be optimal, to have a declarative format that is relatively close to Neuron's internal model, but that such a format is not so likely to be the best option for exporting models from other systems.

XML Style

Stylistically, we have four main concerns about the NeuroML specifications.

1. Overly deep nesting
2. Unnecesary dissociation of conceptually bound items into different parts of a file
3. Use of "magic" attribute values within generic elements rather than defining appropriate elements
4. Implicit units

For examples of most of these, see some of the equivalent ChannelML and PSICS representations for various ion channels.

An example of the first is in the first channel model on that page. The nesting for the statement that there is an m^2 dependence in the channels involves elements with names current_voltage_relation - ohmic - conductance - gate -state as in the block below:

<current_voltage_relation>
    <ohmic ion="ca">
        <conductance default_gmax="9.084216">
            <rate_adjustments>
                 <q10_settings q10_factor="3" experimental_temp="17.350264793" />
                 <offset value="0.010" />
            </rate_adjustments>
            <gate power="2">
                 <state name="m" fraction="1" />
            </gate>
            <gate power="1">
                 <state name="h" fraction="1" />
            </gate>
        </conductance>
    </ohmic>
</current_voltage_relation>

<Channel id="Generic_CaHVA" permeantIon="Ca">
	<gate id="m" instances="2">
		...transition data
	</gate>
</Channel>

The same example also illustrates the second point. The current_voltage_relation eventally refers to two "states", m and n, but the definition of the kinetics of these states is elsewhere in the file (leaving aside the semantics of whether it is acutlly a "state" or a "gate").

The following fragment illustrates the magic attribute problem:

<voltage_gate>
   <alpha>
       <parameterised_hh type="sigmoid" expr="A/(1 + exp(-k*(d-v)))">
           <parameter name="A" value="1600" />
           <parameter name="k" value="-72" />
           <parameter name="d" value="0.005" />
       </parameterised_hh>
   </alpha>
   <beta>
       <parameterised_hh type="linoid" expr="A*(k*(v-d))/(1 - exp(-(k*(v-d))))">
           <parameter name="A" value="100" />
           <parameter name="k" value="-200" />
           <parameter name="d" value="-0.0089" />
       </parameterised_hh>
   </beta>
</voltage_gate>

A paramterized_hh transition can be one of a few types - sigmoid, linoid etc. And for each type, a number of parameters are required. The user of the specification must recognize the type and then look for parameters with the right names. Internally, they almost certainly want to create a "sogmoid" object with field "A", "k", and "d", since this is the natural representation of the information. Fortunately, this can also be expressed in XML as, eg,

	<Sigmoid a="1600" k="-72" d="0.005" />

<voltage_gate>
<Sigmooid direction="alpha" a="1600" k="-72" d="0.005" />
<Linoid direction="beta" a="100" k="-200" d="-0.0089" />
</voltage_gate>

Finally, the issue of units is probably significantly more important for hand written models as used in PSICS than for machine written formats like NeuroML. However, the requirement that ther should be some units on physical quantities and the ability to use almost any dimensionally consistent units is definitely popular with users and provides a degree of assurance that you really are expressing the model you intend to express.

It would be very good at least to have the option of including units with NeuroML models either to override globally specified defaults or in place of any global units set. Physical quantities with units, as in the example below, are not particularly hard to parse and process, and are much closer to normal usage where unit-less statements such as "the distance is 3" or "the duration is 2.5" are almost never seen.

<SigmoidTransition rate="1600.0per_ms" scale="0.01388mV" midpoint="0.0050mV" from="mc" to="mo" baseTemperature="17.3Celsius" q10="3.0" />

Next: experience working with MorphML, ChannelML and NeuroML biophysics.