diff --git a/doc/conf.py b/doc/conf.py
index 73060fb68ad252125efe5ca0e6074127f3a5c4d0..77657b4d50fa273008cbddf4ee35725a150e996f 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -3,6 +3,7 @@
def setup(app):
app.add_stylesheet('custom.css')
+ app.add_object_type('generic', 'gen', 'pair: %s; generic')
extensions = ['sphinx.ext.todo', 'sphinx.ext.mathjax']
source_suffix = '.rst'
diff --git a/doc/cpp_common.rst b/doc/cpp_common.rst
index a7ff50029fbdb330bffc4f015bf925c812661982..33ea047e7285b9396756c1af350cf846a2bc79b6 100644
--- a/doc/cpp_common.rst
+++ b/doc/cpp_common.rst
@@ -17,7 +17,7 @@ cells and members of cell-local collections.
:cpp:type:`cell_local_size_type` at the time of writing, however
this could change, e.g. to handle models that cell gid that don't
fit into a 32 bit unsigned integer.
- It is thus recomended that these type aliases be used whenever identifying
+ It is thus recommended that these type aliases be used whenever identifying
or counting cells and cell members.
@@ -58,7 +58,7 @@ cells and members of cell-local collections.
Each synapse has a post-synaptic cell (:cpp:member:`gid`), and an index
(:cpp:member:`index`) into the set of synapses on the post-synaptic cell.
- Lexographically ordered by :cpp:member:`gid`,
+ Lexicographically ordered by :cpp:member:`gid`,
then :cpp:member:`index`.
.. cpp:member:: cell_gid_type gid
@@ -72,24 +72,24 @@ cells and members of cell-local collections.
.. cpp:enum-class:: cell_kind
- Enumeration used to indentify the cell type/kind, used by the model to
+ Enumeration used to identify the cell type/kind, used by the model to
group equal kinds in the same cell group.
- .. cpp:enumerator:: cable1d_neuron
+ .. cpp:enumerator:: cable
A cell with morphology described by branching 1D cable segments.
- .. cpp:enumerator:: lif_neuron
+ .. cpp:enumerator:: lif
Leaky-integrate and fire neuron.
- .. cpp:enumerator:: regular_spike_source
+ .. cpp:enumerator:: spiking
- Regular spiking source.
+ Proxy cell that generates spikes from a spike sequence provided by the user.
- .. cpp:enumerator:: data_spike_source
+ .. cpp:enumerator:: benchmark
- Spike source from values inserted via description.
+ Proxy cell used for benchmarking.
Probes
------
diff --git a/doc/cpp_distributed_context.rst b/doc/cpp_distributed_context.rst
index 93a07ce042bfc177369df35da20116610efaf4ad..69cef0f75e7a8c57689b4c35691f8cc1a7cb0ee9 100644
--- a/doc/cpp_distributed_context.rst
+++ b/doc/cpp_distributed_context.rst
@@ -43,7 +43,7 @@ communicator for distributed communication, it can be initialised with the commu
// Partition model over the distributed system.
arb::domain_decomposition decomp = arb::partition_load_balance(recipe, context);
- // Instatitate the simulation over the distributed system.
+ // Instantiate the simulation over the distributed system.
arb::simulation sim(recipe, decomp, context);
// Run the simulation for 100ms over the distributed system.
@@ -65,7 +65,7 @@ A distributed context can then be generated using helper functions :cpp:func:`ar
// Create a context that uses only local resources (is non-distributed).
auto dist_ctx arb::make_local_context();
- // Create an MPI context that uses the standared MPI_COMM_WORLD communicator.
+ // Create an MPI context that uses the standard MPI_COMM_WORLD communicator.
auto dist_ctx = arb::make_mpi_context(MPI_COMM_WORLD);
@@ -87,7 +87,7 @@ Class Documentation
.. cpp:function:: distributed_context()
- Default contstructor initializes the context as a :cpp:class:`local_context`.
+ Default constructor initializes the context as a :cpp:class:`local_context`.
.. cpp:function:: distributed_context(distributed_context&& other)
diff --git a/doc/cpp_domdec.rst b/doc/cpp_domdec.rst
index 7f5a5813397a631c73ef12f5e6e954b6eb333ae2..95a3462a732b7c9889c9b850f7a26b75c012790f 100644
--- a/doc/cpp_domdec.rst
+++ b/doc/cpp_domdec.rst
@@ -24,6 +24,19 @@ describes the cell groups on the local MPI rank.
or when the user has specific insight into running their model on the
target computer.
+.. Important::
+ When users supply their own :cpp:class:`domain_decomposition`, if they have
+ **Gap Junction connections**, they have to be careful to place all cells that
+ are connected via gap junctions in the same group.
+ Example:
+ ``A -gj- B -gj- C`` and ``D -gj- E``.
+ Cells A, B and C need to be in a single group; and cells D and E need to be in a
+ single group. They may all be placed in the same group but not necessarily.
+ Be mindful that smaller cell groups perform better on multi-core systems and
+ try not to overcrowd cell groups if not needed.
+ Arbor provided load balancers such as :cpp:func:`partition_load_balance`
+ guarantee that this rule is obeyed.
+
.. cpp:namespace:: arb
.. cpp:function:: domain_decomposition partition_load_balance(const recipe& rec, const arb::context& ctx)
@@ -70,14 +83,14 @@ Documentation for the data structures used to describe domain decompositions.
.. cpp:class:: domain_decomposition
- Describes a domain decomposition and is soley responsible for describing the
+ Describes a domain decomposition and is solely responsible for describing the
distribution of cells across cell groups and domains.
It holds cell group descriptions (:cpp:member:`groups`) for cells assigned to
the local domain, and a helper function (:cpp:member:`gid_domain`) used to
look up which domain a cell has been assigned to.
The :cpp:class:`domain_decomposition` object also has meta-data about the
number of cells in the global model, and the number of domains over which
- the model is destributed.
+ the model is distributed.
.. Note::
The domain decomposition represents a division **all** of the cells in
diff --git a/doc/cpp_hardware.rst b/doc/cpp_hardware.rst
index b2a6783c920580f62c7cc592f2d0325dd87f8b03..ded7196b24c8b0500302e7625567075bde284b2d 100644
--- a/doc/cpp_hardware.rst
+++ b/doc/cpp_hardware.rst
@@ -101,8 +101,8 @@ own code for managing MPI, GPUs, and thread counts.
Arbor allows at most one GPU per MPI rank, and furthermore requires that
an MPI rank has exclusive access to a GPU, i.e. two MPI ranks can not
share a GPU.
- The task of assigning a unique GPU to each rank when more than one rank
- have access to the same GPU(s).
+ This function assigns a unique GPU to each rank when more than one rank
+ has access to the same GPU(s).
An example use case is on systems with "fat" nodes with multiple GPUs
per node, in which case Arbor should be run with multiple MPI ranks
per node.
diff --git a/doc/cpp_intro.rst b/doc/cpp_intro.rst
index e5ce8f24c0b6a01b1dde32f7b11df79d07474ce5..14c41eeacc8fda6a67ab6b251f682be11ac37950 100644
--- a/doc/cpp_intro.rst
+++ b/doc/cpp_intro.rst
@@ -10,4 +10,4 @@ implement models.
Arbor makes a distinction between the **description** of a model, and the
**execution** of a model.
-A :cpp:type:`arb::recipe` describes a model, and a :cpp:type:`arb::simulation` is an executable instatiation of a model.
+A :cpp:type:`arb::recipe` describes a model, and a :cpp:type:`arb::simulation` is an executable instantiation of a model.
diff --git a/doc/cpp_recipe.rst b/doc/cpp_recipe.rst
index c40e60175f4a0edcb60567ce2a3cc39bd2462e51..4c644a38365bb6bd7246ab1d93fa335cc505c651 100644
--- a/doc/cpp_recipe.rst
+++ b/doc/cpp_recipe.rst
@@ -40,7 +40,7 @@ Class Documentation
.. Warning::
All member functions must be **thread safe**, because the recipe is used
- by the multithreaded model builing stage. In practice, this means that
+ by the multithreaded model building stage. In practice, this means that
multiple threads should be able to call member functions of a recipe
simultaneously. Model building is multithreaded to reduce model building times,
so recipe implementations should avoid using locks and mutexes to introduce
@@ -66,7 +66,7 @@ Class Documentation
The type used to describe a cell depends on the kind of the cell.
The interface for querying the kind and description of a cell are
- seperate to allow the cell type to be provided without building
+ separate to allow the cell type to be provided without building
a full cell description, which can be very expensive.
**Optional Member Functions**
@@ -80,6 +80,16 @@ Class Documentation
By default returns an empty list.
+ .. cpp:function:: virtual std::vector<gap_junction_connection> gap_junctions_on(cell_gid_type gid) const
+
+ Returns a list of all the gap junctions connected to `gid`.
+ Each gap junction ``gj`` should have one of the two gap junction sites ``gj.local.gid`` or
+ ``gj.peer.gid`` matching the argument :cpp:any:`gid`, and the corresponding synapse id
+ ``gj.local.index`` or ``gj.peer.index`` should be valid on `gid`.
+ See :cpp:type:`gap_junction_connection`.
+
+ By default returns an empty list.
+
.. cpp:function:: virtual std::vector<event_generator> event_generators(cell_gid_type gid) const
Returns a list of all the event generators that are attached to `gid`.
@@ -108,6 +118,12 @@ Class Documentation
By default returns 0.
+ .. cpp:function:: virtual cell_size_type num_gap_junction_sites(cell_gid_type gid) const
+
+ Returns the number of gap junction sites on `gid`.
+
+ By default returns 0.
+
.. cpp:function:: virtual probe_info get_probe(cell_member_type) const
Intended for use by cell group implementations to set up sampling data
@@ -115,7 +131,7 @@ Class Documentation
information in the concrete cell implementations to allow monitoring.
By default throws :cpp:type:`std::logic_error`. If ``arb::recipe::num_probes``
- returns a non-zero value, this must also be overriden.
+ returns a non-zero value, this must also be overridden.
.. cpp:function:: virtual util::any get_global_properties(cell_kind) const
@@ -154,3 +170,19 @@ Class Documentation
Delay of the connection (milliseconds).
+.. cpp:class:: gap_junction_connection
+
+ Describes a gap junction between two gap junction sites.
+ Gap junction sites are represented by :cpp:type:cell_member_type.
+
+ .. cpp:member:: cell_member_type local
+
+ gap junction site: one half of the gap junction connection.
+
+ .. cpp:member:: cell_member_type peer
+
+ gap junction site: other half of the gap junction connection.
+
+ .. cpp:member:: float ggap
+
+ gap junction conductance in μS.
diff --git a/doc/cpp_simulation.rst b/doc/cpp_simulation.rst
index 2b5ff66db90a20a39a51aadbe70fd75fa9198ac0..57d00a697047cc60e68c448bd9502167b789b9ed 100644
--- a/doc/cpp_simulation.rst
+++ b/doc/cpp_simulation.rst
@@ -35,7 +35,7 @@ then build the simulation.
// (and gpu if available) on node.
arb::domain_decomposition decomp = arb::partition_load_balance(recipe, context);
- // Instatitate the simulation.
+ // Instantiate the simulation.
arb::simulation sim(recipe, decomp, context);
@@ -71,7 +71,7 @@ Class Documentation
.. cpp:type:: spike_export_function = std::function<void(const std::vector<spike>&)>
- User-supplied callack function used as a sink for spikes generated
+ User-supplied callback function used as a sink for spikes generated
during a simulation. See :cpp:func:`set_local_spike_callback` and
:cpp:func:`set_global_spike_callback`.
diff --git a/doc/index.rst b/doc/index.rst
index b0cdf6da8ec63aa73be63a5469f267536a6226fd..cab1d117435877672979415214323fb5937d7d15 100644
--- a/doc/index.rst
+++ b/doc/index.rst
@@ -47,7 +47,7 @@ Some key features include:
:caption: Arbor Models:
model_intro
- model_common
+ model_concepts
model_hardware
model_recipe
model_domdec
diff --git a/doc/install.rst b/doc/install.rst
index 6e0162cd0677fe5c9b5e0dd41791f7b8b4eae170..9c740dd3b74651314a9faf62f9e8d4645c5129b3 100644
--- a/doc/install.rst
+++ b/doc/install.rst
@@ -321,7 +321,7 @@ for the architecture, enabling ``ARB_VECTORIZE`` will lead to a compilation erro
With this flag set, the library will use architecture-specific vectorization intrinsics
to implement these kernels. Arbor currently has vectorization support for x86 architectures
-with AVX, AVX2 or AVX512 ISA extensions, and for ARM architectures with support for AArch64 NEON intrinsincs (first available on ARMv8-A).
+with AVX, AVX2 or AVX512 ISA extensions, and for ARM architectures with support for AArch64 NEON intrinsics (first available on ARMv8-A).
.. _gpu:
@@ -472,7 +472,7 @@ Cray Systems
The compiler used by the MPI wrappers is set using a "programming environment" module.
The first thing to do is change this module, which by default is set to the Cray
programming environment, to a compiler that can compile Arbor.
-For example, to use the GCC compilers, select the GNU programming enviroment:
+For example, to use the GCC compilers, select the GNU programming environment:
.. code-block:: bash
@@ -504,7 +504,7 @@ respectively on Cray systems.
CMake detects that it is being run in the Cray programming environment, which makes
our lives a little bit more difficult (CMake sometimes tries a bit too hard to help).
To get CMake to correctly link our code, we need to set the ``CRAYPE_LINK_TYPE``
-enviroment variable to ``dynamic``.
+environment variable to ``dynamic``.
.. code-block:: bash
diff --git a/doc/model_common.rst b/doc/model_common.rst
deleted file mode 100644
index 6d431bd35b87d28948a3677da960c7f449a10ece..0000000000000000000000000000000000000000
--- a/doc/model_common.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-.. _modelcommon:
-
-Common Types
-=================
-
-The basic unit of abstraction in an Arbor model is a cell.
-A cell represents the smallest model that can be simulated.
-Cells interact with each other via spike exchange and gap junctions.
-Cells can be of various types, admitting different representations and implementations.
-A *cell group* represents a collection of cells of the same type together with an implementation of their simulation.
-Arbor currently supports specialized leaky integrate and fire cells and cells representing artificial spike sources in addition to multi-compartment neurons.
-
-Since the neuron model and the associated workflow are formulated from a cell-centered perspective, cell identifiers and indexes need to be utilized.
-
-.. table:: Cell identifiers and indexes
-
- ======================== ====================== ===========================================================
- Identifyer/ Index Type Description
- ======================== ====================== ===========================================================
- gid integral The global identifier of the cell associated with the item.
- index integral The index of the item in a cell-local collection.
- cell member tuple (gid, index) The global identification of a cell-local item
- associated with a unique cell, identified by the member `gid`,
- and identifying an item within a cell-local collection by the member `index`.
- cell size integral Counting collections of cells.
- cell local size integral Counting cell-local data.
- cell kind eunum Identifiies of the cell type, including:
-
- * Cell with morphology described by branching 1D cable segments.
- * Leaky-integrate and fire neuron.
- * Regular spiking source.
- * Spike source from values inserted via description.
- ======================== ====================== ===========================================================
-
-Example
- A `cell member` identifier is used to uniquely identify synapses.
- Each synapse has a post-synaptic cell (`gid`), and an `index` into the set of synapses on the post-synaptic cell.
-
-C++ specific common types are explained in detail in :ref:`cppcommon`.
diff --git a/doc/model_concepts.rst b/doc/model_concepts.rst
new file mode 100644
index 0000000000000000000000000000000000000000..9a5a0ee953a812a4c065749bf8bf33bbd2e22c05
--- /dev/null
+++ b/doc/model_concepts.rst
@@ -0,0 +1,131 @@
+.. _modelconcepts:
+
+Concepts
+########
+
+This section describes some of the core concepts of Arbor.
+
+.. _modelcells:
+
+Cells
+=====
+
+The basic unit of abstraction in an Arbor model is a cell.
+A cell represents the smallest model that can be simulated.
+Cells interact with each other via spike exchange and gap junctions.
+Cells can be of various types, admitting different representations and implementations.
+Arbor currently supports specialized leaky integrate and fire cells and cells representing artificial spike sources in
+addition to multi-compartment neurons.
+
+.. table:: Identifiers used to uniquely refer to cells and objects like synapses on cells.
+
+ ======================== ================================ ===========================================================
+ Identifier Type Description
+ ======================== ================================ ===========================================================
+ .. generic:: gid integral The unique global identifier of a cell.
+ .. generic:: index integral The index of an item in a cell-local collection.
+ For example the 7th synapse on a cell.
+ .. generic:: cell_member tuple (:gen:`gid`, :gen:`index`) The global identification of a cell-local item with `index`
+ into a cell-local collection on the cell identified by `gid`.
+ For example, the 7th synapse on cell 42.
+ ======================== ================================ ===========================================================
+
+
+Each cell has a global identifier :gen:`gid`, which is used to refer to cells in :ref:`recipes <modelrecipe>`.
+To describe or refer to cell-to-cell interactions, the following object types need to be enumerated:
+
+1. **Sources**
+2. **Targets**
+3. **Gap Junction Sites**
+
+Cells interact with other cells via :ref:`connections <modelconnections>` or
+:ref:`gap junctions <modelgapjunctions>`. Connections are formed from **sources** to **targets**. Gap junctions
+are formed between two **gap junction sites**.
+
+A cell can have multiple sources, targets and gap junction site objects. Each object has a local :gen:`index`
+relative to other objects of the same type on that cell.
+A unique (:gen:`gid`, :gen:`index`) pair defned by a :gen:`cell_member` can be used to uniquely identify
+objects on a cell in a global model.
+
+
+Cell Kinds
+----------
+
+.. table:: The types of cell supported by Arbor
+
+ ======================== ===========================================================
+ Cell Kind Description
+ ======================== ===========================================================
+ **cable** Cell with morphology described by branching
+ 1D cable segments.
+ **lif** Leaky-integrate and fire neuron.
+ **spiking** Proxy cell that generates spikes from a user-supplied
+ time sequence.
+ **benchmark** Proxy cell used for benchmarking (developer use only).
+ ======================== ===========================================================
+
+1. **Cable Cells**
+
+ Cable cells are morphologically-detailed cells represented as branching linear 1D segments. They can be coupled
+ to other cell types via the following mechanisms:
+
+ 1. Spike exchange over a **connection** with fixed latency.
+ Cable cells can *receive* spikes from any kind of cell, and can be a *source* of spikes
+ cells that have target sites (i.e. *cable* and *lif* cells).
+ 2. Direct electrical coupling between two cable cells via **gap junctions**.
+
+ Key concepts:
+
+ * **Morphology**: The morphology of a cable cell is composed of a branching tree of one-dimensional line segments.
+ Strictly speaking, Arbor represents a morphology is an *acyclic directed graph*, with the soma at the root.
+ * **Detectors**: Spike detectors generate spikes when the voltage at location on the cell
+ passes a threshold. Dectectors act as **sources** of :ref:`connections <modelconnections>`.
+ * **Synapses**: Synapases act as **targets** of :ref:`connections <modelconnections>`.
+ A synapse is described by a synapse type (with associated parameters) and location on a cell.
+ * **Gap Junction Sites**: These refer to the sites of :ref:`gap junctions <modelgapjunctions>`.
+ They are declared by specifying a location on a branch of the cell.
+
+2. **LIF Cells**
+
+ A single compartment leaky integrate and fire neuron with one **source** and one **target**.
+ LIF cells does not support adding additional **sources** or **targets** or gap junctions.
+
+3. **Spiking Cells**
+
+ Spike source from values inserted via a `schedule description`. It is a point neuron with one built-in **source** and no **targets**.
+ It does not support adding additional **sources** or **targets**. It does not support gap junctions.
+
+4. **Benchmark Cells**
+
+ Proxy cell used for benchmarking, and used by developers to benchmark the spike exchange and event delivery infrastructure.
+
+.. _modelconnections:
+
+Connections
+===========
+
+Connections implement chemical synapses between **source** and **target** cells and are characterized by having a transmission delay.
+
+Connections in Arbor are defined in two steps:
+
+1. Create **Source** and **Target** on two cells: a source defined on one cell, and a target defined on another.
+2. Declare the connection in the :ref:`recipe <modelrecipe>`: with a source and target idenfied using :gen:`cell_member`, a connection delay and a connection weight.
+
+.. _modelgapjunctions:
+
+Gap Junctions
+=============
+
+Gap junctions represent electrical synapses where transmission between cells is bidirectional and direct.
+They are modeled as a conductance between two **gap junction sites** on two cells.
+
+Similarly to `Connections`, Gap Junctions in Arbor are defined in two steps:
+
+1. A **gap junction site** is created on each of the two cells.
+ These locations need to be declared on the :ref:`cell <modelcells>`.
+2. Gap Junction instantiation in the :ref:`recipe <modelrecipe>`: The **gap junction sites** are indexed using :gen:`cell_member`
+ because a single cell may have more than one gap junction site.
+ A gap junction is instantiated by providing two **gap junction sites'** and a conductance in μS.
+
+ .. Note::
+ Only cable cells support gap junctions as of now.
diff --git a/doc/model_domdec.rst b/doc/model_domdec.rst
index cce522dd57c58ef3ca1ff441146f45c8a76f61eb..3029e3d18e70828d17232cbaa1b4ccaa842b451a 100644
--- a/doc/model_domdec.rst
+++ b/doc/model_domdec.rst
@@ -3,18 +3,21 @@
Domain Decomposition
====================
-A *domain decomposition* describes the distribution of the model over the available computational resources. The description partitions the cells in the model as follows:
+A *domain decomposition* describes the distribution of the model over the available computational resources.
+The description partitions the cells in the model as follows:
* group the cells into cell groups of the same kind of cell;
* assign each cell group to either a CPU core or GPU on a specific MPI rank.
-The number of cells in each cell group depends on different factors, including the type of the cell, and whether the cell group will run on a CPU core or the GPU. The domain decomposition is soley responsible for describing the distribution of cells across cell groups and domains.
+The number of cells in each cell group depends on different factors, including the type of the cell, and whether the
+cell group will run on a CPU core or the GPU. The domain decomposition is solely responsible for describing the distribution
+of cells across cell groups and domains.
Load Balancers
--------------
-A *load balancer* generates the domain decomposition using the
-model recipe and a description of the available computational resources on which the model will run described by an execution context.
+A *load balancer* generates the domain decomposition using the model recipe and a description of the available computational
+resources on which the model will run described by an execution context.
Currently Arbor provides one load balancer and more will be added over time.
diff --git a/doc/model_hardware.rst b/doc/model_hardware.rst
index dff3281be12791906baef56f9060c583f8994ee2..7ee66076926079ad96719670894c690e772461ae 100644
--- a/doc/model_hardware.rst
+++ b/doc/model_hardware.rst
@@ -24,4 +24,4 @@ Execution Context
An *execution context* contains the local thread pool, and optionally the GPU state and MPI communicator, if available. Users of the library configure contexts, which are passed to Arbor methods and types.
-See :ref:`cppdomdec` for documentation of the C++ interface for domain decomposition.
+See :ref:`cpphardware` for documentation of the C++ interface for managing hardware resources.
diff --git a/doc/model_intro.rst b/doc/model_intro.rst
index 4280fe9b0473fb93de94424072366abde41a98fe..dd898a7c0ed2f984e03c8df674a06b59982ae6e2 100644
--- a/doc/model_intro.rst
+++ b/doc/model_intro.rst
@@ -2,24 +2,22 @@
Overview
=========
-Arbor's design aims to enable scalability through abtraction.
+Arbor's design aims to enable scalability through abstraction.
To achieve this, Arbor makes a distinction between the **description** of a model, and the
**execution** of a model:
-a *recipe* describes a model, and a *simulation* is an executable instatiation of a model.
+a *recipe* describes a model, and a *simulation* is an executable instantiation of a model.
To be able to simulate a model, three basic steps need to be considered:
-* first, describe the neuron model by defining a recipe;
-* then, define the computational resources available to execute the model;
+* first, describe the model by defining a recipe;
+* second, define the computational resources available to execute the model;
* finally, initiate and execute a simulation of the recipe on the chosen hardware resources.
-.. topic:: Concepts
+:ref:`modelrecipe` represent a set of neuron constructions and connections with *mechanisms* specifying ion channel and synapse dynamics in a cell-oriented manner. This has the advantage that cell data can be initiated in parallel.
- :ref:`modelrecipe` represent a set of neuron constructions and connections with *mechanisms* specifying ion channel and synapse dynamics in a cell-oriented manner. This has the advantage that cell data can be initiated in parallel.
+A cell represents the smallest unit of computation and forms the smallest unit of work distributed across processes. Arbor has built-in support for different :ref:`cell types <modelcells>` , which can be extended by adding new cell types to the C++ cell group interface.
- A cell represents the smallest unit of computation and forms the smallest unit of work distributed across processes. Different :ref:`modelcommon` can be utilized.
+:ref:`modelsimulation` manage the instantiation of the model and the scheduling of spike exchange as well as the integration for each cell group. A cell group represents a collection of cells of the same type computed together on the GPU or CPU. The partitioning into cell groups is provided by :ref:`modeldomdec` which describes the distribution of the model over the locally available computational resources.
- :ref:`modelsimulation` manage the instantiation of the model and the scheduling of spike exchange as well as the integration for each cell group. A cell group represents a collection of cells of the same type computed together on the GPU or CPU. The partitioning into cell groups is provided by :ref:`modeldomdec` which describes the distribution of the model over the locally available computational resources.
-
- In order to visualise the result of detected spikes a spike recorder can be used and to analyse Arbor's performance a meter manager is available.
+In order to visualise the result of detected spikes a spike recorder can be used and to analyse Arbor's performance a meter manager is available.
diff --git a/doc/model_recipe.rst b/doc/model_recipe.rst
index d0579c480494ce77796960856a53186f4127f223..36bffdf3eab838739a3a6c806ee924631600fc28 100644
--- a/doc/model_recipe.rst
+++ b/doc/model_recipe.rst
@@ -11,7 +11,9 @@ building phase to provide information about cells in the model, such as:
* a description of a cell, e.g. with soma, synapses, detectors, stimuli;
* the number of spike targets;
* the number of spike sources;
- * incoming network connections from other cells terminating on a cell.
+ * the number of gap junction sites;
+ * incoming network connections from other cells terminating on a cell;
+ * gap junction connections on a cell.
Why Recipes?
--------------
@@ -65,7 +67,7 @@ General Best Practices
.. topic:: Be lazy
A recipe does not have to contain a complete description of the model in
- memory; precompute as little as possible, and use
+ memory. Precompute as little as possible, and use
`lazy evaluation <https://en.wikipedia.org/wiki/Lazy_evaluation>`_ to generate
information only when requested.
This has multiple benefits, including:
@@ -75,12 +77,12 @@ General Best Practices
.. topic:: Be reproducible
- Arbor is designed to give reproduceable results when the same model is run on a
+ Arbor is designed to give reproducible results when the same model is run on a
different number of MPI ranks or threads, or on different hardware (e.g. GPUs).
This only holds when a recipe provides a reproducible model description, which
can be a challenge when a description uses random numbers, e.g. to pick incoming
connections to a cell from a random subset of a cell population.
- To get a reproduceable model, use the cell `gid` (or a hash based on the `gid`)
+ To get a reproducible model, use the cell `gid` (or a hash based on the `gid`)
to seed random number generators, including those for :cpp:type:`event_generator` s.
@@ -89,7 +91,7 @@ Mechanisms
The description of multi-compartment cells also includes the specification of ion channel and synapse dynamics.
In the recipe, these specifications are called *mechanisms*.
Implementations of mechanisms are either hand-coded or a translator (modcc) is used to compile a
-subset of NEURONs mechanism specification language NMODL.
+subset of NEURON's mechanism specification language NMODL.
Examples
Common examples are the *passive/ leaky integrate-and-fire* model, the *Hodgkin-Huxley* mechanism, the *(double-) exponential synapse* model, or the *Natrium current* model for an axon.
diff --git a/doc/profiler.rst b/doc/profiler.rst
index 6f0d0787ebdb14d11a6c188c85971b9b304e646b..7b11adde8613221c48de7e7e2a38f17a6194abdc 100644
--- a/doc/profiler.rst
+++ b/doc/profiler.rst
@@ -192,7 +192,7 @@ and the profiler regions can be reset.
}
After a call to ``util::profiler_clear``, all counters and timers are set to zero.
-This could be used, for example, to generate seperate profiler reports for model building and model executation phases.
+This could be used, for example, to generate separate profiler reports for model building and model execution phases.
Profiler Output
~~~~~~~~~~~~~~~
diff --git a/doc/sampling_api.rst b/doc/sampling_api.rst
index 2ec638249af55a766d0ede7697a2a4a420d4f0d9..1c025511268e79b7b18a0d06e4185224d5d08d5e 100644
--- a/doc/sampling_api.rst
+++ b/doc/sampling_api.rst
@@ -246,7 +246,7 @@ the same sequence of time points, that is, it must exhibit repeatable
and deterministic behaviour.
The ``schedule`` object itself uses type-erasure to wrap any schedule
-implementation class, which can be any copy--constructible class that
+implementation class, which can be any copy--constructable class that
provides the methods ``reset()`` and ``events(t0, t1)`` above. Three
schedule implementations are provided by the engine:
@@ -275,11 +275,11 @@ Helper classes for probe/sampler management
The ``simulation`` and ``mc_cell_group`` classes use classes defined in ``scheduler_map.hpp`` to simplify
the management of sampler--probe associations and probe metdata.
-``sampler_association_map`` wraps an ``unordered_map`` between sampler assocation
+``sampler_association_map`` wraps an ``unordered_map`` between sampler association
handles and tuples (*schedule*, *sampler*, *probe set*), with thread-safe
accessors.
-``probe_assocation_map<Handle>`` is a type alias for an unordered map between
+``probe_association_map<Handle>`` is a type alias for an unordered map between
probe ids and tuples (*probe handle*, *probe tag*), where the *probe handle*
is a cell-group specific accessor that allows efficient polling.