Kinetic schemes

The existing components provide everything necessary to define types that allow a model to specify a kinetic scheme (Markov model). The missing ingredient is the Dynamics element to actually expresses how instances of the components develop through time.

First then, the following definitions can be used to express ion channel models where the the channel state is represented by an occupancy vector among a number of distinct states with rates for the transitions between states.

This says that a gate can contain any number of states and transitions. A state has an occupancy variable, and a transition has links to two states giving the source and target states for the transition.

The transition element here is an abstract element because it doesn't provide a Dynamics block but just specifies what quantities transitions should privide via the two exposures. One of the most useful forms of transition is a damped Boltzman equation which can be parameterizd as follows:

Given these definitions, we can express a couple of simple channel models that use kinetic schemes. There is nothing special about these models. They are just examples used in PSICS that produce spikes (albeit rather unnatural looking ones) when used together.

This has all been done with the existing components. They allow types to be defined for expressing kinetic schemes, and models can be expressed that use these types, but there is nothing so far that says that the model actually is governed by a kinetic scheme. In particular, there is an "occupancy" state variable in each state element for which there is no governing equation and the rates generate "rf" and "rr" quantities that are not unused anywhere.

What is needed is a new element in the Dynamics block to link these together and say that the rates apply to the changes of occupancy among the state elements. This is done by adding a KineticScheme element to the Dynamics block for a gate as follows (this now shows the full definition of the KSGate element):

The new part here is the KineticScheme element and its children Nodes, Edges and Tabulable. The Nodes element says which elements in the parent container are goverened by the scheme, and which variable in those elements represents the relative occupancy.

The Edges element is a little more complicated. It has to say not only which elements define the transitions, but how the fields in the transitions map to things the scheme knows about. For a transition in a kinetic scheme, you need to know which state the transition comes from, which it goes to, and how fast it goes. It is possible (as here) that a single transition defines both directions, in which case it must also say which variable in the target objects provides the reverse transition rates. This is what the last four attributes of the Edges element do.

The Tabulable element is a temporary convenience for implementation purposes. In this case it says that the rates depend only on v and that the transition matrices can be cached an reused on a grid of spacing deltaV rather than recomputed every time. This is not used in the 0.2.1 version of the interpreter.

Note that the KineticScheme element doesn't say anything about what the outputs are. All it does is control the occupancy state variable in the state elements. The interpretation of these quantities is specified in the normal way with the two DerivedVaraible declarations. No special elements are needed in the scheme itself.

To actually use these models we need cell and population elements to link them all together. There is nothing new here - it all works just as for HH channels. The rest of the example4.xml file is:

When run, this produces:

There are clearly some initialization issues but the basic Dynamics is the same as the PSICS version of this model.