Updaet docs with new automated build.
diff --git a/documentation/ModelersGuide.html b/documentation/ModelersGuide.html
deleted file mode 100644
index d0a8d93..0000000
--- a/documentation/ModelersGuide.html
+++ /dev/null
@@ -1,598 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-</head>
-<body>
-<h1 id="Introduction">Introduction</h1>
-<p>In this section of the documentation we'll provide an in-depth understanding of what goes into an Agent Model and
-how you can use the Agent Modeling Framework tools to design them. Fundamentally, an agent-based model, or "ABM", is
-composed of five pieces: Agents and Context Agents, Actions, Attributes, Spaces and Styles. We'll describe each
-component in depth. But first a generic concept:</p>
-<h1 id="General">General</h1>
-<h2 id="Descriptions">Descriptions</h2>
-<p>Everything represented in an Acore model needs to be referred to in some way. Just as software classes have
-names, Acore provides a way to label and describe every entity, but in a richer and more maintainable way. All entities
-in Acore define:</p>
-<h5 id="Label">Label</h5>
-<p>A reasonably short, human readable name for the agent. For example, "Timber Wolf", "Forex Trader" or "Movement
-Probability". These should be defined so that they fit in well with auto-generated documentation.</p>
-<h5 id="ID">ID</h5>
-<p>An ID is an identifier that can be used to represent the object in a software program. This means that it must
-follow certain rules such as no-spaces or non alpha-numeric characters. The editing tools will help make sure that this
-value is legal. Note that when you enter a label, a legal ID is automatically created for you! Usually you won't need to
-change this, but you might if for example you want the value to match up with some database or other external
-representation. So reasonable values here might be "timberWolf" or perhaps "MVMNT_PRB" if say you're trying to match up
-to some old statistics records you have. (Note that currently IDs by default use "camel case", i.e.
-"thisIsAnExampleOfCamelCase" to match with Java variable naming conventions, but this is likely to change.)</p>
-<p>And most entities also define:</p>
-<h5 id="Description">Description</h5>
-<p>A complete textual description of the object. Don't overlook this -- it is the most important part of your model.
-The description will show up in your auto-generated html documentation, software documentation and even in your running
-model. You should include enough information that model users will understand what the entity is for and what it does
-without referring elsewhere. This is also where any attributions and references should go. You can put html tags in here
--- such as href's to external papers, but keep those to a minimum as they won't be rendered as html in all contexts.</p>
-<h5 id="Plural_Label">Plural Label</h5>
-<p>The plural representation of an entity. This can be a surprisingly useful thing to have in generated
-documentation and software code, so it's worth maintaining. The editor will automatically add an "s" at the end of the
-label you've entered above, but you change it to whatever is appropriate. For example "Person", or "Timber Wolves".</p>
-<h1 id="Structure">Structure</h1>
-<h2 id="Agents">Agents</h2>
-<p>An Agent is simply a software object that has autonomous behavior and (generally speaking) exists within some set
-of spaces. By autonomous, we mean that agents make the choice about when and how to execute a behavior, as opposed to
-have that controlled from "above", so to speak. Like any software objects, agents have attributes (fields) and actions
-(methods) associated with them.</p>
-<h3 id="Context_Agents_.28Contexts.29">Context Agents (Contexts)</h3>
-<p>Agents also form the basic structural component of an agent-based model. Unlike the approach of a traditional
-Object Oriented environment, the dominant organizing principal for agents within AMF follows a compositional
-hierarchical model, not an inheritance model. (Inheritance-like behavior will be supported in forthcoming versions of
-Acore, but in a more sophisticated, flexible and dynamic way than is supported by traditional programming languages such
-as Java.) Contexts -- also referred to as "Swarms" or "Scapes", are simply Agents that are capable of containing other
-agents. With this basic construct -- known as a Composition in design pattern language -- agents are able to contain
-other agents. To get an idea for how this works, have a look at the "EpidemicRegional.metaabm" model. Note that in
-future releases, we will probably refer to Contexts as "Scapes".</p>
-<h2 id="Attributes">Attributes</h2>
-<p>Agents need some way to represent their internal state. For example, an agent in an economic model might have a
-wealth attribute, and an agent in an ecology model might have a quantity of food and a particular vision range. These
-states are represented as attributes just as all software objects do. In an agent model, we keep richer information
-about these attributes and generally represent them at a higher level. For example, rather than specify that a real
-value is a "double", a "float" or a "big number", we represent them as "Reals" so that they can be implemented and
-tested in different environments. This might allow us for instance to ensure that a model's behavior is not dependent on
-a particular machine implementation of floating point arithmetic. Also, note that attributes only represent so-called
-"primitive" values -- that is, actual measurable features of a particular agent but not an agent's relationship to other
-agents or objects. See the discussion about networks for more on this key topic.</p>
-<p>Here are the basic types of attributes available in Acore models:</p>
-<h3 id="Basic_Attributes">Basic Attributes</h3>
-<p>Attributes are single values that a given agent contains. For example, an agent might have an "Age" attribute.
-Attributes have descriptions of course, and they also have:</p>
-<h5 id="Type">Type</h5>
-<p>These can be anyone of the following:</p>
-<table border="1" cellpadding="10" cellspacing="0">
- <tr>
- <td>Boolean</td>
- <td>A value that is simply true or false. Note that unless this value really is a simple binary value, you
- should consider using state instead. (See details below.) For example, rather than representing gender as a
- 'Female' boolean value, define a 'Gender' state with values 'Male' and "Female'. Generated artifacts and
- documentation will be much clearer, and you'll be able to easily modify the model later if for example you
- discover that there are more than two potential gender categories that are relevant to your model.</td>
- </tr>
- <tr>
- <td>Integer</td>
- <td>A discrete whole number value, such as "100", "-1", "10029920". It's generally a good idea to represent
- any value that can never have a decimal value as an integer.</td>
- </tr>
- <tr>
- <td>Real</td>
- <td>A continuous number value. While these are typically represented in software as floating point numbers,
- they can conceivably represent numbers at any arbitrary precision and in any scheme. Note that while technically
- speaking we should be representing irrational numbers, this is not currently supported for default values and
- users should simply use the closest decimal approximation.</td>
- </tr>
- <tr>
- <td>Symbol</td>
- <td>A string representing some state. More precisely, a computationally arbitrary value with contextual
- meaning. This could be any kind of identifier. For example, you might use it to store some kind of input coding
- from data that is then converted into an object state. Or it could simply be an agent's name. But theoretically
- (though this is not currently supported) one could imagine a symbol using an idiogram, an icon or even a sound
- that identifies or represents the agent in question.</td>
- </tr>
-</table>
-<p>(Undefined and Numeric types should not be used within a well-defined model.)</p>
-<h5 id="Default_Value">Default Value</h5>
-<p>The value that should be assigned to the attribute at the beginning of any model run. The attribute may of course
-be assigned a different value in an Initialize rule, but its a good idea to specify one here. It's OK to leave it blank,
-in which case a sensible 'empty' value will be assigned, i.e. false for Boolean, 0 for Integers and Reals, and an empty
-string for Symbol.</p>
-<h5 id="Gather_Data">Gather Data</h5>
-<p>Here you can specify whether executing models should collect aggregate values for the data. For example, if you
-select this value as true for a 'Wealth' attribute, Escape will automatically keep track of minimum, maximum, average,
-sum and optionally standard deviation and variance across all agents for each model execution period. All of these
-statistics will then be selectable with a mouse click to appear in your model charts at runtime.</p>
-<h5 id="Immutable">Immutable</h5>
-<p>This value indicates whether you expect the model value to change. If you know that it won't or shouldn't, this
-value should be true.</p>
-<h5 id="Units">Units</h5>
-<p>Specifies what the attribute is actually measuring. For example, if you're defining an attribute for "Wealth" in
-the context of a model of the world economy, you might specify "USD". If you're defining "Age", you might specify
-"Years", for "Mass" "Kg". Like description, this value is often overlooked, but can be critically important to allowing
-yourself and others to understand and correctly calibrate a model. Note that this will also allow you to simplify
-variable names -- instead of using "Age in Years", you can simply specify "Age" and the appropriate unit. It may be
-obvious to you that your model is concerned with age in years, but a user who needs to specify a different granularity
-will be grateful for more clarity.</p>
-<h3 id="Arrays">Arrays</h3>
-<p>Arrays are simply attributes with zero or more entries. For example, you might have an array of three Real
-numbers representing the Red Green and Blue color components for an object. Note that if you find yourself defining very
-complex sets of arrays, its likely that what you really want to define is a new agent with attributes for each array. In
-addition to whatis defined above, arrays specify:</p>
-<h5 id="Size">Size</h5>
-<p>The number of values that the array attribute will contain.</p>
-<h3 id="States">States</h3>
-<p>States represent any agent quality that may take on one of a number of well defined values. For example, an "Ice
-Cream Consumer" Agent might contain a state of "Ice Cream Preference" with options of "Chocolate", "Vanilla" and
-"Ginger".</p>
-<h4 id="State_Options">State Options</h4>
-<p>Create new options for states by adding them to the state node. States are simple described items. Don't forget
-to provide a description! States also have</p>
-<h5 id="Default_Option">Default Option</h5>
-<p>unlike for regular attributes, this option is not optional! Simply pick a state option to be assigned that the
-agent will take if no other option has been assigned.</p>
-<h2 id="Spaces">Spaces</h2>
-<p>All contexts can contain spaces. Spaces provide an environment in which agents can have a physical or notional
-location and upon which they can interact with one another and their environment. Agents can exist in more than one
-space at a time, and a given agent need not exist in every space. (Note that this is different from the Repast Simphony
-notion of projections, though the two representational approaches are generally compatible.) Agents need not represent
-explicit, "real" spatial structures such as a landscape, though this is of course the most common use. They can also
-represent relational and state information, such as a belief space or a social network. There are four kinds of space
-represented:</p>
-<h3 id="Space_.28Continuous.29">Space (Continuous)</h3>
-<p>In the modeling tools, we simply refer to this as a "Space" as it is represents the general concept of a space. A
-space is simply something that contains objects with certain locations and extents and has a certain number of
-dimensions. The space is continuous, in the sense that objects can be placed anywhere with arbitrary position. Spaces
-hold attributes, which simply define their dimensions-- see below.</p>
-<h5 id="Border_Rule">Border Rule</h5>
-<p>A value representing what happens to an agent when that agent is asked to move beyond its extent.</p>
-<table border="1" cellpadding="10" cellspacing="0">
- <tr>
- <td>Periodic</td>
- <td>When encountering an edge, the agent will treat the space as wrapping around to the other side of the
- space. For example, if the agent at location <a href="1,2">1,2</a> (0-based) within a Moore space (see grid
- discussion below) of size <a href="10,10">10,10</a> is asked to find some other agent within distance 3, the
- agent look in the square defined between <a href="8,9">8,9</a> and <a href="4,5">4,5</a>. An agent asked to move
- beyond the confines of the space will simply stop when it reaches the edge. You can imagine this as taking a
- piece of graph paper and connecting the opposite edges. You can't actually do that with paper, but if you could
- you would have a toroidal (donut) shape in three dimensions defining the shape in two.</td>
- </tr>
- <tr>
- <td>APeriodic</td>
- <td>When encountering an edge, the agent treats it as the edge of the space. For example, if the agent at
- location <a href="1,2">1,2</a> is asked to find some other agent within distance 3, the agent look between <a
- href="0,0">0,0</a> and <a href="4,5">4,5</a>. An agent asked to move beyond the confines of the space will
- simply stop when it reaches the edge.</td>
- </tr>
-</table>
-<p>The "Strict" and "Bouncy" values are obsolete and should not be used.</p>
-<h5 id="Dimensionality">Dimensionality</h5>
-<p>The number of dimensions that the space has. After selecting a dimensionality, attributes will be added to
-represent each dimension. For example, if you enter 3 here, you will have an attrbiute for X, Y, and Z. Be sure to enter
-default values here, as they will be used to specify the actual size of the space.</p>
-<h3 id="Grid">Grid</h3>
-<p>A grid is technically a regular lattice structure. Currently, only rectilinear strcutures are supported, i.e. a
-One-dimensional vector, a two-dimensional grid, a three-dimensional cube and so on. (Though none of the current target
-platfroms support n-d spaces yet.)</p>
-<p>Like continuous spaces, a grid has a border rule and dimensionality. A grid has a couple of other important
-values:</p>
-<h5 id="Multi-Occupant">Multi-Occupant</h5>
-<p>Does the grid allow more than one agent to occupy it at a time? This value can usually be ignored and will likely
-be deprecated in future releases.</p>
-<h5 id="Neighborhood">Neighborhood</h5>
-<p>This value determines what constitutes a region within a particular distance from the agent. The value for this
-is often ciritical in obtaining particular behavior from a model, and shouldn't be overlooked. There are three possible
-values:</p>
-<table border="1" cellpadding="10" cellspacing="0">
- <tr>
- <td>Euclidian</td>
- <td>The distance between any two cells is taken to be the "real" distance. For example, if an agent was
- within a chess board, and we wanted to find all agents within distance three of it, we could determine that by
- taking a string of length 3, tacking it to the center of the source square, and including all cells whose
- centers we can reach with the other string end. Note that although Euclidian space may seem the most reasonable
- neighborhood configuration to choose, this really isn't the case. Euclidian space is continuous whereas grid
- space is discrete, and mapping the two to each other can create unexpected issues. Still, this is a good choice
- for models representing notionally real spaces.</td>
- </tr>
- <tr>
- <td>Moore</td>
- <td>Here, the distance between any two cells is defined by the number of edge <i>or</i> corner adjacent
- cells crossed to get between them. To continue the chess board analaogy, this is the set of moves that a king
- can make. Note that this does not map well to real space at all, as a cell at distance 1 in a moore space is at
- distance sqrt(2) in "real" space.</td>
- </tr>
- <tr>
- <td>Von-Neumann</td>
- <td>Here, the distance between any two cells is defined by the number of edge adjacent cells crossed to get
- between them. This is the set of moves that a rook might make on a chess board -- if a rook could only move one
- square at a time.</td>
- </tr>
-</table>
-<h3 id="Network">Network</h3>
-<p>A network represents a set of relationships between agents, in a graph structure. The concept is pretty simple,
-but note that a network is actually a critical part of many AMF models. This is because we use networks to represent any
-kind of references between agents. You may have noticed in the discussion about attributes that there is no generic
-"object" type for an attribute. In fact, attributes only contain primitive values. So we will use networks to do the
-kinds of things that we would often use object references for in a traditional Object-Oriented model. For example, if an
-agent is a member of a family, rather than have that agent have a member attribute of "family" with a reference to the
-"Family" object, the modeler would create a "Family Members" network and connect agent's to their families as
-appropriate. This implies that network members can contain members of many different types.</p>
-<p>A network has only one value to specify:</p>
-<h5 id="Directed">Directed</h5>
-<p>This indicates whether connections between agents are one-way or two-way. If this value is false, then if a
-connection is made between an agent A and an agent B, and agent B searches within distance 1, agent B will find agent A.
-If this value is true, agent A can find agent B, but agent B can not find agent A. (Unless of course some other path
-leads B to A.)</p>
-<h3 id="Geography">Geography</h3>
-<p>A geography represents a physical landscape. Here we assume that that landscape is going to be defined by an
-external data source and representational scheme -- typically a Geographical Information System. We'll describe how to
-work with GIS in more detail when we discuss builder actions.</p>
-<h2 id="Reference">Reference</h2>
-<h3 id="Diagrams">Diagrams</h3>
-<p>For readers familiar with UML and meta-modeling, the following diagrams give more detail on the structural
-design.</p>
-<h4 id="Meta-Classes">Meta-Classes</h4>
-<p>Our first diagram depicts the core structural design of the model.</p>
-<p><img border="0" src="image/StructureComplexDiagram.png" /></p>
-<pre>There seems to be a lot going on here, but the basic components are pretty straightforward as we can see in the next diagram.
-</pre>
-<h4 id="Key_Collaborations">Key Collaborations</h4>
-<p><img border="0" src="image/StructureSimpleDiagram.png" /></p>
-<pre>Core interactions are in Red. The meta-model structure is essentially a Composite pattern.
-</pre>
-<h4 id="Details">Details</h4>
-<ol>
- <li>Every model has at its root a Context (Scape). Contexts are Agents that are capable of containing other
- Agents (including other contexts, naturally).</li>
- <li>(Meta-level) Contexts contain (meta-level) Agents at the model (design-time) level. At runtime,
- (model-level) Context instances defined in a (meta-level) SContext will contain (model-level) agent instances of the
- defined (meta-level) SAgent. This sounds more complicated than it is, so let's look at a simple example. Suppose we
- create a new Context, and give it a label of "Wiki Example". Within that Context, we create an Agent and give it a
- label of "Individual" and another Agent with the label "Block". At runtime when we are actually executing the model
- we will have one WikiExample model instance which contains a number of Individuals.</li>
- <li>Agents contain Attributes, such as Vision and Age. Context attributes often represent input parameters for
- contained agents. For example, our Wiki Agent Context might contain an Individual Count as well as a Minimum Age and
- Maximum Age.</li>
- <li>Contexts can contain Projections (Spaces), which represent some kind of spatial or structural interaction
- space for the agents; either a grid, a continuous (euclidian) space, or a network (graph) or geographic space of
- some kind. For example, we might want to have a City that contains Blocks and that an Individual can move around
- within.</li>
- <li>Agents are Actables and thus can contain any number of behaviors called "Actions", described in detail in
- the next section. Actions can describe individual behavior, and at the Context (Scape) level can define how member
- Agents and Projections are created.</li>
- <li>Styles provide a mechanism for defining generic visualization behavior for Agents and so are also Actables.
- For example, an Agent might have an Action that says effectively "draw a red circle shaded red for the wealth of the
- agent".</li>
-</ol>
-<h1 id="Actions">Actions</h1>
-<p>Actions are the most important part of an agent model. While Agents, Attributes and Spaces define what we're
-modeling, it is Actions that give the models life.</p>
-<h2 id="Background">Background</h2>
-<p>Actions allow the definition of behavior for agents at a very high level. You can think of actions as being
-analogous to methods in a traditional object-oriented model but that analogy only goes so far. In the same way that
-methods are defined as part of objects, actions belong to particular agents. (Though even more expressive ways of
-defining actions are contemplated in future releases.) In the next section we go into detail about what Actions are and
-how they can be used to define all agent behavior. They are also conceptually more challenging as unlike with structure
-they have no direct analogies to past agent representations.</p>
-<p>An action provides simple, well-defined details that a model can use to determine what steps to take in model
-execution. That definition seems general enough to be almost useless, but its important to understand that an action is
-not equivalent to an instruction, a method or a query. In fact, actions can have aspects of all of these. But an action
-is not in itself an instruction specifying exactly <i>how</i> the modeling engine should do something -- instead an
-action represents <i>what</i> the modeler intends for the agents to do. (Technically, we might say that Actions takes a
-"declarative" approach instead of an 'imperative' approach, but that's not quite true, because actions do allow us to
-define behavior in a richer way than most declarative approaches, and many action constructs map directly to imperative
-approaches.)</p>
-<p>Actions are connected together in a series of sources and targets. (Technically, an acyclic directed graph.) In
-an abstract sense that is similar to the way any programming language is defined although that structure isn't usually
-obvious because of the constraints of textual representations. But unlike a typical programming language, in Actions it
-is not the execution thread (the processor) that moves from one instruction to the next, but the result of the previous
-action. In this way, action results "flow" from the output of one action into the next action.</p>
-<p>Why are these distinctions between traditional Object-Oriented and the Action approaches important? They give us
-the advantages of simplicity, clarity and flexibility that <a
- href="/wiki/http://en.wikipedia.org/wiki/Dataflow_programming"
- title="http://en.wikipedia.org/wiki/Dataflow_programming">data-flow approaches</a> like spreadsheets and some query
-languages have, but with less restrictions. At the same time, they can bring us much of the power and expressivity of <a
- href="/wiki/http://en.wikipedia.org/wiki/Functional_programming"
- title="http://en.wikipedia.org/wiki/Functional_programming">functional languages</a> like Lisp or <a
- href="/wiki/http://en.wikipedia.org/wiki/Logical_programming"
- title="http://en.wikipedia.org/wiki/Logical_programming">logical languages</a> like Prolog, but without the level of
-complexity and obscurity that such languages can have.</p>
-<p>We can get a better idea for how Actions work by thinking about how a spreadsheet works. In a spreadsheet, we
-might define a cell A that adds up a row of data, say "Income". We might define another cell C ("Profit") that takes A
-and adds it to another cell B that adds up another row of data ("Expenses"). Now, if we change a value in any of the
-rows, all of the other rows are added up and we get the results in A and B updated automatically. We never had to write
-code that said something like "for each cell in row X, where...". In fact, we don't really care <i>how</i> our
-Spreadsheet program adds up the numbers -- it could have added them all up at once but in backward order, or stored a
-running total somewhere and updated just the difference in value for the cell we changed -- what we care about is <i>what</i>
-the result is, and whether it is correct.</p>
-<p>But Actions are much more powerful than a spreadsheet, because what is flowing from Action A to Action B is not
-just a number, but any model component such as a space or a set of agents that we need to use in target actions.</p>
-<h2 id="Types_of_Actions">Types of Actions</h2>
-<p>Before getting into the details of how each Action works, we need to understand how they all fit together. As
-discussed above, actions are strung together in a sequence. They're always composed of two parts, though those parts can
-be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do
-something with that selection. We refer to these two parts as Selections and Commands. There are two special kinds of
-selections. First, we need some way to start the whole chain of actions off, and so we have a kind of Selection called a
-Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first
-place, so we have a Create Agents action. For the technically minded, another useful way of looking at the Actions
-approach is as a Query Transformation language, as with SQL and Stored Procedures. Except again, the results of the
-queries along with the transformations flow through from one query to the next.</p>
-<p>There are two other special categories of actions. One we use to crate the spaces that agents exist upon. We call
-these Builders. The other category contains just one member, "Method".</p>
-<p>These are all summarized in the diagram below.</p>
-<p><img border="0" src="image/ActionsBlocks.png" /></p>
-<h2 id="Selections">Selections</h2>
-<p>A selection defines a particular set of agents that we want to do something with. Selections are made up of the
-Select action itself, along with Query and Logic actions. When we refer to a selection in any target command, we are
-referring to the selection in the context of where we have defined the behavior.</p>
-<h3 id="Sequences">Sequences</h3>
-<p>Again, a set of Behaviors in Actions is always defined by a set of selections and queries. In the following
-diagram, we can see the pattern.</p>
-<p><img border="0" src="image/ActionsSequence.png" /></p>
-<p>First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of
-Query and Logic Actions to define the specific agents that we are intrested in. These are all part of the Selection.
-Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of
-that selection to immediatly define another selection, for example if we are searching for an agent that is near another
-agent. The next diagram depicts a simple example.</p>
-<p><img border="0" src="image/ActionsSimpleSequence.png" /></p>
-<p>Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll
-evaluate some function based on their state, and then set some value on them. In the next example, we'll first create
-the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</p>
-<p><img border="0" src="image/ActionsSimpleSequence2.png" /></p>
-<p>Logic Actions are used to assemble any kind of query structure needed. In the following example, we've defined a
-selection where the Set action occurs for any agent whoe meets the criteria defined by (Query 1 AND Query 2) OR Query 3.
-(Readers with experience with programming or formal logic will note that this looks just like a parse tree, and while
-that's basically what it is, there are important differences from how such trees are generally treated as we'll see
-later.)</p>
-<p><img border="0" src="image/ActionsComplexLogic.png" /></p>
-<p>Note that Unions are often superfulous, though they can be useful for organizing queries. This is because all
-sources that flow into a given target Action act just like a union since any of the paths might reach that target. The
-following Action design is fully equivalant to the one above.</p>
-<p><img border="0" src="image/ActionsComplexLogicNoOr.png" /></p>
-<h3 id="Boundaries">Boundaries</h3>
-<p>An important concept in Actions is the idea of selection boundaries. A selection boundary is defined as the limit
-of a query directly upon a given Select Action. For example, in the following diagram, we can see the extent of the
-boundary for a straightforward selection.</p>
-<p><img border="0" src="image/ActionsSelBoundary1.png" /></p>
-<p>When does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is
-defined for a given Action by the place where:</p>
-<ol>
- <li>A Query Action is not followed by a Logic Action, or</li>
- <li>A Logic Action is not followed by another Logic Action</li>
-</ol>
-<p>In other words, as soon as a Logic Action occurs in a path leading to an Action, and other Query will define a
-new Selection, as we can see in the following example.</p>
-<p><img border="0" src="image/ActionsSelBoundary2.png" /></p>
-<p>These rules allow actions to be defined in the simplest possible way, but it is important to understand their
-implication as they result in behvavior that can be different from what someone used to and imperative programming
-environment such as Java might expect. In a simple case the distinciton might not matter. For example, if we are using a
-Query 1 to test wether an agent's attribute a = x and attribute b = y, we would get the same outcome if we placed
-intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with
-a = x, and <i>then</i> taking those agents and choosing those agents with b=y, but the outcome would be the same. But
-consider a more sophisticated case, where we are searching for neighboring available cells.</p>
-<p><img border="0" src="image/ActionsSelBoundaryComplex.png" /></p>
-<p>In the first case, we execute a search for all agents that meet the two criteria. This means that if there are <i>any</i>
-neighboring cells whcih are available, we're guranteed to find one (random) cell. In the second case, we first search
-for all cells that are neighbors. This will match any agents that include both available and non available agents. Now,
-at this point since our search returns one agent (in the current AMF design -- richer behavior will be supported in the
-future) the randomly selected agent could be either available or not. So in the second case, we might end up with no
-cell to move to, and thus make no move at all.</p>
-<h3 id="Root_Actions">Root Actions</h3>
-<p>Root actions are a special case of a selection. These represent behaviors that are defined for all members of
-agents; these are the highest granularity of an agent's behavior, such as "Find Partners" or "Eat" or "Reproduce". When
-you want to create a new set of Actions, you have the following choices.</p>
-<h4 id="Build">Build</h4>
-<p>The Build Action is a specialized action that allow the construction of member agents and spaces within a parent
-context. A Build Action executes once for each context before any initialization actions occur for any children agents
-of that context. Currently it is undefined wether a context's own Initialize Action is executed before the Build Action
-occurs, so implementors should not rely on any initialized values being available at build time.</p>
-<h4 id="Initialize">Initialize</h4>
-<p>An Initialize action is excuted once and only once for every agent when the model is first started -- at time 0.
-Initialize Actions are guranteed to execute before any other non-builder action occurs.</p>
-<h4 id="Rule">Rule</h4>
-<p>A Rule executes once for every agent for every iteration of the model. An important note is that the actual
-sequence of rules is technically undefined. An implementor should not rely on the fact that a rule occurs before another
-rule in the list of agent actions though typically the order in which the rules were actually created is respected.</p>
-<h4 id="Schedule">Schedule</h4>
-<p>A schedule is executed on a recurring basis, according to the values detailed below. Note that schedules are
-often overused. In most agent-based models it makes sense to have any behaviors occur at the same granularity using a
-Rule. Please note that Schedules are not currently supported in the Escap target, but that support should be available
-soon. In the following descriptions we refer to period as the current iteration of the model, that is where time = t.</p>
-<h5 id="Start">Start</h5>
-<p>The period that the schedule will first be invoked. For example, if this value is 100, and interval is 1, the
-schedue will be executed at times 100,101,102..</p>
-<h5 id="Interval">Interval</h5>
-<p>How often the schedule is invoked. For example, if this value is 3 and start is 1, the schedule will be executed
-at times 1,4,7..</p>
-<h5 id="Priority">Priority</h5>
-<p>Where the rule will be placed in the execution queue for a given time period. For example, if Schedule A's
-priority is set to 3 and Schedule B's is set to 2, Schedule B will be executed for all agents before Schedule B is
-executed for any agents.</p>
-<h5 id="Pick">Pick</h5>
-<p>Controls how many agents to execute the schedule against. While this value will have an effect on the Repast
-target, it is not recommended to be used for general models and is likely to be repalced by another approach.</p>
-<h4 id="Watch">Watch</h4>
-<p>A Watch action is executed anytime the watched value is set for any agent. Note that the Action will be
-triggerred even if the state is simply set back to the value that it already has. It is important to be careful about
-creating Watches that might set the values of other Watch actions which might in turn trigger this watch. To clarify, if
-a modeler creates a Watch A for attribute a, and creates a target Set for it for attribute b, and Watch B is watching
-attribute b, then if Watch B has a target Set for attribute A, a circular execution could occur. This would cause the
-model to get stuck in its current iteration. To help model developers avoid this case, a warning will be provided if
-such a set of circular watch dependencies is created.</p>
-<h5 id="Attribute">Attribute</h5>
-<p>The attribute that will be monitored for change.</p>
-<h3 id="Selection">Selection</h3>
-<p>A selection defines what we are searching for (Agent), where we are searching for it (Space), and from whose
-perspective we are doing it (Selection):</p>
-<h5 id="Selection_2">Selection</h5>
-<p>The selection that we are searching "from". This seems to be the concept that new users have the most difficulty
-with, but it is key to understanding how Actions works. Just as with any other Action -- a Move command for example -- a
-selection needs to know what set of agents that it is working with. For example, if we want to define a selection B that
-finds the cells neighboring a rule B's agent, we would set selection B's selection to A.</p>
-<h5 id="Agent">Agent</h5>
-<p>Here we define what agent we will be looking for. In order for this to make sense, the agent has to be related in
-some meaningful way to the agent whose behavior we are defining. For example, it might be a partner agent or a location
-that we might want to move to. An agent must be specified unless we are searching within a continuous space, in which
-case this value should be empty, and the result of the selection will represent some location in that space. In the
-current version of the framework, we treat destination cell locations as agents, and require that location to be
-specified as a target agent, but in a future version we'll allow searches without defining an agent within grid spaces
-as well.</p>
-<h5 id="Space">Space</h5>
-<p>The space that we want to search within. Of course, this must be specified if we use any spatial query terms (see
-below), but if we simply want to search across all agents it should not be specified.</p>
-<p>Represent Queries (Controls) on agents and Transformations, or Commands, on the result of those queries. Queries,
-Transformations and other in which each child target carries the execution and data context for it's particular path.</p>
-<h5 id="For">For</h5>
-<p>This value is obsolete and will be replaced with a different mechanism in the next version of the modeling
-environment.</p>
-<h3 id="Query">Query</h3>
-<p>A Query represents a concrete criteria for our search. The name is a bit confusing because of potential for
-confusion with a generic query. Queries -- along with their cousin Evaluators -- define a function that is evaluated and
-that can take Agent attributes, and the results of other Actions as input. Queries are combined with each other and with
-the logic actions to determine the results of a selection for their direct target actions.</p>
-<h5 id="Function">Function</h5>
-<p>A query function is evaluated to determine the results of a particular selection. Functions can represent very
-simple search criteria such as "My Age = Your Age", but they can also representSee the functions section for more
-information on specific functions.</p>
-<h3 id="Logic">Logic</h3>
-<h4 id="Intersection">Intersection</h4>
-<p>An intersection contains only those agents that match all of its source actions. This is essentially equivalent
-to a logical AND statement and has similarities to an && operator in a java "if" statement. But it carries
-important differences too. For example, there is not neccesarily short circuit execution (it's not needed) and much
-richer criteria can be joined together.</p>
-<h4 id="Union">Union</h4>
-<p>A union contains all agents that match any of its source actions. This essentially equivalent to a logical OR
-statement and shares similarities with the || operator in a java "if" statement.</p>
-<h4 id="Difference">Difference</h4>
-<p>A difference contains all agents that do not match any of its source actions. This essentailly equivalent to a
-logical NOT statement, and has similarities to (and important differences from) the Java else statement.</p>
-<h2 id="Example">Example</h2>
-<p>In this section, we'll look at an example that should make clear how the basic Actions approach works in a model.
-Say we want to define a behavior like:</p>
-<pre>"Search for a random agent within my vision that is the same age as I am. Find a location next to that agent that is not already occupied and move to it."
-</pre>
-<p>Here, we create a sequence of actions like so:</p>
-<ol>
- <li>Select every agent for every period of the model. ("Find Partner" Rule)</li>
- <li>For every member of that selection, search for other agents of the same age within vision distance.
- ("Partner" selection.)</li>
- <li>From "Partners" find a random member and search for a neighboring locations. ("Partner Neighbor"
- selection.)</li>
- <li>Finally, move the agent in "Find Partner" to the "Partner Neighbor" location.</li>
-</ol>
-<p>Now, notice that although it's convenient to speak as if there is only one "Find Partner" and one "Partner
-Neighbor" in step 4 above, in fact selections are flowing through for each of the results of each of the previous action
-sequences, and we can refer to each of the directly. We could represent these behaviors in many different ways. For
-example, we might want to specify the model in a (hand-drawn) graphical language or in a (made-up) textual language:</p>
-<p><img border="0" src="image/ActionsExample.png" /></p>
-<p>This is how it looks in an actual model:</p>
-<p><img border="0" src="image/ActionsExampleNew.png" /></p>
-<p>And here is how this works in detail:</p>
-<ol>
- <li>Create a Rule that will trigger the behavior. In this case, we want this rule to apply to all "Individual"
- agents within the model. (Space isn't relevant in this case.</li>
- <li>Create a child Select Action that will find our partner. Two important things to note here:
- <ol>
- <li>The selection occurs based on the "Find Partner" selection. This means that for each Individual in the
- model, we'll be searching from the point of view of that agent to some other selection of agents.</li>
- <li>We also need to define what type of agent we want and in this case the space does matter. We want to
- find an agent that is nearby within the City space. If instead we wanted to find a partner in a social network,
- we'd specify that instead.</li>
- </ol>
- </li>
- <li>Create two child Query Actions:
- <ol>
- <li>We want to search for someone who is the same age as us. This highlights the importance of the idea of
- the Selection in the Actions design. We're qualifying Age by our <font color="green">Partner</font> and <font
- color="red">ourselves</font>. The selection carries throughout the flow of execution and this context is an
- explicit part of the entire structure. Note that this is very different from the way control flow works in a
- traditional imperative language such as Java.</li>
- <li>We also want to search using a function for nearness, "within", which takes a parameter of vision. Note
- that the spatial functions are all polymorphic -- if we decided later on that we would rather search within say
- "Kevin Bacon space", that is a graph structure representation of space, we would only need to change the space
- we've defined in Select Partner. (Design discussion note: re-examine this issue WRT possibility of allowing
- users to search in multiple spaces within the same query.)</li>
- </ol>
- </li>
- <li>Intersect the results of these two query components. This delineates the end of the selection definition
- for any target Actions.</li>
- <li>Select a neighbor. Again, we can see the importance of Selections. Here, we are selecting from the point of
- view of the partner, not the initial agent that the current Rule is being executed for. Note that this time our
- target agent is a "Block", that is, a location within the city.</li>
- <li>As above, define some queries. This time we want only those agents that are:
- <ol>
- <li>available, and</li>
- <li>neighbors of our partner.</li>
- </ol>
- </li>
- <li>And another intersection..</li>
- <li>Finally, we move to the location we've found. All that's required at this point is to specify:
- <ol>
- <li>The movement selection, or those agents that are moving, which in this case is the original agent we're
- executing the rule for, and</li>
- <li>The destination, which is the cell that we've found. Note that the framework infers from the space
- definition that the Block agent is capable of hosting the Individual.</li>
- </ol>
- </li>
-</ol>
-<h2 id="Reference_2">Reference</h2>
-<h3 id="Diagrams_2">Diagrams</h3>
-<p>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</p>
-<h4 id="Meta-Classes_2">Meta-Classes</h4>
-<p><img border="0" src="image/ActionsDiagram.png" /></p>
-<h4 id="Details_2">Details</h4>
-<p>In the diagram above, all meta-objects except for Input, Literal, and the enumerators (lists of options) are
-Actions. Blue meta-classes are concrete (you can create and use them directly). Red meta-classes are key collaborations.</p>
-<ol>
- <li>An Act is anything that might happen during the execution of an Agent-Based Model.</li>
- <li>All Actions have as their root-most source action a Root. These are added first to any agent behavior and
- act as triggers for all target behavior. For example, a Watch will execute anytime the watched attribute is
- modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that Accessor
- includes a reference to some Attribute, but it does. To see these kinds of relationships you will want to refer to
- the metaabm.ecore file itself.)#Actions are targets and sources of one another, but an Act can never have itself as
- a source. (That is, Actions are acyclic, but branches can re-converge. When we refer to an Act source or target, we
- typically mean to include all ancestors or descendants, not just the immediately connected Act.)</li>
- <li>All Actions (except for root Actions) reference a Select, referred to as the "selected" relation. An
- ASelect represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent)
- "world" that is currently being selected.</li>
- <li>Commands trigger some model state change (Set) or spatial transformation (Transform).</li>
- <li>Controls determine wether target Actions are executed and against what agents. They are in some sense query
- terms and include Query actions and Logic Actions.</li>
- <li>Transforms also specify a "destination" Select. This represents aspects that the selected agent(s) will
- transform to. For example, a Move may use a Rule to select all SugarAgents (type) in the SugarGrid (space) every
- period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time
- implicit).</li>
- <li>Sinks are Actions which use some Function (see next section) to interpret state in the form of Inputs.
- Inputs can come from selected agent attributes, other Actions, or literal values.</li>
-</ol>
-<h1 id="Functions">Functions</h1>
-<p>Functions are relatively simple in terms of model design, but we need to understand how particular functions work
-in order to develop models. Functions are divided in two ways. By type:</p>
-<ol>
- <li>Operators are simple calculations sharing the same type.</li>
- <li>Generics that can represent any general function that takes some well-defined input(s) and returns some
- well-defined output(s).</li>
-</ol>
-<p>And by usage:</p>
-<ol>
- <li>Functions proper can return any value and are used in Evaluate actions.</li>
- <li>Logicals return some boolean result and are used by Query actions to decide wether target Actions apply to
- a particular selection, and by Evaluate actions just as with any other functions. Input types should be defined as
- generally as possible.</li>
-</ol>
-<p>A tehcnical note: conceptually, functions can return multi-values, but that is not currently implemented in the
-reference targets because of limitations of the target language Java.</p>
-<p>These overlap, so we have</p>
-<h2 id="Reference_3">Reference</h2>
-<h3 id="Diagrams_3">Diagrams</h3>
-<p>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</p>
-<h4 id="Meta-Classes_3">Meta-Classes</h4>
-<p><img border="0" src="image/FunctionsDiagram.png" /></p>
-</body>
-</html>
\ No newline at end of file
diff --git a/documentation/_index.html b/documentation/_index.html
index 4a78622..aa9fb02 100644
--- a/documentation/_index.html
+++ b/documentation/_index.html
@@ -3,5 +3,5 @@
<p>AMP comes with Eclipse Help allowing you to refer to all documentation dirrectly from your Eclipse IDE. Go to
the "Help" menu and select "Help Contents". Then look for the Agent Modeling category in the help browser. You can also
search in and explore help using "Search" and "Dynamic Help".</p>
-<p><a href="ModelersGuide.php">Modeler's Guide</a> (In progress.)</p>
+<p><a href="amp.php">Agent Modeling Guide</a> (In progress.)</p>
<p><a href="http://wiki.eclipse.org/AMP/UserGuide/Contents">Wiki Documentation</a></p>
diff --git a/documentation/amp.html b/documentation/amp.html
new file mode 100644
index 0000000..ab46aa5
--- /dev/null
+++ b/documentation/amp.html
@@ -0,0 +1,1331 @@
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Agent Modeling Guide</title>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="book" title="Agent Modeling Guide">
+<div class="titlepage">
+<div>
+<div>
+<h1 class="title">
+<a name="N10001"></a>Agent Modeling Guide</h1>
+</div>
+</div>
+<hr>
+</div>
+<div class="toc">
+<p>
+<b>Table of Contents</b>
+</p>
+<dl>
+<dt>
+<span class="chapter"><a href="#Introduction">1. Introduction</a></span>
+</dt>
+<dt>
+<span class="chapter"><a href="#General">2. General</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="#Descriptions">Descriptions</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="chapter"><a href="#Structure">3. Structure</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="#Agents">Agents</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Attributes">Attributes</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Spaces">Spaces</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Reference">Reference</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="chapter"><a href="#Actions">4. Actions</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="#Background">Background</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Types_of_Actions">Types of Actions</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Selections">Selections</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Example">Example</a></span>
+</dt>
+<dt>
+<span class="section"><a href="#Reference_2">Reference</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="chapter"><a href="#Functions">5. Functions</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="#Reference_3">Reference</a></span>
+</dt>
+</dl>
+</dd>
+</dl>
+</div>
+<div class="chapter" title="Chapter 1. Introduction">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Introduction"></a>Chapter 1. Introduction</h2>
+</div>
+</div>
+</div>
+<p>In this section of the documentation we'll provide an in-depth understanding of what goes into an Agent Model and how you can use the Agent Modeling Framework tools to design them. Fundamentally, an agent-based model, or "ABM", is composed of five pieces: Agents and Context Agents, Actions, Attributes, Spaces and Styles. We'll describe each component in depth. But first a generic concept:</p>
+</div>
+<div class="chapter" title="Chapter 2. General">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="General"></a>Chapter 2. General</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Descriptions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Descriptions"></a>Descriptions</h2>
+</div>
+</div>
+</div>
+<p>Everything represented in an Acore model needs to be referred to in some way. Just as software classes have names, Acore provides a way to label and describe every entity, but in a richer and more maintainable way. All entities in Acore define:</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Label">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N10018"></a>Label</h5>
+</div>
+</div>
+</div>
+<p>A reasonably short, human readable name for the agent. For example, "Timber Wolf", "Forex Trader" or "Movement Probability". These should be defined so that they fit in well with auto-generated documentation.</p>
+</div>
+<div class="section" title="ID">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="ID"></a>ID</h5>
+</div>
+</div>
+</div>
+<p>An ID is an identifier that can be used to represent the object in a software program. This means that it must follow certain rules such as no-spaces or non alpha-numeric characters. The editing tools will help make sure that this value is legal. Note that when you enter a label, a legal ID is automatically created for you! Usually you won't need to change this, but you might if for example you want the value to match up with some database or other external representation. So reasonable values here might be "timberWolf" or perhaps "MVMNT_PRB" if say you're trying to match up to some old statistics records you have. (Note that currently IDs by default use "camel case", i.e. "thisIsAnExampleOfCamelCase" to match with Java variable naming conventions, but this is likely to change.)</p>
+<p>And most entities also define:</p>
+</div>
+<div class="section" title="Description">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Description"></a>Description</h5>
+</div>
+</div>
+</div>
+<p>A complete textual description of the object. Don't overlook this -- it is the most important part of your model. The description will show up in your auto-generated html documentation, software documentation and even in your running model. You should include enough information that model users will understand what the entity is for and what it does without referring elsewhere. This is also where any attributions and references should go. You can put html tags in here -- such as href's to external papers, but keep those to a minimum as they won't be rendered as html in all contexts.</p>
+</div>
+<div class="section" title="Plural Label">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Plural_Label"></a>Plural Label</h5>
+</div>
+</div>
+</div>
+<p>The plural representation of an entity. This can be a surprisingly useful thing to have in generated documentation and software code, so it's worth maintaining. The editor will automatically add an "s" at the end of the label you've entered above, but you change it to whatever is appropriate. For example "Person", or "Timber Wolves".</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="chapter" title="Chapter 3. Structure">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Structure"></a>Chapter 3. Structure</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Agents"></a>Agents</h2>
+</div>
+</div>
+</div>
+<p>An Agent is simply a software object that has autonomous behavior and (generally speaking) exists within some set of spaces. By autonomous, we mean that agents make the choice about when and how to execute a behavior, as opposed to have that controlled from "above", so to speak. Like any software objects, agents have attributes (fields) and actions (methods) associated with them.</p>
+<div class="section" title="Context Agents (Contexts)">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Context_Agents_.28Contexts.29"></a>Context Agents (Contexts)</h3>
+</div>
+</div>
+</div>
+<p>Agents also form the basic structural component of an agent-based model. Unlike the approach of a traditional Object Oriented environment, the dominant organizing principal for agents within AMF follows a compositional hierarchical model, not an inheritance model. (Inheritance-like behavior will be supported in forthcoming versions of Acore, but in a more sophisticated, flexible and dynamic way than is supported by traditional programming languages such as Java.) Contexts -- also referred to as "Swarms" or "Scapes", are simply Agents that are capable of containing other agents. With this basic construct -- known as a Composition in design pattern language -- agents are able to contain other agents. To get an idea for how this works, have a look at the "EpidemicRegional.metaabm" model. Note that in future releases, we will probably refer to Contexts as "Scapes".</p>
+</div>
+</div>
+<div class="section" title="Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Attributes"></a>Attributes</h2>
+</div>
+</div>
+</div>
+<p>Agents need some way to represent their internal state. For example, an agent in an economic model might have a wealth attribute, and an agent in an ecology model might have a quantity of food and a particular vision range. These states are represented as attributes just as all software objects do. In an agent model, we keep richer information about these attributes and generally represent them at a higher level. For example, rather than specify that a real value is a "double", a "float" or a "big number", we represent them as "Reals" so that they can be implemented and tested in different environments. This might allow us for instance to ensure that a model's behavior is not dependent on a particular machine implementation of floating point arithmetic. Also, note that attributes only represent so-called "primitive" values -- that is, actual measurable features of a particular agent but not an agent's relationship to other agents or objects. See the discussion about networks for more on this key topic.</p>
+<p>Here are the basic types of attributes available in Acore models:</p>
+<div class="section" title="Basic Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Basic_Attributes"></a>Basic Attributes</h3>
+</div>
+</div>
+</div>
+<p>Attributes are single values that a given agent contains. For example, an agent might have an "Age" attribute. Attributes have descriptions of course, and they also have:</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Type">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N10051"></a>Type</h5>
+</div>
+</div>
+</div>
+<p>These can be anyone of the following: </p>
+<table id="N10056">
+<tr>
+
+<td>Boolean</td>
+ <td>A value that is simply true or false. Note that unless this value really is a simple binary value, you should consider using state instead. (See details below.) For example, rather than representing gender as a 'Female' boolean value, define a 'Gender' state with values 'Male' and "Female'. Generated artifacts and documentation will be much clearer, and you'll be able to easily modify the model later if for example you discover that there are more than two potential gender categories that are relevant to your model.</td>
+
+</tr>
+<tr>
+
+<td>Integer</td>
+ <td>A discrete whole number value, such as "100", "-1", "10029920". It's generally a good idea to represent any value that can never have a decimal value as an integer.</td>
+
+</tr>
+<tr>
+
+<td>Real</td>
+ <td>A continuous number value. While these are typically represented in software as floating point numbers, they can conceivably represent numbers at any arbitrary precision and in any scheme. Note that while technically speaking we should be representing irrational numbers, this is not currently supported for default values and users should simply use the closest decimal approximation.</td>
+
+</tr>
+<tr>
+
+<td>Symbol</td>
+ <td>A string representing some state. More precisely, a computationally arbitrary value with contextual meaning. This could be any kind of identifier. For example, you might use it to store some kind of input coding from data that is then converted into an object state. Or it could simply be an agent's name. But theoretically (though this is not currently supported) one could imagine a symbol using an idiogram, an icon or even a sound that identifies or represents the agent in question.</td>
+
+</tr>
+</table>
+<p>(Undefined and Numeric types should not be used within a well-defined model.)</p>
+</div>
+<div class="section" title="Default Value">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Default_Value"></a>Default Value</h5>
+</div>
+</div>
+</div>
+<p>The value that should be assigned to the attribute at the beginning of any model run. The attribute may of course be assigned a different value in an Initialize rule, but its a good idea to specify one here. It's OK to leave it blank, in which case a sensible 'empty' value will be assigned, i.e. false for Boolean, 0 for Integers and Reals, and an empty string for Symbol.</p>
+</div>
+<div class="section" title="Gather Data">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Gather_Data"></a>Gather Data</h5>
+</div>
+</div>
+</div>
+<p>Here you can specify whether executing models should collect aggregate values for the data. For example, if you select this value as true for a 'Wealth' attribute, Escape will automatically keep track of minimum, maximum, average, sum and optionally standard deviation and variance across all agents for each model execution period. All of these statistics will then be selectable with a mouse click to appear in your model charts at runtime.</p>
+</div>
+<div class="section" title="Immutable">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Immutable"></a>Immutable</h5>
+</div>
+</div>
+</div>
+<p>This value indicates whether you expect the model value to change. If you know that it won't or shouldn't, this value should be true.</p>
+</div>
+<div class="section" title="Units">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Units"></a>Units</h5>
+</div>
+</div>
+</div>
+<p>Specifies what the attribute is actually measuring. For example, if you're defining an attribute for "Wealth" in the context of a model of the world economy, you might specify "USD". If you're defining "Age", you might specify "Years", for "Mass" "Kg". Like description, this value is often overlooked, but can be critically important to allowing yourself and others to understand and correctly calibrate a model. Note that this will also allow you to simplify variable names -- instead of using "Age in Years", you can simply specify "Age" and the appropriate unit. It may be obvious to you that your model is concerned with age in years, but a user who needs to specify a different granularity will be grateful for more clarity.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Arrays">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Arrays"></a>Arrays</h3>
+</div>
+</div>
+</div>
+<p>Arrays are simply attributes with zero or more entries. For example, you might have an array of three Real numbers representing the Red Green and Blue color components for an object. Note that if you find yourself defining very complex sets of arrays, its likely that what you really want to define is a new agent with attributes for each array. In addition to whatis defined above, arrays specify:</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Size">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N100A9"></a>Size</h5>
+</div>
+</div>
+</div>
+<p>The number of values that the array attribute will contain.</p>
+</div>
+</div>
+</div>
+<div class="section" title="States">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="States"></a>States</h3>
+</div>
+</div>
+</div>
+<p>States represent any agent quality that may take on one of a number of well defined values. For example, an "Ice Cream Consumer" Agent might contain a state of "Ice Cream Preference" with options of "Chocolate", "Vanilla" and "Ginger".</p>
+<div class="section" title="State Options">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="State_Options"></a>State Options</h4>
+</div>
+</div>
+</div>
+<p>Create new options for states by adding them to the state node. States are simple described items. Don't forget to provide a description! States also have</p>
+<div class="section" title="Default Option">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Default_Option"></a>Default Option</h5>
+</div>
+</div>
+</div>
+<p>unlike for regular attributes, this option is not optional! Simply pick a state option to be assigned that the agent will take if no other option has been assigned.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="section" title="Spaces">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Spaces"></a>Spaces</h2>
+</div>
+</div>
+</div>
+<p>All contexts can contain spaces. Spaces provide an environment in which agents can have a physical or notional location and upon which they can interact with one another and their environment. Agents can exist in more than one space at a time, and a given agent need not exist in every space. (Note that this is different from the Repast Simphony notion of projections, though the two representational approaches are generally compatible.) Agents need not represent explicit, "real" spatial structures such as a landscape, though this is of course the most common use. They can also represent relational and state information, such as a belief space or a social network. There are four kinds of space represented:</p>
+<div class="section" title="Space (Continuous)">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Space_.28Continuous.29"></a>Space (Continuous)</h3>
+</div>
+</div>
+</div>
+<p>In the modeling tools, we simply refer to this as a "Space" as it is represents the general concept of a space. A space is simply something that contains objects with certain locations and extents and has a certain number of dimensions. The space is continuous, in the sense that objects can be placed anywhere with arbitrary position. Spaces hold attributes, which simply define their dimensions-- see below.</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Border Rule">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N100CE"></a>Border Rule</h5>
+</div>
+</div>
+</div>
+<p>A value representing what happens to an agent when that agent is asked to move beyond its extent.</p>
+<table id="N100D3">
+<tr>
+
+<td>Periodic</td>
+ <td>When encountering an edge, the agent will treat the space as wrapping around to the other side of the space. For example, if the agent at location
+ <a class="ulink" href="1,2" target="_new">1,2</a> (0-based) within a Moore space (see grid discussion below) of size
+ <a class="ulink" href="10,10" target="_new">10,10</a> is asked to find some other agent within distance 3, the agent look in the square defined between
+ <a class="ulink" href="8,9" target="_new">8,9</a> and
+ <a class="ulink" href="4,5" target="_new">4,5</a>. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge. You can imagine this as taking a piece of graph paper and connecting the opposite edges. You can't actually do that with paper, but if you could you would have a toroidal (donut) shape in three dimensions defining the shape in two.
+ </td>
+
+</tr>
+<tr>
+
+<td>APeriodic</td>
+ <td>When encountering an edge, the agent treats it as the edge of the space. For example, if the agent at location
+ <a class="ulink" href="1,2" target="_new">1,2</a> is asked to find some other agent within distance 3, the agent look between
+ <a class="ulink" href="0,0" target="_new">0,0</a> and
+ <a class="ulink" href="4,5" target="_new">4,5</a>. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge.
+ </td>
+
+</tr>
+</table>
+<p>The "Strict" and "Bouncy" values are obsolete and should not be used.</p>
+</div>
+<div class="section" title="Dimensionality">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Dimensionality"></a>Dimensionality</h5>
+</div>
+</div>
+</div>
+<p>The number of dimensions that the space has. After selecting a dimensionality, attributes will be added to represent each dimension. For example, if you enter 3 here, you will have an attrbiute for X, Y, and Z. Be sure to enter default values here, as they will be used to specify the actual size of the space.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Grid">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Grid"></a>Grid</h3>
+</div>
+</div>
+</div>
+<p>A grid is technically a regular lattice structure. Currently, only rectilinear strcutures are supported, i.e. a One-dimensional vector, a two-dimensional grid, a three-dimensional cube and so on. (Though none of the current target platfroms support n-d spaces yet.) </p>
+<p>Like continuous spaces, a grid has a border rule and dimensionality. A grid has a couple of other important values:</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Multi-Occupant">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N1011A"></a>Multi-Occupant</h5>
+</div>
+</div>
+</div>
+<p>Does the grid allow more than one agent to occupy it at a time? This value can usually be ignored and will likely be deprecated in future releases.</p>
+</div>
+<div class="section" title="Neighborhood">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Neighborhood"></a>Neighborhood</h5>
+</div>
+</div>
+</div>
+<p>This value determines what constitutes a region within a particular distance from the agent. The value for this is often ciritical in obtaining particular behavior from a model, and shouldn't be overlooked. There are three possible values:</p>
+<table id="N10125">
+<tr>
+
+<td>Euclidian</td>
+ <td>The distance between any two cells is taken to be the "real" distance. For example, if an agent was within a chess board, and we wanted to find all agents within distance three of it, we could determine that by taking a string of length 3, tacking it to the center of the source square, and including all cells whose centers we can reach with the other string end. Note that although Euclidian space may seem the most reasonable neighborhood configuration to choose, this really isn't the case. Euclidian space is continuous whereas grid space is discrete, and mapping the two to each other can create unexpected issues. Still, this is a good choice for models representing notionally real spaces.</td>
+
+</tr>
+<tr>
+
+<td>Moore</td>
+ <td>Here, the distance between any two cells is defined by the number of edge <span style="color: red"><i>or</i></span> corner adjacent cells crossed to get between them. To continue the chess board analaogy, this is the set of moves that a king can make. Note that this does not map well to real space at all, as a cell at distance 1 in a moore space is at distance sqrt(2) in "real" space.</td>
+
+</tr>
+<tr>
+
+<td>Von-Neumann</td>
+ <td>Here, the distance between any two cells is defined by the number of edge adjacent cells crossed to get between them. This is the set of moves that a rook might make on a chess board -- if a rook could only move one square at a time.</td>
+
+</tr>
+</table>
+</div>
+</div>
+</div>
+<div class="section" title="Network">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Network"></a>Network</h3>
+</div>
+</div>
+</div>
+<p>A network represents a set of relationships between agents, in a graph structure. The concept is pretty simple, but note that a network is actually a critical part of many AMF models. This is because we use networks to represent any kind of references between agents. You may have noticed in the discussion about attributes that there is no generic "object" type for an attribute. In fact, attributes only contain primitive values. So we will use networks to do the kinds of things that we would often use object references for in a traditional Object-Oriented model. For example, if an agent is a member of a family, rather than have that agent have a member attribute of "family" with a reference to the "Family" object, the modeler would create a "Family Members" network and connect agent's to their families as appropriate. This implies that network members can contain members of many different types.</p>
+<p>A network has only one value to specify:</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Directed">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N10157"></a>Directed</h5>
+</div>
+</div>
+</div>
+<p>This indicates whether connections between agents are one-way or two-way. If this value is false, then if a connection is made between an agent A and an agent B, and agent B searches within distance 1, agent B will find agent A. If this value is true, agent A can find agent B, but agent B can not find agent A. (Unless of course some other path leads B to A.)</p>
+</div>
+</div>
+</div>
+<div class="section" title="Geography">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Geography"></a>Geography</h3>
+</div>
+</div>
+</div>
+<p>A geography represents a physical landscape. Here we assume that that landscape is going to be defined by an external data source and representational scheme -- typically a Geographical Information System. We'll describe how to work with GIS in more detail when we discuss builder actions.</p>
+</div>
+</div>
+<div class="section" title="Reference">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Reference"></a>Reference</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Diagrams">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Diagrams"></a>Diagrams</h3>
+</div>
+</div>
+</div>
+<p>For readers familiar with UML and meta-modeling, the following diagrams give more detail on the structural design.</p>
+<div class="section" title="Meta-Classes">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Meta-Classes"></a>Meta-Classes</h4>
+</div>
+</div>
+</div>
+<p>Our first diagram depicts the core structural design of the model. </p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/StructureComplexDiagram.png"></div>
+<p>
+
+</p>
+<div class="literallayout">
+<p>There seems to be a lot going on here, but the basic components are pretty straightforward as we can see in the next diagram.<br>
+
+</p>
+</div>
+</div>
+<div class="section" title="Key Collaborations">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Key_Collaborations"></a>Key Collaborations</h4>
+</div>
+</div>
+</div>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/StructureSimpleDiagram.png"></div>
+<p>
+
+</p>
+<div class="literallayout">
+<p>Core interactions are in Red. The meta-model structure is essentially a Composite pattern. <br>
+
+</p>
+</div>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Details"></a>Details</h4>
+</div>
+</div>
+</div>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Every model has at its root a Context (Scape). Contexts are Agents that are capable of containing other Agents (including other contexts, naturally). </p>
+</li>
+<li class="listitem">
+<p>(Meta-level) Contexts contain (meta-level) Agents at the model (design-time) level. At runtime, (model-level) Context instances defined in a (meta-level) SContext will contain (model-level) agent instances of the defined (meta-level) SAgent. This sounds more complicated than it is, so let's look at a simple example. Suppose we create a new Context, and give it a label of "Wiki Example". Within that Context, we create an Agent and give it a label of "Individual" and another Agent with the label "Block". At runtime when we are actually executing the model we will have one WikiExample model instance which contains a number of Individuals.</p>
+</li>
+<li class="listitem">
+<p>Agents contain Attributes, such as Vision and Age. Context attributes often represent input parameters for contained agents. For example, our Wiki Agent Context might contain an Individual Count as well as a Minimum Age and Maximum Age.</p>
+</li>
+<li class="listitem">
+<p>Contexts can contain Projections (Spaces), which represent some kind of spatial or structural interaction space for the agents; either a grid, a continuous (euclidian) space, or a network (graph) or geographic space of some kind. For example, we might want to have a City that contains Blocks and that an Individual can move around within.</p>
+</li>
+<li class="listitem">
+<p>Agents are Actables and thus can contain any number of behaviors called "Actions", described in detail in the next section. Actions can describe individual behavior, and at the Context (Scape) level can define how member Agents and Projections are created.</p>
+</li>
+<li class="listitem">
+<p>Styles provide a mechanism for defining generic visualization behavior for Agents and so are also Actables. For example, an Agent might have an Action that says effectively "draw a red circle shaded red for the wealth of the agent".</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="chapter" title="Chapter 4. Actions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Actions"></a>Chapter 4. Actions</h2>
+</div>
+</div>
+</div>
+<p>Actions are the most important part of an agent model. While Agents, Attributes and Spaces define what we're modeling, it is Actions that give the models life.</p>
+<div class="section" title="Background">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Background"></a>Background</h2>
+</div>
+</div>
+</div>
+<p>Actions allow the definition of behavior for agents at a very high level. You can think of actions as being analogous to methods in a traditional object-oriented model but that analogy only goes so far. In the same way that methods are defined as part of objects, actions belong to particular agents. (Though even more expressive ways of defining actions are contemplated in future releases.) In the next section we go into detail about what Actions are and how they can be used to define all agent behavior. They are also conceptually more challenging as unlike with structure they have no direct analogies to past agent representations.</p>
+<p>An action provides simple, well-defined details that a model can use to determine what steps to take in model execution. That definition seems general enough to be almost useless, but its important to understand that an action is not equivalent to an instruction, a method or a query. In fact, actions can have aspects of all of these. But an action is not in itself an instruction specifying exactly
+ <span class="italic">how</span> the modeling engine should do something -- instead an action represents
+ <span class="italic">what</span> the modeler intends for the agents to do. (Technically, we might say that Actions takes a "declarative" approach instead of an 'imperative' approach, but that's not quite true, because actions do allow us to define behavior in a richer way than most declarative approaches, and many action constructs map directly to imperative approaches.)
+ </p>
+<p>Actions are connected together in a series of sources and targets. (Technically, an acyclic directed graph.) In an abstract sense that is similar to the way any programming language is defined although that structure isn't usually obvious because of the constraints of textual representations. But unlike a typical programming language, in Actions it is not the execution thread (the processor) that moves from one instruction to the next, but the result of the previous action. In this way, action results "flow" from the output of one action into the next action.</p>
+<p>Why are these distinctions between traditional Object-Oriented and the Action approaches important? They give us the advantages of simplicity, clarity and flexibility that
+ <a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Dataflow_programming" target="_new">data-flow approaches</a> like spreadsheets and some query languages have, but with less restrictions. At the same time, they can bring us much of the power and expressivity of
+ <a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Functional_programming" target="_new">functional languages</a> like Lisp or
+ <a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Logical_programming" target="_new">logical languages</a> like Prolog, but without the level of complexity and obscurity that such languages can have.
+ </p>
+<p>We can get a better idea for how Actions work by thinking about how a spreadsheet works. In a spreadsheet, we might define a cell A that adds up a row of data, say "Income". We might define another cell C ("Profit") that takes A and adds it to another cell B that adds up another row of data ("Expenses"). Now, if we change a value in any of the rows, all of the other rows are added up and we get the results in A and B updated automatically. We never had to write code that said something like "for each cell in row X, where...". In fact, we don't really care
+ <span class="italic">how</span> our Spreadsheet program adds up the numbers -- it could have added them all up at once but in backward order, or stored a running total somewhere and updated just the difference in value for the cell we changed -- what we care about is
+ <span class="italic">what</span> the result is, and whether it is correct.
+ </p>
+<p>But Actions are much more powerful than a spreadsheet, because what is flowing from Action A to Action B is not just a number, but any model component such as a space or a set of agents that we need to use in target actions.</p>
+</div>
+<div class="section" title="Types of Actions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Types_of_Actions"></a>Types of Actions</h2>
+</div>
+</div>
+</div>
+<p>Before getting into the details of how each Action works, we need to understand how they all fit together. As discussed above, actions are strung together in a sequence. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. There are two special kinds of selections. First, we need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures. Except again, the results of the queries along with the transformations flow through from one query to the next.</p>
+<p>There are two other special categories of actions. One we use to crate the spaces that agents exist upon. We call these Builders. The other category contains just one member, "Method".</p>
+<p>These are all summarized in the diagram below.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsBlocks.png"></div>
+<p>
+
+</p>
+</div>
+<div class="section" title="Selections">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Selections"></a>Selections</h2>
+</div>
+</div>
+</div>
+<p>A selection defines a particular set of agents that we want to do something with. Selections are made up of the Select action itself, along with Query and Logic actions. When we refer to a selection in any target command, we are referring to the selection in the context of where we have defined the behavior.</p>
+<div class="section" title="Sequences">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Sequences"></a>Sequences</h3>
+</div>
+</div>
+</div>
+<p>Again, a set of Behaviors in Actions is always defined by a set of selections and queries. In the following diagram, we can see the pattern.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSequence.png"></div>
+<p>
+
+</p>
+<p>First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are intrested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediatly define another selection, for example if we are searching for an agent that is near another agent. The next diagram depicts a simple example.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSimpleSequence.png"></div>
+<p>
+
+</p>
+<p>Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them. In the next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSimpleSequence2.png"></div>
+<p>
+
+</p>
+<p>Logic Actions are used to assemble any kind of query structure needed. In the following example, we've defined a selection where the Set action occurs for any agent whoe meets the criteria defined by (Query 1 AND Query 2) OR Query 3. (Readers with experience with programming or formal logic will note that this looks just like a parse tree, and while that's basically what it is, there are important differences from how such trees are generally treated as we'll see later.)</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsComplexLogic.png"></div>
+<p>
+
+</p>
+<p>Note that Unions are often superfulous, though they can be useful for organizing queries. This is because all sources that flow into a given target Action act just like a union since any of the paths might reach that target. The following Action design is fully equivalant to the one above.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsComplexLogicNoOr.png"></div>
+<p>
+
+</p>
+</div>
+<div class="section" title="Boundaries">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Boundaries"></a>Boundaries</h3>
+</div>
+</div>
+</div>
+<p>An important concept in Actions is the idea of selection boundaries. A selection boundary is defined as the limit of a query directly upon a given Select Action. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSelBoundary1.png"></div>
+<p>
+
+</p>
+<p>When does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>A Query Action is not followed by a Logic Action, or</p>
+</li>
+<li class="listitem">
+<p>A Logic Action is not followed by another Logic Action</p>
+</li>
+</ol>
+</div>
+<p>In other words, as soon as a Logic Action occurs in a path leading to an Action, and other Query will define a new Selection, as we can see in the following example.</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSelBoundary2.png"></div>
+<p>
+
+</p>
+<p>These rules allow actions to be defined in the simplest possible way, but it is important to understand their implication as they result in behvavior that can be different from what someone used to and imperative programming environment such as Java might expect. In a simple case the distinciton might not matter. For example, if we are using a Query 1 to test wether an agent's attribute a = x and attribute b = y, we would get the same outcome if we placed intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with a = x, and
+ <span class="italic">then</span> taking those agents and choosing those agents with b=y, but the outcome would be the same. But consider a more sophisticated case, where we are searching for neighboring available cells.
+ </p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsSelBoundaryComplex.png"></div>
+<p>
+
+</p>
+<p>In the first case, we execute a search for all agents that meet the two criteria. This means that if there are
+ <span class="italic">any</span> neighboring cells whcih are available, we're guranteed to find one (random) cell. In the second case, we first search for all cells that are neighbors. This will match any agents that include both available and non available agents. Now, at this point since our search returns one agent (in the current AMF design -- richer behavior will be supported in the future) the randomly selected agent could be either available or not. So in the second case, we might end up with no cell to move to, and thus make no move at all.
+ </p>
+</div>
+<div class="section" title="Root Actions">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Root_Actions"></a>Root Actions</h3>
+</div>
+</div>
+</div>
+<p>Root actions are a special case of a selection. These represent behaviors that are defined for all members of agents; these are the highest granularity of an agent's behavior, such as "Find Partners" or "Eat" or "Reproduce". When you want to create a new set of Actions, you have the following choices.</p>
+<div class="section" title="Build">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Build"></a>Build</h4>
+</div>
+</div>
+</div>
+<p>The Build Action is a specialized action that allow the construction of member agents and spaces within a parent context. A Build Action executes once for each context before any initialization actions occur for any children agents of that context. Currently it is undefined wether a context's own Initialize Action is executed before the Build Action occurs, so implementors should not rely on any initialized values being available at build time.</p>
+</div>
+<div class="section" title="Initialize">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Initialize"></a>Initialize</h4>
+</div>
+</div>
+</div>
+<p>An Initialize action is excuted once and only once for every agent when the model is first started -- at time 0. Initialize Actions are guranteed to execute before any other non-builder action occurs.</p>
+</div>
+<div class="section" title="Rule">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Rule"></a>Rule</h4>
+</div>
+</div>
+</div>
+<p>A Rule executes once for every agent for every iteration of the model. An important note is that the actual sequence of rules is technically undefined. An implementor should not rely on the fact that a rule occurs before another rule in the list of agent actions though typically the order in which the rules were actually created is respected.</p>
+</div>
+<div class="section" title="Schedule">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Schedule"></a>Schedule</h4>
+</div>
+</div>
+</div>
+<p>A schedule is executed on a recurring basis, according to the values detailed below. Note that schedules are often overused. In most agent-based models it makes sense to have any behaviors occur at the same granularity using a Rule. Please note that Schedules are not currently supported in the Escap target, but that support should be available soon. In the following descriptions we refer to period as the current iteration of the model, that is where time = t.</p>
+<div class="section" title="Start">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Start"></a>Start</h5>
+</div>
+</div>
+</div>
+<p>The period that the schedule will first be invoked. For example, if this value is 100, and interval is 1, the schedue will be executed at times 100,101,102..</p>
+</div>
+<div class="section" title="Interval">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Interval"></a>Interval</h5>
+</div>
+</div>
+</div>
+<p>How often the schedule is invoked. For example, if this value is 3 and start is 1, the schedule will be executed at times 1,4,7..</p>
+</div>
+<div class="section" title="Priority">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Priority"></a>Priority</h5>
+</div>
+</div>
+</div>
+<p>Where the rule will be placed in the execution queue for a given time period. For example, if Schedule A's priority is set to 3 and Schedule B's is set to 2, Schedule B will be executed for all agents before Schedule B is executed for any agents.</p>
+</div>
+<div class="section" title="Pick">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Pick"></a>Pick</h5>
+</div>
+</div>
+</div>
+<p>Controls how many agents to execute the schedule against. While this value will have an effect on the Repast target, it is not recommended to be used for general models and is likely to be repalced by another approach.</p>
+</div>
+</div>
+<div class="section" title="Watch">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Watch"></a>Watch</h4>
+</div>
+</div>
+</div>
+<p>A Watch action is executed anytime the watched value is set for any agent. Note that the Action will be triggerred even if the state is simply set back to the value that it already has. It is important to be careful about creating Watches that might set the values of other Watch actions which might in turn trigger this watch. To clarify, if a modeler creates a Watch A for attribute a, and creates a target Set for it for attribute b, and Watch B is watching attribute b, then if Watch B has a target Set for attribute A, a circular execution could occur. This would cause the model to get stuck in its current iteration. To help model developers avoid this case, a warning will be provided if such a set of circular watch dependencies is created.</p>
+<div class="section" title="Attribute">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Attribute"></a>Attribute</h5>
+</div>
+</div>
+</div>
+<p>The attribute that will be monitored for change.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Selection"></a>Selection</h3>
+</div>
+</div>
+</div>
+<p>A selection defines what we are searching for (Agent), where we are searching for it (Space), and from whose perspective we are doing it (Selection):</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N1029D"></a>Selection</h5>
+</div>
+</div>
+</div>
+<p>The selection that we are searching "from". This seems to be the concept that new users have the most difficulty with, but it is key to understanding how Actions works. Just as with any other Action -- a Move command for example -- a selection needs to know what set of agents that it is working with. For example, if we want to define a selection B that finds the cells neighboring a rule B's agent, we would set selection B's selection to A.</p>
+</div>
+<div class="section" title="Agent">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Agent"></a>Agent</h5>
+</div>
+</div>
+</div>
+<p>Here we define what agent we will be looking for. In order for this to make sense, the agent has to be related in some meaningful way to the agent whose behavior we are defining. For example, it might be a partner agent or a location that we might want to move to. An agent must be specified unless we are searching within a continuous space, in which case this value should be empty, and the result of the selection will represent some location in that space. In the current version of the framework, we treat destination cell locations as agents, and require that location to be specified as a target agent, but in a future version we'll allow searches without defining an agent within grid spaces as well.</p>
+</div>
+<div class="section" title="Space">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Space"></a>Space</h5>
+</div>
+</div>
+</div>
+<p>The space that we want to search within. Of course, this must be specified if we use any spatial query terms (see below), but if we simply want to search across all agents it should not be specified.</p>
+<p>Represent Queries (Controls) on agents and Transformations, or Commands, on the result of those queries. Queries, Transformations and other in which each child target carries the execution and data context for it's particular path.</p>
+</div>
+<div class="section" title="For">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="For"></a>For</h5>
+</div>
+</div>
+</div>
+<p>This value is obsolete and will be replaced with a different mechanism in the next version of the modeling environment.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Query">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Query"></a>Query</h3>
+</div>
+</div>
+</div>
+<p>A Query represents a concrete criteria for our search. The name is a bit confusing because of potential for confusion with a generic query. Queries -- along with their cousin Evaluators -- define a function that is evaluated and that can take Agent attributes, and the results of other Actions as input. Queries are combined with each other and with the logic actions to determine the results of a selection for their direct target actions. </p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Function">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="N102BE"></a>Function</h5>
+</div>
+</div>
+</div>
+<p>A query function is evaluated to determine the results of a particular selection. Functions can represent very simple search criteria such as "My Age = Your Age", but they can also representSee the functions section for more information on specific functions.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Logic">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Logic"></a>Logic</h3>
+</div>
+</div>
+</div>
+<div class="section" title="Intersection">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Intersection"></a>Intersection</h4>
+</div>
+</div>
+</div>
+<p>An intersection contains only those agents that match all of its source actions. This is essentially equivalent to a logical AND statement and has similarities to an && operator in a java "if" statement. But it carries important differences too. For example, there is not neccesarily short circuit execution (it's not needed) and much richer criteria can be joined together.</p>
+</div>
+<div class="section" title="Union">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Union"></a>Union</h4>
+</div>
+</div>
+</div>
+<p>A union contains all agents that match any of its source actions. This essentially equivalent to a logical OR statement and shares similarities with the || operator in a java "if" statement.</p>
+</div>
+<div class="section" title="Difference">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Difference"></a>Difference</h4>
+</div>
+</div>
+</div>
+<p>A difference contains all agents that do not match any of its source actions. This essentailly equivalent to a logical NOT statement, and has similarities to (and important differences from) the Java else statement.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Example">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Example"></a>Example</h2>
+</div>
+</div>
+</div>
+<p>In this section, we'll look at an example that should make clear how the basic Actions approach works in a model. Say we want to define a behavior like:</p>
+<div class="literallayout">
+<p>"Search for a random agent within my vision that is the same age as I am. Find a location next to that agent that is not already occupied and move to it."<br>
+
+</p>
+</div>
+<p>Here, we create a sequence of actions like so:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Select every agent for every period of the model. ("Find Partner" Rule)</p>
+</li>
+<li class="listitem">
+<p>For every member of that selection, search for other agents of the same age within vision distance. ("Partner" selection.)</p>
+</li>
+<li class="listitem">
+<p>From "Partners" find a random member and search for a neighboring locations. ("Partner Neighbor" selection.)</p>
+</li>
+<li class="listitem">
+<p>Finally, move the agent in "Find Partner" to the "Partner Neighbor" location.</p>
+</li>
+</ol>
+</div>
+<p>Now, notice that although it's convenient to speak as if there is only one "Find Partner" and one "Partner Neighbor" in step 4 above, in fact selections are flowing through for each of the results of each of the previous action sequences, and we can refer to each of the directly. We could represent these behaviors in many different ways. For example, we might want to specify the model in a (hand-drawn) graphical language or in a (made-up) textual language:</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsExample.png"></div>
+<p>
+
+</p>
+<p>This is how it looks in an actual model:</p>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsExampleNew.png"></div>
+<p>
+
+</p>
+<p>And here is how this works in detail:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Create a Rule that will trigger the behavior. In this case, we want this rule to apply to all "Individual" agents within the model. (Space isn't relevant in this case.</p>
+</li>
+<li class="listitem">
+<p>Create a child Select Action that will find our partner. Two important things to note here:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>The selection occurs based on the "Find Partner" selection. This means that for each Individual in the model, we'll be searching from the point of view of that agent to some other selection of agents.</p>
+</li>
+<li class="listitem">
+<p>We also need to define what type of agent we want and in this case the space does matter. We want to find an agent that is nearby within the City space. If instead we wanted to find a partner in a social network, we'd specify that instead.</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>Create two child Query Actions:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>We want to search for someone who is the same age as us. This highlights the importance of the idea of the Selection in the Actions design. We're qualifying Age by our <span style="color: red"><font>Partner</font></span> and <span style="color: red"><font>ourselves</font></span>. The selection carries throughout the flow of execution and this context is an explicit part of the entire structure. Note that this is very different from the way control flow works in a traditional imperative language such as Java.</p>
+</li>
+<li class="listitem">
+<p>We also want to search using a function for nearness, "within", which takes a parameter of vision. Note that the spatial functions are all polymorphic -- if we decided later on that we would rather search within say "Kevin Bacon space", that is a graph structure representation of space, we would only need to change the space we've defined in Select Partner. (Design discussion note: re-examine this issue WRT possibility of allowing users to search in multiple spaces within the same query.)</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>Intersect the results of these two query components. This delineates the end of the selection definition for any target Actions.</p>
+</li>
+<li class="listitem">
+<p>Select a neighbor. Again, we can see the importance of Selections. Here, we are selecting from the point of view of the partner, not the initial agent that the current Rule is being executed for. Note that this time our target agent is a "Block", that is, a location within the city.</p>
+</li>
+<li class="listitem">
+<p>As above, define some queries. This time we want only those agents that are:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>available, and</p>
+</li>
+<li class="listitem">
+<p>neighbors of our partner.</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>And another intersection..</p>
+</li>
+<li class="listitem">
+<p>Finally, we move to the location we've found. All that's required at this point is to specify:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>The movement selection, or those agents that are moving, which in this case is the original agent we're executing the rule for, and</p>
+</li>
+<li class="listitem">
+<p>The destination, which is the cell that we've found. Note that the framework infers from the space definition that the Block agent is capable of hosting the Individual.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="section" title="Reference">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Reference_2"></a>Reference</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Diagrams">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Diagrams_2"></a>Diagrams</h3>
+</div>
+</div>
+</div>
+<p>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</p>
+<div class="section" title="Meta-Classes">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Meta-Classes_2"></a>Meta-Classes</h4>
+</div>
+</div>
+</div>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/ActionsDiagram.png"></div>
+<p>
+
+</p>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Details_2"></a>Details</h4>
+</div>
+</div>
+</div>
+<p>In the diagram above, all meta-objects except for Input, Literal, and the enumerators (lists of options) are Actions. Blue meta-classes are concrete (you can create and use them directly). Red meta-classes are key collaborations.</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>An Act is anything that might happen during the execution of an Agent-Based Model.</p>
+</li>
+<li class="listitem">
+<p>All Actions have as their root-most source action a Root. These are added first to any agent behavior and act as triggers for all target behavior. For example, a Watch will execute anytime the watched attribute is modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that Accessor includes a reference to some Attribute, but it does. To see these kinds of relationships you will want to refer to the metaabm.ecore file itself.)#Actions are targets and sources of one another, but an Act can never have itself as a source. (That is, Actions are acyclic, but branches can re-converge. When we refer to an Act source or target, we typically mean to include all ancestors or descendants, not just the immediately connected Act.)</p>
+</li>
+<li class="listitem">
+<p>All Actions (except for root Actions) reference a Select, referred to as the "selected" relation. An ASelect represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent) "world" that is currently being selected.</p>
+</li>
+<li class="listitem">
+<p>Commands trigger some model state change (Set) or spatial transformation (Transform).</p>
+</li>
+<li class="listitem">
+<p>Controls determine wether target Actions are executed and against what agents. They are in some sense query terms and include Query actions and Logic Actions.</p>
+</li>
+<li class="listitem">
+<p>Transforms also specify a "destination" Select. This represents aspects that the selected agent(s) will transform to. For example, a Move may use a Rule to select all SugarAgents (type) in the SugarGrid (space) every period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time implicit).</p>
+</li>
+<li class="listitem">
+<p>Sinks are Actions which use some Function (see next section) to interpret state in the form of Inputs. Inputs can come from selected agent attributes, other Actions, or literal values.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="chapter" title="Chapter 5. Functions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Functions"></a>Chapter 5. Functions</h2>
+</div>
+</div>
+</div>
+<p>Functions are relatively simple in terms of model design, but we need to understand how particular functions work in order to develop models. Functions are divided in two ways. By type:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Operators are simple calculations sharing the same type.</p>
+</li>
+<li class="listitem">
+<p>Generics that can represent any general function that takes some well-defined input(s) and returns some well-defined output(s).</p>
+</li>
+</ol>
+</div>
+<p>And by usage:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Functions proper can return any value and are used in Evaluate actions.</p>
+</li>
+<li class="listitem">
+<p>Logicals return some boolean result and are used by Query actions to decide wether target Actions apply to a particular selection, and by Evaluate actions just as with any other functions. Input types should be defined as generally as possible.</p>
+</li>
+</ol>
+</div>
+<p>A tehcnical note: conceptually, functions can return multi-values, but that is not currently implemented in the reference targets because of limitations of the target language Java.</p>
+<p>These overlap, so we have </p>
+<div class="section" title="Reference">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Reference_3"></a>Reference</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Diagrams">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Diagrams_3"></a>Diagrams</h3>
+</div>
+</div>
+</div>
+<p>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</p>
+<div class="section" title="Meta-Classes">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Meta-Classes_3"></a>Meta-Classes</h4>
+</div>
+</div>
+</div>
+<p>
+
+</p>
+<div class="mediaobject">
+<img src="images/FunctionsDiagram.png"></div>
+<p>
+
+</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+</body>
+</html>
diff --git a/documentation/ModelersGuide.php b/documentation/amp.php
similarity index 92%
rename from documentation/ModelersGuide.php
rename to documentation/amp.php
index 45d221c..6eacaab 100755
--- a/documentation/ModelersGuide.php
+++ b/documentation/amp.php
@@ -2,7 +2,7 @@
$pageTitle = "AMP - Documentation";
$html = '<div id="midcolumn">';
- $html .= file_get_contents('ModelersGuide.html');
+ $html .= file_get_contents('amp.html');
$html .= "</div>";
# Generate the web page
diff --git a/documentation/book.css b/documentation/book.css
new file mode 100644
index 0000000..8ea5bb4
--- /dev/null
+++ b/documentation/book.css
@@ -0,0 +1,239 @@
+.literallayout .code {
+ display: block;
+ border: 1px solid gray;
+ margin: 1em;
+ padding: 1em;
+ background-color: #F0F0F0;
+}
+
+code {
+ display: inline;
+}
+
+pre.programlisting {
+ display: block;
+ text-align: left;
+ text-indent: 0.00pt;
+ margin-top: 0.000000pt;
+ margin-bottom: 0.000000pt;
+ margin-right: 0.000000pt;
+ margin-left: 15pt;
+ font-size: 10.000000pt;
+ font-weight: medium;
+ font-style: Regular;
+ color: #4444CC;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+ font-family: "Courier New";
+}
+
+P.Code {
+ display: block;
+ text-align: left;
+ text-indent: 0.00pt;
+ margin-top: 0.000000pt;
+ margin-bottom: 0.000000pt;
+ margin-right: 0.000000pt;
+ margin-left: 15pt;
+ font-size: 10.000000pt;
+ font-weight: medium;
+ font-style: Regular;
+ color: #4444CC;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+ font-family: "Courier New";
+}
+
+H6.CaptionFigColumn {
+ display: block;
+ text-align: left;
+ text-indent: 0.000000pt;
+ margin-top: 3.000000pt;
+ margin-bottom: 11.000000pt;
+ margin-right: 0.000000pt;
+ margin-left: 0.000000pt;
+ font-size: 9.000000pt;
+ font-weight: medium;
+ font-style: Italic;
+ color: #000000;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+ font-family: "Arial";
+}
+
+P.Note {
+ display: block;
+ text-align: left;
+ text-indent: 0pt;
+ margin-top: 19.500000pt;
+ margin-bottom: 19.500000pt;
+ margin-right: 0.000000pt;
+ margin-left: 30pt;
+ font-size: 11.000000pt;
+ font-weight: medium;
+ font-style: Italic;
+ color: #000000;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+ font-family: "Arial";
+}
+
+EM.UILabel {
+ font-weight: Bold;
+ font-style: Regular;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+}
+
+EM.CodeName {
+ font-weight: Bold;
+ font-style: Regular;
+ text-decoration: none;
+ vertical-align: baseline;
+ text-transform: none;
+ font-family: "Courier New";
+}
+
+SPAN.NoWrap {
+ white-space: nowrap;
+}
+
+/* following font face declarations need to be removed for DBCS */
+body,h1,h2,h3,h4,h5,h6,p,table,td,caption,th,ul,ol,dl,li,dd,dt {
+ font-family: Arial, Helvetica, sans-serif;
+ color: #000000
+}
+
+pre {
+ font-family: Courier, monospace
+}
+
+/* end font face declarations */
+ /* following font size declarations should be OK for DBCS */
+body,h1,h2,h3,h4,h5,h6,p,table,td,caption,th,ul,ol,dl,li,dd,dt {
+ font-size: 10pt;
+}
+
+pre {
+ font-size: 10pt
+}
+
+/* end font size declarations */
+body {
+ background: #FFFFFF
+}
+
+h1 {
+ font-size: 18pt;
+ margin-top: 5;
+ margin-bottom: 1
+}
+
+h2 {
+ font-size: 14pt;
+ margin-top: 25;
+ margin-bottom: 3
+}
+
+h3 {
+ font-size: 11pt;
+ margin-top: 20;
+ margin-bottom: 3
+}
+
+h4 {
+ font-size: 10pt;
+ margin-top: 20;
+ margin-bottom: 3;
+ font-style: italic
+}
+
+p {
+ margin-top: 10px;
+ margin-bottom: 10px
+}
+
+pre {
+ margin-left: 6;
+ font-size: 9pt
+}
+
+a:link {
+ color: #0000FF
+}
+
+a:hover {
+ color: #000080
+}
+
+a:visited {
+ text-decoration: underline
+}
+
+ul {
+ margin-top: 0;
+ margin-bottom: 10
+}
+
+li {
+ margin-top: 0;
+ margin-bottom: 0
+}
+
+li p {
+ margin-top: 0;
+ margin-bottom: 0
+}
+
+ol {
+ margin-top: 0;
+ margin-bottom: 10
+}
+
+dl {
+ margin-top: 0;
+ margin-bottom: 10
+}
+
+dt {
+ margin-top: 0;
+ margin-bottom: 0;
+ font-weight: bold
+}
+
+dd {
+ margin-top: 0;
+ margin-bottom: 0
+}
+
+strong {
+ font-weight: bold
+}
+
+em {
+ font-style: italic
+}
+
+var {
+ font-style: italic
+}
+
+div.revision {
+ border-left-style: solid;
+ border-left-width: thin;
+ border-left-color: #7B68EE;
+ padding-left: 5
+}
+
+th {
+ font-weight: bold
+}
+
+xxtd{
+ border-top:2px solid black;
+}
\ No newline at end of file
diff --git a/documentation/image/600px-MetaABMStructure.png b/documentation/images/600px-MetaABMStructure.png
similarity index 100%
rename from documentation/image/600px-MetaABMStructure.png
rename to documentation/images/600px-MetaABMStructure.png
Binary files differ
diff --git a/documentation/image/AMFScreenshot.png b/documentation/images/AMFScreenshot.png
similarity index 100%
rename from documentation/image/AMFScreenshot.png
rename to documentation/images/AMFScreenshot.png
Binary files differ
diff --git a/documentation/image/AMPArchitectureDiagram.jpg b/documentation/images/AMPArchitectureDiagram.jpg
similarity index 100%
rename from documentation/image/AMPArchitectureDiagram.jpg
rename to documentation/images/AMPArchitectureDiagram.jpg
Binary files differ
diff --git a/documentation/image/AMPScreenshot.png b/documentation/images/AMPScreenshot.png
similarity index 100%
rename from documentation/image/AMPScreenshot.png
rename to documentation/images/AMPScreenshot.png
Binary files differ
diff --git a/documentation/image/ActionsBlocks.png b/documentation/images/ActionsBlocks.png
similarity index 100%
rename from documentation/image/ActionsBlocks.png
rename to documentation/images/ActionsBlocks.png
Binary files differ
diff --git a/documentation/image/ActionsComplexLogic.png b/documentation/images/ActionsComplexLogic.png
similarity index 100%
rename from documentation/image/ActionsComplexLogic.png
rename to documentation/images/ActionsComplexLogic.png
Binary files differ
diff --git a/documentation/image/ActionsComplexLogicNoOr.png b/documentation/images/ActionsComplexLogicNoOr.png
similarity index 100%
rename from documentation/image/ActionsComplexLogicNoOr.png
rename to documentation/images/ActionsComplexLogicNoOr.png
Binary files differ
diff --git a/documentation/image/ActionsDiagram.png b/documentation/images/ActionsDiagram.png
similarity index 100%
rename from documentation/image/ActionsDiagram.png
rename to documentation/images/ActionsDiagram.png
Binary files differ
diff --git a/documentation/image/ActionsExample.png b/documentation/images/ActionsExample.png
similarity index 100%
rename from documentation/image/ActionsExample.png
rename to documentation/images/ActionsExample.png
Binary files differ
diff --git a/documentation/image/ActionsExampleNew.png b/documentation/images/ActionsExampleNew.png
similarity index 100%
rename from documentation/image/ActionsExampleNew.png
rename to documentation/images/ActionsExampleNew.png
Binary files differ
diff --git a/documentation/image/ActionsSelBoundary1.png b/documentation/images/ActionsSelBoundary1.png
similarity index 100%
rename from documentation/image/ActionsSelBoundary1.png
rename to documentation/images/ActionsSelBoundary1.png
Binary files differ
diff --git a/documentation/image/ActionsSelBoundary2.png b/documentation/images/ActionsSelBoundary2.png
similarity index 100%
rename from documentation/image/ActionsSelBoundary2.png
rename to documentation/images/ActionsSelBoundary2.png
Binary files differ
diff --git a/documentation/image/ActionsSelBoundaryComplex.png b/documentation/images/ActionsSelBoundaryComplex.png
similarity index 100%
rename from documentation/image/ActionsSelBoundaryComplex.png
rename to documentation/images/ActionsSelBoundaryComplex.png
Binary files differ
diff --git a/documentation/image/ActionsSequence.png b/documentation/images/ActionsSequence.png
similarity index 100%
rename from documentation/image/ActionsSequence.png
rename to documentation/images/ActionsSequence.png
Binary files differ
diff --git a/documentation/image/ActionsSimpleMultiple.png b/documentation/images/ActionsSimpleMultiple.png
similarity index 100%
rename from documentation/image/ActionsSimpleMultiple.png
rename to documentation/images/ActionsSimpleMultiple.png
Binary files differ
diff --git a/documentation/image/ActionsSimpleSequence.png b/documentation/images/ActionsSimpleSequence.png
similarity index 100%
rename from documentation/image/ActionsSimpleSequence.png
rename to documentation/images/ActionsSimpleSequence.png
Binary files differ
diff --git a/documentation/image/ActionsSimpleSequence2.png b/documentation/images/ActionsSimpleSequence2.png
similarity index 100%
rename from documentation/image/ActionsSimpleSequence2.png
rename to documentation/images/ActionsSimpleSequence2.png
Binary files differ
diff --git a/documentation/image/EpidemicModelAgentProperties.png b/documentation/images/EpidemicModelAgentProperties.png
similarity index 100%
rename from documentation/image/EpidemicModelAgentProperties.png
rename to documentation/images/EpidemicModelAgentProperties.png
Binary files differ
diff --git a/documentation/image/EpidemicModelComparison.png b/documentation/images/EpidemicModelComparison.png
similarity index 100%
rename from documentation/image/EpidemicModelComparison.png
rename to documentation/images/EpidemicModelComparison.png
Binary files differ
diff --git a/documentation/image/EpidemicModelControls.png b/documentation/images/EpidemicModelControls.png
similarity index 100%
rename from documentation/image/EpidemicModelControls.png
rename to documentation/images/EpidemicModelControls.png
Binary files differ
diff --git a/documentation/image/EpidemicModelProperties.png b/documentation/images/EpidemicModelProperties.png
similarity index 100%
rename from documentation/image/EpidemicModelProperties.png
rename to documentation/images/EpidemicModelProperties.png
Binary files differ
diff --git a/documentation/image/EpidemicModelRunning.png b/documentation/images/EpidemicModelRunning.png
similarity index 100%
rename from documentation/image/EpidemicModelRunning.png
rename to documentation/images/EpidemicModelRunning.png
Binary files differ
diff --git a/documentation/image/Functions.png b/documentation/images/Functions.png
similarity index 100%
rename from documentation/image/Functions.png
rename to documentation/images/Functions.png
Binary files differ
diff --git a/documentation/image/FunctionsDiagram.png b/documentation/images/FunctionsDiagram.png
similarity index 100%
rename from documentation/image/FunctionsDiagram.png
rename to documentation/images/FunctionsDiagram.png
Binary files differ
diff --git a/documentation/image/StructureComplexDiagram.png b/documentation/images/StructureComplexDiagram.png
similarity index 100%
rename from documentation/image/StructureComplexDiagram.png
rename to documentation/images/StructureComplexDiagram.png
Binary files differ
diff --git a/documentation/image/StructureSimpleDiagram.png b/documentation/images/StructureSimpleDiagram.png
similarity index 100%
rename from documentation/image/StructureSimpleDiagram.png
rename to documentation/images/StructureSimpleDiagram.png
Binary files differ
diff --git a/documentation/image/WikiExample.png b/documentation/images/WikiExample.png
similarity index 100%
rename from documentation/image/WikiExample.png
rename to documentation/images/WikiExample.png
Binary files differ
