SORTIE-ND: goals of the re-engineering and overall design

Presented by Charlie Canham.

Re-engineering guidelines

• Software will be open source (with some restrictions)
• Encourage different groups to add new features and behaviors, and share them with the larger community
• Modification of the program will require programming skills

Licensing

Sharing may mean version proliferation. What's the best way to manage this? There must be clearinghouse operations in place, but here funding is an issue. The goal is to make sure that no one profits from the software, and that those who modify it share their modifications back with the community at large.

Long-term plans

• New name for the model, to emphasize neighborhood interactions?
• Open source code with documentation for developers
• Web site for sharing code, data, output, analyses and discussion among research groups

Architecture and user demonstration

Presented by Lora Murphy.
(Note: the previous talk and this talk have been incorporated together to some extent to hopefully combine the best aspects of both.)

Software architecture

Why is the architecture important?

The architecture is important because it helps you use the model better. There are powerful tools available and without an understanding of the underlying model structure you cannot make good use of them. The architecture will also become very important when it is time to customize the model.

Software structure

Previously, the user interface and the core model code were heavily mixed together. This had some advantages, like easily being able to change settings and update data displays, but it had serious disadvantages too. It was difficult to make updates to either the interface or the core without worrying about breaking the other side. Plus, the interface was built using proprietary code from Borland, the company that makes the C++ development environment that we use. This meant that it would be impossible to port the interface to any other platform, such as Unix or Macintosh.

We have separated the user interface from the core model code. Now they communicate with each other only through files. This has allowed us to free our software from proprietary and platform-specific code, which will make it easier to keep it updated and easier to port to other systems. We also are using third-party open-source software tools to do some of the jobs that we used to tackle ourselves. This helps make the software better overall, because we can concentrate on the actual model code.

Objects

The three important types of objects in the model are populations, grids, and behaviors.

Populations

Populations are collections of individuals. A population is responsible for organizing and controlling access to its individuals. For tree individuals, we have defined seven life history stanges: seed, seedling, sapling, adult, snag, woody debris, and stump. The tree population handles the transition between stages.

Grids

Grids store spatially explicit data in rectangular cells. Their values can be static or dynamic. Possible examples include light, topography, drainage, soil chemistry, and small mammal density.

Behaviors

Behaviors perform all the work on the model. A model run is an assembly line of behaviors taking turns accessing and modifying populations and grids. Behaviors control the individual data attributes of the populations and grids.

Each population and grid has a specified set of behaviors that are executed in a specified order in each time step. Indeed, the behaviors are often defined at the individual-type level within the population. For example, for a seed INDIVIDUAL of the tree POPULATION object, the desired behaviors might be:

• dispersal
• seed predation
• germination

And for a soil nutrient availability (GRID) object, there might be one behavior to update current soil nutrient availability in each time step based on the distribution and identity of canopy trees in the neighborhood.

With the new model, it is now possible to change the order of behaviors to some degree.

Making changes to the model

In order to make changes to the model, you need someone who knows how or is willing to learn to program. (The relevant languages are C++ and Java.) However, the much more important part of making model updates is careful planning when translating biological processes to code.

Demo

Backwards compatibility

Old SORTIE parameter files (.par), tree map files (.stmf), and harvest regime files (.hvr) are still supported as input. Old output files (.out) can be viewed with the data visualization portion of the code.

Parameter files

Parameter files now function as complete run definitions. The new parameter file format is XML (eXtensible Markup Language). We have incorporated third-party software that specializes in XML to deal with the files.

Output files

There are two kinds of output files: summary output and rundata. Summary output is exactly the same as the old output. It is tab-delimited text identified with a .out extension. Rundata files are in XML format, compressed with GZIP and packaged together with TAR.

The rundata files contain raw run data. It is possible to define the data to be saved at a very fine level, and save it at different timescales.

Data visualization

Data visualization analyzes output files and lets you feed data into different chart types.

Other changes

Coordinate axes are reversed - X is E-W, east positive, and Y is N-S, north positive.

There is no basic grid for which the user need set a grid size.

Discussion

Parameter input

The vision...

• Define the objects and their behaviors (drawing from a menu of choices …)
• Specify the parameter values for each behavior (i.e. coefficients of growth functions for each species)
• Specify initial conditions (initialize all populations and grids)
• Specify any interventions during the course of a run
• Describe the output to be saved for each timestep

The basic style for parameter entry is tabular data entry, with logical parameter grouping. There should be user-selected parameter subsets (database model of access).

The rundata options input screen needs "Select all" and "Clear all" buttons to facilitate entry.

There should be a way to print and save all the parameters entered so you can double-check them. There should also be some way to enter notes to yourself that remain in the output files for later reference.

Data visualization

There should be a way to save, copy to the clipboard, and print the data used to create a particular chart in tabular format so you can export it to other applications - specifically tree maps.