Using the ECLPSS software environment to build a spatially explicit ...

Ecological Modelling 150 (2002) 211– 238 www.elsevier.com/locate/ecolmodel

Using the ECLPSS software environment to build a spatially explicit component-based model of ozone effects on forest ecosystems Peter B. Woodbury a,*, Ronald M. Beloin b, Dennis P. Swaney a, Brian E. Gollands a, David A. Weinstein a a

Plant Modeling Group, Boyce Thompson Institute for Plant Research, Ithaca, NY 14853, USA b Cornell Laboratory of Ornithology, Cornell Uni6ersity, Ithaca, NY 14853, USA

Received 31 January 2001; received in revised form 15 October 2001; accepted 28 October 2001

Abstract We have developed a modeling framework to support grid-based simulation of ecosystems at multiple spatial scales, the Ecological Component Library for Parallel Spatial Simulation (ECLPSS). ECLPSS helps ecologists to build robust spatially explicit simulations of ecological processes by providing a growing library of reusable interchangeable components and automating many modeling tasks. To build a model, a user selects components from the library, and then writes new components as needed. Some of these components represent specific ecological processes, such as how environmental factors influence the growth of individual trees. Other components provide simulation support such as reading and writing files in various formats to allow inter-operability with other software. The framework manages components and variables, the order of operations, and spatial interactions. The framework provides only simulation support; it does not include ecological functions or assumptions. This separation allows biologists to build models without becoming computer scientists, while computer scientists can improve the framework without becoming ecologists. The framework is designed to operate on multiple platforms and be used across networks via a World Wide Web-based user interface. ECLPSS is designed for use with both single processor computers for small models, and multiple processors in order to simulate large regions with complex interactions among many individuals or ecological compartments. To test Version 1.0 of ECLPSS, we created a model to evaluate the effect of tropospheric ozone on forest ecosystem dynamics. This model is a reduced-form version of two existing models: TREGRO, which represents an individual tree, and ZELIG, which represents forest stand growth and succession. This model demonstrates key features of ECLPSS, such as the ability to examine the effects of cell size and model structure on model predictions. © 2002 Elsevier Science B.V. All rights reserved. Keywords: Model building; Modeling methodology; Model reuse; Model construction tools; Process model; Spatially explicit model; Component-based modeling; Object-oriented; Reusable code; Ecological model

* Corresponding author. Tel.: + 1-607-254-1216; fax: +1-607-254-1242. E-mail address: [email protected] (P.B. Woodbury). 0304-3800/02/$ - see front matter © 2002 Elsevier Science B.V. All rights reserved. PII: S 0 3 0 4 - 3 8 0 0 ( 0 1 ) 0 0 4 6 5 - 3

212

P.B. Woodbury et al. / Ecological Modelling 150 (2002) 211–238

1. Introduction Simulation models have become essential tools for assessing human influences on ecosystems. To better understand and manage ecosystems, models are needed that consider the ecological and spatial connections within large ecosystems and between contiguous ecosystems (He et al., 1999; Mladenoff and Baker, 1999). As the focus of ecological assessments has shifted to larger spatial scales, modelers have created more comprehensive and complex models (Huston et al., 1988), adopted new programming techniques (Sequeira et al., 1991, 1997; Costanza and Maxwell, 1991; Maxwell and Costanza, 1995; Luo et al., 1997), linked multiple models (Alcamo et al., 1994; Hong et al., 1999; Laurence et al., 2001), and combined models with geographic information systems, databases, and statistical analysis tools (Granger, 1990; Green et al., 1990; Baker et al., 1991; Woodbury et al., 1998; Laurence et al., 2000). All of these approaches have tended to create complex computer code whose flexibility of application is limited by the initial design of the model. These initial designs are often outdated and inadequate for current and projected uses of models. When old models are modified for new uses, they often contain a substantial amount of computer code that has undergone haphazard growth rather than redesign (Clark, 1990). Several investigators have recognized these problems, and have developed new systems for constructing spatially explicit models. Most of these new systems use object-oriented design (OOD) and object-oriented programming (OOP). The reasons for using OOP in creating ecological models have been reviewed previously (Sequeira et al., 1991, 1997). OOD can be viewed as a continuation of the trend in computer science toward increased modularity and generality of code, but it is actually a radical departure from procedural approaches to programming. One important feature is the focus on the interaction of objects (modules or components comprising both data and functionality) by means of passing messages requesting that a task be performed. Objects can be quite independent because they need only know what request they are passing and what

information they will receive in return, they do not need to know how the request will be carried out by another object. The details of how a task is accomplished, as well as the data, are generally hidden within an object; this is known as encapsulation, and it promotes modularity of code and models. Objects are instances of a template called a class, which defines how to build the object in memory. A second important feature is that classes can inherit properties from a parent (super) class, which reduces the amount of code required to define new objects since many will share some similarities with other objects. Further explanation of OOP and OOD for the C+ + language is provided by Booch (1991) and for the Java language by Budd (2000). Examples of OOD approaches for spatially explicit ecological modeling include: (a) HOBO: developed in the Smalltalk programming language for creating individual-based aquatic models from reusable and extensible classes (Lhotka, 1994). The authors acknowledge that Smalltalk is not the best choice for efficient use of computer resources. (b) ECOSIM: a library of classes in the C+ + language developed for individual-based ecological simulations (Lorek and Sonnenschein, 1998, 1999). The authors recognize the need for libraries of reusable code for common modeling tasks, and better tools to assist ecological modelers in writing correct code. (c) Spatial Modeling Environment (SME): supports construction of spatially explicit models of landscape and regional ecological processes (Maxwell and Costanza, 1997a,b; Maxwell, 1999; Voinov et al., 1999). This system was designed to support creation of spatially explicit multimedia models for use in regional ecological risk assessments. (d) ECOBAS: a web-based suite of tools to assist in standardization and modularization of ecological models, checking of substance type as well as units, and assistance with model documentation (Benz et al., 2001). This system also performs automatic conversion of a model specification into selected computer


languages including FORTRAN, MATLAB, and EXTEND. The ECOBAS system does not appear to provide specific support for spatially explicit modeling. Each of these systems provides some of the tools that are needed for building spatially explicit ecological models, but all have some limitations. We have developed a system that addresses some of the limitations identified by the authors of other approaches (Lhotka, 1994; Lorek and Sonnenschein, 1998). This system is called the Ecological Component Library for Parallel Spatial Simulation (ECLPSS), and can be viewed as a toolbox for ecological simulation modeling (Beloin and Weinstein, 1994). The goal of ECLPSS is to permit users to design and build fully three-dimensional spatially explicit ecological models by connecting existing reusable software components and readily creating new components. These components are short sections of code that interact by means of a common interface. The ECLPSS framework contains specifications for creation of reusable modeling components, as well as a growing library of such components for use in creating ecological models. The framework is designed to take advantage of parallel processing to enable simulation of many individuals in a large spatial domain at high speeds, and is largely platform-independent. In this paper, three topics are covered: the design of the ECLPSS system, a description of an example model created in ECLPSS, and a comparison of ECLPSS to other tools for creating spatially explicit ecological models. Details of the implementation of Version 1.0 of the ECLPSS framework are available in a report on the World Wide Web (Woodbury et al., 2000; http:// cycas.cornell.edu/ebp/projects/eclpss/ phase1rpt.html). Several typographical conventions are used herein. Italics are used for all terminology specific to the ECLPSS system, including class names, names of portions of the framework, etc. Bold is used for occasional emphasis such as introducing new terminology. The Courier font is used for small sections of code and for names of C+ + methods such as Get and Put.

213

2. Description of ECLPSS framework The design goals of ECLPSS are to: 1. Create a flexible modeling system for developing and testing spatially explicit ecological models. 2. Facilitate collaborative modeling efforts by providing specifications for creating spatially explicit models. 3. Allow biologists who do not have in-depth programming knowledge to readily construct new spatially explicit models from a library of reusable components. 4. Allow biologists and other scientists to rearrange and experiment with model structure, grid cell size, scale, etc. without tedious reprogramming. 5. Facilitate the reuse of computer code for building new models by the creation of a library of reusable components. 6. Separate the chemical/physical/biological concepts from routine programming tasks. 7. Allow computer scientists to automate tasks such as parallelization of model code without requiring models to be rewritten. 8. Create inter-operability with existing tools such as geographic information systems software. 9. Permit models to be created and run on multiple platforms, including parallel computers and remotely over networks such as the World Wide Web.

2.1. Key design features ECLPSS is a modeling framework. A framework is a set of cooperating classes that make up a reusable design for a specific class of software (Gamma et al., 1995). With a framework, applications can be built more quickly, are easier to maintain, and appear more consistent to their users (Gamma et al., 1995). The ECLPSS modeling framework is based on the principle that spatially explicit ecological models can be built from assemblages of small, independent building blocks that are able to read and write portions of a global, four-dimensional (space and time) model

214


state space in a standardized way. The building blocks are referred to as components, the global data as state variables, and the current value of all the state variables as the model state. The ECLPSS framework and models created within the ECLPSS framework are constructed using object-oriented programming. ECLPSS is designed for grid-based model construction. It is also designed to work in conjunction with grid-based geographical information systems (GIS) and other software tools, rather than to duplicate all of their functionality. This design makes it possible to create spatially explicit models of any process at any spatial scale. ECLPSS separates the activities related to simulating the processes of the ecological systems from the way that the framework manages routine tasks, freeing modelers from handling details such as data storage and access, input/output, memory usage, and program flow. This design makes it feasible for computer scientists to optimize the framework on new platforms (e.g. on multiple processor machines) largely independent of a particular model structure. The ECLPSS framework was designed to be spatially explicit by having each state 6ariable associated with three spatial dimensions as well as a time dimension. A dimension (x, y, z, or t) has a lower and upper bound and a step value that indicates the distance between actual values. Therefore, state variables may have numerous values at different locations and times. State variables can have distinct values for each grid cell for each time, or they may exist as a single point in space and time, or anywhere between these extremes. At run time, the framework iterates over the spatial grid and increments the time step. Components are invoked in order from a list, and are given access to the state variables that they require. A component can act on the data of the current cell or span over several cells in space and time. These ‘data accesses’ are all visible to the framework, facilitating data-sharing schemes required for parallel computation.

2.2. Use of object-oriented programming Object-oriented programming has been applied

to ecological modeling by specifying biological entities as objects (Booch, 1991; Sequeira et al., 1991, 1997; Vaisanen et al., 1994). However, this approach requires that the system being modeled is so well defined that permanent definitions of the objects can be specified. In ecological modeling, complete knowledge of the functioning of parts of an ecosystem is not available. Even if it were, the specification of the parts will vary depending on the scale and nature of the problem (He et al., 1999). Defining a maple tree as an object that will never change, for example, guarantees that this object will quickly become useless as our concept of how a maple tree functions is redefined. With traditional object-oriented programming, the user may be forced to redesign the basic structure of the software with each change in ideas. This hinders experimentation by making it difficult, time consuming, and costly to make refinements to large existing models. Because different models may represent ecological processes such as plant development in different ways, a flexible modeling framework should separate the simulation logic from the object structure (Gauthier et al., 1999). Instead of defining a hierarchy of biological objects, object-oriented programming is used to implement the framework and to assist in authoring modeling components. For example, a class called ECLPSS Component serves as a parent from which the common features of a component are inherited. All modeling ideas are coded within components; they are not coded into the underlying object-oriented design of the framework. To create a component, a programmer starts with an ECLPSS component form in text format, and fills in the name, purpose, state variable requirements, and code for the required functionality. Component authors must be able to write some C+ + code, but do not need to know the details of object-oriented programming because they do not need to create new classes. A utility program then reads the component form the author has filled in and generates a subclass of the base component class. The new component is then compiled, and another utility program brings the library of components up to date to


include the new component’s information. An example of a component is presented in Appendix A. In principle, a modeler who is not a programmer can construct a model using components from the existing library without writing any code at all. A key feature of ECLPSS is that the component interface, data handling and storage, and program flow control are kept separate from the physical and biological concepts. The components in ECLPSS have a common, generic interface: all components appear the same to other parts of the program, and can be sent the same messages. From the modeler’s point of view, each component is simply a short section of code designed to accomplish a single task, with completely specified requirements for input and output data. This means that components are truly standard and interchangeable. Because of this interchangeability, any code that represents an ecological process can be altered without disturbing the other parts of the model. Additionally, the stable, reusable parts of the framework which handle routine programming tasks can be maintained without requiring attention and debugging by the modeler.

2.3. State 6ariables All variables in any ECLPSS model are state variables, which are roughly similar to global variables in languages such as FORTRAN. State variables can be either floating point or integer values, and must be explicitly defined as such. State variables can be single, fixed values (or they can take on different values for each grid cell for each time step of the model, or even contain an array of values for each grid cell. State variables can exist for any subset of the grid and any subset of the time domain of the model run. To define where and when a state variable exists, each state variable has a 7olume string in a special ECLPSS syntax which defines the state variable volume in three spatial dimensions, one time dimension, and one vector (array) dimension. The syntax for volume strings and other implementation details are described in a report available from the authors (Woodbury et al., 2000). Because all variables in ECLPSS are state variables, they are all accessible

215

to the framework and potentially to any component. A key feature of ECLPSS is that components only interact by means of state variables; components cannot communicate directly with each other (Fig. 1). Version 1.0 of the ECLPSS framework consists of three major parts: a Component Management System, a Model Builder, and a Model Interpreter (Fig. 2). These parts are described in more detail below.

2.4. Component management system The Component Management System contains a repository or Component Library of modeling components and associated utilities, as shown in Fig. 2. Components are used for all modeling tasks, such as coding common mathematical relationships and algorithms. Components are also used to share data with other software by reading and writing specific file formats. Components are not allowed to call other components: they can only interact with predefined state variables, and therefore components make no assumptions about what other components are in a model. This constraint allows components to be replaced without causing unwanted side effects. For example, a component might represent a biological process such as respiration. In a traditional model, multiple sections of code might call a respiration function, but the programmer might not be aware of each function call. In an ECLPSS model, each instance in which the respiration function is used must be separately added to the model (‘instantiated’). Components are stored in a library, and are available for creating new models or modifying existing ones. When a component is created, the required input and output data are specified explicitly, as is the spatial/temporal range of the data, and this information is available to the entire ECLPSS system. When a model is running and a component is invoked over a specific grid cell, the model has a notion of ‘here’ (the current grid cell) and ‘now’ (the current time step). Some common data requests are to read a variable here’ and ‘now’, or perhaps ‘here’ and ‘now minus one day’, or even ‘here plus or minus 10 m’ and ‘last year.’ Compo-

216


nents typically act on data associated with a given place, e.g. growing a tree in the current grid cell using the nutrients and light available in the current grid cell, but need not know the size, dimensions, or any other details of the landscape that is modeled, or be concerned with any of the details of the data structures. Because distances are defined in absolute terms independent of cell size (i.e. meters, rather than array elements), a model can run at different cell sizes without rewriting code. This permits a modeler to explore the conse-

quences of spatial aggregation on the output of either a component or of a model. This feature also means that when a component asks for data from, for example, two meters to the south, these values may be from the same cell or from different cells, depending on whether the model is running at a cell size of one meter or 10 m (see Fig. 3). Of course, just because a model does not malfunction when run at different cell sizes does not mean that the results are valid. Obviously, components, and process descriptions in general,

Fig. 1. The interaction of components, state variables, and input files within the ECLPSS framework. (a) Parts of an example component. Public information, such as the component name and the state variables that are inputs and outputs, is shown outside the central hexagon. Inside this hexagon is the private code — it is only available to the component. (b) For each grid cell in turn, this component reads two inputs, tree height and light, and writes one output, tree height. Note that components do not interact directly with each other, they only interact with state variables.


217

After a model is specified, the Model Builder generates a Model Description File. This file contains all the information required for the Model Interpreter (described below) to create a working model, including the components to be included, the variables that each component reads and writes, and the specific spatial and temporal characteristics of the state variables.

2.6. Model interpreter

Fig. 2. Overview of the major design elements of the ECLPSS framework. The ECLPSS framework can be divided into two main parts, one to manage models and one to manage components. Each of these parts has a separate graphical user interface. To build a model from existing components, a modeler uses the ‘Model Builder’ interface. To create new components, a programmer uses the ‘Component Editor’ interface.

have an optimum range of cell sizes that are appropriate for a given application. This range must be determined by the modeler.

2.5. Model builder The Model Builder is designed to provide a graphical interface that the modeler uses to build a new model. This interface provides information about the components in the Component Library and allows the modeler to select desired components and assign state variables as the inputs and outputs of these components. In addition, the Model Builder is used to set a grid cell size, the numbers of cells in the spatial dimensions, and the start and stop times of the model using the Model Run Setup File. The functionality available in this file is summarized in Table 1.

The Model Interpreter is designed to parse the Model Description File from the Model Builder and turn it into a running model. It is responsible for a number of routine programming tasks with which the modeler need not be concerned, but which are described briefly below. First, the Model Interpreter must allocate all memory required for state variables. It calculates this memory requirement by examining all variable accesses in the Model Description File, which contains spatial and temporal information for each variable. The program then creates instances of all required components and builds the links between components and their associated state variables. The next task is scheduling components. Components are invoked for each cell in the grid that represents the landscape to be modeled, as shown in Fig. 4. The Model Interpreter must iterate over time and space as components are invoked according to when and where they need to modify the model state. The spatial and temporal information contained in the Model Description File is designed to be sufficient to permit the Interpreter to automate the scheduling of components, although such automation was not implemented in Version 1.0.

2.7. Current implementation of ECLPSS Version 1.0 of ECLPSS was completed in July 2000, but not all of the original design goals were achieved. However, we plan to implement all of the design goals in Version 2.0 of the framework (estimated completion: 2002). The implementation of Version 1.0 of the ECLPSS framework is described in a report available from the authors on


218

Fig. 3. Components read data from nearby locations based on physical distance rather than the number of grid cells. Both panels show an ECLPSS model comprised of three components. In the left panel, the grid cell size for the model run is 2 m, in the right panel it is 4 m. A component is reading data from a location 4 m towards the south. Depending on the grid cell size selected for a particular model run, this location may be in the current cell, in an adjacent cell, or in a more distant cell. For example, in the left panel the data are from two cells away, while in the right panel the data are from an adjacent cell.

the World Wide Web (Woodbury et al., 2000). A brief description of the major classes is presented in Table 2. For Version 1.0, the C+ + language was selected because it supports object-oriented functionality such as inheritance of properties within classes and encapsulation of data and methods within objects, and because it was the most robust language available for multiple computing architectures when ECLPSS was begun in 1993. Perl was selected as a scripting language for utilities that handle text strings because it is freely available and is implemented on all major computer platforms. Our models were compiled using strict ANSI C+ + code so that they could be compiled on any computer platform. Models have been compiled using the GNU gcc compiler on an IBM RS-6000 with the AIX operating system, and using Metrowerks CodeWarrior on both Windows 98 and MacOS operating systems. The following section describes a model built in Version 1.0 of the ECLPSS framework.

3. The

OM

model: an application of ECLPSS

The OM model demonstrates that the ECLPSS framework is capable of addressing important

ecological problems in a spatially explicit manner. This model simulates how ozone affects forests. Many tree species are sensitive to ozone, and it may be having substantial effects on forests throughout the Northeastern USA (Laurence et al., 2000). Although numerous species are simuTable 1 Tasks that can be accomplished with the model run setup file Model setup Change length of the model run Change the time step for the model run Change the size of the cells in which components will be called Change the acti6e region where components will be activated Change the region for the model Create a data buffer zone, so that components will not read data that are ‘‘wrapped’’ from the other side of the model domain grid Model output Write out any variable from the model to an output file of one or two variables Change the name of output files Model documentation Save notes about the particular model run (any number of comment lines may be placed at the top of the file before the first c sign)


219

on inter-tree competition (Laurence et al., 2000, 2001). The first of these models is TREGRO, a model of individual tree physiology and stress responses (Weinstein et al., 1991, 1992, 1998). The second is ZELIG, a gap-succession model of forest stand growth and succession (Urban, 1990; Urban et al., 1991; Urban, 1993). We created components in the ECLPSS framework that were capable of reproducing the response of forests to ozone predicted by TREGRO and ZELIG.

3.2. Spatial and temporal domains OM was used to simulate forest dynamics in an area of about 1 ha using data from Ithaca, New York. The model currently permits a maximum of one tree per square meter corresponding to nearly 10 000 individual trees. The model was run on an annual time step for 100 years in order to be able to compare our results with previous results from TREGRO and ZELIG. Although our focus was on oak and maple, seven tree species were modeled. Fig. 4. Components are invoked in a specified order for each cell in turn within the model spatial domain. Components can be specified to execute only for certain time steps or for certain cells. For example, the ‘ReadTrees’ component reads data from a file only at the beginning of the model run. Similarly, the ‘GrowTrees’ component might be executed only for cells that are identified being in a forest rather than a lake. Note that this figure does not represent the OM model, which has many more components.

lated, the OM model highlights the effects of ozone on competition between red oak and sugar maple. These species are important throughout much of the northeastern USA and are particularly important in our study area near Ithaca, New York, USA. Because red oak is more sensitive to ozone than is sugar maple, red oak may be at a competitive disadvantage at the elevated ozone concentrations typical of much of the Eastern USA.

3.1. Relationship to other models The OM model is a reduced-form version of two prior models written in FORTRAN that we have used to examine the direct effects of ozone on individual tree growth and the subsequent effects

3.3. Variables and components in the

OM

model

Components were created to represent birth, growth, and death of individual trees, and the responses of trees to temperature, ozone, and drought. Based on these responses of individual trees, the spatial dynamics of competition, gap development and succession were simulated. The OM model has 60 state variables and 32 components (Table 3). Of the component classes, some accomplish generic tasks such as reading data from text files of various formats, calculating averages, and creating arrays. For each component class, there may be several separate component instances: for example, there are several instances of a component that reads a single state variable from an input file. The remaining components accomplish the following model-specific tasks: Read data files in several ZELIG-specific formats. Define weather (precipitation and monthly temperature). Calculate individual tree growth rates. Calculate species-specific tree height and leaf area.

220


Table 2 Major classes in the ECLPSS framework

Table 2 (Continued) ECLPSSreadStateVariable

All modeling components use this class as a base. Provides an interface between the modeling component and the ECLPSS framework. ECLPSScomponentHelper Base class for the component helpers and another interface between components and the framework. ECLPSScomponentInfo Stores information about a component: name, description, author, date/version, acti6e region, notes. ECLPSSdata Holds the model data for a state variable. ECLPSSdataVolume Subclass of ECLPSSdiscontiguousVolume, with an added member for the length of the array of data stored here. ECLPSSdefaultCompHelper Subclasses of ECLPSSComponentHelper. ECLPSSstandardCompHelper ECLPSSstandardCompHelper is used in the OM model. ECLPSSdimension Implements a description (high, low, step) for a single spatial dimension of the ECLPSS framework. ECLPSSdiscontiguousVolume Implements a link that acts as both an ECLPSS6olume (data member) and a pointer to another ECLPSSdiscontiguousVolume. ECLPSSfoldDim Subclass of ECLPSSfoldPoint that implements dimension wrapping. ECLPSSfoldPoint Superclass for classes that implement wrapping of dimensions. This one is a special case of point. ECLPSSgridVolume Maintains a component’s acti6e region on the modeling grid. ECLPSSmodelParams Reads in model’s o6erall grid and acti6e grid regions ECLPSSPoint, These classes hold the ECLPSSdataPoint coordinates (x,y,z,t) and (x,y,z,t,6), respectively, for a spatial/temporal point or data point. ECLPSScomponent

ECLPSSspatialCoordinate, ECLPSStimeCoordinate ECLPSSstateVariable

ECLPSSstateVarInfo ECLPSS6olume

ECLPSS6olumeStringParser

ECLPSSwriteStateVariable

Subclass of ECLPSSstateVariable that implements the Get method. Hold the spatial and temporal coordinates used in the model. Base class of the classes ECLPSSreadStateVariable and ECLPSSwriteStateVariable Holds various information about a state variable. Implements a description (x,y,z,t) for a spatial/temporal volume using four ECLPSSdimension members. Implements a parser for converting a volume in text form into a volume object. Subclass of ECLPSSreadStateVariable that implements the Put method.

Calculate growing degree days from monthly temperature (both mean and standard deviation). Calculate how tall trees must be at different distances from a target location to reduce light availability. Germinate new trees. Calculate the effects of temperature on tree growth. Calculate the effects of shade on tree growth. Calculate the effect of ozone on tree growth. Calculate tree mortality based on species and age. An example of the code for a component is presented in Appendix A. Short descriptions of each component are provided in Table 3. As shown in Table 3, a number of components operate only at the beginning of the model run (time zero). Nearly all of these components read data from text files containing model parameters. For example, three components read site characteristics, tree species growth parameters, and weather

P.B. Woodbury et al. / Ecological Modelling 150 (2002) 211–238 Table 3 Components in the

221

Table 3 (Continued) OM

Model Calculates joint effect of drought and ozone on growth rate (based on results of TREGRO) Grow Increments basal area as a function of growth rate (based on ZELIG) Germination Determines the germination of new trees in the spatial grid (based loosely on ZELIG) Write components that come last, in order of calling: WriteSomeCellIWrites an array of integer variables Array WriteSomeCellFWrites an array of float variables Array WriteWrappedHeight Writes the array of tree heights in ‘wrapped’ format to make it readable; e.g. by a spreadsheet WriteWrappedBasal- Writes the array of tree basal area in Area ‘wrapped’ format WriteWrappedLeaf- Writes the array of tree leaf area in AreaTotalTree ‘wrapped’ format WriteWrappedWrites the array of tree diameter at GrowthRateDBH breast height in ‘wrapped’ format GrowRSOzone

The first component called by the OM model-required, but does nothing Input components that run for time zero only: ReadZELIGSite Reads site characterization information (ZELIG parameters) ReadZELIGIni Reads initialization information (ZELIG parameters) ReadZELIGSpecies Reads species characterization information (ZELIG parameters) ReadZELIGWeather Reads weather information (ZELIG parameters) readShadeC1 Reads array of the C1 parameter for the shade calculation readShadeC2 Reads array of the C2 parameter for the shade calculation readShadeC3 Reads array of the C3 parameter for the shade calculation readBiomassReads array of effects of ozone on biomass (TREGRO parameter) O3Tregro readRootShootReads array of effects of ozone on O3Tregro root/shoot ratio (TREGRO parameter) SetupRanges Calculates the low and high bounds of array ‘slices’ corresponding to various integer values (neighborhood ‘lengths’) CalcSunHeights Calculates critical heights for shading at varying radii from current tree as a function of sun angle Components that operate through time, in order of calling: Mortality Calculates mortality of trees and removes dead trees (based on ZELIG) Allometry Calculates height and basal area from allometric relationships with tree radius (based on ZELIG) AverageSliceCalculates a neighborhood (‘slice’) Diameter average of tree diameter AverageSliceBA Calculates a neighborhood (‘slice’) average of basal area LeafAreaDensityCalculates total leaf area density for Calc spatial cells AverageSliceHeight Calculates a neighborhood (‘slice’) average of tree height ShadeCalc Calculates fraction of shading as a function of local tree height (simplified from ZELIG) GrowOptimal Calculates growth rate in the absence of stresses (based on ZELIG) GrowShade Calculates effect of shade on growth rate (based on ZELIG) GrowTemperature Calculates effect of temperature on growth rate (based on ZELIG) GrowOzone Calculates effect of ozone on growth rate (based on results of TREGRO) FirstComp

data. Other initialization components handle routine tasks such as allocating memory related to the cell size selected for a model run (SetupRanges) and determining the minimum tree height that could shade a given location (CalcSunHeights). A number of components operate at each time step to calculate tree germination, diameter growth, leaf area (based on predefined allometry, as in ZELIG), the effects of ozone, and tree mortality. Ozone effects are based on results from the TREGRO model; the actual processes by which ozone affects growth are not represented in the OM model. As shown in Table 3, many calculations related to tree growth use well-established gap-succession model algorithms, and are derived from ZELIG. These algorithms have been described previously (Urban, 1990; Urban et al., 1991; Urban, 1993). However, OM differs from ZELIG, because the actual locations of trees can be modeled explicitly by setting the model run cell size to 1 m2, which results in only one tree per cell. Additional components perform tasks such as calculating average tree heights within a cell (A6erageSliceHeight).

222


The last section of Table 3 shows components that write files of desired output data at the end of the model run. Two of these (WriteSomeCellIArray, WriteSomeCellFArray) are generic components that serve to write to a file any integer or floating point variable, respectively. The modeler can designate variables to be included in output files at run time using the Model Run Setup File (Table 1). The other components in this last section of Table 3 serve to write out commonly used output variables in a ‘wrapped’ format that is convenient for viewing and post-processing.

3.4. Ozone exposure scenarios To evaluate the effects of ozone on tree growth and forest stand dynamics, two ozone exposure scenarios were created: ozone concentrations ca. 0.5 and 1.5 times the ambient concentration, but modified from exact multiples of ambient to avoid unrealistic distributions of ozone exposure. The half-ambient concentration represents a background level that would occur without anthropogenic production of ozone precursors, while the higher ozone scenario represents a plausible increase in ozone due to increased emissions of

precursors or warmer temperatures over the next 100 years. These ozone scenarios have been described previously in greater detail (Laurence et al., 2000, 2001).

4. Results and discussion

4.1. Spatially explicit predictions The primary goal of the OM model is to predict the effect of ozone on the growth and species composition of a mixed-species forest stand. Unlike gap-succession models such as ZELIG, OM provides the capability to model specific spatial arrangements of trees, since trees can have specific locations. Two maps of individual trees of different species in a portion of the simulated forest stand are shown in Figs. 5 and 6. Fig. 5 shows the initial pattern of individual trees within an area of 24× 24 m, ca. 1/16th of the total area simulated (ca. 1 ha). Fig. 6 shows the predicted pattern of individual trees after a 100-year model run under the half-ambient ozone scenario and with a grid cell size of 1× 1 m. In Fig. 5, there is a clear diagonal

Fig. 5. Initial pattern of individual trees prior to an OM model run in a portion of a mixed hardwood stand in Ithaca, New York. This figure shows an area of 24 × 24 m, ca. 1/16th of the total area simulated (ca. 1 ha). The area of each circle is proportional to the basal area of that individual tree. The diagonal pattern of tree distribution is an artifact of how the trees were initially placed on the OM grid area from an input file that was not spatially explicit.


223

Fig. 6. Predicted pattern of individual trees after a 100-year model run with a half-ambient ozone scenario. This figure shows the same area of forest as in Fig. 5, but after a model run with a cell size of 1 m2.

pattern in the locations of trees. This pattern is an artifact of how the trees were initially placed on the OM grid area from an input file that was not spatially explicit. After 100 years of growth, this artificial pattern is no longer observed because the OM model has simulated birth, growth, and death of the trees that comprise the stand (Fig. 6).

4.2. Temporal trends in species basal area The most important output of the OM model is the predicted basal area of each tree species. As discussed above, the model constrains germination such that no more than one tree can germinate within a 1× 1 m area. In Fig. 6, unlike in Fig. 5, trees appear in nearly all possible locations, although some of them are so small that they appear only as dots. Such a high density of trees may be unrealistic for heavily shaded portions of the stand, but does not significantly affect the predicted total basal area of the stand since most of these trees are very small. Because OM accounts for all sizes of trees and ZELIG accounts only for trees greater than 0.5 cm in diameter, more trees are present in a stand when using the OM model. In the portion of the stand shown in Figs. 5 and 6, red oak and sugar

maple are the most common species. This dominance of red oak and sugar maple is a common pattern throughout the simulated stand. The proportion of basal area of each species for the entire simulated stand under the half-ambient ozone scenario is shown in Fig. 7. Total stand basal area increases for about 25 years, but then decreases to approximately the same level as the initial year by the end of the 100-year simulation (Fig. 7). This transient increase is due mostly to increased basal area of comparatively minor species such as black cherry and white ash. Red oak was the species with the greatest basal area: ca. 15 m2 ha − 1 throughout the entire 100-year simulation. Sugar maple was the second most abundant species, with a basal area of ca. 13 m2 ha − 1 throughout the simulation.

4.3. Comparison of

OM

to

TREGRO /ZELIG

The effect of ozone on the growth of sugar maple and red oak was similar in the TREGRO/ZELIG simulations and the OM simulations. Both simulations were conducted with the same input data sets for a 100-year period, but the OM simulations shown in Figs. 5–8 were conducted with a cell size

224


of 1 m2, and the ZELIG model for Ithaca used a cell size of 600 m2. For sugar maple, both OM and TREGRO/ZELIG predicted that basal area would decrease only very slightly (less than 1%) under the higher ozone scenario as compared to the basal area under the lower ozone scenario. This result is reasonable since the models use experimental results showing that sugar maple is relatively insensitive to ozone compared to red oak. For red oak, both OM and TREGRO/ZELIG predicted that basal area would decrease a few percent under the higher ozone scenario. However, the linked TREGRO/ZELIG models predicted that red oak basal area would decrease almost 4%, while OM predicted that red oak basal area would decrease only 2%. For both the TREGRO/ZELIG models and OM, ozone decreased individual tree growth more than stand growth. This result is not surprising because tree species that are relatively insensitive to ozone may benefit from the slower growth of sensitive species within a stand. Indeed, both models predict that ozone can alter species composition by this mechanism. For example, under the higher ozone scenario, red oak decreased as a proportion of total stand basal area. In summary, the OM model adequately, though not precisely, replicated the results of the linked TREGRO/ZELIG models.

4.4. Comparison with other models of ozone effects As mentioned previously, the model of ozone effects presented herein is a reduced-form representation of the linked tree and stand modeling approach described previously (Laurence et al., 2000, 2001). This approach differs from other approaches to modeling the effects of ozone on forests. Measurements of the effects of ozone on seedlings have been extrapolated directly to regional forests without considering scaling issues such as differences between seedlings and mature trees and effects of competition between tree species (Hogsett et al., 1997). The PGSM model of the growth of a single tree has been used to simulate the response of ponderosa pine and loblolly pine to ozone (Chen et al., 1994, 1998). However, this model cannot simulate the effect of ozone on inter-species competition. The PNET model has been used to estimate regional effects of ozone on forest growth, but this model also cannot account for effects of ozone on inter-species competition (Ollinger et al., 1997). Because it is very difficult to measure directly the effects of ozone on mature trees and forests, there are inevitably uncertainties in any attempt to assess ozone effects on forests (Weinstein et al., 1998; Woodbury et al., 1998;

Fig. 7. Predicted basal area of different tree species with half-ambient ozone exposure. To improve the clarity of the figure, data for the two least common species, red maple and white oak, are not shown.


Laurence et al., 2000). However, the TREGRO model does assist in scaling the effects of ozone from the leaf to the whole tree (Samuelson and Kelly, 2001) and the ZELIG model addresses the effect of ozone on inter-species competition. Because the reduced-form model presented herein is derived from these models, it should provide a useful approach for evaluating ozone effects on mixed-species forest stands.

4.5. Effects of cell size All practical models of the response of forests to stresses must aggregate processes to some degree. Such aggregation causes bias if responses to stresses are nonlinear (e.g. King, 1991). The first step in reducing such aggregation error is to identify which processes are most sensitive to aggregation, a task that can be accomplished using either deterministic or probabilistic techniques (Rastetter et al., 1992). The type of error that concerns us here is that associated with aggregation of processes over space. This type of error is receiving increasing scrutiny as spatially explicit models are developed. For example, the effects of changes in step size along environmental gradients and changes in the spatial resolution of a gap-succession model of forest stand dynamics were recently examined by Malanson and Armstrong (1997). Similarly, the effect of grid cell size on runoff and soil moisture for a model of water movement and nitrogen dynamics in a small watershed were investigated by Kuo et al. (1999). In this study, higher average soil water contents and higher evaporation rates were found for large cell sizes, apparently due to aggregation error in defining the shape of the steep slopes in the watershed. Most models are designed to operate at a specific scale or cell size. When comparing two different models that operate at different cell sizes, it is difficult to determine whether differences in the model predictions are due specifically to the spatial scale of the models or to some other factor. However, in ECLPSS, the cell size at which modeling components operate can be changed easily at run time simply by editing the Model Run Setup File. This feature of ECLPSS allowed us to investigate spatial aggregation error. Specifically, we

225

compared the results of runs made with two cell sizes: 1 m2 and 24 ×24 m. As discussed above, at the smaller cell size, individual trees can have precise locations, as shown in Figs. 5 and 6. At a larger cell size, such as 24× 24 m (similar to the 600 m2 cell size used in ZELIG), individual trees are not precisely located in space. Although individual trees can be modeled in such a simulation, it is not possible to examine the effect of different arrangements of trees within the cell. For testing the effects of cell size, simulations were conducted without any drought or ozone stress. Overall, the simulations at the larger cell size significantly overestimated total basal area as compared to the predictions from TREGRO/ZELIG. Cell size also affected the species composition of the simulated stand (Fig. 8). Some species were predicted to comprise similar proportions of the total stand basal area at both cell sizes, while other species showed distinctly different responses for the two cell sizes. For example, red oak comprised ca. 30% of the total basal area after a few years of simulated growth at both cell sizes. However, over the 100-year simulation, sugar maple decreased from ca. 30% to less than 25% of the stand at the 1 m2 cell size, while it increased to 40% of the stand at the 24× 24 m cell size. The cell size also affects the distribution of tree sizes over time. The largest trees die after about 30– 40 years at the 1 m2 scale, but survive considerably longer at the 24× 24 m scale, demonstrating that stand dynamics are truly different in the two simulations. These results demonstrate that a model created in the ECLPSS framework can be successfully operated at quite different cell sizes. Further testing demonstrated that the differences in results at the different cell sizes were due to aggregation error in the algorithm used to calculate the amount of shading. The modular construction of the OM model, which is enforced by the ECLPSS framework, greatly facilitated the process of identifying the source of this error.

4.6. Replacing components, testing model structure Another important feature of the ECLPSS framework is that components can be replaced readily without causing the model to malfunction,

226


permitting modelers to test the influence of model structure on the predictions and to easily improve the model when the understanding of a particular process increases. For example, during development of the OM model, both tree growth and germination were represented in two ways, with different groups of components. These components could be swapped in the model without affecting the action of other components. Similarly, a component can be removed to test its influence. For example, the component that represents the effect of ozone on tree growth was removed in order to examine tree growth without ozone stress. This degree of modularity proved quite useful during model development and testing. This modularity is due to several basic design features of the ECLPSS framework. As discussed previously, components can only communicate with other components or external data files via state variables. Because all components read and/or write only to the state space, and do not communicate directly with each other, there are no hidden dependencies that might cause problems when components are removed from the model. Additionally, all components must specify explicitly whether they read a state variable, write one, or both. This specificity also helps to avoid ambiguity that can cause unexpected problems. While we believe that these design features are useful, there is a cost to achieving the interchangeability of components. It can be more difficult to design components in ECLPSS than to write more traditional code, because all communication occurs via state variables, and no component can ‘call’ another one. This trade-off is not a unique feature of ECLPSS, but applies more generally to component-based programming. Other ecological modelers have suggested that truly reusable and interchangeable code can only be constructed by limiting and clearly defining the structure of the interfaces between sections of code (Acock and Reynolds, 1997; Reynolds and Acock, 1997). The OM model and the ECLPSS framework in general provide good examples of this approach.

4.7. Comparison of ECLPSS with other modeling systems While a comprehensive review of tools designed to create spatially explicit ecological models is beyond the scope of this paper, we review briefly some of the currently available tools. This review is followed by a summary of the limitations and benefits of ECLPSS, and our future ECLPSS development plans. As discussed in Section 1, other groups of ecological modelers and computer scientists have perceived many of the same needs as we have for more intelligent software tools for examining spatial processes. Some of these tools are not designed explicitly for spatial analyses, but can nevertheless be used for them. Some of the tools are grid-based systems in only one or two spatial dimensions; while others focus on specialized problems, such as animal movement or population structure, that are not the main focus of ECLPSS. A few of these systems are similar to ECLPSS in being designed to enable ecologists to build models of terrestrial ecosystems at the local to regional scale. Table 4 compares several characteristics of a representative selection of these systems with those of ECLPSS, including their spatial structure, available libraries, and environments for constructing models and visualizing results. Because we have not used most of these systems, our description of these systems is only cursory, and readers are urged to review the citations presented in Table 4 and contact the system developers for further information. These tools span a considerable range of modeling sophistication, from classes of objects to fully developed modeling platforms with extensive user assistance and documentation. In addition to these systems, there are numerous excellent generic modeling platforms such as MATLAB, SIGMA, and SIMLAB that can be used for ecological modeling. However, because these generic tools do not provide functions specifically for ecological process modeling, they are not addressed herein.

A modeling environment

AME

0-D, but can be Cells, hierarchical linked to GIS. Can topologies. Default create a is 2-D grid multiple-instance submodel with each instance corresponding to a spatial unit.

Spatial structure

Cells

Novice and expert Theoretical modelers Novice and expert modelers modelers

Type of users

Under development

Construction of 3-D dynamic models from a library of components on multiple platforms

Not yet

Ongoing

Ecological component library for parallel spatial simulation 1 Not yet

ECLPSS

Not inherently spatially explicit

Interactive construction of individual-based models, visualization, genetic algorithms

Free

ECOSIM

Limitations

Version Availability/commercial Free for personal, status educational and research purposes Development status Being replaced by SIMILE Documentation Several tutorials and user guide available from web site Strengths Supports GUI-based box-and-flow modular model construction; uses OOP

Full name

Part I Short name

Table 4 Comparison of tools for building spatially explicit models of ecological processes

EXTEND,

Variables can be represented as 2-D arrays; modules can be repeated by cutting and pasting; User must then make connections between modules graphically.

Novice and expert modelers

Spatial models difficult?

Easy-to-use graphic interface, modular construction, clear identification of inputs and outputs from each module

Thorough

4 Yes; commercial software, multiple products Ongoing

EXTEND+BPR

OSIRIS

Handles multi-phase, Spatially explicit multi-component, individual-based coupled chemical modeling tool; reactions at steadyautomated scheduling state in brackish water of events and marine benthic environments 1-D (vertical); freshwater systems require some modification of parametric relationships Experienced modelers; Modelers? programming expertise not necessary, though helpful 1-D (vertical)

Web-based manual partially completed

Continuing

Marine and estuarine diagenetic modeling environment Beta Free; downloadable from website

MEDIA

P.B. Woodbury et al. / Ecological Modelling 150 (2002) 211–238 227

Most


AME

None

Unit and substance checking Model results processing and visualization Model documentation assistance

Downloadable from website

User can build using Tcl/Tk syntax

Yes

Example: ModMED uses AME with a GIS to model vegetation dynamics in the Mediterranean region

Model Construction assistance

Predefined functions and libraries

Previous and current use

Capability to have No front end, engine, data on different connected computers? Data-parallel No? computation? Language Tcl

Version Platform

Full name

Part I Short name

Table 4 (Continued)

None

Genetic algorithms, random numbers, array manipulation

C++

Yes

ECOSIM

EXTEND,

Front end included

4 Mac OS, Windows

EXTEND+BPR

Modules written in MODL, a C-like language Many simulations

Currently using commercial software; have ported to VRML Metadata and versions supported for components

Designed

Yes

Yes

No

Yes

Random numbers, Specific to this a few unit conversions, environment; many some terrestrial available ecosystem components

Forest gap model, multimedia model being designed

Currently C++, soon Java

Designed to facilitate it Not likely

Ecological component library for parallel spatial simulation 1 Windows, MacOS, AIX, Solaris Yes

ECLPSS

None

None

User follows model construction protocol and model simulation protocol; MEDIA user interface (UI) template package checks formatting errors of input files None

Many chemical reaction functions

Chemical transformations in sediments (benthos)

Object-oriented FORTRAN 90

No

No

Marine and estuarine diagenetic modeling environment Beta Windows

MEDIA

Main classes are habitats, populations, conditions, and resources; also has link objects

Used to model Daphnia population dynamics

C++

OSIRIS

228 P.B. Woodbury et al. / Ecological Modelling 150 (2002) 211–238

ECOSIM

ECLPSS

A C++ class library for micropopulation simulation. Simulates up to about 100 000 individuals, supports differential equations

Strengths


Available from URL Thorough

Documentation and example model available from web site

Documentation

Complete environment for creation, evaluation, documentation of GIS-based landscape models

Ongoing

Ongoing

STELLA

6 Yes

Spatial modeling environment

SME

Free, see website

Downloadable from web site

SIMEX

Ecological component library for parallel spatial simulation 1 Automatic Designed to be automated, currently manual No, but uses Possible No components for tasks such as file transfer Lorek and Beloin and Weinstein Sonnenschein 1998 1994 http://helios.bto. http://www.offis.uni- http://cycas.cornell.edu/ ed.ac.uk/ierm/ame/ oldenburg.de/ eclpss/ See also: projekte/ecotools/ http://www.simile. project – ecotools4.htm co.uk/


AME

Version Availability/ commercial status Development status

Full name

Part II Short name

Web site

Citation

Integrated with GIS and/or DBMS?

Version Event scheduling

Full name

Part I Short name

Table 4 (Continued)

EXTEND,

Marine and estuarine diagenetic modeling environment Beta None

MEDIA

Automated

OSIRIS


Ongoing

4

MODELMAKER


Thorough

Ongoing

POWERSIM

Total risk integrated methodology TRIM.FATE v. 1 Scheduled for limited release in 2001 TRIM.FATE and other modules under development Extensive, includes status report and two technical support documents available from URL True multimedia modeling, mass balance, ecological and human health risk assessment, uncertainty analysis for air pollutants

TRIM

Integrated with species, No reaction, and parameter databases Mooij and Boersma (1996) http://imaginethatinc. http://allserv.rug.ac.be/ com/pages/extend. fmeysman/media/ html media.htm

No

4 Unknown

EXTEND+BPR


MODELMAKER

is a class library for micropopulation modeling

Predefined functions and libraries

SIMEX

Numerous human epidemiological applications

Yes, automated

Previous and current use

Not likely

Unix, NT

Platform Capability to have front end, engine, data on different connected computers? Data-parallel computation? Language C++

Specific to this Extensive; include ecological ‘modules’ environment; many available

Modular modeling Self-contained language language (MML), C++ Several large, Many simulations regional, multimedia (water quality oriented) models

Variables can be represented as two-dimensional arrays; modules can be repeated by cutting and pasting; User must then make connections between modules graphically. Mac OS, Windows Front end included

Novice(?) and expert Novice and expert modelers modelers

Grid cells, but supports irregular lattices, networks, and trees

Modelers (with substantial programming ability?)

Spatial structure

Type of users

Monte Carlo capability, stiff equation solver

Chemical, environmental and pharmacokinetic models

Novice and expert modelers

6 4 2 or 2.5 dimensional Spatial models difficult? Spatial models (i.e. several 2-D difficult? layers only)

No spatial functionality? Oriented towards biomedical applications

STELLA

Version Limitations

SME


SIMEX

Full name

Part II Short name

Table 4 (Continued)

TRIM

FORTRAN,

and C

Under development; a testbed for assessing Hg movement through ecosystems; some previous work with Benzo-a-pyrene Chemical mass transfer, uncertainty, variability, exposure estimates for ecological

Java,

Variables can be Compartments represented as contained in 3-D two-dimensional arrays; ‘volume elements’ modules can be repeated by cutting and pasting; User must then make connections between modules graphically. All major platforms Probably

Total risk integrated methodology TRIM.FATE v. 1 Spatial models difficult? Box-and-flow structure does not represent gradients well. Restricts model structure. Not research oriented. Novice and expert Modelers, risk modelers assessors

POWERSIM


Model documentation assistance Event scheduling

Unit and substance checking Model results processing and visualization

Model construction assistance

Model construction environment

Version

Full name

Part II Short name

Table 4 (Continued)

6

STELLA

Advertises integrated Yes visualization and analysis tools; but ‘Menu-driver interface facilitating user control of the simulation and real-time display of simulation output… not implemented in alpha version’ None known Yes

‘Module Constructor’ Yes translates ‘view’ code (e.g. STELLA, or other front end) into MML; ‘code generator’ translates MML into C++ None None

Icon-based graphical Iconic GUI modeling environments


SME

Downloadable from web site Discrete event Automatic, but can simulations by be customized means of the SX – BaseScheduler class

A model-building UI is apparently available

SIMEX

Yes

Yes

Iconic GUI

4

MODELMAKER

Extensive

Yes

None

Yes

Iconic GUI

POWERSIM

Planned to be substantial

Currently Excel; plan to develop visualization tools and some GIS functionality

Automated?

Total risk integrated methodology TRIM.FATE v. 1 receptors, link to ordinary differential equation solver (LSODE) Will be GUI, with ability to select scenarios to represent physical environments and libraries of chemicals Extensive libraries of parameters, transfer functions, will be accessible in GUI

TRIM


Web site

Citations

Version Integrated with GIS and/or DBMS?

Full name

Part II Short name

Table 4 (Continued)

http://www.nmsr. labmed.umn.edu/ nmsr/Object.html

No

SIMEX

Costanza and Maxwell (1991) Maxwell (1999), Maxwell and Costanza (1995, 1997a,b) Voinov et al. (1999) http://kabir. cbl.umces.edu/ SME3/

Integrated GIS and database access


SME

http://www. hps-inc.com/

6 No

STELLA

http://www. modelkinetix.com/

4 No

MODELMAKER

http://www. powersim.com/

No

POWERSIM

http://www.epa.gov/ttn/ uatw/urban/trim/trim pg.html

Total risk integrated methodology TRIM.FATE v. 1 Designed to have utilities to exchange data with external DBMS and GIS systems

TRIM



Icon-based, compartment model simulation platforms are an important class of modeling platforms. These are modeling platforms with diagrammatic (‘iconic’) GUIs that allow the user to specify model compartments and relationships by constructing a diagram of the model structure, and prompting the user for parameter values. Several of these are available commercially, including STELLA, EXTEND, MODELMAKER, and POWERSIM. STELLA is aimed at the general modeling community; EXTEND, the engineering and business community; POWERSIM, the business community; and MODELMAKER, the environmental modeling community. AME, developed at the University of Edinburgh Institute of Ecology and Resource Management, is similar to these packages and is also aimed at the environmental modeling community, but is available free for research and educational purposes. These packages provide no specific tools to build spatially explicit ecological models, but spatial dynamics can be handled through the use of multiple instances of state variables or arrays. Models built using ECOSIM, OSIRIS, SIMEX, and MEDIA utilize the powerful constructs available in object-oriented languages to model ecological phenomena, population dynamics, or biogeochemical processes. In particular, hierarchical class structures with inheritance of properties to subclasses are used to represent physical objects or ecological processes. ECOSIM can utilize parallel processing and has been used primarily to develop individual-based models of fish and bird populations. OSIRIS is used to develop spatially explicit individual-based models for population dynamics, e.g. Daphnia population growth. The SIMEX package contains several C+ + classes that make it easier to build discrete-event, micropopulation models, as well as some differential equation models, aimed primarily at human epidemiological applications. MEDIA is a platform used to develop one-dimensional (depth) diagenetic models of benthic processes; a principal strength is a library of chemical reactions and chemical species. TRIM, short for Total Risk Integrated Methodology, is an ambitious multimedia (air, water, soil) simulation platform for modeling chemical

233

fate and transport and ecological risks. The US Environmental Protection Agency is currently supporting development of this system to help environmental managers conduct better environmental risk assessments. The TRIM system is spatially explicit and will support systems of differential equations. TRIM seems to be designed for spatial scales of small or moderate sized watersheds. SME is the modeling platform most similar to ECLPSS. Like ECLPSS, it is a complete environment for the creation of spatially explicit landscape models, although it is limited to two dimensions. Unlike ECLPSS, it supports irregular lattices, networks, and data trees in addition to regular grids. However, it is not clear how easily the user can replace model components and alter the basic structure of models in SME. It has been used to develop landscape-scale hydrochemical models of the Choptank basin, a subwatershed of the Chesapeake Bay drainage. The modeling environments ECOTALK and HOBO (cited in Section 1) were built for specific uses and are no longer being developed— for this reason they are not included in Table 4.

4.8. Limitations of ECLPSS and future plans While we believe that ECLPSS has the potential to become a powerful tool for ecological modeling, it currently suffers from some limitations. Some of these limitations can be readily overcome by creating additional utility components within the current system. Other limitations, however, will require significant enhancement of the framework code. We are continuing to develop ECLPSS in collaboration with a team of computer scientists, targeting several key areas of ECLPSS for improvement, as described below.

4.9. Language The existing ECLPSS framework, written in C+ +, is being completely revised and converted to the Java language. The Java language is an excellent choice for ECLPSS because it is specifically designed for smooth operation across multiple computer platforms via the Internet and

234


Fig. 8. Comparison of predicted tree basal area growth with model runs at two cell sizes; 1 and 24 m. To improve the clarity of the figure, data for basswood, white ash, and white oak are not shown.

Fig. 9. At the edge of the model domain grid, components read data from either a data buffer or from the opposite side of the grid. Spatially explicit models must successfully address boundary problems that occur at the edge of the model spatial domain. In Version 1.0 of the ECLPSS framework, users can choose one of two methods for handling boundary problems, as shown in panels (a) and (b). Panel (a) shows data being read from a data buffer, which is an extension of the model grid where data can be read or written, but where components do not operate. Panel (b) shows data being read from the opposite side of the grid.

because it provides robust support for multithreaded object-oriented and component-based programming (Budd, 2000).

4.10. Assistance for model construction An improved user interface is needed for linking components to create a model. For initial framework and component development, we primarily used an integrated development environ-

ment (Metrowerks CodeWarrior) to aid in model construction, compilation and debugging. Additionally, a stand-alone user interface for editing components and creating a model is currently being rewritten and expanded. The new graphical user interface will allow rapid assembly of components into models by accessing components from the Component Library, and will automate many aspects of creating, testing, archiving, and managing components.


4.11. Component library ECLPSS currently possesses a limited library of ecological components. Our current work to develop a multimedia model of nitrogen transport and processing in forested watersheds will increase the library substantially. However, creation of other new models will require creation of many new components. The new user interface will be able to connect users on one computer platform to a model running on a different platform via the Internet. Such connectivity should make it easier for modelers to share components in a common Component Library.

4.12. Efficiency of code and parallelization Efficiency of memory allocation, array management, and other optimization issues were regarded as secondary goals in Version 1.0, but these issues are currently being revisited in light of migrating the platform from C+ + to Java. ECLPSS is designed to constrain model structure so as to greatly facilitate automated creation of code that will operate successfully on distributed computer systems. During phase 2 of the project we plan to implement ECLPSS over a distributed computing network capable of simulating detailed processes over large landscapes at high speeds.

4.13. Boundary issues In Version 1.0, the modeler can choose whether or not spatial processes should ‘wrap’ to the other side of the model grid (Fig. 9). Alternatively, fixed boundary conditions may be specified by the use of an ‘active’ grid within a ‘buffer zone’ outside the active area. Version 2.0 of ECLPSS will include improved functionality for specifying different types of boundary conditions and behavior at the limits of the model’s spatial domain.

4.14. Model de6elopment and testing Some utilities for developing and testing models have been created, but additional support will be required to assist in tasks such as reporting intermediate data values during a simulation. While

235

some of these functions can easily be accomplished with components, other functionality will require improvements to the framework code. One feature under development is automated checking of units and substances (e.g. the units and identity of chemicals) for all model calculations.

4.15. Linkages to other software, post-processing, and 6isualization Some functions, such as spatial averaging of results and automated output of results and intermediate variables in different formats, have been implemented in Version 1.0 of ECLPSS. For example, components have been created to provide output in the Virtual Reality Modeling Language, but this capability has not been developed beyond the demonstration phase. Visualization and post-processing will be greatly expanded in Version 2.0, especially given the availability of a large collection of Java applications. Additionally, there will be greater inter-operability with existing GIS software such as ARCGIS.

4.16. Documentation and testing Documentation of the ECLPSS framework is ongoing. While some guidance is available for a modeler who wishes to create a new model using the ECLPSS framework (Woodbury et al., 2000), this guidance needs to be expanded and tested. Further documentation will be developed as Version 2.0 of the ECLPSS framework is completed.

5. Conclusions In conclusion, we believe that current and planned versions of the ECLPSS system will help ecologists to build more robust, spatially explicit ecological models as a result of several design features. Specifically, ECLPSS is designed to: Help ecologists to build robust spatially explicit simulations of ecological processes from a growing library of reusable components representing terrestrial ecosystem processes.

236


Allow models to be rapidly modified because one or more components can be replaced without changing other aspects of model behavior. Simulate ecological phenomena at multiple spatial scales with the same model. Use single processor machines for small models and across distributed networks for larger models.

Acknowledgements This research was funded by the United States Environmental Protection Agency (EPA) High Performance Computing program, grant number: R 825208-01-0. We thank the EPA, the Electric Power Research Institute, and the Boyce Thompson Institute for Plant Research for support over the past several years. The sponsors of this research have not formally reviewed this document and it should not be construed to represent their policies. Thanks also to Barbara Warland for assistance with producing proposals, reports, and manuscripts for this project. Thanks to John Laurence and Bongghi Hong for helpful editorial suggestions. Appendix A. Example of an ECLPSS component form Component for OM model, to analyze effect of ozone on oak/maple forests NAME: GrowOptimalOM AUTHOR: Peter Woodbury, Ron Beloin DATE VERSION: 5 Nov. 1998. 1331 v1 DESCRIPTION: Calculate optimal diameter growth of each tree as a function of leaf area, etc. Other components will decrease actual growth due to shading etc. NOTES: This algorithm is a simpler one from an older version of ZELIG. 5 Nov. Corrected main equation. See the file Test GrowOptimal for a confirmation that this algorithm and data are correct at least for the first tree.

ACTIVE REGION: x= all; y= all; t= all; INPUT: NAME: species UNITS: integer STORAGE TYPE: int SUBSTANCE: integer VOLUME: x= x; y =y; t= t; 6= 576; NOTES: 0 means no tree or a dead tree, other numbers are species codes FILENAME: END. INPUT: NAME: diameter UNITS: [cm] STORAGE TYPE: float SUBSTANCE: any VOLUME: x= x; y = y; t= t; 6 = 576; NOTES: FILENAME: END. [ …other inputs listed here] OUTPUT: NAME: growthRateDBH UNITS: [any] STORAGE TYPE: float SUBSTANCE: wood VOLUME: x= x; y= y; t= t; 6= 576; NOTES: ZELIG manual says units are cm3 m − 2 of leaf area. Need to initialize this var in the model. FILENAME: END. BEGIN MAIN FUNCTION: ECLPSSdataPoint tree(current, lowBound Get( current)); // for the tree arrays, species, height, leafAreaTotalTree, etc. ECLPSSdataPoint index(current, 0); // for the species arrays, heightMax, allometry, etc. const int hi = highBound Get( current); int sp; float rate; float c,d,b2,b3;


float heightMaxCm; for (int i=0; i < hi; i + + ) { if ((sp =species Get( tree))! = 0) { index.SetCoordinatesAndVector( current.GetX( ), current.GetY( ), current.GetZ( ), current.GetT( ), sp); //some shorthand values b2 =allometryB2 Get( index); b3 =allometryB3 Get( index); d=diameter Get( tree); c=expf( b2* d); heightMaxCm = heightMax Get(index)* 100.; //monster eqn rate =growthRateDBHMax Get( index) * leafAreaTotalTree Get( tree)* (1.0-d* height Get( tree)/(diameterMax Get(index)* heightMaxCm))/(d* heightMaxCm*(-1.0*d*b3*b2*c* powf((1.0-c), (b3-1.0)) + 2.0* powf((1.0-c), b3))); growthRateDBH Put( tree, rate); } else { growthRateDBH Put( tree, 0.0); } tree.IncrementVector( ); } END MAIN FUNCTION

References Acock, B., Reynolds, J.F., 1997. Introduction: modularity in plant models. Ecol. Model. 94, 1 –6. Alcamo, J., Kreileman, G.J.J., Krol, M.S., Zuidema, G., 1994. Modeling the global society –biosphere –climate system: Part 1: Model description and testing. Water Air Soil Pollut. 76, 1 – 35. Baker, W.L., Egbert, S.L., Frazier, G.F., 1991. A spatial model for studying the effects of climate change on the structure of landscapes subject to large disturbances. Ecol. Model. 56, 109 –125. Beloin, R.M., Weinstein, D.A., 1994. An object-oriented framework for spatial modeling using libraries of reusable components. In: Power, M.J., Strome, M., Daniel, T.C. (Eds.), Decision Support 2001, Proceedings, American Society for Photogrammetry and Remote Sensing, Bethesda, MD, p. 510. Benz, J., Hoch, R., Legovic, T., 2001. ECOBAS — modelling and documentation. Ecol. Model. 138, 3 –15.

237

Booch, G., 1991. Object-oriented design with applications, Benjamin/Cummings, Redwood City, CA, 580pp. Budd, T., 2000. Understanding Object-Oriented Programming With Java, Addison-Wesley, Reading, MA, USA, 420pp. Chen, C.W., Tsai, W.T., Gomez, L., 1994. Modeling responses of ponderosa pine to interacting stresses of ozone and drought. For. Sci. 40, 267 – 288. Chen, C.W., Tsai, W.T., Lucier, A.A., 1998. A model of air – tree – soil system for ozone impact analysis. Ecol. Model. 111, 207 – 222. Clark, J.D., 1990. Modeling and simulating complex spatial dynamic systems: a framework for application in environmental analysis. Simul. Dig. 21, 9 – 19. Costanza, R., Maxwell, T., 1991. Spatial ecosystem modeling using parallel processors. Ecol. Model. 58, 159 – 183. Gamma, E., Helm, R., Johnson, R., Vissides, J., 1995. Design Patterns. Addison-Wesley, New York. Gauthier, L., Gary, C., Zekki, H., 1999. GPSF: a generic and object-oriented framework for crop simulation. Ecol. Model. 116, 253 – 268. Granger, K.J., 1990. Process modelling and geographic information systems: Breathing life into spatial analysis. Math. Comput. Simul. 32, 243 – 247. Green, D.G., Reichelt, R.E., van der Laan, J., MacDonald, B.W., 1990. A generic approach to landscape modelling. Math. Comput. Simul. 32, 237 – 242. He, H.S., Mladenoff, D.J., Boeder, J., 1999. An object-oriented forest landscape model and its representation of tree species. Ecol. Model. 119, 1 – 19. Hogsett, W.E., Weber, J.E., Tingey, D., Herstrom, A., Lee, E.H., Laurence, J.A., 1997. An approach for characterizing tropospheric ozone risk to forests. Environ. Manag. 21, 105 – 120. Hong, S.H., Mladenoff, D.J., Crow, T.R., 1999. Linking an ecosystem model and a landscape model to study forest species response to climate warming. Ecol. Model. 114, 213 – 233. Huston, M., DeAngelis, D., Post, W., 1988. New computer models unify ecological theory. Bioscience 38, 682 –691. King, A.W., 1991. Translating models across scales in the landscape. In: Turner, M.G., Gardner, R.H. (Eds.), Quantitative Methods in Landscape Ecology. Springer, New York, pp. 479 – 512. Kuo, W.L., Steenhuis, T.S., McCulloch, C.E., Mohler, C.L., Weinstein, D.A., DeGloria, S.D., Swaney, D.P., 1999. Effect of grid size on runoff and soil moisture for a variable-source-area hydrology model. Wat. Resour. Res. 35, 3419 – 3428. Laurence, J.A., Ollinger, S.V., Woodbury, P.B., 2000. Regional impacts of ozone on forest productivity. In: Mickler, R.A., Birdsey, R.A., Hom, J. (Eds.), Responses of Northern Forests to Environmental Change. Springer, New York, pp. 425 – 453. Laurence, J.A., Retzlaff, W.A., Kern, J.S., Lee, E.H., Hogsett, W.E., Weinstein, D.A., 2001. Predicting the regional impact of ozone and precipitation on the growth of loblolly pine and yellow-poplar using linked TREGRO and ZELIG models. For. Ecol. Manag. 146, 247 – 263.

238


Lhotka, L., 1994. Implementation of individual-oriented models in aquatic ecology. Ecol. Model. 74, 47 –62. Lorek, H., Sonnenschein, M., 1998. Object-oriented support for modelling and simulation of individual-oriented ecological models. Ecol. Model. 108, 77 –96. Lorek, H., Sonnenschein, M., 1999. Modelling and simulation software to support individual-based ecological modelling. Ecol. Model. 115, 199 –216. Luo, Y., Field, C.B., Mooney, H.A., 1997. Adapting GePSi (generic plant simulator) for modeling studies in the Jasper Ridge CO2 project. Ecol. Model. 94, 81 – 88. Malanson, G.P., Armstrong, M.P., 1997. Issues in spatial representation: effects of number of cells and between-cell step size on models of environmental processes. Geogr. Environ. Model. 1, 47 –64. Maxwell, T., 1999. A parsi-model approach to modular simulation. Environ. Model. Software 14, 511 –517. Maxwell, T., Costanza, R., 1995. Distributed modular spatial ecosystem modeling. Int. J. Comp. Simul.: Special Issue on Advanced Simulation Methodologies 5, 247 – 262. Maxwell, T., Costanza, R., 1997a. A language for modular spatio-temporal simulation. Ecol. Model. 103, 105 –113. Maxwell, T., Costanza, R., 1997b. An open geographic modeling environment. Simulation 68, 175 –185. Mladenoff, D.J., Baker, W.L., 1999. Development of forest modeling approaches. In: Mladenoff, D.J., Baker, W.L. (Eds.), Advances in Spatial Modeling of Forest Landscape Change: Approaches and Applications. Cambridge University Press, Cambridge, UK. Mooij, W.M., Boersma, M., 1996. An object-oriented simulation framework for individual based simulations (OSIRIS): Daphnia population dynamics as an example. Ecol. Model. 93, 139 – 153. Ollinger, S.V., Aber, J.D., Reich, P.B., 1997. Simulating ozone effects on forest productivity: interactions among leaf-, canopy-, and stand-level processes. Ecol. Appl. 7, 1237 – 1251. Rastetter, E.B., King, A.W., Cosby, B.J., Hornberger, G.M., O’Neill, R.V., 1992. Aggregating fine-scale ecological knowledge to model coarser-scale attributes of ecosystems. Ecol. Appl. 2, 55 – 70. Reynolds, J.F., Acock, B., 1997. Modularity and genericness in plant and ecosystem models. Ecol. Model. 94, 7 –16. Samuelson, L., Kelly, J.M., 2001. Scaling ozone effects from seedlings to forest trees. New Phytol. 149, 21 –41. Sequeira, R.A., Sharpe, P.J.H., Stone, N.D., El-Zik, K.M., Makela, M.E., 1991. Object-oriented simulation: plant

growth and discrete organ to organ interactions. Ecol. Model. 58, 55 – 89. Sequeira, R.A., Olson, R.L., McKinion, J.M., 1997. Implementing generic, object-oriented models in biology. Ecol. Model. 94, 17 – 31. Urban, D.L., 1990. A versatile model to simulate forest pattern: a user’s guide to ZELIG version 1.0. Environmental Sciences Department, University of Virginia. Charlottesville, VA, 108pp. Urban, D.L., 1993. A user’s guide to ZELIG version 2.2. Department of Forest Sciences, Colorado State University. Fort Collins, CO, 77pp. Urban, D.L., Bonan, G.B., Smith, T.M., Shugart, H.H., 1991. Spatial applications of gap models. For. Ecol. Manag. 42, 95 – 110. Vaisanen, H., Strandman, H., Kellomaki, S., 1994. A model for simulating the effects of changing climate on the functioning and structure of the boreal forest ecosystem: an approach based on object-oriented design. Tree Physiol. 14, 1081 – 1095. Voinov, A., Costanza, R., Wainger, L., Boumans, R., Villa, F., Maxwell, T., Voinov, H., 1999. Patuxent landscape model: integrated ecological economic modeling of a watershed. Environ. Model. Software 14, 473 – 491. Weinstein, D.A., Beloin, R.M., Yanai, R.D., 1991. Modeling changes in red spruce carbon balance and allocation in response to interacting ozone and nutrient stress. Tree Physiol. 9, 127 – 146. Weinstein, D.A., Beloin, R.M., Yanai, R.D., Zollweg, C.G., 1992. TREGRO simulation model of the carbon, water, and nutrient balances of a plant-soil system. Volume 1: Model Version 1.74 Description and Parameter Requirements. Electric Power Research Institute: Research Project 2799-1. Weinstein, D.A., Arthur, M.A., Samuelson, L., 1998. Simulating the differences in ozone response between seedlings and mature red oak trees. Environ. Pollut. 102, 307 – 320. Woodbury, P.B., Smith, J.E., Weinstein, D.A., Laurence, J.A., 1998. Assessing potential climate change effects on loblolly pine: a probabilistic regional modeling approach. For. Ecol. Manag. 107, 99 – 116. Woodbury, P.B., Beloin, R.M., Swaney, D.P., Gollands, B.E., Weinstein, D.A., Laurence, J.A., 2000. The ECLPSS Environment for Developing Spatial Ecological Models using Reusable Components. Final Report to the USEPA from the Boyce Thompson Institute for Plant Research. December 6, 2000. (Available in PDF format: http:// cycas.cornell.edu/ebp/projects/eclpss/phase1rpt.html.)

Using the ECLPSS software environment to build a spatially explicit ...

Using the ECLPSS software environment to build a spatially explicit ...

Suggest Documents

Using spatially explicit indicators to investigate

USING A SPATIALLY EXPLICIT STREAM ... - ScholarWorks

A Spatially Explicit Approach to Support ...

Using spatially explicit occupancy models to predict the distribution

Correction to: âForward-in-Time, Spatially Explicit Modeling Software ...

Using spatially explicit simulations to explore size distribution and ...

Using Spatially Explicit Data to Evaluate Marine Protected Areas for ...

Using spatially-explicit captureârecapture models to explain variation

Using spatially explicit surveillance models to ... - Semantic Scholar

Comparing approaches to spatially explicit ecosystem service ...

Spatially explicit approach to estimation of total

A spatially explicit model to identify suitable sites to establish ...

Spatially explicit capture-recapture methods to ...

sGD software for estimating spatially explicit indices of genetic diversity

A Spatially Explicit and Quantitative Vulnerability ...

A Spatially Explicit Environmental Health Surveillance ... - CiteSeerX

A Spatially Explicit Environmental Health Surveillance ... - CiteSeerX

A spatially explicit representation of conservation ...

a spatially explicit approach to measuring carbon ...

PRUNUS: a spatially explicit demographic model to study ... - LAMFA

A Spatially Explicit Open-Ocean DeLury Analysis to Estimate Gear ...

A Spatially Explicit Individual-Based Modeling Approach to Evaluate

A Spatially Explicit Modelling Approach to Socio- economic ... - iEMSs

Evaluating the Performance of Spatially Explicit Models

Using the ECLPSS software environment to build a spatially explicit ...