View of the Real World

Page 1 of 3

View of the Real World

z
z
z

General Concepts
Nodes, Zones, and Elements
Processing Units and Networks

General Concepts
To design a comprehensive simulation system, one must have a consistent means of representing the prototype; in this case, a watershed. We view it as a set of constituents
which move through a fixed environment and interact with each other. Water is one constituent; others are sediment, chemicals, etc. The motions and interactions are called
processes.

Nodes, Zones, and Elements

The prototype is a continuum of constituents and processes. Simulation of such a system on a computer requires representation in a discrete fashion. In general, this is done by
subdividing the prototype into "elements" which consist of "nodes" and "zones."
A node corresponds to a point in space. Therefore, a particular value of a spatially variable function can be associated with it, for example, channel flow rate and/or flow cross
sectional area. A zone corresponds to a finite portion of the real world. It is usually associated with the integral of a spatially variable quantity, for example, storage in a
channel reach. The zone is the smallest unit into which the world is subdivided. The relationship between zonal and nodal values is similar to that between the definite integral
of a function and its values at the limits of integration.
An element is a collection of nodes and/or zones. Figure 1 illustrates these concepts. In HSPF, the response of the land phase of the hydrologic cycle is simulated using
elements called "segments." A segment is a portion of the land assumed to have areally uniform properties. A segment of land with a pervious surface is called a "Pervious
Land-segment" (PLS). Constituents in a PLS are represented as resident in a set of zones (Fig. 1a). A PLS has no nodes. As a further example, consider the formulation of
channel routing. A channel reach is modeled as a one dimensional element consisting of a single zone situated between two nodes (Fig. 1b). Flow rate and depth are simulated
at the nodes; the zone is associated with storage.
The conventions of the finite element technique also fall within the scope of these concepts. Figure 1c shows a two dimensional finite element used in the simulation of an
estuary. Three nodes define the boundaries of the triangular element. A fourth node, situated inside, may be viewed as subdividing the element into three zones. This last type
of element is not presently used in any HSPF module, but is included in this discussion to show the generality provided by HSPF. The system can accommodate a wide
variety of simulation modules.

Nodes, zones, and elements

There are no fixed rules governing the grouping of zones and nodes to form elements. The model builder must decide what grouping is reasonable and meaningful, based on
his view of the real world processes being simulated. In general, it is convenient to define elements so that a large portion of the real world can be represented by a collection
of conceptually identical elements. In this way, a single parameter structure can be defined which applies to every element in the group. Thus, each element is a variation on
the basic theme. It is then meaningful to speak of an "element type." For example, elements of type "PLS" all embody the same arrangement of nodes and are represented by
sets of parameters with identical structure. Variations between segments are represented only by variations in the values of parameters. The same applies to any other element,
such as a Reach, layered lake or a triangular finite element.
As illustrated in the above discussion, nodes are often used to define the boundaries of zones and elements. A zone, characterized by storage, receives inflows and disperses
outflows; these are called "fluxes." Note that if the nodal values of a field variable are known, it is often possible to compute the zonal values (storages). The reverse process
does not work.

Processing Units and Networks

file://C:\Users\Ankit\AppData\Local\Temp\~hhA6F2.htm

6/8/2016

View of the Real World

Page 2 of 3

To simulate a prototype, we must handle the processes occurring within the elements and the transfer of information and constituents between them. The simulation of large
prototypes is made convenient by designing a single "application module" for a given type of element or element group, and applying it repetitively to all similar members in
the system. For example, the RCHRES module may be used to simulate all the reaches in a watershed using storage routing. This approach is most efficient computationally if
one element or group of elements, called a "processing unit" (PU), is simulated for an extended period of time before switching to the next one. To permit this, we must be
able to define a processing sequence such that all information required by any PU comes from sources external to the system or from PU's already simulated. This can only
happen if the PU's and their connecting fluxes form one or more networks which are "directed graphs." In a directed graph there are no bi-directional paths and no cycles.

Directed and Non-directed graphs

The requirement that PU's form directed graphs provides the rule for grouping elements into PU's. Any elements interacting with each other via loops or bi-directional fluxes
must be grouped into a single PU because none of them can be simulated apart from the others.
Thus, we can have both single element and multi-element PU's. A PLS is an example of the former and a channel network simulated using the full equations of flow
exemplifies the latter. A multi-element PU is also known as a "feedback region." The collection of PU's which are simulated in a given run is called a "network."
The processes which occur within a PU are represented mathematically in an "application model." The corresponding computer code in HSPF is called an "application
module" or "simulation module."

file://C:\Users\Ankit\AppData\Local\Temp\~hhA6F2.htm

6/8/2016

View of the Real World

Page 3 of 3

Single- and multi-element processing units

file://C:\Users\Ankit\AppData\Local\Temp\~hhA6F2.htm

6/8/2016