Summary of tests with the testchannels package

The 'testchannels' package was developed to test backwards compatibility of GENESIS 3 (G3) with GENESIS 2 (G2) for scripts that use different GENESIS commands or options for filling the channel gate tables. These are described in the "Units Conversion" documentation. ( In the process of testing, other backwards compatibility issues were also discovered. The results of these tests, carried out in February 2011, are described in this document.

To simplify the analysis, several of the models use the same two-compartment 'simplecell' model, with different Na and K channels, or different GENESIS commands or options for filling the channel tables. The 'simplecells/' directory of this package has tests for many of the problems encountered in testing more complex models. For example, the 'simplecell-M' model implements the solution to an exercise in the GENESIS Modeling Tutorial section "Building a cell the easy way" ( This fails to run under GENESIS 3 for reasons that are more fully explored in the 'simplecells/' tests.

The script 'simplecells/simplecell_spike_pulse.g' was designed to be used as a very simple script that can be mapped to G3 Python commands as a short example that does something non-trivial. The script is less complex than those in the "input-models" test package, but illustrates the same challenge of creating an experimental protocol in a script, and then saving and running it in NDF format. For simplicity, this version does not have a graphics option for use with G2.

The script executes three functions:

make_input - provide pulsed spike trains to /cell/dend/Ex_channel
make_cell - readcell of the simplecell cell.p file
make_output - output the Ex_channel current at intervals out_dt < dt

and then executes function 'step_tmax' to run the simulation

Note that this cleanly separates the user workflow steps of (1) Construct model; (2) Design experiment; (3) Run simulation; (4) Check and analyze results. It does (4) in a trivial way, by just outputting the synchan current, but in principle it could sum synaptic currents over all cells in a network, and output the sum for Fourier analysis as simulated MEG signals. This example should be runnable with either sli_run, or with ndf_load. It fails to run with G3 because backwards compatibility has not yet been implemented for SLI descriptions of experimental or output/analysis protocols.

The most complex model studied is the 'BDK5cell2' layer 5 cortical pyramidal cell model with 9 compartments and 9 voltage or calcium activated channels in the soma. This is proposed as a initial set of channels for testing the RTXI dynamic clamp interface. The original 'BDK5cell' model cannot be run with G3, but the BDK5cell2 model provides an equivalent "workaround" that can be saved and run as an NDF model.

These tests revealed the following "bugs" or unimplemented features that prevented G2 scripts from running properly under G3, although workarounds are available for some:

Notes on gate table scaling and shifting

Problems involving the scaling and shifting of tabchannel gate table values constitute a large category of "bugs" or "ns-sli deficiences" encountered in these tests.

Many GENESIS 2 channel creation scripts create a tabchannel with A and B gate tables that contain 3001 points, or 3000 divisions (the 'xdivs' field). The usual voltage range (specified by 'xmin' and 'xmax') is from -0.1 to 0.05 V. This is the default behavior of the 'setupalpha' function. This range is appropriate because action potentials can safely assumed to be within this range. However, there are many reasons to use a wider voltage range and to allow scaling and shifting of the gate table values.

When constructing a new cell model by populating a morphology with channel models taken from various sources, it is usually necessary to make some changes in the channel activation functions that can be accomplished by scaling or shifting gate table values. For example, "Q10 scaling" or adjustments for temperature differences between species or experimental conditions depend on scaling of 'tau'.

When using a channel model in a cell with a different resting potential than the cell for which it was developed, it is common to shift both 'tau' and the 'minf' functions up or down along the x-axis (voltage) by an amount depending on the resting potential. This insures that, when the cell is at its resting potential, the channel will be in the same state of activation that it would be in the original cell at rest.

G2 uses a global variable 'EREST_ACT' for shifting of activation and tau curves along the voltage axis. Section 1.3.1 "Conversion of Parameterized Constants to SI Units" of the 'units-conversion' document describes how EREST_ACT affects the values of the gate 'setupalpha' parameters. The activation time constant 'tau' can be scaled without affecting the activation if the A and B tables are scaled by the same amount. This may be seen from "units-conversion" Eqs. (11) and (12).

There is a potential problem when shifting gate tables, however. Shifting of tables along the x-axis is accomplished by moving data values up and down in the tables. This means that data can spill out of the ends of the tables and be lost. This can be prevented by making extra room at the end of the tables with a wider range of voltages ('xmin' and 'xmax') than would be strictly required. Some of the G2 'Neurokits/prototypes' scripts, such as 'yamadachan.g' use a range of -0.1 to 0.1 V.

In spite of its antiquated XODUS-based GUI, the channel editor of the G2 'Neurokit' application continues to be a powerful and useful tool for "tuning" a cell model. It is based upon the G2 methods for scaling and shifting gate tables. G3 will at some point need a Python-based channel editor that gives this capability with a much better GUI.

There are four ways that scaling and shifting may be performed in GENESIS 2.

  1. At the time of creation, by modifying the setpalpha parameters or equations used to fill the tables. The use of the 'EREST_ACT' variable described above is a simple way to perform shifts along the voltage axis. However, this does not provide for adjustments when "tuning" a channel that has already been created.
  2. By use of the sx, sy, ox, oy fields of a tabchannel to perform scaling and offset of the A and/or B gate tables. This is similar to the use of 'scaletabchan' to perform the operation on alpha, beta, tau, or minf, and may often used as a replacement by scaling A and B appropriately.
  3. By use of 'scaletabchan' to change the channel gate tables. The values of alpha, beta, tau, or minf may be scaled or offset along the x or y axes by specifying a value of sx, sy, ox, or oy.
  4. By use of script commands to get table values, modify them, and set them to the new value.

At present, only the first of these methods is possible with G3.