Glossary

This section defines important terms used in describing the Opus system, from a modeler's viewpoint. In addition, there are a few technology-oriented terms that might otherwise be confused with these domain-specific terms.

Agent

An object, such as a job or a household, that takes direct action on its environment, such as making choices among a set of alternatives. Typically, agents represent ``real-world'' objects from the model domain. Agents have state. Agents can engage in behavior, communicate, change state, etc. An agent's behavior usually depends upon its context.

Agent set

An object that contains a set of agents.

Alternative

One of the objects that an agent may choose.

Attribute

A value that can be attributed to a particular object. An inherent characteristic of an object. For instance, the UrbanSim job object may have attributes such as ``id'', ``gridcell_id'', and ``is_in_scalable_sector_group''. Attributes may be "primary'', in that the jobs in the input database have values for that attribute. Or attributes may be computed by a variable definition. There are no ``constant'' attributes. Models may modify any attributes, including ``primary'' attributes.

baseyear cache

The file-based storage for the attribute values read from the baseyear database. Access to a file-based cache is much faster than to a database. Data cached during model simulation is written to a simulation cache.

Characteristic

Synonym for attribute.

Choice

We avoid using this term because it is ambiguous: it can mean either a member of a choice set, or it can mean the single chosen alternative.

Choice set

An object that contains a set of alternatives. By convention, we use this term instead of ``alternative set''.

Category

A single state of a nominal variable, such as a development type. Often used to group objects based upon their characteristics.

Category set

A set of categories.

CUSPA

The Center for Urban Simulation and Policy Analysis at the University of Washington (home of the UrbanSim project).

Dataset

A set of objects, such as gridcells or jobs, of the same type. You can think of a dataset as a table, with one column for each attribute, and one row for each object. Each object in the dataset has a unique identifier (an integer) stored in an attribute whose name is referenced by the ``id_name'' key of the Resources dictionary passed to the dataset.

In practice, a dataset often is constructed from a single table read from a Storage object, though some datasets are constructed by joining information from multiple tables.

Logit Equation

Also known as a Logit Transformation, this transforms the collection of an agent's computed direct utilities for all alternatives in the choice set into an estimated probability for each alternative:

$$P_{ij}=\frac{e^{\lambda U_{ij}}}{\sum_{j' \in J}e^{\lambda U_{ij'}}},$$ (22)

Estimated Utility Function

A set of paired variables and coefficients of the form $\sum c_{i}*v_{i}$.

Interaction Set

A dataset of variables describing the interaction between two different datasets. See ``Interaction Variable''.

Interaction Variable

A variable that computes the interaction between two different datasets, such as that gridcell ``number_of_households'' variable that computes the number of households residing in each gridcell.

Logit Model

A Logit model is defined using an indirect utility equation, which includes the error term and specifies how that error is distributed. For example:

$$U_{ij}={\theta}{X}_{ij}+\epsilon_{ij} =\sum_{k \in K}{\theta}_{k}X^{k}_{ij}+\epsilon_{ij},$$ (23)

where $\epsilon_{ij}$ is i.i.d. distributed Gumbel Type I.

Model

An object that defines behavior and that has a run() method. Models have no state. They get their data from data objects, and store their results in data objects. A model can be a formula that calculates on the data provided to it. A model can be a sequence of actions to perform. A model also can act as an action. A model must have a run() method.

By convention, every model module contains a set of tests that test that model.

Model implementation

A model whose specification, or both specification and coefficients, have been estimated to a particular data set.

Model object

A model, or a model part. Model objects act on data objects.

Model component

An object that performs a logically distinct task that is part of how the model runs. Every model is formed by a sequence, and perhaps cycle, of model steps. Different models may combine the same model components in different ways to define different models.

Note that models can become components in other higher-level models, such as a land-price model and a neighborhood choice model that are parts of a household-location-choice model, which is part of an UrbanSim model.

Model specification

A definition of what variables are included in an econometric model. Coefficient values may, or may not, also be part of the specification.

Opus

The Open Platform for Urban Simulation, a new Python-based framework for writing urban and regional models.

Opus package

Opuspackage The term ``Opus package'' refers to any Python package built using the Opus framework and that follows the Opus package guidelines. The packages in the Opus base distribution will all be Opus packages in this sense, as will contributed Opus packages. See Section 10.1 for directions for creating your own Opus package.

Python package

A way of structuring Python's module namespace by using ``dotted module names''. See the Python documentation at http://www.python.org/doc.

Resources

A Python dictionary object. It is used to contain parameters passed between model steps.

simulation cache

The file-based storage for the attribute values for the datasets used by the models. Access to a file-based cache is much faster than to a database. The baseyear attributes are stored in the baseyear cache.

Simulation cycle

A set of sub-models that run in sequence before repeating. Typically, this refers to the outermost loop.

Submodel

A ...need to supply this definition

Time step

The unit of simulated time between each simulation cycle. For many simulations, this will be a year.

Variable

An attribute that is computed by a variable definition. Each variable definition resides in its own Python module. The Python module for a variable, e.g. ``is_industrial'', is the same as the variable name except with a ``.py'' extension, e.g. ``is_industrial.py''.

Work request system

A system for filing and tracking work requests, including bug reports.