- Repository Organization
- Graphic Displays
The following conventions are used for the names of PsyNeuLink objects and their documentation:
- Class (type of object): names use CamelCase (with initial capitalization); the initial mention in a section of documentation is formatted as a link (in colored text) to the documentation for that class;
methodof a Component or Composition: names use lower_case_and_underscore; appear in a
small boxin documentation;
- argument of a method or function: names use lower_case_and_underscore; formatted in boldface in documentation.
- KEYWORD: uses UPPER_CASE_AND_UNDERSCORE; italicized in documentation.
Examples:Appear in boxed insets.
See Naming for conventions for default and user-assigned names of instances.
The PsyNeuLink “repo” is organized into two major sections:
This contains the basic PsyNeuLink objects (described in the next section) that are used to build models and run simulations, and is divided into three subsections: Components (the basic building blocks of PsyNeuLink models), Compositions (objects used to combine Components into models), and Scheduling (used to control execution of the Components within a Composition).
This contains extensions based on the Core objects (under Compositions and Components), and PsyNeuLink implementations of published models (under Models). The Library is meant to be extended, and used both to compare different models that address similar neural mechanisms and/or psychological functions, and to integrate these into higher level models of system-level function.
PsyNeuLink Mechanisms can be executed on their own. However, usually, they are executed when a Composition to which
they belong is executed, under the control of the Scheduler. The Schedule executes Compositions iteratively
in rounds of execution referred to as
PASS es, in which each Mechanism in the Composition is given an opportunity
to execute; By default, each Mechanism in a Composition executes exactly once per
PASS. However, the Scheduler
can be used to specify one or more Conditions for each Mechanism that determine whether it executes in
PASS. This can be used to determine when a Mechanism begins and/or ends executing, how many times it
executes or the frequency with which it executes relative to other Mechanisms, and any other dependency that can be
expressed in terms of the attributes of other Components in PsyNeuLink. Using a Scheduler and a combination of
pre-specified and custom Conditions, any pattern of execution can be
configured that is logically possible.
Using a Scheduler, a Composition continues to execute
PASS es until its
TRIAL termination Condition is met, which constitutes a
TRIAL of executions. This is associated with a
single input to the System. Multiple
TRIAL s (corresponding to a sequences of inputs) can be executed using a
PsyNeuLink supports logging of any attribute of any Component or Composition under various specified
conditions. Logs are dictionaries, with an entry for each Component being logged. The key for each entry is
the name of the Component, and the value is a record of the Component’s
value recorded under the
conditions specified by its
logPref attribute, specified as a
LogLevel; each record is a
tuple, the first item of which is a time stamp (the
TIME_STEP of the
RUN), the second a string indicating the
context in which the value was recorded, and the third the
At the moment, PsyNeuLink has limited support for graphic displays: the graph of a System can be displayed
show_graph method. This can be used to display just the processing components
(i.e., ProcessingMechanisms and MappingProjections), or to include
learning and/or control components. A future release may include
a more complete graphical user interface.
PsyNeuLink supports a hierarchical system of Preferences for all Components and Compositions. Every object has its own set of preferences, as does every class of object. Any preference for an object can be assigned its own value, or the default value for any of its parent classes for that preference (e.g., an instance of a DDM can be assigned its own preference for reporting, or use the default value for ProcessingMechanisms, Mechanisms, or Components. There are preferences for reporting (i.e., which results of processing are printed to the console during execution), logging, levels of warnings, and validation (useful for debugging, but suppressible for efficiency of execution).