Robert G. Knox, Virginia Kalb, Elissa R. Levine, and Uday Bindingnavle
FEDMOD (the Forest Ecosystem Dynamics Modeling Environment) is a modeling tool, developed using an object-oriented design, which allows multiple process models to be coupled in order to improve simulations of forest ecosystems. The system consists of a Graphical User Interface (GUI) which provides powerful, easy to use access to the configuration of various complex environmental models, and a simulation framework which orchestrates the simultaneous execution of and communication among the models. Using a generic query-response mechanism, parameter values from detailed models in one discipline are provided to drive models of other disciplines. In addition scaling parameters can be derived from detailed models which improve the accuracy or realism of models from other disciplines. Distinct reporting objects route information among models and process user requests for displays, logs, or summaries of simulated properties. An external clock object ensures synchronization among the models and reporting objects. Databases associated with each model instance save the state space at the end of each clock-step to provide a stable environment for queries. Prospective developments include adding more sophisticated management of spatial extent within the environment to allow model instances to have non-trivial forms of spatial overlap.
A wide array of scientific and engineering disciplines develop environmental models. Although applied models may have narrow scopes and defined limited objectives, models developed to advance fundamental understanding may be used to explore a wider range of questions and to push the limits of present knowledge. For global change research, models are being asked to make predictions outside the range of present conditions. This precludes a strictly empirical approach, since only through a high level of realism in representation of critical processes is at all reasonable to expect valid extrapolations beyond available data (Hanninen 1995). Because ecosystems can be studied from many different perspectives, the best available representations of component processes come from an assortment of disciplines. For example, land surface models used in plant ecology or climate modeling employ highly simplified representations of soil hydrology, with one or two layers and aggregated parameters such as "rooting zone field capacity" or "profile moisture." When such a model, developed by one scientist or a small team, fails, it may be because of submodels that represent processes studied more rigorously by scientists from other disciplines (see Bonan 1993, Bugmann and Martin 1995). Whether a more rigorous understanding would improve matters may remain an open question, because the primary model authors lack the disciplinary expertise and merging models from different disciplines would often produce excessively complex models (cf. Bugmann and Martin 1995).
For several years, we and our collaborators have been pursuing an alternative strategy for merging knowledge represented in different environmental models (Levine et al. 1993). Our aim has been to provide a flexible and reliable environment for simulation using multiple environmental models. We have developed an object-oriented framework called the Forest Ecosystem Dynamics Modeling environment (FEDMOD). Its primary purpose is to advance understanding by allowing simulation experiments, using communication among existing models that were developed by model authors from different science disciplines. Using this environment, a scientist can explore the effects of relying upon more rigorous representations of various ecosystem processes. They might then chose to maintain the present representations of non-focal processes--knowing that key features are consistent with a more specialized understanding, to adopt a more rigorous formulations, or to scale model coefficients to more closely approximate the behavior of the other model(s).
The FEDMOD environment encapsulates existing models to provide object- like behavior, rather than rewriting models in an object-oriented programming language. These models have a proven record of testing and use as stand-alone models of terrestrial ecosystems. As a design goal we strive to minimize changes to existing code, and we benchmark encapsulated models against the results of their stand-alone versions. In object oriented terminology, a particular encapsulated model then forms a "class," and a copy of a model running for a particular set of parameters is an "object" or "model instance."
A disadvantage of stand-alone models is the lack of synchronization on parallel runs. Without a centralized synchronization mechanism, it is impossible for models to dynamically share data. Thus, there is no simple and reliable way for scientists to create and study links among models. Also, types and formats for model outputs are pre-defined. Hence any change in the reporting of results implies a change in the source program of the model. During research use of these models there are frequent changes in the output required, and each change risks introducing errors to model algorithms. Also, when using a model from another discipline, a researcher has to carefully prepare model inputs ensuring that combinations of parameters are compatible and in the proper format. Even were parameters for a variety of locations available from a GIS, there are potential mistakes in formatting those data for use in each situation.
Hence, our goals were to create a reliable environment where these models could be run synchronously, where the researcher has the flexibility to select the output content and the type of reporting, and where less familiar models could be configured for a range of locations and run with some protection from errors in formatting parameters and checks for reasonableness on the values provided. We did not include interactive access to GIS data or real-time model linkages to a GIS. However, spatial data retrievals from a GIS have been used to populate simple databases of model parameters for common types of land units. These can be used interactively to configure model instances for situations of interest. This system addresses the range of issues that arise from the specialized, stand-alone nature of the original models. In the following, we describe the design philosophy, the operation of the simulation environment and the steps involved in adding an existing stand-alone model to the simulation environment.
After analyzing the requirements for such a system (see Levine et al. 1993), the design phase involved identifying the classes in the entire system and the types of relationships that exist between classes. In object-oriented software design (see Booch 1991), "classes" abstract the key features and required behavior of the things systems analysis identifies as making up the problem. Then, instances of classes, or "objects," contain data or represent states. Methods of a class (sometimes called member functions or valid operations on a class or object) define how other objects or people interact with objects of that class. All members of the class or of daughter classes derived from this class then support these same methods or operations. Thus for many circumstances, it isn't necessary to know exactly what class an object belongs to, since many objects share similar behavior. The relationship by which classes obtain some of their behavior from definitions higher up in the class hierarchy is called "inheritance."
The relations among some important classes are illustrated in Booch Notation (Booch 1991) by Figure 1. In FEDMOD, a class called "ecosystem process" abstracts the idea that the models we use represent the dynamics of a cluster of related features of a terrestrial ecosystem. Reporters service relationships between two models, or between a model and the user's visual system or an on-line file system. They define model outputs without the frequent changes to source code often characteristic of scientific programming. The also can define inputs to other models. The central design decision for this partitioning was to define all the flexible I/O as query operations among collaborating agents. By then associating a query or sequence of queries with an active agent, the reporter, any complexities of timing and message routing are hidden from client models that need the results of queries. The same query mechanism supports graphics routines that display how model states evolve. Once all encapsulated models are defined as ecosystem processes, operations such as queries can take the same form for any model. The rest of the software system was designed to provide a consistent environment to configure these agents and allow their behavior to evolve over time.
A second decision was to maintain the intuitive before-after ordering of time sequences and a metaphor between elapsed execution time and simulated time. This allowed us to be selective about recording sequences of state changes, but it also required the introduction of artificially discrete "events", during which time is synchronized and temporally consistent queries on arbitrary states are possible. For some existing models a fixed fundamental time step is consistent with their design. A clock tick comfortably maps on to a call or iteration of a loop. For other models, once encapsulated, they execute anonymously in between fixed time points when control is returned to the modeling environment.
Ecosystem process, Reporter, and Event are abstract classes that are only instantiated in their derived subclasses. (Thus, no instances or objects of class Ecosystem Process, Reporter, or Event ever exist--just objects of classes that inherit from these classes.) The three classes follow directly from the decisions just described. Several other key classes were needed to manage them in a particular distributed computing system, and to support the metaphor of a physical place or landscape in which these agents interact.
Figure 1. Class Diagram in Booch Notation. Arrows show class inheritance, pointing to the parent class of a class that inherits from another class. Lines with filled circles show which classes contain instances of other classes. Lines with open circles show classes that use other classes to implement their operations or methods.
The Ecosystem Process class captures the common characteristics shared by every ecosystem model in the FEDMOD environment. Some of these include the existence of a special initialization routine or routines, a model step value, which is the length of a distinct simulation time-step for the model, and a way of accessing the model's attribute values. Attributes are the model state variables, input data, and simulation results that the encapsulated model makes available for query. Attributes are defined in consultation with scientists intimately familiar with the model. They include the contents of variables useful to diagnose problems or understand model behavior, as well as variables normally output by the stand-alone model. When the environment is able to create a place in the computer's file system for a model to run, and confirms that the program to be executed is a valid encapsulated model and that the initialization procedure was successful, then the instance of an ecosystem process is said to be alive and ready-to-run. The common behaviors for each encapsulated simulation model are represented as an inheritance from the Ecosystem Process abstract class. Thus an inherited shared definition forms the basis for how simulation models appear in the environment.
Each model is different, in that configuration requirements, required parameters, and simulated attributes are all different. The common behavior and interface definition provided by the abstract class allow these differences to be expressed in consistent ways.
The Reporter class maintains the common characteristics that exist in each type of reporter. Reporters are distinct agents that are responsible for querying the simulation models at a specified reporting frequency and presenting the output in the manner requested. The manner of presentation is a characteristic of the type of reporter. To date, we have identified four types of reporters: Display reporters that provide a continuous graphical output in the specified graph form such as Stripcharts, Scattergrams, or Connected-line graphs; File Reporters that are responsible for dumping the results of the queries into a specified output file; Diagnostic Reporters that query model attributes that might not otherwise be queryable; and Inter-Model Reporters that provide a means of accessing the attribute values of a running model for use in another running model. The common characteristics for each reporter type include the "name" of the attribute that needs to be queried, the Model "instance" to which the attribute belongs, the "steps" which indicates the frequency of reporting, and the "query type" which specifies that either Point Query, Averaged Query, Summed by steps, or Cumulative Summing needs to be performed. An important application of reporters is to show the interactions among model attributes during simulations, using one of the types of Display Reporters.
The Event class provides a generic set of methods used to schedule discrete events. This class maintains the current simulation time value and keeps the system informed when the time value changes (increments, resets, etc.). It provides a "Time" attribute, which reports the current time value, for use by the events that are scheduled by the derived classes of this abstract class. It also contains an internal flag called "Time_Changed", which is set after the scheduling of events has been completed for the current time step. Finally, there are two attributes called "Step" and "StepLen", which save the step-value and step-length parts of the simulation time. The actual simulation time in seconds can be obtained by multiplying the "Step" value by its units ("StepLen"). Splitting simulated time into two attributes helps avoid numerical overflows likely if century long simulations were measured solely in integer seconds. This class also contains access functions to access and update the attributes.
The Event Scheduler class schedules reporters based on the clock step. There is a single instance of this class, the Event Scheduler object, for each ecosystem simulation that is active. As reporter objects are created, they get registered by the Event Scheduler object, which later activates the reporters that need to run at any particular clock step. The Event Scheduler object is driven by the clock object. At each transition of the clock step, the Event Scheduler object checks to see if any reporters need to become active at that step. The Event Scheduler class contains "Add_Reporter" and "Del_Reporter" methods, which respectively register and remove reporters from the Event Scheduler object, a "Reporters2Activate" method that generates a list of reporters to run at a given clock step, and an "Activate_Reporters" function that activates the reporters from the list created by the Reporters2Activate method. A singly linked linear list is used to store the list of reports.
The Clock class maintains the overall simulation time information. When a clock object is created, it negotiates a meaningful clock step based on all the model and reporter interval steps. To avoid arithmetic overflow, the simulation time is represented by a value part and a step-length part. The units for step-length are seconds. The clock object is responsible for broadcasting the new time after each clock increment, to each model that is being simulated. There is a provision to introduce a user-specified delay between each clock increment. This delay can be specified through the user interface, and is useful when the simulation speed needs to be slowed down in order to study the results that are continuously displayed by the display reporters.
A system clock and facilities for scheduling events are a normal part of a high-level simulation language. We have re-created them for use with existing simulation models, written in procedural languages.
The Message Server class provides a means of communication between model processes and reporters. There are two levels of communication:
The Execution Shell class creates model processes, starts up a clock instance and an Event Scheduler instance, registers reporter objects to the Event Scheduler object, communicates with the GUI, and ensures that all the models are synchronized with respect to the clock object. It represents the overall simulation arena or framework.
An instance of the RPC Server should always be running in the background on any compute server (remote host machine) supporting FEMOD. This server contains the messaging functions that enable communication between a GUI and the part of simulation environment where the models are run. In addition to a master server that routes requests from remote machines, each scientist using the FEDMOD environment starts up a server process using their own account. This user process then handles authentication of remote requests and owns all of the simulation processes and files created while running that person's simulations. By distributing the environment in this way, the graphical interface (GUI) can be run locally while the simulations are run remotely on the fastest machine available.
The Graphical User Interface (GUI) is a separate set of programs from the actual models and the classes that manage collaborative computation. This permits the compute-intensive models to be resident on a powerful compute server, and permits the GUI to provide quick response time by running as a local process. The GUI was developed with TAE+ (Szczur and Sheppard 1993), a Motif Interface builder created under contract to NASA. At the top level, the GUI provides the overall management of the modeling session. The definition of overall parameters (e.g., simulation length, spatial extent), choice of specific models for simulation, and run-time control are handled through a menu bar that is visible throughout the simulation session.
Each model has its unique requirements for configuration. Hence, the selection of a model type triggers a model-level panel hierarchy which has been customized for each type of model. Although the parameters are specific to one type of model, much of the code that defines the user interface for each model is shared. Thus, models encapsulated in FEDMOD have a common appearance and it is relatively easy provide interfaces for new models.
In the main panel, one can select the "Models" item from the menu bar. This results in a pull-down menu with "Framework", each of the encapsulated models available, and "Configured Models" as the menu items. Initially, the only accessible choice is Framework, since the global modeling parameters must be specified first. After successfully completing the top-level specification panel, the model-specific menu items become accessible. A particular model can now be selected. Although each model must be selected and configured separately, the researcher is free to select multiple models for a single simulation session, including multiple instances of a particular model. The Configured Models menu selection shows any models have been selected, and their configuration status (e.g., ready-to-run, or awaiting user configuration). Since configuration can start from either default parameters or a previously saved configuration, it is easy to set a series of model instances with similar parameters.
Each type of encapsulated model has a distinct sub-interface consisting of a model-specific main panel and panels for configuring instances of that model and any associated reporters. When a model type is selected, the appropriate sub-interface becomes active. Configuration panels are specialized to provide access to parameters that define how model instances differ when run for different sites or under alternative scenarios. Figure 2 illustrates an initialization panel for the Hybrid v3.4 model (see Friend et al. 1993; Friend et al. in press).
Values entered with the GUI are checked against a series of rules or constraints to insure that they represent part of a valid set of run parameters for this type of model. Rather than being coded into the GUI, these constraint sets are tables that researchers can edit to define more or less restrictive conditions for simulations with a particular model. By selecting among different constraint sets, researchers using the environment could have relatively restrictive, safe choices for routine use or for using unfamiliar models, or permissive environments for testing the limits of familiar models. Where constraints are used define how the GUI looks, for example upper and lower limits for a slider widget, the constraints are supplied each time a new model is selected. Thus, the sub-interface directly reflects how permissive the current rules are. Violations of rules are reported with alert panels that pop up when a violation is detected, but the researcher may chose to ignore the rule by over-riding the warning. Similarly, key-in fields are available to enter values outside the end points of a slider widget or to easily enter specific numerical values that may be awkward to select with a graphical widget.
The present version of FEDMOD has simple constraints on single parameters and pairs of parameters implemented in a generic way. More complex constraints are either handled by custom code for a particular model, or by grouping the parameters in external files that are selectable as parameter sets but not specified individually with the GUI. An important change to improve robustness would be to further consolidate definition of the parameter lists for each model. Multiple copies of these lists embedded within the rule-checking classes and the classes that format parameter files to be read by models are a potential source of maintenance problems. They also increase the effort required to add new models by reducing the fraction of code that can be reused.
After the configuration is defined, selecting "Add Model" from a pull-down menu under the left-most "File" menu bar item generates a request to the Execution Shell to create and initialize an instance of the model using the specified parameters. Success of the Add_Model operation means that the model instance exists and is ready-to-run. A partial configuration will also persist, so the full configuration needn't be completed before starting work setting up other model instances.
Figure 2. Sub-Interface for Hybrid v3.4 with a Configuration Panel.
Under the model-specific panel or sub-interface, reporters are added by selecting the VIEW menu bar item and then the type of reporter in the resulting pull down menu. Based on the type of reporter selected, the GUI requests pertinent information from the user and sends the information to the simulation environment (Execution Shell) through the message server. The Execution Shell then creates the Reporter instances and registers them to the Event Scheduler object (using the Add_Reporter method). Reporters that combine information from different model instances, including different types of models, may be created using the "View" item on the main menu bar.
The simulation has five distinct control commands that initiate changes in the overall state of the simulation environment. The commands are: Run, Halt, Suspend, Resume and Reset, and the four states are: running, halted, suspended and reset. The running state means that simulation computations are underway. The halted state indicates that processing has stopped and cannot readily be restarted from that point. The suspended state represents a paused simulation that preserves a snapshot of the simulation prior to the Suspend command. Normally this is implemented by stopping the clock object and leaving model processes and reporters waiting for the next clock tick (see below). Reporters can be added to a suspended modeling environment, but changes to configured models that might require reinitialization are prohibited. This permits a researcher to add a graphical display or log another state variable to learn more about a phenomenon that has just appeared in the simulation. The Resume command follows a Suspend, and implies that models continue from the snapshot prior to the Suspend. After a Resume, the simulation returns to a running state. The Reset command must act on a suspended simulation and differs from a Resume in that, it disregards the snapshot of the simulation prior to the Suspend and reinitializes the simulation by resetting the clock to the first time step and reinitializing the active models. It then expects a Run or Halt command to advance to the next state.
Once the researcher has specified the model(s) to be simulated and any reporters for the model(s), she uses the Control menu bar item from the main panel to issue the Run command, which starts the simulation. (See Figure 3.) When the GUI routes the Run command to the Execution Shell, the execution shell creates a clock instance, with the clock step being a value negotiated between the step values of all the models and reporters specified. (The negotiated value is the largest integer step length that will insure that all the objects in the environment can be run as often as requested, so sets of step lengths with small greatest common divisors, e.g., 1, should be avoided.)
For each clock increment, the clock object broadcasts the time value to the Event Scheduler object and each of the ecosystem processes. For each clock increment, the Event Scheduler object activates reporters scheduled to run at that time step. The reporters query a states database (see below) for one or more model instances and report back the result in a way characteristic of the type of reporter. After the reporters have been activated, the models evolve to their next states and the states database is updated. Hence at any time step, the reporters query the states database that reflects the stable state for the previous state evolved. In case of display reporters, the results of the reporter queries are continuously plotted on a graph. File reporters log query results to a disk file, and so on. Note that for efficiency reasons, reporters were grouped under a centralized scheduler, whereas model instances are more autonomous--receiving the broadcast time value directly.
Figure 3. Main GUI panel with the Run command selected under Control on the menu bar.
Once the simulation is running, it may be paused at the end of any time step by issuing the Suspend control command. When this command is sent to the simulation environment, the clock object, which constantly polls for the existence of a Suspend control command prior to each clock increment, goes into a wait state. All the processes are thus put to sleep once they complete any on-going calculations. The clock is triggered out of the wait state by the arrival of a Resume control command from the GUI. If a Halt control command is issued instead, then the clock object considers this to be the end of the simulation and broadcasts a special code to all the model processes. The researcher can add or modify reporters while the simulation is in a suspended state, but not model instances.
To encapsulate an existing stand-alone ecosystem model, apart from providing a model-specific GUI and the other services described above, a series of changes are made to the model code itself and to specialize the ecosystem process class to support this type of model. We designed these procedures to be relatively simple and easy to repeat when new model versions are provided by the models' primary authors. They include making some limited changes to the existing model code and providing new code to supply responses to queries and other required behavior.
The stand-alone model is revised so that it can be invoked (started up) by a new external procedure. Thus any main module, which in several languages is the starting point of execution in a program, must be converted to a callable unit, such as a subroutine. The second important change is to prepare the stand-alone model to accept an external time token, which would be used to evolve the model to its next state of simulation. In stand-alone programs, time is often simulated with some kind of an iterative loop, with the maximum clock time signifying the last iteration of main loop. Loops that serve to step the model states through time must be converted to conditional blocks of code that are executed whenever the time token meets certain conditions.
The steps involved in modularizing the stand-alone model are as follows:
The process of preparing the stand-alone model to evolve its states in response to an external clock involves identifying all the clock emulating loops in the stand-alone program, and replacing them by decision structure (IF--END IF) that ensure the correct frequency and timing. For example:
FOR Hour = 1 TO 24 DO : : END DO Figure 4: Pseudo-code representing hourly calculations with a loop. /* Hourly interval in seconds */ IF (Modulus (Clock, 3600) = 0) THEN : : END IF Figure 5: A decision structure representing hourly calculations, for a fixed clock step length of one second.
As implemented, the timing code is slightly more complicated than this, since clock ticks will represent a negotiated step length rather than integer seconds. The divisor in the modulus operation will be calculated from the ratio of the model's intrinsic frequency and the external step length. For example, if the global step length is 3600 seconds (one hour) the clock will be in units of one hour, and a model running at an hourly step will take the modulus of Clock and 24 for daily operations. For code blocks executed once for each call at the requested frequency, the conditional statements can be omitted, assuming the calling frequency is correct. Some care may be required to control execution of sections specifically assigned to the beginning or end of a longer time interval, say the first or last hour of the day.
A Class representing the new model inherits from the abstract class: Ecosystem Process. This new class must encapsulate any specific characteristics of the new ecosystem model. The model interfaces (methods/valid operations) are designed so they are consistent regardless of type of ecosystem model. An important departure from the usual examples of object-oriented software design is that the names of model attributes or state variables are treated as qualifiers to general query methods, rather than supporting a distinct access method for each attribute. Experience has shown that the list of supported attributes is one of the more frequent things to change during model revisions. Authors of ecosystem models often change the formulation of minor processes, altering the way states are partitioned. By treating the attribute name as a modifier to a generic query, we can avoid changes to the model's formal interface, while tracking substantive changes in the underlying model.
The stand-alone ecosystem model could be implemented using any major computer programming language. In order to communicate with its stand-alone code, we needed interlanguage function calls. (The simulation environment is implemented using C++). The bare minimal set of interlanguage functions includes: CInitialize, CAttrCount, CAttrNames and CGetAttr. The CInitialize function invokes the initialization part of the ecosystem code. The CAttrCount function obtains the number of queryable attributes from the ecosystem model, while the CAttrNames function obtains the list of supported attribute names. The CGetAttr function gets the current value of a specified attribute from the states database. All these interlanguage functions are grouped into one location (a file) in order to:
Ideally, for any particular source language for ecosystem models and set of compilers, there should be one definition of the interlanguage calling functions. For historical reasons, FEDMOD has versions associated with each of the main types of model encapsulated to date. We plan to consolidate these when developing a version of the environment to distribute to other researchers.
A model-specific states database is implemented to store the stable state values of the model attributes at the end of each complete time step. The only requirement for the states database is to store the model attribute values in a queryable form. This could be implemented using various data structures. While selecting the data structure, it is important to consider the size of the attribute set, the requirement that it be easily accessible (to read and write) with low execution overhead, and that it needs to be hidden from other parts of the environment to avoid erroneous or accidental changes. If Fortran 90 is being used, we recommend the use of modules (Metcalf 1992) to represent the states database. Along with a states database, we implement access functions that get and set attribute values.
Although it adds some execution overhead, we use string matching on attribute names to resolve accesses to particular attributes. This permits use of generic access methods (one for each of the intrinsic types in use) that are only resolved to specific attributes during execution, even when the language of the original model does not support run-time binding. At present, although access methods are fully generic C++ functions, some dependence on the list of attributes extends through the C++ and interlanguage layers. Restricting dependence on the actual list of attributes to a single module, that would also supply the master list to other procedures, would make this part of the system easier to update and maintain.
The FEDMOD simulation environment enables us to perform simulations of several instances of different models in parallel, with the flexibility to dynamically select which models to run and which attributes to report and display. Models for forest tree population dynamics, soil physics, snow physics, terrestrial biogeochemistry, and physics of canopy thermal regimes have been encapsulated for use in the environment. We have several series of simulation experiments planned or underway, which use intermodel reporters to share information among models from different disciplines. As expected, new models have become progressively easier to encapsulate and include in FEDMOD. Also, we find areas for improvement and as other model authors release new versions, we are able to incorporate them readily--with substantially less effort than the initial model encapsulation.
Experience encapsulating these models has identified parts of the initial design where an even greater emphasis on code reuse and strict object-oriented design would improve the robustness of the FEMOD system. We are also exploring adding routines to support client models using results of queries to scale calculations from internal functions rather than directly using a queried value from the previous time step. Another aspect where work is in progress is in extending the design of the model specification to include spatial extent. With this feature, we would be able to differentiate instances of a model based on their extents and take into account non-trivial spatial overlaps among model instances. Intermodel reporters would then return an appropriately weighted average from all the overlapping instances.
We thank K. Hammond for help in the "Encapsulating a Stand-Alone Model" section of this paper, and D. Kendig for work encapsulating additional models and streamlining the modeling environment. Funding for this work was provided by the Office of Mission to Planet Earth, U.S. National Aeronautics and Space Administration.
Bonan, G.B. (1993) Do biophysics and physiology matter in ecosystem models? Climatic Change 24: 281-285.
Booch, G. (1991) Object Oriented Design with Applications. Redwood City, CA: Benjamin/Cummings.
Bugmann, H. and Martin, P. (1995) How physics and biology matter in forest gap models. Climatic Change 29: 251-257.
Friend, A.D., Shugart, H.H., and Running, S.W. (1993) A physiology-based gap model of forest dynamics. Ecology 74: 792-797.
Friend, A.D., Stevens, A.K., Knox, R.G., and Cannell, M.G.R. A process-based biogeochemical, terrestrial biosphere model of ecosystem dynamics. Ecological Modelling (in press).
Hanninen, H. (1995) Assessing ecological implications of climatic change: Can we rely on our simulation models? Climatic Change 31: 1-4.
Levine, E., Ranson, K.J., Smith, J.A., Williams, D.L., Knox, R.G., Shugart, H.H., Urban, D.L., and Lawrence, W.T. (1993) Forest ecosystem dynamics: linking forest succession, soil process and radiation models. Ecological Modelling 65: 199-219.
Metcalf, M. and Reid, J. (1992) Fortran 90 Explained. New York: Oxford University Press.
Szczur M.R. and Sheppard, S.B. (1993) TAE Plus: Transportable Applications Environment Plus: A User Interface Development Environment. ACM Transactions on Information Systems 11(1): 76-101.
UNIX System Laboratories, Inc. (1990) UNIX SYSTEM V RELEASE 4. Programmers' Guide: Networking Interfaces. Englewood Cliffs, NJ: Prentice Hall.
UNIX System Laboratories, Inc. (1990) UNIX SYSTEM V RELEASE 4. Programmers' Reference Manual. Englewood Cliffs, NJ: Prentice Hall
(a) NASA/Goddard Space Flight Center, Biospheric Sciences Branch, Code 923, Greenbelt, MD 20771
(b) NASA/Goddard Space Flight Center, Laboratory for Terrestrial Physics, Code 920.2, Greenbelt, MD 20771
(c) Hughes STX Corporation, 7701 Greenbelt Rd, Ste.397, Greenbelt, MD 20770
