The development of complex models can be greatly facilitated by the utilization of libraries of reusable model components. In this paper we describe an object-oriented module specification formalism (MSF) for implementing archivable modules in support of continuous spatial modeling. This declarative formalism provides the high level of abstraction necessary for maximum generality, provides enough detail to allow a dynamic simulation to be generated automatically, and avoids the "hard-coded" implementation of space-time dynamics that makes procedural specifications of limited usefulness for specifying archivable modules. A set of these modules can be hierarchically linked within the MSF formalism to create a MSF model. The MSF exists within the context of a modeling environment ( an integrated set of software tools which provide the computer services necessary for simulation development and execution ), which can offer simulation services that are not possible in a loosely-coupled "federated" environment, such as graphical module development and configuration, automatic differentiation of model equations, run-time visualization of the data and dynamics of any variable in the simulation, transparent distributed computing within each module, and fully configurable space-time representations. We believe this approach has great potential for bringing the power of modular model development into the collaborative simulation arena.
One of the factors limiting the development of ecosystem models in general has been the inability of any single team of researchers to deal with the conceptual complexity of formulating, building, calibrating, and debugging complex models. The need for collaborative model building has been recognized [1, 2] in the environmental sciences. Realistic ecosystem models are becoming much too complex for any single group of researchers to implement single-handed, requiring collaboration between species specialists, hydrologists, chemists, land managers, economists, ecologists, and others. Communicating the structure of the model to others can become an insurmountable obstacle to collaboration and acceptance of the model.
A well-recognized method for reducing program complexity involves structuring the model as a set of distinct modules with well-defined interfaces [1-4] 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. A modeling environment that supports modularity could provide a universal modeling language to promote global collaborative model development.
In this paper we discuss a method for supporting modular modeling based on high level object-oriented module specifications which we call meta-models. These meta-models encapsulate the structure and definition (equations) of a module in a purely declarative format, and can be utilized within a modeling environment to generate a highly configurable dynamic simulation. For specificity we will focus on supporting spatial System Dynamics [5] style simulation, but the methodology is applicable to a more general simulation paradigm. We believe this approach has great potential for bringing the power of object oriented model development into the collaborative simulation arena.
We consider a model to consist of two parts: 1) a model specification and 2) a model executable. The model specification is the text-based description of the model that is used to generate the executable, the executable is the binary application that runs the simulation. We recognize three types of module specification: 1) declarative formalism (meta-model), 2) procedural language, and 3) source code. A meta-model is a high level specification of the structure and dynamics of the model which contains no specific computational specifications, but contains enough information to algorithmically derive the model's source code. The source code, which is written in a general-purpose programming language such as C++ or FORTRAN, contains all the computational details necessary to run the model. The model's source code is compiled/linked to generate the model executable. A procedural language specification defines a module using a specialized modeling language (e.g. DYNAMO [6]) at a level of abstraction that is above general-purpose programming languages such as C or FORTRAN, but below a purely declarative formalism.
A number of procedural languages have been developed to support continuous modeling [7], the most relevant being DYNAMO [6], which was developed to support System Dynamics [5] modeling. Developing a module in one of these languages requires the user to implement the spatio-temporal representation, dynamics of the simulation, and input-output of data in the simulation module. Since all these aspects are "hard-coded" into the module, the flexibility of the module is severely limited. Declarative languages, such as the meta-model formalism described here, which allow the spatio-temporal dynamics and input-output of the module to be flexibly generated at runtime, posses the level of generality necessary for implementing archivable modules.
A number of declarative formalisms have been developed to support model archiving, but the only well-developed example in the realm of continuous modeling is the model interchange format (MIF) developed by PowerSim Corporation [8]. The MIF was developed to support the exchange of models between various System Dynamics simulators. It is well designed to support graphical model development, but is not well suited for archiving generic modules, because it overspecifies the module and is not particularly readable by humans. The associated modeling environment (PowerSim) is well designed for supporting non-spatial Systems Dynamics simulation, but runs exclusively on one platform (Windows) and includes no support for distributed computing.
We recognize two methods for supporting modular model construction, which we call the "federation" and "meta-model" approaches. In the federation approach model executables are linked computationally into a mega-model ( or "federated" model ) within a distributed object architecture such as CORBA [9] or COM [10]. In the meta-model approach a set of meta-models are linked formally within a model specification formalism (MSF), and a linked executable is created using a code generator.
This approach involves the development of a set of "wrappers" which are used to encapsulate a set of model executables in order to integrate them within a single distributed environment, resulting in a "federated" simulation ( encompassing a set of "federated" model executables ). This wrapper is implemented as a library of functions (or distributed objects) that is embedded in the existing simulation source codes to enable them to "publish" (and "subscribe to") simulation services over the network. Each federated model publishes its set of available services using a common high-level interface specification language, which is platform and programming language independent. The base infrastructure for implementing this approach is becoming available with the advent of interoperability specifications such as CORBA [9], COM [10], and OGIS [11]. The best developed example of this approach is the High level Architecture [12] developed by the Defense Modeling and Simulation Office (DMSO).
In this approach a (sub-)model is defined using an (object-oriented) model specification formalism (MSF) to create an archivable MSF module. A set of these modules can be linked using the MSF formalism to create a MSF model. The MSF always exists within the context of a modeling environment, which is defined here as an integrated set of software tools which provide the computer services necessary for simulation development and execution. The modeling environment should provide 1) tools to import models from other languages into MSF, 2) graphical tools to support MSF module development, 3) code generators to convert the MSF model specification into source code (used to build the simulation executable), and 4) extensive simulation services not found in a loosely coupled heterogeneous simulation. The MSF should facilitate model development and communication because it focuses on the issues of interest to the modelers while hiding unnecessary or dangerous implementation details, and encourages modular, hierarchical program design. We will discuss this approach for the remainder of this paper.
The basic properties of a model specification formalism (MSF) outlined here. We simply assume in this paper that a formalism designed to support modularity will be object-oriented. For further reading on object oriented design methodology, consider the general references [13-17], as well as the environmental sciences references in section 1.
Some of the key properties of an (object-oriented) meta-model formalism include:
The federation approach to supporting modularity has received the most attention because it allows legacy code to be integrated into a federation without requiring the code to be completely rewritten. However, the meta-model approach, when applicable (typically in new model development), has a number of important advantages over the federation approach:
In this section we outline a meta-model formalism which we call the Modular Modeling Language (MML), designed to support spatial simulation. This formalism has been implemented and tested within the context of our Spatial Modeling Environment (SME) [18-20]. As shown in the simple example in table 1, an MML module declaration consists of a nested set of object declarations. When the MML declaration is run through a code generator, each MML object declaration is converted into a source code object declaration. The major classes of simulation objects include Module, Variable, Action, Event and Frame objects. A typical MML module specification contains only Module, Variable, and Action declarations, the Event and Frame objects are generated automatically at run time (although the Event class does exist in the MML to allow the specification of customized Event objects). In the next section we describe the process of automatically generating the model dynamics from the MML specification. In this section we describe the major classes of objects used in an MML-generated simulation.
class Module {
List variableObjects
List inputPorts
Frame spatialGrid
}
The Module object is the unit of encapsulation of the model dynamics, i.e. a model specification consists of an (arbitrary) number of module specifications. Modules are designed to be self-contained archivable sub-models, which may interact with other Modules through well-defined input and output ports. Module declarations may be nested to arbitrary depth, and Modules may inherit from other Modules.
Each Module object contains a list of Variable objects (section 4.2), a list of input Ports, and a single Frame object (section 4.5). The input Ports behave as local Variable objects within the Module, i.e. they can be utilized within the local Action objects' (section 4.3) equations as Variable objects declared within the Module. Each input Port is connected to an output Variable in another Module.
class Variable {
List codeObjects
Array value
Attribute Dynamic { true, false }
Attribute Spatial { true, false }
Attribute Clamped { true, false }
Attribute Import { true, false }
Attribute Export { true, false }
Attribute Type { aux, flux, state, constant }
}
Variable objects represent the atomic components of a Module, i.e. each Variable corresponds to a labeled (array of) numeric quantity(s), either calculated or specified as a boundary condition, called it's "value" that is used to compute the model dynamics. Variables can be either "spatial" or "non-spatial". The value of a spatial Variable is represented by an array of floating point values, with each value corresponding to a spatial location ( i.e. a "cell" in the Module's spatial representation, as defined by it's Frame; see section 4.5). The value of a non-spatial variable consists of a single floating point number for each (simulated) time step. For specificity we assume a stock-and-flow (System Dynamics) model structure, in which there are four major Variable types:
Each Variable object contains a list of Action objects (section 4.3), which are used to update it's value, and a set of attributes:
class Action {
Variable target
FunctionPtr equation
List dependentVaraibles
Attribute type { pipe, import, init, update, integrator, userCode, script }
}
Action objects perform the computations or data import/export operations that update the values of variables. Each Action object is associated with a single Variable object, called it's target. Action objects that perform computations (a.k.a. "Code" objects) have an equation attribute (implemented as a function pointer) which is used to update the target's value, and a list of dependent Variables (i.e. Variables whose values are referenced in it's equation). Code objects whose target is non-spatial execute their equation function once each timestep of the simulation, but Code objects whose target is spatial execute their equation function once in each cell of the module's Frame (section 4.5) at each timestep.
All Action objects have a type attribute, and there are six Action object types:
Data is transferred in and out of the model using Pipe objects. A Pipe object links a Variable object with an external data source/sink/display object. Pipes exist for 1) importing data from the GIS or database, 2) archiving data to the GIS or database, and 3) displaying data in real time using various formats.
class Event {
Time timestamp
Schedule schedule
List import
List inputPipes
List update
List integrate
List finalize
List scripts
Attribute type { init, update }
}
The simulation is driven by a set of Event objects. An Event object contains a timestamp and a number of lists of Action objects to be executed, each separately sorted by dependency (when one of these lists is "executed", it's Action objects are executed sequentially). Event objects are posted to a global list which is sorted by timestamp. The objects in the list are executed sequentially to generate the dynamics of the simulation. When an Event object is executed the global simulation time is set equal to the event's timestamp and then the object's Action lists are executed in order. Following each Event execution the Event object uses it's Schedule object to repost itself to the model's event list.
The Schedule object controls the scheduling of Event objects. Schedules are arranged in a hierarchical structure, with Events inheriting Schedules from their Modules and sub-Modules inheriting Schedules from super-Modules. At any level of the hierarchy a Schedule may be reconfigured, overriding aspects of it's inherited Schedule.
Each Module object has a Frame object that is used to define the module's spatial representation. In this formalism, a spatial representation consists of a set of "cells" (representing the units of spatial area) and links ( representing spatial contiguity ) which covers the active area of the simulation, and which may be distributed over a number of processors. The simulation environment provides a set of configurable Frame types, such as grids, networks, and trees. The user specifies a Frame type and a Frame configuration map (to be read from the GIS at runtime) for each Module in the simulation configuration information. Every Frame object includes methods for distributing it's grid over the set of available processors and interacting with and mapping data to/from other Frames.
. All Variable objects belonging to a module inherit the module's
Frame. The value of a spatial Variable is represented by an array
of floating point values, with each value corresponding to a "cell"
in the spatial representation defined by it's Frame. Spatial
interactions are defined in this formalism using relative coordinates.
Relative coordinates can be either Frame-dependent or Frame-independent.
For an example of Frame-dependent notation, the statement SURFACE_WATER[0][0][1]
with a TIN grid Frame represents the value of SURFACE_WATER in
the cell neighboring the current cell along the third link. For
an example of Frame-independent notation, the statement SURFACE_WATER@(1,1)
represents the value of SURFACE_WATER in the cell one (spatial)
unit to the North and one unit to the East of the current cell.
Because of the complexity of spatial referencing in multiple
spatial representations, Action objects which involve complex
spatial interactions are typically constructed at the source code
level using the modeling environment's programming interface.
This section outlines that process of automatically generating simulation dynamics from an MML specification. As can be seen from the example in table 1, the simplest MML module declarations are purely declarative, i.e. they describe only the structure and equations of a module, and say nothing about the execution of the equations in space and time. The space/time dynamics of the model are generated at run-time by the modeling environment based on the MML specification and configuration information read at that time. In the rare event that the user requires greater control over the simulation then is supplied by the configuration options then (s)he can include (in the meta-model) customized MML declarations describing event scheduling and/or develop a customized spatial representation using the modeling environment's API. The steps required in generating the spatio-temporal dynamics are:
The process begins by instantiating the Module and Variable objects as declared in the MML specification. Each flux Variable is linked to it's origin and destination state variables, and each modules' import Ports are linked to corresponding export Variable objects in other modules. The simulation configuration information is then read from files and/or input directly by the user.
The simulation dynamics are generated automatically based on information in the MML specification and configuration information read in the previous step. This process is described by the following set of algorithms, where the symbol E means "is an element of" ( a set or a list ) and a set of attributes is denoted by quantities in brackets, e.g. { A, B, C }.
Loop until equilibrium is reached:
For each Action object c associated with each Variable v in each module:
For each Variable vd E c.dependentVariables:
If (vd.Dynamic = True) then v.Dynamic := True.
Loop until equilibrium is reached:
For each Action object c attached to the global initialization Event:
For each Variable vd E c.dependentVariables:
For each Action object cd E vd.codeObjects:
if( cd.type E {import,update} ) then add cd to the global initialization Event.
Loop until equilibrium is reached:
For each Action c object in the list:
For each Action object cd in c's list of dependency links:
if( cd.index >= c.index ) then cd.index := c.index-1.
Events are initially posted to the global event list, starting with the global init event, followed by the update events for each Module. The Model dynamics are generated by iterating the following procedure until the simulation end time is reached:
A realization of this meta-modeling formalism, called the Modular Modeling Language (MML), has been implemented in the context of our Spatial Modeling Environment (SME) [18-20], which has been developed in an attempt to address the conceptual and computational complexity barriers to spatio-temporal model development. The MML forms the core of the (SME), which links icon-based graphical modeling environments with parallel supercomputers and a generic object database. This system will allow users to create and share modular, reusable model components, and utilize advanced parallel computer architectures without having to invest unnecessary time in computer programming or learning new systems.
The current applications of this framework include the Patuxent
Landscape Model (PLM), [22] and the Everglades Landscape Model
(ELM) [23]. The PLM is a regional landscape simulation model
that can address the effects of different management and climate
scenarios on the ecosystems in the Patuxent Watershed. Application
of this model in the Patuxent watershed is expected to allow extensive
analysis of past and future management options, and will form
the basis for future application to other areas in the Chesapeake
Bay watershed.
We believe that effectively managing human affairs through the next century will require extremely complex and reliable computer models. Widespread utilization of modeling environments supporting graphical, hierarchical/modular design of distributed simulations will facilitate reliable, economical model construction. General adoption of this paradigm will support the development of libraries of modules representing reusable model components that are globally available to model builders, as well as making advanced computing architectures available to users with little computer knowledge.
[1] B. Acock and J.F. Reynolds, "Model Structure and Data Base Development," in Process Modeling of Forest Growth Responses to Environmental Stress., R.K. Dixon, et al., Eds., Portland, OR:Timber Press, 1990.
[2] D.W. Goodall. "The Hierarchical Approach to Model Building," Proceeding of the First International Congress of Ecology, Wageningen, 1974.
[3] R.L. Gauthier and S.D. Ponto, Designing Systems Programs, Englewood Cliffs, NJ: Prentice-Hall, 1970.
[4] W. Silvert, "Object-Oriented Ecosystem Modeling," Ecological Modeling, vol. 68, pp. 91-118, 1993.
[5] J.W. Forrester, Industrial Dynamics., Cambridge, MA.: MIT Press, 1961.
[6] G.P. Richardson, Introduction to System Dynamics Modeling with Dynamo, Cambridge, MA.: MIT Press, 1981.
[7] R. Wexelblat, History of Programming Languages, Academic Press, 1981.
[8] PowerSim, The PowerSim Corp. page, www.powersim.no.
[9] CORBA, Object Management Group, www.omg.org/.
[10] D. Rogerson, Inside COM, Redmond WA.: Microsoft Press, 1997.
[11] OGIS, The OpenGIS Guide., ogis.org/guide/guide1.htm.
[12] DMSO, High Level Architecture, hla.dmso.mil.
[13] P. Robinson, Hierarchical Object-Oriented Design, New York: Prentice Hall, 1996.
[14] S. Cook and J. Daniels, Designing Object Systems, New York: Prentice Hall, 1994.
[15] R.H. Erich Gamma, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Series, Reading, Massachusettss: Addison-Wesley, 1995.
[16] B.P. Zeigler, Theory of Modeling and Simulation., New York, N.Y.: Wiley, 1976.
[17] B.P. Zeigler, Object-Oriented Simulation with Hierarchical, Modular Models, New York, NY: Academic Press, 1990.
[18] T. Maxwell and R. Costanza, "Spatial Ecosystem Modeling in a Distributed Computational Environment," in Toward Sustainable Development: Concepts, Methods, and Policy, J. van den Bergh and J. van der Straaten, Eds., Washington, D.C.:Island Press, 1994.
[19] T. Maxwell, Distributed Modular Spatial Ecosystem Modelling 1994,
[20] T. Maxwell and R. Costanza, "Distributed Modular Spatial Ecosystem Modelling," International Journal of Computer Simulation: Special Issue on Advanced Simulation Methodologies, vol. 5(3), pp. 247-262, 1995.
[21] D.E. Knuth, The Art of Computer Programming: Sorting and Searching, 2nd ed. Vol. 2. Addison-Wesley Pub. Co., 1997.
[22] PLM, Integrated Ecological Economic Modeling, http://giee.uvm.edu/PLM.
[23] ELM, Everglades Landscape Model, http://www.sfwmd.gov/org/wrp/elm/.
Module DEER_module {
state Variable DEER_POPULATION {
integrate Action I0 { Value = { BIRTHS-DEATHS }; }
init Action i1 { Value = { 100 }; }
}
aux Variable BIRTHS {
update Action u2 { Value = { DEER_POPULATION*BIRTH_FRACTION }; }
}
aux Variable DEATHS {
update Action u3 { Value = { DEER_POPULATION*DEATH_FRACTION }; }
}
aux Variable BIRTH_FRACTION {
update Action u4 { Value = { .2 }; }
}
aux Variable DEATH_FRACTION {
update Action u5 { Value = { Graph0(VEGETATION) }; }
}
input Variable VEGETATION {}
LUT Graph0 { Data = ( ( 0.0000E+00, 1.0000E+00 ), ( 1.0000E+02, 8.1500E-01 ), ... }
}Table 1. An MML declaration of a simple module representing deer dynamics.