# Quick Reference¶

## Conventions¶

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;
• attribute or method of a Components or Compositions: names use lower_case_and_underscore; appear in a small box in 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.

## Repository Organization¶

The PsyNeuLink “repo” is organized into two major sections:

### Core¶

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).

### Library¶

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.

## Scheduling¶

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 a given 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 Composition’s run method.

## Logging¶

PsyNeuLink supports logging of any attribute of any Components or Compositions 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 value itself.

## Graphic Displays¶

At the moment, PsyNeuLink has limited support for graphic displays: the graph of a System can be displayed using its 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.

## Preferences¶

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).