Spatial modeling of ecosystems is essential if one's modeling goals include developing a relatively realistic description of past behavior and predictions of the impacts of alternative management policies on future ecosystem behavior (Costanza, Sklar, & White, 1990; Risser, Karr, & Forman, 1984; Sklar & Costanza, 1991) . Development of these models has been limited in the past by the large amount of input data required, the difficulty of even large mainframe serial computers in dealing with large spatial arrays, and the conceptual complexity involved in writing, debugging, and calibrating very large simulation programs. These limitations have begun to erode with the increasing availability of remote sensing data and GIS systems to manipulate it, and the development of parallel computer systems. Although the importance of advances in the parallel processing field have been recognized in the field of spatial modeling (Casey & Jameson, 1988) the conceptual complexity involved in building complex models in a distributed computational environment remains a major barrier to the utilization of these systems in the environmental sciences.
This barrier can be addressed through the development of general-purpose modeling environments to support ecological/economic (or other, e.g. biological/social/physical) model development for state-of-the-art parallel and serial computer systems. The SME, for example, links graphical tools for developing self-contained component models with module databases and parallel code generators. This environment supports modular, reusable model development, and allows scientists to utilize state-of-the-art parallel processing architectures without investing unnecessary time in computer programming.
Figure:The basic structure of a spatial ecosystem model. Each cell has a (variable) habitat type, which is used to parameterize the unit model for that cell. The unit model simulates ecosystem dynamics for that cell in the above- sediment and below-sediment subsystems. Nutrients and suspended materials in the surface water and saturated sediment water are fluxed between cells in the domain of the spatial model.
X(t+1) = F(X(t),Y(t))
where X(t) is the spatial pattern at time t and Y(t) is a set of array, vector or scalar variables that may affect the transition. Although many forms of dynamic spatial modeling are utilized within the broad field of ecology (Sklar & Costanza, 1991) , and the spatial modeling tools proposed in this paper are applicable to a wide range of modeling tasks in the biological, social, economic and physical sciences, our primary focus in this paper is on process-based landscape models. These models simulate spatial structure by first compartmentalizing the landscape into some geometric design and then describing flows within compartments and spatial processes between compartments according to location-specific algorithms (Figure). Examples of process-based, spatially articulate landscape models include wetland models (Boumans & Sklar, 1991; Costanza, H., & Day, 1986; Costanza, et al., 1990; Kadlec & Hammer, 1988; Sklar, Costanza, & Day, 1985; White, Day, Maxwell, Costanza, & Sklar, 1992) , oceanic plankton models (Show, 1979) , coral reef growth models (Maguire & Porter, 1977) and fire ecosystem models (Kessell, 1977) .
One example of a process-based spatial simulation model is the Everglades Landscape Model (ELM), discussed in Section 4. Another example is the Coastal Ecological Landscape Spatial Simulation (CELSS) model, which consists of 2,479 interconnected cells, each representing 1 km2, constructed for the Atchafalaya/Terrebonne marsh/estuarine complex in south Louisiana (Costanza, et al., 1990; Sklar, et al., 1985) . Each 1 km2 cell in the CELSS model contains a dynamic, nonlinear ecosystem simulation model with seven state variables, similar to the one shown in the Figure. The model is generic in structure and can represent one of six habitat types by assigning unique parameter settings. Each cell is potentially connected to each adjacent cell by the exchange of water and materials. This model is several years old and is much simpler than many models in use today.
The original CELSS model took four people about four years (16 person-years) to fully develop and implement using a supercomputer. The model has proved to be very effective at helping us understand complex ecosystem behavior and at guiding policy and research (Costanza, et al., 1990; Sklar, et al., 1985) . We are now concerned with reducing the time involved for both developing and running this type of model, and moving the modeling to smaller, less expensive computers. Toward that end we are developing the integrated spatial modeling environment described below.
A well-recognized method for reducing program complexity involves structuring the model as a set of distinct modules with well-defined interfaces (Acock & Reynolds, 1990; Gauthier & Ponto, 1970; Goodall, 1974; Hodges, Johnson, & Johnson, 1992; Silvert, 1993; Tichenor, 1989) . Modular, hierarchical model structuring is well developed in the context of discrete event modeling (Zeigler, 1976; Zeigler, 1990) , but has received comparatively little development in the realm of continuous modeling (Cellier, 1991; Goodall, 1974; Silvert, 1993) . Ecosystem models with a modular hierarchical structure should be closer to natural ecosystem structure than procedural models (Goodall, 1974; Silvert, 1993) , since the component populations of ecosystems are themselves complex hierarchical systems with their own internal dynamics. Modular design facilitates collaborative model construction, since teams of specialists can work independently on different modules with minimal risk of interference. Modules can be archived in distributed libraries and serve as a set of templates to speed future development. The inheritance property of object-oriented languages allows the properties of object-modules to be utilized and modified without editing the archived object. A modeling environment that supports modularity could provide a universal modeling language to promote worldwide collaborative model construction.
A second step toward reducing model complexity involves the utilization of graphical, icon-based module interfaces, wherein the structure of the module is represented diagramatically, so that new users can recognize the major interactions at a glance. Scientists with little or no programming experience can begin building and running models almost immediately. Inherent constraints make it much easier to generate bug-free models. Built-in tools for display and analysis facilitate understanding, debugging, and calibration of the module dynamics.
One major advantage of this graphical approach to modeling is that the process of modeling can become a consensus building tool. The graphical representation of the model can serve as a blackboard for group brainstorming as the model grows through a collaborative process of exploration. New ideas can be tested and scenarios investigated using the model within the context of group discussion. When applied in this manner the process of creating a model may be more valuable then the finished product.
Tremendous computational resources are required to integrate the equations of a large spatial model in a reasonable amount of computer time. Large models typically require supercomputers for efficient execution. This class of models is a near-ideal application for parallel processing since a typical model consists of a large number of cells that can be simulated semi-independently. Each processor can be assigned a different subset of cells, and most interprocessor communication is nearest-neighbor only. Despite their great promise and increasing availability, parallel architectures have not found much usage in the life sciences. The major barrier to wide acceptance of these techniques has been the difficulty of programming and debugging large parallel programs, and reluctance on the part of scientists to invest time in learning new languages and architectures. Each parallel architecture tends to have it's own programming formalisms, so that models must be largely rewritten in the process of porting from a serial computer, or from one parallel machine to another. Model builders must usually make a substantial time investment learning a new language or development system when beginning work on a new parallel computer.