From 3d725ce12a07a06c2da97f7be6ec9e8ba3c1be51 Mon Sep 17 00:00:00 2001
From: Sebastian Schmitt <sebastian.schmitt@phys.uni-goettingen.de>
Date: Tue, 6 Oct 2020 14:13:51 +0200
Subject: [PATCH] Fix some typos (#1175)
---
doc/ai_sampling_api.rst | 6 +++---
doc/co_cell.rst | 4 ++--
doc/py_domdec.rst | 6 +++---
doc/py_morphology.rst | 4 ++--
doc/py_simulation.rst | 2 +-
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/ai_sampling_api.rst b/doc/ai_sampling_api.rst
index 4deac7fe..df34db51 100644
--- a/doc/ai_sampling_api.rst
+++ b/doc/ai_sampling_api.rst
@@ -65,7 +65,7 @@ identified with a probe-id: ``cell_member_type{gid, k}``.
One probe address may describe more than one concrete probe, depending
upon the interpretation of the probe address by the cell group. In this
-instance, each of the concerete probes will be associated with the
+instance, each of the concrete probes will be associated with the
same probe-id. Samplers can distinguish between different probes with
the same id by their probe index (see below).
@@ -88,7 +88,7 @@ will be passed to a sampler function or function object:
};
using sampler_function =
- std::function<void (probe_metadta, size_t, const sample_record*)>;
+ std::function<void (probe_metadata, size_t, const sample_record*)>;
where the parameters are respectively the probe metadata, the number of
samples, and finally a pointer to the sequence of sample records.
@@ -298,7 +298,7 @@ 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.
+and probe metadata.
``sampler_association_map`` wraps an ``unordered_map`` between sampler association
handles and tuples (*schedule*, *sampler*, *probe set*, *policy*), with thread-safe
diff --git a/doc/co_cell.rst b/doc/co_cell.rst
index 2fe8503b..20658f63 100644
--- a/doc/co_cell.rst
+++ b/doc/co_cell.rst
@@ -70,8 +70,8 @@ Cell kinds
* **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>`.
+ passes a threshold. Detectors act as **sources** of :ref:`connections <modelconnections>`.
+ * **Synapses**: Synapses 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.
diff --git a/doc/py_domdec.rst b/doc/py_domdec.rst
index 2f0bfaad..1ac9ea1c 100644
--- a/doc/py_domdec.rst
+++ b/doc/py_domdec.rst
@@ -81,7 +81,7 @@ An example of a partition load balance with hints reads as follows:
n_cells = 100
recipe = my_recipe(n_cells)
- # The hints perfer the multicore backend, so the decomposition is expected
+ # The hints prefer the multicore backend, so the decomposition is expected
# to never have cell groups on the GPU, regardless of whether a GPU is
# available or not.
cable_hint = arb.partition_hint()
@@ -117,14 +117,14 @@ Therefore, the following data structures are used to describe domain decompositi
.. 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 (:attr:`groups`) for cells assigned to
the local domain, and a helper function (:func:`gid_domain`) used to
look up which domain a cell has been assigned to.
The :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 of **all** of the cells in
diff --git a/doc/py_morphology.rst b/doc/py_morphology.rst
index d49a958b..972deeeb 100644
--- a/doc/py_morphology.rst
+++ b/doc/py_morphology.rst
@@ -160,7 +160,7 @@ Cell morphology
A segment can not be added before its parent, hence the first segment
is always at the root. In this manner, a segment tree is
- always guarenteed to be in a correct state, with consistent parent-child
+ always guaranteed to be in a correct state, with consistent parent-child
indexing, and with *n* segments numbered from *0* to *n-1*.
To illustrate how a segment tree is constructed by appending segments,
@@ -327,7 +327,7 @@ Cell morphology
is stored for fast look up during later stages of model building, and
querying by users.
- For this reason, morpholgies are read only. To change a morphology, a new
+ For this reason, morphologies are read only. To change a morphology, a new
morphology should be created using a new segment tree.
There is one *constructor* for a morphology:
diff --git a/doc/py_simulation.rst b/doc/py_simulation.rst
index 1b60539e..bfecff2b 100644
--- a/doc/py_simulation.rst
+++ b/doc/py_simulation.rst
@@ -236,7 +236,7 @@ In order to analyze the data collected from an :class:`arbor.probe` the samples
import arbor
- # Instatitate the simulation.
+ # Instantiate the simulation.
sim = arbor.simulation(recipe, decomp, context)
# Build the sample recorder on cell 0 and probe 0 with regular sampling interval of 0.1 ms
--
GitLab