To extend our knowledge beyond experimentally tractable short-term physics and physiology to the long-term responses of whole terrestrial ecosystems, researchers construct process-oriented simulation models.
 
Some tested computer applications of limited scope and predictive ability are already in regular use for ecological forecasting and enviromental management.  For many purposes, though, we are still at an earlier stage, using computational systems to research how to model ecology.   Good research models can demonstrate the effects of "what if" assumptions and hypotheses and help frame further questions, which will lead to better models and eventually to tested applications for routine use.

What makes good ecological modeling so difficult, and what makes the building of computational systems to further this goal such a challenge as well, is that ecosystems are immensely complex.  They include millions of entities-living species, chemical compounds, forms and fluxes of energy-and innumerable interactions among these factors.  Ecological modeling always becomes an exercise in simplification and approximation.  What must we include?  What can we leave out?
 

Different scientific disciplines studying ecosystems emphasize different structures, details, and theories in their models.  When approaching questions that cross disciplines, it is seldom clear at the outset whether detail central to the approach of one discipline (such as soil physics) is important to dynamic responses of the ecosystem as studied by another discipline (such as plant physiology).  However, including all the latest theories and potentially important details in a single model would make that model intractable for analysis, and the comprehensive data required would rarely even be available.  Moreover, if a complex ecological model simultaneously embodied untested theoretical innovations from several disciplines, assessing the validity of any one of them would be difficult.
 
To help overcome these obstacles, we have developed a problem-solving environment for linking models and performing coupled simulations, called a Workbench for Interactive Simulation of Ecosystems (WISE). WISE lets a researcher selectively test the effect of supplying to a model from one discipline, the complex behavior believed to be important by experts in another discipline. Visualization tools and on-demand logging of results to files let the researcher both see the possible effect and perform further analysis of the results.

If testing with the coupled models (see side-bar ) shows that a particluar simulated  effect is important, then  representing it on a routine basis becomes a research problem for the model's author--just as if experimental work or new theoretical developments within her discipline suggested the change. WISE adds to the dialog between disciplines by providing an avenue for transferring insights among them. This approach is part of an ongoing project, an outgrowth of research into combining models from different disciplines and of applying concepts from object-oriented software design to the reuse of ecological simulation models.^3,4

There is no single accepted approach to coupling complex models. Some have taken the stance that already complex models are likely to become intractable when coupled to each other. Nonetheless, there are viable tactics for selectively coupling models  to study or include particular effects as shown in Figure A.

One strategy (case 1) is to use one model, say "Model B", as a source of data to estimate the parameters of some function to be embedded in Model A, a model to be changed or improved.  Here the role of the model is similar to ecological field data that need to be approximated as a function of other variables. Similarly, in a modeling environment, Model B could provide simulated states or boundary conditions dynamically to Model A (case 2). This resembles providing Model A with a time series of observations. In both cases 1 and 2, Model B may be able to provide information for a broader range of circumstances than available observations can.

In ecosystem modeling, once detail about a subsystem has proved important for answering a question, the usual approach has been to then imbed some version of Model B in Model A (case 3). This approach is valuable if the models are theoretically compatible, if the models have appropriately nesting representations of time and space, and if the resulting enhanced Model A remains tractable for analysis and use.

Two-way dynamic coupling of  separate models can address the situation (case 4)  when detail that is important to one scientific discipline affects the answers to questions asked by another. With the proper simulation environment, sufficiently short time steps, and attention to error propagation and the dynamical consequences of the coupling, models which may or may not be theoretically, temporally, or spatially compatible can be coupled to answer specific questions.

. 

Developing the System Requirements

When determining what we wanted WISE to be able to do and how, we had to consider the application domain, several issues of overall architecture, and the user's need for effective visualization.

Domain Requirements
 
WISE is designed to simultaneously run a variety of ecological models, or multiple instances of a particular model, for a specified simulation period.  We achieved this by creating a coupling mechanism which allows any model instance to query another model instance dynamically for the most recent values of its state variables. For example, a soil model could be linked to a model of canopy growth with minimal effort, and then the  canopy model could use the reported soil conditions to improve its calculations.

Because WISE is a research tool, we  designed  it for flexibility.  For instance,  models using various time steps need to run simultaneously: an hourly model might need to run in tandem with a daily model.  Moreover, we wanted to be sure that scientists could test their hypotheses by modifying the internals of the model.  With such a feature, a compiled 'microversion' of the original could then be executed using the existing interface.

A user interface that gives a common look and feel across disparate models was critical to hiding the inherent complexity of a multi-model application., especially since each model type has its own unique set-up parameters, constraints, and input files.   Shared data visualization tools were also needed to provide dynamic displays for monitoring selected attributes during a simulation run.

A simple encapsulation process for running a legacy model  within the appplication minimizes the chances of introducing new software errors in the model. Furthermore, as researchers release new versions  and revisions of their models throughout most development projects, updates must be easily incorporated, or the application will fall behind the ecological state of the art.  Our encapsulated model hides implementation details but allows access to the model's state variables, which are needed for visualization and inter-model exchanges, as well as for testing  predictions and behavior.

WISE was also designed to allow multiple levels of human expertise/interaction with models, including canned configurations to help learn how to use the models and PSE, while retaining flexibility for the expert.

Architecture Requirements

The first issue in designing the system's architecture was careful management of computer resources.   Often simulation modeling is very CPU intensive, especially when many models are running simultaneously.  Input and output files can be very large and require large amounts of disk space.  Therefore, the system had to efficiently scale up to large simulations.

Complex configurations of models might run for hours or days on a single researcher's problem, implying a need for a multi-user environment.  We addressed the need by creating seperate workspaces for each researcher and maintaining them with proper user authentication.

Interprocess communication is essential since the models need to be able to exchange data.   In WISE, actions to be taken by an object are requested by event-driven communications,  and synchronized message passing is used to exchange deterministic results between processes.

Finally, we wanted  WISE to be easily portable.  We enhanced portability  by isolating language-dependent extensions and system level access and avoiding proprietary software packages.
 

Visualization Requirements

We wanted WISE  to provide both real-time feedback with the ability to track the evolution of a quantity in time, and a facility for postprocessing of numerical results from the simulation.   Given the massive amounts of data generated by the encapsulated models, that meant we needed both visual displays and utilities for generating data files.

WISE includes a time-filtering option was designed to compare results from models running at different time steps. For example, when running an hourly model and a daily model simultaneously,  a researcher may wish to compare the average daily value of attributes from the hourly model with the daily model. 
In some cases, she may want to compare several configurations of a model type or the effect different instances have on an attribute. Multimodel reports allow easy comparison of attributes from different model instances to be compared easily. In addition, some specialized 'smart' graphics reporters get the information they need directly from particular models, without burdening the simulation manager with this task.

Software Design

We selected an object-oriented approach⁵ to maximize the code reuse as new models were added, as well as to minimize the encapsulation time. Each encapsulated model inherits its behavior from a base class, which enforces a common interface between all model types. Therefore, as the design evolves, modifications only need to be made to the base class. The model is modified only to the extent of encapsulation into the model base class.

To distribute heavy processing, graphical display, and need for disk storage to the most appropriate computers, we chose a client-server architecture.   Collaborating computers pass set-up files and results using remote procedure calls.  Figure 1 displays an overview of the major components of the design and their interactions.

Figure 1. Context diagram of WISE displaying major client and server entities. Directional information flows are indicated by arrows.  

Select here to view larger image.

Model processes needed to report state information to other coupled models or for visualization. We achieved this using message queues  for interprocess communication on the same host. An IPC message queue class was written to hide message passing complexities.

The Standard Template Library⁶ is used in WISE as an important tool for storing and managing various objectsand object types, without adding, significant development costs.

Graphical User Interface

The domain requirements for ease of use lead naturally to a graphical user interface (GUI) as a means of interacting with the computing environment. A client-server implementation allows the models to execute on a powerful compute server while maintaining the fast response of a local GUI. While the power of the system lies in its ability to support a wide variety of models, the GUI design must extract the issues shared by all models and present a common interface to the researcher.
 
The basic tasks which must be done for a simulation are:
        (1) select model(s),
        (2) set up or configure model(s),
        (3) set up reports for desired model results, and
        (4) interact with the simulation itself.

The tasks are the same for all models, although the options available for configuration and reports are model-specific. This was addressed by a tiered design which distinguishes between simulation level and model level options. The main window, which remains visible throughout the simulation, provides an overview of the system options, system status, and access to simulation control (run, suspend, resume, reset, and halt). The Motif-style menu bar offers the options of File, View, Models, Control and Help. Selection of a model invokes a similar window, the model-main window. The menu bar presents the options of File, View, Configure, and Help (Figure 2). Then, these common top level menu choices cascade to model specific options.

Figure 2. A sample model configuration panel with soil data selected from a list of soil profiles and initial conditions set for one soil layer.  

Select here to view larger image.

Simulation level menus. A new simulation begins from the File menu.  This is a fresh start with no models selected, and the user enters certain simulation-level information via a pop-up window.   Alternatively, Open option restores a previously saved state of configured models and reports.  This feature is very powerful:  we can save and restore a complex array of models and reports with a single user operation. This is valuable not only as a time-saver, but also for reliable duplication of results and a method of documenting a special multimodel system configurations.  Save and Save as are available at any time in the simulation to save the current workspace information. This menu also provides an Exit from the simulation environment.

The researcher sets up multimodel reports are set up through the View menu,  which displays a list of  configured models.  Selecting a model  invokes that model's specific attribute selection list, as well as the report selection options detailed later.

The model menu lists all the available types of models and provides access to microversions via a remote file selection box, which includes files on the computing server rather than the local machine. When a model or microversion has been selected, a model main window appears. One "model"  that must be selected is the Framework.  Its role is special: it provides  the simulation-wide settings which define the context for the rest of the models. The Framework requires a valid user identifier on the computing server which permits user authentication and file ownership for the simulation.

The Control  menu includes the  Run, Suspend, Resume, Reset, and Halt which are passed to the computing server for control of the simulation. Reports may be added during a suspended state.

Model level menus. These file menu options include the steps needed to prepare a model for simulation. The GUI helps the researcher sequence through the steps properly by controlling the sensitivity of the menu options. For a new model, the first choice is a model configuration. The GUI helps the researcher sequence through steps properly by controlling the sensitivity of the menu options.  The Standard option yields a safe setting of model parameters: Open option allows the user to select a set of alternate parameters (saved from a previous work session).  In either case, the user can display and change the associated parameter values  from the configuration menu.  Choosing Add Model adds an instance of this model to the GUI's  internal list, and initiate the steps needed to run it. The first step is to validate the parameter settings against model-specific constraints. If the configuration is flagged as invalid, the GUI will still keep track of the model but not complete the operation. If all is well, the GUI will create a model initializtion file is created in a model-specific format and passed to the simulation manager.  Save and  Save As  options allow the configuration and reports information to be saved to a disk file for later use.

Adding a model instance to the simulation (that is, creating and initializing a simulation process for that model and configuration), enables the 'View' menu where the researcher may specify runtime reports such as disk files and stripcharts.  Selecting a reporter type triggers a sequential display of dialog boxes that cue for reporting time interval, attribute selection, and time filtering option. These windows are generic, but the attribute list will be different for each model type and the level of reporting varies among models. For instance, a soil model may have simulation level attributes and attributes for discrete soil layers. A dialog box will prompt for any additional information needed.

Every model has configurable items, but a simple model may only have a few which are grouped into one initialization window, while a more complex model may have many items organized into several categories. In both cases the selection of the Configuration menu item cascades to a list of that model's configuration windows. Selection of a configuration menu item displays a window showing the current settings of the parameters included under that heading. These items may then be altered interactively Figure 2.

GUI implementation. The GUI development itself was simplified by the use of TAE+, an interface builder originally funded by NASA⁷. This tool is built on top of Motif, and the run-time libraries are freely distributable, allowing the application code to run on any Motif compliant platform. TAE+ allows interactive widget layout which is perfect for rapid prototyping of the windows before doing any coding. This permits a fast validation cycle with the model author for model-specific configuration windows.

Minimal coding effort is required to add a new model to the GUI by the use of shared event handlers. While the number of configurable items varies among models, the type of items does not. A relatively small set of widgets handles the existing models, and every instance of a given widget uses the same event handler.

The most complex task associated with running a model is its proper is configurating it properly.  Since the GUI  supports diverse models, we decided to hide most model-specific information from it by developing a configuration tool class as a back end to the GUI. The model-specific configuration tool behaves as a database, with the added responsibilities of constraint checking and creation of a model initialization parameters.  The configuration class accesses these constraints from an external table as a set of rules about the parameters for a model, allowing revision of constraints without having to rebuild the tool set.   A reference to the set of constraints to enforce is part of each configuration.  Each configuration tool is a separate process which exists for the duration of the work session, and uses a unique message queue for communication on a per model instance basis. This scheme makes it easy to keep track of many models and multiple configurations per model type, and greatly simplifies the GUI design.

One goal of the GUI is to make the complex model configuration process accessible to people who are not completely familiar with the model. The organization of the configuration windows aids this by organizing the parameters in a logical manner (e.g., all parameters dealing with a particular subsystem would be grouped together in a separate window). Each model is provided with a default, or safe, configuration which may be changed interactively through the configuration windows. Simultaneously, the GUI maintains a dialog with the configuration tool, apprising it of the current values, and receiving notice of any constraint violations. If someone enters a value for a parameter that is known to be outside its physical limits, a warning will appear in a separate window allowing the user to undo or edit the offending item.

Managing the Computations

An RPC daemon is used to handle incoming client calls from multiple users. A second user specific daemon process is used to maintain distinct work spaces for each user. This process then becomes the parent of subsequent processes that are required to conduct the simulation as shown in Figure 1.

Simulation manager. This process controls all model and reporting instances. Initially, it creates a work area for each model instance and instanciates each model and reporter request. The simulation manager includes three classes of reporters for reporting specific state information for a particular model instance at specified intervals.  File reporters write attribute values out to a file for possible postprocessing. Display reporters use visualization tools to display their values. Intermodel reporters are used to link models. A model instance may query an intermodel reporter to obtain data from another model. Intermodel reporters are unique in that they are not initiated through the GUI but by a configured model instance.

The manager contains a clock object that accesses a list of all configured models and reporters. When a run command is issued, the clock negotiates the optimal clock step size based on the various step sizes of the configured models and reporters. The clock broadcasts a step and step size to each model and reporter object. Each of these objects determines if it is appropriate for them to act on this particular clock step. Then the clock checks the message queues for any requests from models for sharing attribute values betweens models.  After receiving acknowledgments from all the models, the clock advances to the next step.

The researcher may suspend the simulation at the end of any clock step in order to add reporters or examine model output in detail. If a display is no longer needed, the user can delete the stripchart and its reporter.  Creating and deleting of stripcharts on the fly can be very useful as a diagnostic tool. There is also provision via the GUI to introduce a delay between clock steps to pace output for easier comprehension.

Encapsulated models.  Generally coded in Fortran, authors encapsulate their models into WISE by the following steps. The model is modified to become re-entrant. subroutine which may be called at each time step.  All loops with time related indices are replaced with conditional blocks based on the clock step. Procedural calls then are added to update attribute values in the states database. These calls are coded in Fortran 90 to allow for polymorphism based on attribute type. The model is compiled with a Fortan 90 compiler and linked to a C++ layer which supplies the model class constructs. Models in other languages could use the same model class but would require new interlanguage calls. The model class enforces common behavior between all models and contains the repository of model attributes that are available for external queries from reporters. Finally a configuration tool for the GUI must be created. The amount of effort required to encapsulate the model varies widely, depending on the complexity of the model and its initial inputs, but typically these steps can be achieved with a few days of effort.

WISE allows the researcher the flexibility to create variants of the default encapsulated model. These microversions are different in the sense that the researcher provides an absolute path to them at initialization. They may also differ from the default model in the attributes available, the algorithms used for particular ecosystem processes, or in coupling to other models via intermodel queries.

Visualization Tools

Each model manages its own list of attributes, or reportable state variables. A user can request this list from the GUI dynamically at runtime, when each attribute is available at runtime, when each attribute  is available for reporting in several forms.  Generating a reporter request formalizes the selection of one or several attributes for feedback.  Each request is sent to the simulation manager, which creates a reporter to gather the information from the appropriate models at runtime.  The GUI provides a sequence of pop-up windows to help the researcher request a reporter with the desired reporting options, including attribute selection and time filters.  The selected attributes may be written to a disk file for postprocessing offline, or reported live graphically as the simulation runs. We concentrated development effort on the stripchart, which permits simultaneous display of multiple attributes on a common scale, and scrolls over time. However, the object-oriented design of the graphics software permits the adding of more visual display types with little effort. The stripchart can be used by all models, but more sophisticated graphics displays may be available, depending on the model.  For instance, the Dynamic Layers graphics program reads model state variables from a many-layered soil physics model called FroST.  The variables are used  to generate a time series display of the soil layers as shown in Figure 3. This graphics program is generically useful for models which employ a similar spatial structure, but is not applicable to all models.

Figure 3. Snow, water, and ice content for simulated soil layers during the spring thaw of 1994. 

Select here to view larger image.

The reports are sent to the simulation manager as they are requested. This allows the user to customize the look of the display prior to runtime. Options for both the stripchart and the Dynamic Layers display include adjusting scaling in the data axis (vertical), selecting color for all components of the window, and defining line attributes for the stripchart (color, width and style).  While these may also be changed during the simulation-a pause button allows  for a momentary cessation of data handling-it is convenient to set things up beforehand as much as possible.

Finally, this implementation will permit the eventual inclusion of 3D graphics using OpenGL by taking advantage of the ability to use OpenGL calls to drive a drawing area widget under Motif.

The PSE at work: A Case Study

Using WISE, we showed that the dynamics of soil ice in a complex soil model can be important to the timing and amount of transpiration of water by forest trees simulated for cold boreal regions (such as much of Alaska, Canada, and Siberia). For example, simulations for a site in Maine, USA, near the southern boreal forest boundary, show marked effects of soil ice in some years and not others. We simulated this with the FroST  soil physics model  and a vegetation model, Hybrid in coupled and uncoupled modes.

The FroST simulation model estimates several values of interest to soil scientists, such as water content, matric potential, temperature, and ice content within each soil horizon⁸. FroST uses network analysis to describe heat and moisture transfer, and accounts for short-wave and long-wave radiative transfer, changes in energy status, surface runoff, infiltration, redistribution, drainage, evaporation, transpiration, Penman demand, and snow. Daily input requirements include global short-wave radiation, maximum and minimum air temperatures, average wind speed, precipitation, and lower boundary soil temperature and water. Soil profile, site and canopy characteristics are also needed. FroST is unique in that it simulates soil moisture and temperature flux at a greater level of detail, and canopy processes at a more simplified level of detail than most ecosystem models.

Hybrid is a numerical biogeochemical model of terrestrial ecosystem dynamics⁹ with features including fully coupled carbon, water, and nutrient cycles within the soil-plant-atmosphere system; drivers and constraints for climate, nitrogen deposition, and atmospheric CO₂ and O₂; and both transient and equilibrium responses to climate change.

Hybrid uses a flexible subdaily time step for cycling and exchange of carbon, nitrogen, and water, and for growth of grass. Individual tree growth occurs on an annual time step. Individual trees and grass compete for light, water, and nitrogen within a patch or "plot" resulting in smaller plants being shaded by larger ones, and larger plants taking up more of the available water and nitrogen. The soil is represented as three layers with a simple daily hydrological budget. Decomposition is calculated using an empirical sub-model.

In the first months of 1994, early winter snows were light in east-central Maine and soils froze to a substantial depth. Simulated latent heat fluxes from instances of Hybrid running alone and coupled to FroST were similar for much of the winter of 1994. However, during the spring thaw, the coupled model showed evaporation being restricted by soil ice (see Figure 4, in which evaporation is proportional to the latent heat flux shown).  In contrast, the Hybrid-only run showed more soil moisture being lost to respiration during the thaw.

A consequence of this discrepancy, is that months later in the simulation, Hybrid running alone predicted drought in August and September 1994, whereas the coupled model (with its carry-over of winter precipitation in the form of soil ice) showed sufficient soil moisture for plant growth during the  whole summer season. The stand-alone Hybrid simulation lost carbon (a measure of vegetation productivity), while the coupled model had a positive balance for 1994 despite below-average rainfall.   Because of these findings and similar results for other boreal ecosystems, we are exploring ways including the effects of soil ice in global simulations with Hybrid.

Figure 4. Heat flux associated with evaporation during the time when the upper soil layers first thaw sufficiently to support transport of soil water by roots and transpiration of water by leaves (blue line), in the vegetation model (Hybrid) coupled with the soil physics model (FroST). Daytime transpiration in the uncoupled vegetation model is well underway (white line).  

Select here to view larger image.

 This case study demonstrates one of many effects that can be explored and characterized with WISE that would be difficult to study with less flexible approaches to coupling complex ecological models. By allowing these sorts of modeling experiments, WISE can contribute to better understanding of ecosystem dynamics and help lead to more informed choices about the management of ecosystems and global change.  The WISE problem-solving environment  could also be adapted for research on other types of complex,  heterogeneous systems in other disciplines.

The six-year-old WISE development project is made up of a small team of scientists and engineers that has varied between two and five people.  WISE runs on Sun architectures, specifically Berkeley and System V.  Client software is also compatible with HP-Unix, and porting to other Unix platforms should be possible with modest effort.  The models vary in size and complexity but are typically a few thousand lines of code each.  More information on WISE and each of the models can be found at our Web site at http://fedwww.gsfc.nasa.gov.

Acknowledgments

Jon Ranson and Darrel Williams developed the multidisciplinary research effort in forest ecosystem dynamics that provided the impetus for this work. Among the other individuals who contributed significant time, advice, or ecological models were: William Bidlake, Uday Bindingnavle, Steve Fifer, Andrew Friend, Kevin Hammond, Rachel Jordan, Lara Prihodko, Hank Shugart, Jim Smith, Dean Urban, and John Weishampel. This research was supported by NASA's Office of Mission to Planet Earth.

References

1. P.M. Vitousek, "Beyond global warming - ecology and global change," Ecology, Vol. 75, No. 7, October 1994, pp. 1861-1876.

2. E.B. Rastetter, "Validating models of ecosystem response to global change," BioScience, Vol., No. 3, March 1996, pp. 190-198.

3. E.R. Levine et al., "Forest ecosystem dynamics: linking forest succession, soil process and radiation models," Ecological Modelling, Vol 65, No. 3-4, February 1993, pp. 199-219.

4. R.G.Knox et al., "A framework for integrating environmental models to simulate forest ecosystem dynamics," Third International Conference/Workshop on Integrating GIS and Environmental Modeling, (CD-ROM), National Center for Geographic Information and Analysis, Univ. of California, Santa Barbara, CA., 1996.

5. G. Booch, Object-Oriented Analysis and Design with Applications, Second Edition, Benjamin/Cummings Publishing, Redwood City, CA, 1994.

6. D.R. Musser and A. Saini, STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library, Addison-Wesley, Reading, MA, 1996.

7. M.R. Szczur and S.B. Sheppard, "TAE Plus: Transportable Applications Environment Plus: A User Interface Development Environment," ACM Transactions on Information Systems, Vol. 11, No. 1, Jan., 1993, pp. 76-101.

8. E.R. Levine and R.G. Knox, "Modeling Soil Temperature and Snow Dynamics in Northern Forests," Journal of Geophysical Research, Atmospheres, In press 9. A.D. Friend et al., "A process-based, biogeochemical, terrestrial biosphere model of ecosystem dynamics (Hybrid v3.0)," Ecological Modelling, 95:249-287.

9. A.D. Friend et al.,  "A Process-Based, Biogeochemical, Terrestrial Biosphere Model of Ecosystem Dynamics (Hybrid v3.0), " Ecological Modeling, Vol. 95, 1997, pp. 249-287.
 

Biographical sketches

Dr. Robert G. (Bob) Knox is a Co-PI on the FED project. His responsibilities combine research in forest community and ecosystem ecology with design of models and statistical analyses. He is the primary person responsible for the FED modeling environment and is actively involved in spatial heterogeneity studies and scaling from individual plants and habitat patches to ecosystems. His work continues the study of ecosystem constraints on vegetation dynamics and feedbacks among vegetation dynamics, soil processes, and forest structural properties, especially consumer/resource interactions. Collaborating with other investigators, he is developing appropriate statistical and graphical analyses of spatial and temporal patterns in data from field sites and of comparable data simulated by FED models. Dr. Knox joined the Biospheric Sciences Branch in 1991. Research for his doctorate in botany emphasized statistical ecology methods for problems in forest population dynamics and community composition. He has participated in long-term studies of forest demography in North Carolina and southeast Texas. Dr. Knox is also a PI for a BOREAS effort that emphasizes modeling carbon and water flux from boreal forest canopies.

Virginia Kalb is a Co-I, and has the primary responsibility for the development of the graphical user interface, designed in close cooperation with the end-user scientists. Her knowledge of UNIX and client-server programming are also be useful in the analysis phase of the modeling environment software development cycle. She has already written custom X Windows/Motif software to provide a variety of realtime graphical feedback from the models. She continue to explore new ways to visualize the model dynamics for both model testing and for insight into the multivariate data space of ecological modeling. She has a BA and MA in mathematics from the University of Maryland at College Park and is currently working on her Ph.D in Applied Mathematics.

David Kendig is an employee of Hughes STX. He joined the Forest and Ecosystem Dynamics Modeling (FEDM) in late 1995 and supplies programming support to Dr. R. Knox and Dr. E. Levine on the FEDM project. This involves on going systems analysis and design of a system of computer programs for the multidiscipline, interactive modeling of forest ecosystems. Previously, he was operations manager of the EGRET instrument onboard the Compton Gamma Ray Observatory. David has an MS in Computer Science from John's Hopkins (1996) and a BS in Astronomy from The Pennsylvania State University (1983).

Dr. Elissa R. Levine has been a Co-PI in the FED program since 1987, and has primary responsibility for the design, testing, and implementation of the soil models. Dr. Levine has been a Soil Scientist in the Biospheric Sciences Branch since 1986, a coinvestigator and staff scientist for NASA's BOREAS project, and a PI on the GLOBE (Global Learning and Observation to Benefit the Envrionment) environmental education project. Dr. Levine received her B.S. degree in Natural Resource Management from Kansas State University, and M.S. and Ph.D. (1984) from Penn State in Agronomy (Soil Genesis and Morphology). A Workbench for Interactive Simulation of Ecosystems (WISE), ver. 2, submitted June 27,1997 R.G.Knox, V.L.Kalb, D.J.Kendig, E.R.Levine