Next: Messages from and to Up: Introducing Hsolve for Single Previous: Exercise: Speed Comparison Contents

# Communication with Other Elements

Knowing how to use `hsolve` can only be interesting when you also know how to setup experiments and how to save the output. Interfacing `hsolve` to other elements is not always trivial and deserves a special paragraph of attention.

A distinction can again be made between the lower and the higher chanmodes. When using the lower chanmodes - the 'compatibility' chanmodes - everything behaves almost as without `hsolve`. In chanmode 0, under no circumstance you will experience problems when interfacing `hsolve` to other objects. Incoming and outgoing messages that have been created before the `SETUP` action call are handled automatically. In chanmode 1, `hsolve` puts severe restrictions on the messages that can be send to the tabulated channels. Since `hsolve` will not always give an appropriate error message for messages that are handled or that are ignored, it is recommended not to use chanmode 1 unless you are sure that you do not have any tabulated channels with messages that are not handled by `hsolve` (these messages include `DOMAINCONC` and `ADD_GBAR`).

The higher chanmodes are the more interesting modes of operation because of their excellent performance. We will concentrate on them from now on and explain how to use them correctly.

As already said, when using the higher chanmodes, `hsolve` compiles your model into optimized byte-codes. During the simulation these byte-codes are interpreted at each time step. They instruct `hsolve` to compute the conductances and evaluate the cable equations. To be able to compile a model into byte-codes, `hsolve` must know the object type. The object types `hsolve` is currently supporting are `compartment`, `tabchannel`, `tab2Dchannel`, `tabcurrent`, `Ca_concen`, `concpool`, `difshell`, `taupump`, `mmpump`, `hillpump`, `fixbuffer`, `difbuffer`, `dif2buffer`, `fura2`, `nernst`, `ghk`, `channelC2`, `channelC3`, `synchan`, `synchan2`, `Mg_block`, `spikegen`, `neutral`.

When using these objects in a model, be sure to create them beneath the subtree of the compartments they reside in. Then you link them together with messages as usual. Afterwards you create `hsolve`, set the `path` field (point it to the compartments only), and perform a `SETUP` and `RESET` call. If anything is wrong with the model structure, e.g. if a message incoming to a channel is not handled by `hsolve`, `hsolve` will give an appropriate error message. If all is right, `hsolve` is setup correctly. This means that (1) all computations normally done by the modeling elements, are now done by `hsolve` in a more efficient way and (2) the message passing between these elements is done by `hsolve`'s internal communication facilities. This is all made transparent for a user except ......that the computed values are not stored anymore in the original elements, but they are stored in `hsolve`'s internal data arrays. How to communicate with these data arrays will be explained shortly.

NOTE: `Hsolve` implicitly assumes that you are not doing fancy things like sending an `AXIAL` message from a channel to a compartment. Genesis's flexibility allows you to construct absurd and unrealistic models. It could be that you do not get any error message if you try to have `hsolve` compute such models.

Subsections

- - - Messages from and to external objects
    - The '`findsolvefield`' command

Next: Messages from and to Up: Introducing Hsolve for Single Previous: Exercise: Speed Comparison Contents