Next: Exercises Up: Networks of Cells Previous: Introduction Contents

# The `DUPLICATE` Action

To understand how to use `hsolve` for network simulations, remember for a moment how `hsolve` examines the model it has to compute:

1. First during the `SETUP` action, `hsolve` examines the structure of the model and stores parameters that describe it.
2. Second during a `RESET`, `hsolve` stores recalculated quantitative values in its private data structures.

With the `DUPLICATE` action it is possible to have multiple `hsolve` elements share the structure between identical neurons (neurons with an identical morphology, number of channels etc. The descriptive quantitative aspects like reversal potential of channels may differ between these neurons).

To use `hsolve` for a population of resembling cells, you have to:

1. create and use `SETUP` to have `hsolve` examine the structure of the first cell.
2. create an `hsolve` element for every other cell in the population. This is not done with a regular `create` command, but by calling the `DUPLICATE` action on the `solver` element for the first cell, to have the new `hsolve` element share some of its internal data structures with the first `hsolve` element. The syntax for the `DUPLICATE` action is:

           genesis > call hsolve1 DUPLICATE hsolve2 <path>

   The `<path>` argument points to the compartments to be computed by the `hsolve` about to be created and is (as always) a wild card specification that will be expanded relative to the `hsolve` element.
3. call the `RESET` action on every `hsolve` element. This is most conveniently done with the `reset` command.

NOTE: Never use the `-hsolve` option for `readcell` for cells that you want to duplicate. The layout of the cells when using e.g. `createmap` assumes that all cells reside in `neutral` elements. Such commands do not take special precautions when copying `hsolve` elements. The net result is that you are not allowed to use the `DUPLICATE` action on `hsolve` elements created by the `-hsolve` option of the `readcell`.

Let us examine an example:

        genesis > include ht_granule_compartments.g
        genesis > granule_make_compartments
        genesis > setclock 0 0.000010
        genesis > readcell granule.p /granule
        genesis > createmap \
        genesis >         /granule /granule_cell_layer 5 1 \
        genesis >         -delta 1e-4 7.5e-5 -origin 5e-5 3.75e-5
        genesis > ce /granule_cell_layer/granule[0]
        genesis > create hsolve solver
        genesis > setmethod granule 11
        genesis > setfield solver chanmode 4 path "../[][TYPE=compartment]"
        genesis > call solver SETUP
        genesis > int i
        genesis > for (i = 1 ; i < 5 ; i = i + 1)
        genesis >         call solver DUPLICATE \
        genesis >                 /granule_cell_layer/granule[{i}]/solver \
        genesis >                 ../##[][TYPE=compartment]
        genesis > end
        genesis > reset

As already noted, we do not use the `-hsolve` option for `readcell` here. After creating a grid of cells, we manually create an `hsolve` element for the first cell in the grid and initialize it with `SETUP` after proper configuration. Then comes a small for-loop that walks over the remaining cells of the population and calls the `DUPLICATE` action for each cell. Note that the wild card specification that points to the compartments to be computed is - as usual - relative to the `hsolve` element that will do the wild card expansion, it is not relative the current working element or the original `hsolve` element (that was initialized with `SETUP`). At this point we have a correctly initialized set of `hsolve` elements regarding structure. Finally we still have to initialize all data structures with the computed values, that is done with the '`reset`' command.

Although almost complete, there is still one caveat in this example that becomes clear if we inspect the simulation schedule:

        genesis > showsched

        WORKING SIMULATION SCHEDULE

        [1] Simulate    /##[CLASS=segment]      -action INIT
        [2] Simulate    /##[CLASS=segment][CLASS!=membrane][CLASS!=gate] \
            [CLASS!=concentration][CLASS!=concbuffer]       -action PROCESS
        [3] Simulate    /##[CLASS=membrane]     -action PROCESS
        [4] Simulate    /##[CLASS=hsolver]      -action PROCESS
        [5] Simulate    /##[CLASS=concentration]        -action PROCESS

As apparent from the simulation schedule, some compartment(s) and channel(s) are still scheduled to compute their internal state. Requesting a list of elements at the top of the element hierarchy makes all clear:

        genesis > le /
        *proto
        output
        *library/
        granule/
        granule_cell_layer/

The original cell that was used to create the grid of cells in the population is still scheduled for simulation (indicated by the lacking asterisk '*'). Disabling it, solves the situation, only `hsolve` will be scheduled for computations. It is necessary to do `reset` again such that Genesis recomputes the simulation schedule. If the `disable` command is put at an appropriate place in the script, only one `reset` is necessary of course.

        genesis > disable /granule
        OK
        genesis > reset
        genesis > le /
        *proto
        output
        *library/
        *granule/
        granule_cell_layer/
        genesis > showsched
        WORKING SIMULATION SCHEDULE
        [1] Simulate        /##[CLASS=hsolver]      -action PROCESS

NOTE: The way to setup input or output for `hsolve` that has been created with a `DUPLICATE` is not the same as for `hsolve` elements that have been created with `SETUP`. Only with the `findsolvefield` command you will be able to access computed fields. Messages created before the `DUPLICATE` action are ignored. (also take a look at the exercises for networks)

Next: Exercises Up: Networks of Cells Previous: Introduction Contents