You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
180 lines
8.5 KiB
180 lines
8.5 KiB
Architecture of CNModel |
|
======================= |
|
|
|
CNModel is built in a layered architecture that provides both high-level tools |
|
for constructing and simulating networks, as well as low-level access to the |
|
individual components. The model consists of three major pieces: *cell types*, |
|
which describe the morphology and membrane physiology of the various cell types |
|
in the cochlear nucleus; *synapse types*, which describe the strength, kinetics, |
|
and short-term plasticity of the many synaptic connections; and *populations*, |
|
which describe the aggregate organization of cell types, including their |
|
distribution within the nucleus and their patterns of connectivity. |
|
|
|
.. figure:: architecture.svg |
|
|
|
|
|
Cells |
|
----- |
|
|
|
The cell types found in the cochlear nucleus (bushy, t-stellate, etc.) are each |
|
represented in CNModel as classes that inherit from the base `Cell` class. One |
|
instance of any of these classes represents exactly one neuron, and internally |
|
manages any number of NEURON sections and mechanisms. |
|
|
|
Each class is responsible for determining the morphology and intrinsic membrane |
|
properties of the cell it represents. Additionally, cell classes define the |
|
properties of their synapses in a cooperative manner: the pre- snd postsynaptic |
|
cells each create half of the synapse. |
|
|
|
Morphology can be procedurally generated (usually a single somatic section, |
|
perhaps with another for a dendrite and/or axon), or it can be loaded from an |
|
SWC file. After the cell morphology is established, the membrane is "decorated" |
|
with channels using a `ChannelDecorator` object. |
|
|
|
Cell classes may be further divided into a class hierarchy. For example, the |
|
base `DStellate` class is further inherited by `DStellateRothman` and |
|
`DStellateEager` classes that each implement different D-stellate models that |
|
have been published previously. To simplify (and in many cases to automate) the |
|
creation of cells each base cell class (`Bushy`, `SGC`, `TStellate`, etc.) |
|
implements a `create` method that can be used to generate instances from any of |
|
the subclasses. |
|
|
|
|
|
Synapses |
|
-------- |
|
|
|
Every synapse in CNModel is represented by an instance of the `Synapse` class. |
|
This class contains two objects: a `Terminal`, and a `PSD`. Synapses are created |
|
by calling the `connect` method of the presynaptic cell with the postsynaptic |
|
cell as an argument:: |
|
|
|
pre_cell.connect(post_cell) |
|
|
|
When `connect` is called, the presynaptic terminal is created by calling |
|
``pre_cell.make_terminal()``, and the postsynaptic receptors are created by |
|
calling ``post_cell.make_psd()``. In this way, both pre- and postsynaptic |
|
cells are given a chance to influence the creation of the synapse. |
|
|
|
CNModel implements most synapses in two different ways. The first is a simple |
|
synapse that implements variable amplitude, short-term plasticity, and double- |
|
exponential rise/fall kinetics. This synapse is relatively efficient to compute |
|
and simple to configure. The second synapse implementation is a much more |
|
physiologically detailed model that includes stochastic release from multiple |
|
release zones per terminal, synaptic cleft diffusion, and state models of |
|
postsynaptic receptors. This synapse is computationally expensive but may capture |
|
important behaviors that are not possible with the simpler implementation. |
|
|
|
|
|
Populations |
|
----------- |
|
|
|
Populations are objects that encapsulate a group of cells sharing a common cell |
|
class. Each base `Cell` class has a corresponding `Population` class that |
|
implements the organization of many cells within the nucleus and the patterns |
|
of connectivity between populations. |
|
|
|
Conceptually, a `Population` represents *all* cells of a particular type within |
|
the nucleus. When a population is created, it initially decides how many cells |
|
is will represent and how to distribute properties across those cells. For |
|
example, an `SGC` population describes 10k cells distributed uniformly across |
|
the tonotopic axis. Initially, none of these 10k cells are created; rather, |
|
each cell is simply represented as a virtual placeholder, and only instantiated |
|
when it is explicitly requested or when it is required to satisfy the input |
|
requirements for another cell. |
|
|
|
Populations are connected to each other in much the same way cells are:: |
|
|
|
pre_pop.connect(post_pop) |
|
|
|
Like the virtual cells, however, this connection does not create any synapses, |
|
but instead merely records the fact that one population of cells projects to |
|
another. Once the populations of interest are created and connected, the user |
|
then manually instantiates only the cells that they wish to record from, and |
|
finally the entire network of presynaptic inputs is automatically instantiated. |
|
|
|
Because populations manage the creation of synaptic connections between large |
|
groups of neurons, they are also responsible for ensuring that the appropriate |
|
patterns of connectivity are followed. For example, this allows us to ensure |
|
that bushy cells are automatically connected to auditory nerve fibers coming |
|
from a relatively narrow window across the tonotopic axis, whereas D-stellate |
|
cells integrate the same inputs across a broader window. |
|
|
|
|
|
Physiological parameters |
|
------------------------ |
|
|
|
Throughout the model we use physiological parameters (channel kinetics, |
|
synaptic strengths, convergence ratios, etc.) that are often derived |
|
from published reports. In an attempt to make the provenance of these |
|
parameters clear, we have separated them from the source code and embedded |
|
them in annotated tables. These tables are found in `cnmodel/data`, and are |
|
automatically parsed by the model as they are needed. |
|
|
|
Morphology |
|
---------- |
|
|
|
The model implements the ability to use morphological reconstructions of |
|
cells, as rendered in hoc files, the native NEURON format. These reconstructions |
|
can be decorated with ion channels and synapses according to pre-specified |
|
tables or pre-defined rules. |
|
|
|
Unit testing |
|
------------ |
|
|
|
CNModel attempts to reproduce several specific published observations. |
|
The complexity of the model makes it quite fragile--small modifications to one |
|
physiological parameter may have unexpected (and sometimes unnoticed) |
|
consequences in the output of the model. |
|
|
|
To combat this unavoidable fragility, CNModel includes a large battery of unit |
|
tests that are used to ensure the model output is stable across modifications |
|
and platforms, and that it does reproduce our target observations within |
|
reasonable limits. As such, any modification to the model should usually be |
|
followed soon after by running the unit tests (these depend on the py.test |
|
package and may be invoked by running the included `test.py` script). |
|
|
|
|
|
Auditory nerve input |
|
-------------------- |
|
|
|
CNModel builds from the auditory periphery model developed by Zilany et al. |
|
(2014). The periphery model converts auditory stimuli into |
|
spike trains for auditory nerve fibers of a specific CF and SR group. |
|
|
|
CNModel uses the Python version of the auditory periphery model |
|
as implemented by Rudnicki and Hemmert (available from https://github.com/mrkrd/cochlea). |
|
This version does not require MATLAB, and in some simulations may run slightly faster |
|
because there is no delay associated with loading (and unloading) MATLAB. The |
|
interface is otherwise exactly the same, and the model type can be selected |
|
at runtime. |
|
|
|
An alternative approach is to use the original auditory periphery model. Because |
|
this model was developed in MATLAB, CNModel uses a Python-to-MATLAB bridge |
|
that transparently invokes the periphery model in a background process. |
|
When using CNModel, is is generally not necessary to manually interact with |
|
MATLAB in any way; this interaction is wrapped within functions in the |
|
`cnmodel/an_model` subpackage. |
|
|
|
At present, there is no mechanism for feedback from the cochlear nucleus model |
|
back into the auditory periphery model. As such, the output of the periphery |
|
model is a convenient place to do some caching--we can precompute auditory |
|
nerve spike trains in response to various sound stimuli and reuse those spike |
|
trains to improve the computational performance of the nucleus model. This |
|
caching is performed automatically, but relies on the use of `Sound` objects |
|
(described below) as a mechanism for storing and retrieving cached spike trains. |
|
|
|
|
|
Generating sound stimuli |
|
------------------------ |
|
|
|
Sound stimuli are defined as subclasses of `cnmodel.util.sound.Sound`. Each |
|
subclass (for example, `TonePip` and `NoisePip`) defines the function for |
|
generating a sound waveform, but also provides a unique key that is used to |
|
store and retrieve auditory nerve spike trains that were generated with |
|
a particular stimulus. |
|
|
|
`Sound` objects may be passed directly to `SGC` cells or populations, and the |
|
necessary spike trains will be automatically computed (or read from cache). |
|
|
|
|
|
|
|
|