Chapter 3. User Guide

Overview
Modeling
Perspective
Creating Projects and Models
Menus, Popups and Toolbar
Views
Editor
Default Views
Diagnostic Views
Modeling Tree Editor
Opening the Editor
Structure
Actions
Building
Building Models
Generating Specialized Model Artifacts
Platform Targets
Interfaces
Skeleton
Test Cases
Text Documents
Generate Key Graphics
Function Docs
Executing
Launching a Model (AMF)
Execute
Execute Headless
Execute Headless (Data)
Executing a Model (Java / 3D)
Controlling Models
The Active Model
Views
Properties
Agent Navigator
Model Manager
Visualization
2D Views
3D Views
Graph Views
Charts
Launching Other Targets
Model Parameterization
Syntax
Example
Model Testing
Syntax
Example
Model Data

In this section of the guide, we'll discuss specific aspects of the Agent Modeling tools and show you how to use them in your day to day agent development activities. We discuss only tools specific to Agent Modeling itself. For more general information about the tools, such as how to customize editors, views, and perspectives, see the Workbench User Guide.

Overview

The Agent Modeling Platform provides two general modes or "perspectives" for working with Agent Models.

Agent Modeling supports all aspects of working with models, including editing models and automatically generating all the of your code and documentation. Agent Execution supports running and exploring those models. A key feature of the Agent Modeling Platform is the ability to execute models within the same environment that they are developed within -- you don't need to launch a separate environment in order to run a model. Agent Execution automatically activates when you launch a model. We'll discuss the agent modeling tools first, and then turn to agent execution.

Modeling

Perspective

The Provides a custom layout menus and tools specific to working with agent models. Because the agent modeling process also often involves Java and Eclipse Plugin development we include easy access to many of those tools here as well.

Creating Projects and Models

You can create projects and project components using the Popup menu. Just click in a blank space within the Package Explorer. Any installed project targets are displayed in this menu. For example, if you've installed the Simphony target, you'd see that displayed in this menu as well.

Menus, Popups and Toolbar

The popup menus and application menus provide access to various model features and are context sensitive. Throughout these screenshots, we've customized the toolbar in order to only show the agent Modeling specific features.

Views

By default the workbench includes a number of views. See the Workbench documentation for more details on how they can be customized accessed and used.

Editor

This is not technically a view in itself. It is the major focus of the workbench and contains any edit models or other files such as Java source or parameters.

Default Views

The default modeling views are visible by default.

Package Explorer

Supports navigation within projects.

Properties

The properties allows you to view and edit specific details for the currently selected object. For example, if you select a model context, you'll be able to edit its attributes here.

Outline

The outline view supports easy navigation within the edited files. See the model editing sections for more on how the outline can be used to assist exploration of Agent Models.

Diagnostic Views

There are a number of views that can be used to explore issues that might come up during the modeling process. You can see them on the lower left-hand corner of the screenshot above. Click on one of the icons to view their contents.

Problems

This view is one that you'll become very familiar with. It is used to display specific about problems with any of the artifacts (files) in your modeling project. If you see a red or yellow marker on a file, opening the view will present a list of the issues that are currently being reported. For a usage example, please see the Tutorial.

Console

This view displays text (console) output for appropriate processes. For example, if you launch an Ascape project, this will display any output that would go to the Java console.

Errors

This is another view that you will find valuable in your day to day modeling activities. The error log lists everything important that happens during model execution. It's the first place to look if something mysterious goes wrong, and when you report problems it's always helpful to include anything that could be relevant in the log. Despite its name, the Errors view is not just for reporting errors -- it is also used to report progress on normal operations. For example, when models are automatically generated that is reported to the log, as we can see in the following example:

Modeling Tree Editor

The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models include textual languages and custom editors that are part of commercial offerings.

Opening the Editor

To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using Open With > Other... and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll discuss at the end of this section.

Structure

The model is composed of nodes representing specific model entities such as agents, actions and spaces. For details about any of these entities, see the Concepts section.

Opening Components

After opening a model, you can see the contents by clicking the Triangle symbol to the left of an item. For example, opening the root context node, we see:

Creating Components

You add nodes by right-clicking on a node, like so:

Editing Components

To edit components, select the node you want to modify. The Properties View will be updated with the agent details. Use the properties view to modify the values. In the screenshot below, we're editing the values for the City space.

Moving Components

You can often rearrange model components by dragging them from one place to another. In the following example, we're creating a model of a regional epidemic by creating a City sub-context and moving the agent into it:

Removing Components

You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entity still exist.

Copying Components

To make a copy of an entity and place it in a new location, option-drag the entity to the destination. You can make a copy in the existing location by dragging it into the same parent. The name will automatically be updated with "copy" appended to it.

Editing Attributes

The attributes node -- along with the actions and styles nodes -- represents a group of components rather than an entity itself. It contains all of the attributes for the parent agent or context. In the examples below, we can see the attributes for the Epidemic route model. Note that the top level attributes in a root context act as the parameters for the model itself.

Editing Styles

The Styles node is another group node, in this case representing a set of styles that can be used to visualize the agents. When creating a style, you will need to create a Rule for each style as well, like so:

Actions

Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying structure of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.

Like attributes and styles, every agent has a single Actions nodes which contains its Root Action(s).

Creating Actions

You create actions as with any other component, by right-clicking on the source action and choosing the new action. The menu is organized by usage.

Editing Actions

Actions and their inputs are edited just like any other model component. Click on the action or input you want to edit and then make changes to it in the properties editor.

Order

Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that the order of the nodes does not indicate a specific source and target relationship. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part of the label.

In the above example, the Initialize Location "Initialize Action" is straightforward. We simply define a Select Action, a Query Action target for that selection, and then a Move Action target for the query. The "Transmission" Rule is more complicated. Note for example that the "Infectious" Union Action is the target of both the "Asymptomatic Infectious" and "Symptomatic Infectious" Query Actions. The "Vulnerable Neighbor" action has the label "Vulnerable Neighbor [Potential Exposure] <- [Potential Exposure]" indicating that the "Potential Exposure" action serves as its selection as well as its source.

Initial Order

A new action's initial target will be the action that you clicked on when creating it. For an action that should always act within a given root action (i.e. Rule, Schedule, etc..), add it to the root action. A root action can have more than one target.

Changing Sources and Targets (Reordering)

An action's target can be changed by dragging it over the new target action. Note that this is a different behavior from that of standard entity movement. You cannot make an action a target of an action that is itself a source of the modified action! (See the concepts section for why.) Using the default tree editor you cannot change an action's targets directly; instead select the action's target and move that.

Adding Sources and Targets

As discussed earlier, actions often have multiple sources and targets. To make an action the target of an additional action, click on target action, hold down the control key, and drag the action to its new destination. See the tutorial for a complete example.

Removing Sources and Targets

You cannot remove single sources from targets directly using the tree editor. Instead, first drag the agent to a source nodes that will be part of its changed set of sources. That will remove all existing actions sources but for the one you have just dragged it to. Then add back any of the other source and target nodes you wish to retain.

Removing Actions

You can remove actions in the same way as with structural model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from high in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.

Copying Actions

Copying actions works just as with other entities, and copies will become targets of their option-drag destination.

Query and Evaluation Inputs

The number of inputs is determined by the selected functions. (In rare cases where a function can take an arbitrary number of arguments you may need to create additional values or delete existing ones.) In the following example, we're picking the Symptom Infectious status for a query that will affect the potentially exposed agents. Note that is instead you wanted to compare another kind of value -- for example an Integer value -- you would need to change the first input listed before changing the second input so that you will be able to get the appropriate options for the second.

Input Literals

To create an input value, right click on the input and select Create Member > Literal. Then specify the actual value in the Value property in the Properties View.

Building

Building Models

If you've used other development environments, you're probably used to a separate build step. For example, if you edit a set of Java files, you might invoke a compile command. Eclipse and the Agent Modeling Platform support automatic building. This means that in order to build your code, you simply save the model and the environment takes care of the rest. What gets built is defined by the project. For example, if you save a model that is contained within an Agent Modeling Escape Project, the following steps occur automatically:

  1. The Escape builder generates Java code for the Escape API, including support for specialized graphics and (if enabled) 3D visualization.

  2. The Documentation builder generates custom html documentation for the model.

  3. The Java builder takes the Java code generated above and compiles it.

  4. The Manifest and Schema builders package the project for use as part of the Eclipse plugin environment.

So what do you do if you want to generate code for a different target, such as Repast? Here, you simply create another project and drag the model into it. You can also edit the builders for a given project (see the Workbench Documentation) but you'll only want to do that if you're making permanent changes to the project itself.

Generating Specialized Model Artifacts

You can also manually generate code for models. This is useful if you want to create code for a model in a non target project and don't want the automatic build capabilities. There are also specialized targets that can be generated manually that are bundled with the tools -- AMP plugin developers can easily add custom generation targets for this menu. To generate custom artifacts, right-click on a model and select Generate.

Targets include:

Platform Targets

Creates code for one of the installed targets, such as Ascape, Escape, and Simphony. (Again, these generators are unnecessary for projects that already have target specific builders configured.)

Interfaces

Creates a complete set of interfaces for the model classes. These can be very useful for development and integration in enterprise environments. Generated classes are placed in the src directory with "I" added to the name. For example, if you generate interfaces for a model with an "Individual" agent, this target will create an "IIndividual" interface that includes getters, setters and methods for all of the agent's attributes and actions.

Skeleton

Creates a base class for the model. This is essentially a complete implementation, but without the action implementations. Again, these classes can be useful when generating code for use in enterprise and other specialized environments.

Test Cases

Generates base support (needing customization) test cases for use in JUnit tests.

Text Documents

Creates simple text documentation for use in other documents.

Generate Key Graphics

This specialized target supports the creation of graphic keys for the model. To use this target:

  1. Generate the code.

  2. Add a dependency to the Manifest for "org.eclipse.amp.amf.gen.extras".

  3. In the srcutil directory find the Java source code for the calss {RootContext}GraphicsWriter. For example, for the Epidemic model, this would be srcutil/name.milesparker.epi/EpidemicGraphicsWriter.java.

  4. Right-click, and select Run As > Java Application.

  5. Refresh the project by right-clicking on it and selecting Refresh.

  6. The Doc directory will now contain a number of new files, including

    1. {RootContext}Key.png

    2. {RootContext}GraphicsKey.html

Both files contain graphic representations of the model using the definitions defined by the model styles, very useful artifacts for inclusion in papers and web pages describing your model. For example, here is the EpidemicKey.png:

Function Docs

Generates WikiText documentation for function libraries. We use it to create the function documentation in this guide!

Executing

Launching a Model (AMF)

Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar.
If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)

One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.

The execution options are:

Execute

Launches the model using default graphics, opening the Agent Execution perspective.

Execute Headless

Launches the model without graphics, opening the Agent Execution perspective.

Execute Headless (Data)

Launches the model with an observer that collects data into the AMF adata model representation.

Executing a Model (Java / 3D)

You can execute any Escape model directly from its Java file by right-clicking on it. This is used for models that have been written directly in Java, or that you have created or that have been automatically generated, such as the 3D versions of AMF models. In order for the model to launch correctly, it must have as a superclass the Escape "Scape" class. In the following screenshot, we've launched a 3D version of the Epidemic model. The 3D models are automatically generated for all .metaabm models. You can also launch a model into 3D by clicking on the model file and clicking the second (Execute Model with 3D) execute button.

Controlling Models

Once a model has been launched, the toolbar buttons allow you to control model execution.

Model Execution Controls

From right to left, you can start, restart, pause, step, stop and close a model. You can even run multiple models and control them independently. You can also move views around, close them and so on as with any other Eclipse views. Here we're running two separate models for comparison.

Speed Slider

A special feature of the modeling tools is the "Speed Slider". This allows you to dynamically "speed up" and "slow down" the model execution. You can see where you've set the current speed in the status bar in the lower left hand corner of the environment.

Actually, you're not controlling the speed of model execution at all. Agent models are almost always constrained not by the time of model execution -- a typical model can execute many thousands of iterations a second -- but by the time it takes to draw visualizations. By updating the views less frequently we allow the model to run at full speed until the next visualization period. This gives the illusion that we're speeding up the model. When we slow the model down, we're inserting a wait period between each model iteration.

To increase model execution speed, move the slider to the right. Here we're only updating the model every 56 iterations.

To decrease speed, move the slider to the left. Here, we're pausing between each iteration for 1.65 seconds.

The Active Model

An important concept in the execution workbench is the "active model". The active model is the model that is controlled by the toolbar buttons. As discussed, the Escape environment supports more than one running model at any given time. The active model is the current "focused" or front-most model, there can be only one active model at any given time and whenever any models are running one of them will be active. To make a model become the active model, you simply select a view of that model or select the model in the model manager (see below). When a model is closed, another model is automatically activated.

Views

There are many views specific to the Agent Execution environment that will enable you to explore and control running models.

Properties

If you want to find out more about an agent, show the properties view, and click on agent in the 2D view or any other views that support agent selection such as the tree view.

You can experiment with different parameters (settings) for models by then clicking on the model in the Model Manager or by selecting a general mode area such as the gray area enclosing the 2D view.

Agent Navigator

The Agent Navigator allows you to select agents from a tree view. The agent selection is coordinated across views so that for example when you select an agent in the navigator it is also selected in the 2D view. In the following screenshot you can see an agent selected in both views as well as the properties editor.

Model Manager

The 'Model Manager' allows you to examine and control the status of all running models. In the following screenshot, we've launched four separate models so that we can compare the typical model state at different periods.

The manager shows that two of the models are running and two are paused. By opening the model node, we can see the views that are currently being displayed. Note that we mean something different by "Views" in this context. Here "Views" are any thing that is monitoring the state of a running model. A view may not have a graphical component at all.

You can make any model the current active model by clicking on its node in this view.

"About this Model"

The 'About this Model' view displays information about a (AMF or Java based) model if it has been provided by the developer. In order to appear in this dialog, create a file named "About[MyModel].html" where "MyModel" is the model's Scape Class Name (not the AMF model file name). The file should be placed in a "res" source folder in the model project directory in a parallel directory path to the root scape's Java class package. For example, an about file for a model defined by the scape "edu.brook.norms.Norms" should be placed at "res/edu/brook/norms/AboutNorms.html". The file should be an html fragment -- that is, without body and head tags -- and can include any valid html tags, including links.

Visualization

The Agent Modeling Environment is designed to support many kinds of 2D or 3D visualization. AMP includes the following views for generated models. The Escape API supports a number of additional visualization to support Ascape models that aren't shown here. Look at the example org.ascape.escape.models.examples and org.ascape.escape.models.brook for examples of those.

2D Views

The Graphic 2D view is the most common view way to work with an Agent Model and is automatically generated and displayed for executing models.

There are a number of view widgets in the upper-right hand corner that you can use to modify the view. You can:

Scaling
  1. Enter or select a specific scale in the combo menu.

  2. Select a button to have the model scale either:

    1. Freely

    2. Within the bounds of the view

    3. Within the vertical bounds of the view

    4. Within the horizontal bounds of the view

  3. Zoom In

  4. Zoom Out

3D Views

The 3D views provide a three-dimensional representation of a running model. Currently they support 2D models only, which makes them 2 1/2 D views.

You can navigate and customize the model with the following controls:

From left to right, they are:

Animation

Turns on and off the interpolated (smooth) movement of agents from one cell to another. This is a unique feature of AMP and provides a very nice visualization, but it does slow down model execution. For very large models, you can switch it off -- visualization will be "jerky" but much quicker.

Perspectives

The three perspectives are used to control the camera location -- in other words the perspective from which the movie is being made. Note that if the camera is currently moving to a given perspective and you select a new perspective the camera may become confused! It is best to wait until the camera comes to a stop before choosing a different perspective. You can speed up camera movement by pausing the model temporarily.

First Person

Moves the point of view to ground level, as if the observer were in the space itself.

Overhead

Moves the point of view to overhead, giving a similar view as you have with the 2D view. Note that in many cases the 3D view is actually faster than the 2D view, so this is a good way to observe any kind of 2D model.

Helicopter

Moves the point to an oblique perspective. This is useful for getting an overall sense of model behavior.

Graph Views

Graph views allow you to undestand the network relationships between various agents in the model. By default, a graph is creaed for all relationships, but you can customize that behavior programmatically. Graphs are also super-imposed on 2D models, as we can see in the following example running the EpidemicContact model.

Note that complex models can take a long time to visualize and we'll be looking for opportuntites to optimize performance further in the future. If you think the visualization is stuck it is likely that it is simply calculating the next visualization step -- wait a bit before canceling the model or closing it.

Graph views can be customized with the following controls:

From left to right, they are:

Layout

The layout buttons control how the nodes are placed within the graph. You can swithc between layout dynamically to gain insight into network relationships.

Tree (Down): Places the graph nodes into a downward oriented tree formation. You'll find that the tree views are more effecient at visualizing, and can be very ood at representing models with an inherent hierarchical structure such as kinship diagrams, but don't always give the best insight into the model for complex network relations. Tree (Right): The same tree layout oriented from the root-most nodes rightward.
Radial: Places the nodes in a radial layout with the root-most nodes at the center. This is a great way to represent semi-hierarchical models with complex structure, but is a little slower than the tree layouts. Spring: This layout uses a spring and strain approach that allows nodes to find their own location within the visualization. It can provide beautiful and insightful diagrams, but it is also slower than the other layouts. For more complex models it often works well to use the radial layout and then switch to the Spring layout when examining relationships in depth.
Spring Layout Customization

You can customize how the Spring by clicking on the customization button. This allows you to change a number of values that determine how nodes are layed out. While the default settings work well with many graph structures it can be helpful (and fun) to play with different settings to get the best visualization. |

Charts

A Chart view is automatically created and displayed for executing models. It can display aggregate values for any of the agent attributes you have set the "gather data" value to true for. Charts can be easily modified. While the built-in view is not meant to be the sole tool for Escape model data analysis, it provides an easy to use and powerful way to explore models interactively. The Chart view widgets allow you to modify the chart with the click of a button.

Chart Type

Several chart types are supported: The line, area, bar and pie chart. Click on one of the icons to select that type.

Line Area
Bar Pie
Chart Legend

Turn the legend on and off by selecting the "T" icon.

Chart Data

To select the statistics to display, show the Chart Customizer view. When the customizer has been selected, select a chart to customize. The customizer presents the possible choices in a 2D format. On one axis are the attributes that have data being collected, and on the other are the measurements collected on those axes, i.e. Count, Minimum, Maximum, Variance, Standard Deviation, Sum and Average. To clear all selections, click the Gray "X" button.

There are a number of other things to play around with, such as zooming the agent view or selecting other chart series to display using the Chart Customizer, so just explore. You can always close an active model by clicking on the close toolbar button. Or if you can't access the models controls for some reason, you can open the progress view and close projects form there.

Launching Other Targets

To execute applications for other targets such as Ascape or Simphony, just right-click on the metaabm model, select Run As.. and pick the target you want to launch. In the example below, we're launching Ascape from within an ..ascape project.

The external tool you've selected will then open into a separate Java application.

Note: remember that the menu options are active regardless of whether the target is actually supported within a given project. If you attempt to Run (external targets) or Execute (internal targets) models from a project that does not support that target you will get an error!

Model Parameterization

Escape provides full support for parameterization of models. This allows you to create many sets of parameters for a given model, allowing you to decouple model runtime settings from the model itself. (Support for parameter sweeps is forthcoming.) To create a new parameterization, right-click in the location you want to create the parameter file, and select New > Parameters File.

In the wizard that follows, give your parameter file a name:

The edit the file. See below for file syntax. The parameter editor has built-in support for code-completion, syntax high-lighting and other editor features.

In the example below, we've created two separate parameter files for the epidemic model with different values for contact transmission probability.

As with other runnable files, you can launch a parameter file simply by selecting execute in the popup menu, application menu or toolbar.

Syntax

Parameter files are quite simple. Every parameter file specifies the "model" that will be executed.The "incorporates" keyword supports including parameter values from other files. File locations are relative to the location of the parameter file, but it is usually more flexible to refer to model files relative to their project location. You can do that by inserting a "|" character at the beginning of the file name.

Attribute values are specified by the attribute ID (with the first character in upper-case) followed by "=" and the desired value.

Example

We can create a base parameters file called "EpiBase.apar".

model "|Epidemic.metaabm"
StopPeriod=500

This means that we expect the Epidemic.metaabm model to be at the root of the project, and we want the model to stop at period 500. Then -- in this overly simple example -- we could create two other files, EpiHighTransmission.apar:

model "|Epidemic.metaabm"
incorporates "EpiBase.apar"
MinContactTransmissionProbability=0.05
MaxContactTransmissionProbability=0.2

and EpiLowTransmission.apar:

model "|Epidemic.metaabm"
incorporates "EpiBase.apar"
MinContactTransmissionProbability=0.0
MaxContactTransmissionProbability=0.15

Both of which reference the base set of parameters we've just defined and add run specific variables. Note that the incorporates reference is a parameter file relative reference so that we can easily move the set of parameter files to any location we want. With these two files defined we can click on both of them at once, select the Execute button and immediately compare the two values. (Not shown.)

Model Testing

One of the most important and over-looked aspects of modeling is verification. Very loosely speaking, model validation is the process of determining whether a model matches up to the "real world". Model verification is the process of determining whether your model specification matches up to the model you've actually implemented. In other words, does the model do what you say it does?

To help you answer this important question, the modeling tools include unique support for an approach to validation and verification called "unit testing". A thorough discussion is far beyond the scope of this manual, but this guide should give you enough information to get testing your own models. Testing might seem tedious ut its actually a real time saver, because you can quickly run a set of tests to ensure that you a new model change hasn't broken existing functionality. This peace of mind is priceless, and once you start testing, you won't know how you lived without it!

To create a new test, right-click at the location you want to put the test files. (Not shown.) Then we can edit the test file using the syntax shown below. It's helpful to keep them organized in sets of folders. To execute a test or set of tests, simply select the test files and click "Test Once" or "Test 5 times" to run a set of identical tests. The latter is useful for stochastic tests in which tests may create significantly different results for the same random seeds. (We'll provide more options in a future release.) If you select an entire folder, the framework will run all of the tests in the folder. This process is very similar to that for parameter files, so we won't show it here.

Once a test is complete, an "ares" file is created in the "test-results" folder. To see how your tests faired, open the .ares file. For the example test file below, we should see something like this:

Notice that we can view the expected values and where our results actually fall.

Syntax

Test files are also pretty simple. It's a good idea to provide a description of the test so you can understand why you created it and what feature you're testing. Just put quote characters around your description. Then, use the "tests" keyword to specify what parameter file you'll be using. Again you can use file or project relative references. You don not specify a model here -- that's defined by the parameter file. You can use the "contains" keyword just like the incorporates keyword for parameter files, to specify a set of test constraints that you want to include with the new tests you've defined. This is useful for including a series of "sanity checks" with other tests. Then you specify the test constraints themselves. This uses the following form:

{Measure}({TestedAttribute}) = [{MinimumConstraint}, {MaximumConstraint}]

The measures available are Average, Minimum, Maximum Count and Sum. In order for an attribute to be tested the "gather data" value must be set for that attribute. All Measures are not appropriate for all attribute types. Booleans, Symbols and States should only use the Count measure as they represent discrete values that can either meet some condition or not.

The tested attributes are qualified by their model agent definition. The constraint definition is inclusive, as implied by the square brackets. Future implementations are expected to provide richer expressions and constraints but a very wide range of cases are supported by this construct, especially when combined with derived attributes. Tested Attributes are again specified by the attribute ID (with the first character in upper-case) followed by "=" and the desired value.

Example

In the following simple example we want to make sure that an epidemic can't occur without disease transmission taking place. Here we're just looking to make sure that we have some very basic logic right. (This might be almost too simple for a real-world design, depending on how rigorous we want to be.) Note that some individuals are infected at the beginning of the model run so we need to account for that in our expected results. So first we have defined the EpiZeroTransmission.apar file like the other transmission rate parameterizations above except with these settings:

MinContactTransmissionProbability=0.0
MaxContactTransmissionProbability=0.0

Then we define our ZeroTransmission.atest file:

"Test that no disease transmission occurs with contact transmission set to 0."
tests "|params/EpiZeroTransmission.apar"
Count(Individual.Status=Dead) = [0,5]
Count(Individual.Status=Exposed) = [0,10]
Count(Individual.Status=SymptomInfectious)=[0,0]

Here we have a nice description, a reference to the parameterization we want to use, and then the set of constraints we will apply to them. After running this test, a test result file like the one above will be created and placed in our "test-results" directory.

Model Data

As discussed above, you can collect data for any model by selecting it or a paramters file and clicking the "Execute Model with data collection" button. If you use a parameters file setting the StopPeriod parameter will cause the model to stop executing and save the model at the specified time. Or you can stop the model manually. The model data will be collected into an "adata" file and stored in the "output" directory in your project. A new run entry will be created for each execution of a model. We are currently developing tools for exporting this data to various file formats as well as providing more seemless integration to sophisticated Eclipse hosted charting and report tools. You can use BIRT to interact with the data set using an XML schema data source and there is also an Ecore driver available. Model data can also be produced by writing custom views for data output. See the Ascape programmer guide for more information on how to do that.