SELES (the Spatially Explicit Landscape Event Simulator) is a model-building and simulation environment that attempts to strike a balance between the flexibility of a programming language that can be used to construct novel models and the ease of applying and parameterizing (estimating the parameters for) existing models (Fall and Fall 2001). Its foundation is a declarative language that lets its users focus on defining the specific needs of landscape modeling and analysis rather than a strictly procedural language that focuses on the details of computer program execution. By providing a language closely adapted to landscape ecology and spatiotemporal modeling, it allows relatively rapid and transparent development of models. For example, models can be written in the form of text files that are loaded directly into SELES rather than imposing the complexity of a conventional software development environment. The underlying assumptions are therefore explicit and not hidden within a black-box program that cannot be examined by anyone other than the programmer, and are not inseparably intertwined with the complicated programming code that performs the actual simulation. SELES models have been successfully applied to support landscape-level forestry decision processes in land-use planning (Fall et al. 2004a; Morgan et al. 2002), the management of natural disturbance (Fall et al. 2004b), and parks planning (Manseau et al. 2002).
The model-development process can be conceptualized using the analogy of car production (Figure 3.2). The overall objectives for a new car (by analogy, the landscape model) are set by marketers and clients (stakeholders). The design is created by engineers (modelers and resource experts) who understand automobile (modeling) capabilities, and the constraints and opportunities imposed by materials and aerodynamics (system knowledge and feasibility thresholds). They combine experience and knowledge with design objectives to create a blueprint (a conceptual model). It is important to note that the designers do not actually build the car, so they do not need to know the details of the implementation tools and technology, but they do need to understand the potential capabilities.
The people who construct the car (build the model) must understand the operation of the factory machines and input resources (model-building tools and input data). They must be capable of understanding a design blueprint and implementing it (starting with prototypes), but do not necessarily need to be able to create designs. They must be able to test the car (the model) by means of test drives to ensure that its implementation matches the blueprint (preliminary model verification). This leads to the first level of iteration, which is performed entirely within the factory by the manufacturer (the modeling research team). Given a product that matches its design specifications, further testing is then required to assess how well its performance matches the design objectives. This may lead to a second level of iteration, indicated by the feedback arrow between designers and developers in Figure 3.1, in which the designers refine any of the blueprints that require updated implementations.
Given a car that matches its specifications (a verified model), a driver (the user of the model) can take the car for a ride (conduct a simulation). The driver does not need to understand the details of the blueprint or the manufacturing process. However, a user guide describing the control features and the consequences of manipulation of the controls is essential, as is an appropriate road map and destination (directions for what scenarios to assess with the model). Some basic knowledge of mechanics (understanding of basic information on modeling) can help the driver (the model user) make minor repairs or modifications and customize the vehicle (the model) in order to make the fullest use of the product and to reduce reliance on the factory workers. Understanding the assumptions that govern the use of the car (the model), such as the fact that the car is not designed to operate in a body of water, is also necessary. For something as familiar as a car, this knowledge is implicit, but for modeling, the knowledge is more abstract and must be taught to the model's users. Dials and other feedback features (progress indicators in the modeling software) provide indicators during a drive and a travel log (model output indicators) provides a long-term record.
Assessing whether the car meets its original objectives will likely require a number of drives under different conditions. Summaries of the travel logs can be analyzed by designers and presented to those who defined the original objectives (stakeholders), completing the third level of iteration.
The key features of this analogy that are relevant to the development of a model are:
• The process is inherently collaborative, with multiple levels of feedback and iteration. Products at one stage are used to refine the objectives (higher-level specifications) for subsequent stages. The feedback emerges through communication between all parties during all stages to ensure that objectives are met and that later stages encapsulate the results of earlier stages.
• No one person performs all modeling tasks. A range of modeling expertise is required for success, particularly for model design (abstraction of reality), model implementation and testing, and model utilization and analysis.
• The process involves multiple levels of abstraction, and people at one level in the process only need to fully understand the aspects of the overall system that are relevant to their level. This helps to reduce the scope of the problems to be addressed during any given stage, and minimizes the level of perceived complexity at any stage.
Modeling tools can be placed along a spectrum from traditional procedural programming languages to fully constructed models (Fall and Fall 2001). Building models directly by programming is akin to constructing a new car without a specialized factory, using generic hardware and tools. On the other hand, using a prebuilt model is akin to using the same car for all types of transportation needs (i.e., fitting the question to the model rather than vice versa). SELES fills a niche by providing a "model-building factory" that facilitates the production of customized models that suit the user's objectives.
LANDIS is a landscape model that simulates spatial forest dynamics, including forest succession, seed dispersal, species establishment, various disturbances, and the interactions among these factors (Gustafson et al. 2000; Mladenoff and He 1999). LANDIS was developed as a research tool to simulate the reciprocal effects of disturbance processes (i.e., fire, wind, vegetation management, insect outbreaks) on patterns of forest vegetation and vice versa across landscapes up to 1 million ha in size and long time scales (50 to 1000 years). Our purpose here is not to describe LANDIS in great detail, but rather to demonstrate the model's power and the complexity of parameterizing and using the model.
LANDIS (v 4.0) uses a raster-based map (i.e., a grid), in which each cell contains information on the presence or absence of a tree species and the 10-year age cohort of that species, but no information about the number or size of the individual stems. Forest succession processes are simulated based on the relative ages of the species found in each cell and on the vital attributes of the species (e.g., shade tolerance, probability of establishment within each land type, longevity, seed dispersal distance). Disturbances remove certain age classes, and the number and characteristics of these classes depend on the severity of the disturbance, which in turn is determined by the characteristics of each cell and in some cases by the characteristics of nearby cells. The number of occurrences and spatial extent of a disturbance are determined by a number of parameters that typically vary as a function of land type. For example, the fire regime for a given land type is defined by the mean size of fires, fuel accumulation rate, and fire-return interval, which is defined as the average number of years required to burn an area equal to the area of the land type on the landscape. Forest management activities are specified by a spatial component (algorithms and spatial zones that determine the order in which stands are selected for treatment), a temporal component that specifies the timing of treatments, and a removal component that specifies which age classes are removed by the treatment. Readers interested in more details of the model should consult Gustafson et al. (2000), He et al. (1999a,b, 2004), He and Mladenoff (1999), Mladenoff and He (1999), Sturtevant et al. (2004a), and Yang et al. (2004).
A powerful attribute of this modeling approach is the feedback between disturbance and species response. For example, windthrow events may alter the species composition relative to sites without windthrow, and will contribute to fuel accumulation on a site, increasing the severity of subsequent fire events. The forest harvest module of LANDIS provides the ability to simulate specific and complex management alternatives, including timber extraction, fuel reduction treatments, and prescribed fires. The interaction of such treatments with natural disturbances and with the dynamics of forest succession produces powerful insights into the complex cumulative effects of specific proposed actions. For example, LANDIS simulations have shown an interaction between ecological land type (defined by land form, soils, and climate), management prescriptions, and initial conditions, and have predicted a highly variable risk of canopy fire in northern Wisconsin, USA (Gustafson et al. 2004; Sturtevant et al. 2004b).
Although LANDIS is a powerful projection tool, it is also quite complicated to use. The model requires input maps that specify the initial forest conditions for each cell of the grid. Preparation of these maps requires sophisticated statistical estimation and mapping techniques (He and Mladenoff 1999). Depending on the species, at least eight vital attributes must be parameterized for each species, and scaling methods are typically used to estimate species establishment coefficients for each land type (He et al. 1999b). At least 15 parameters are required to define the statistical distributions of natural disturbance regimes and fuel accumulation rates for each land type. A new fuel module (He et al. 2004) requires three times as many parameters as previous versions of the model. The sheer volume of the model outputs and the computational demands of the simulations require a fairly powerful desktop computer. For these reasons, LANDIS applications are somewhat intimidating for most land managers.
Was this article helpful?