Developing Agent Models with Repast Michael North

Transcription

1 Developing Agent Models with Repast Michael North

2 Agent-Based Models Can Be Constructed Using a Variety of Approaches Environments are the stage upon which agents play These environments must be constructed A variety of processes exist to construct software, including agent-based models: Traditional methods such as the systems development life cycle ( waterfall ) method or the evolutionary spiral method can be used Newly emerging agile development methods such as Extreme Programming can be used Plain old quick and dirty coding can be used Many, many other approaches exist Software Engineering is a complex discipline, there is no need to restate the details of these methods here However, regardless of which methods are used, several important issues must be addressed when developing and using models

3 Several Important Issues Must Be Addressed When Developing and Using Models The model must be correctly designed The model should be fully documented The model must undergo suitable verification and validation (V&V) The model must be properly used

4 ABMS Design is Often Iterative and Evolutionary ABMS design is often iterative: Most substantial designs undergo major revisions before they are completed The revisions often occur in stages where a design concept is considered, tested in a prototype form, and then adjusted as needed Prototyping is often done using live simulations, simple tools such as StarLogo, or even Excel spreadsheets The steps need not be explicitly defined and are often simply implicit ABMS design is often evolutionary: The model designers learn more about the model (and possibly the underlying system) during each design iteration This learning can be used to improve the design during the next step

5 ABMS Architectures Have Three Basic Components User Interface The interface collects input data and displays output data The simulation engine performs the simulation work Data Flow Simulation Engine Data Flow Data Flow Data Storage Data storage provides persistence for agents and their environments

6 The ABMS Architectural Components are Conceptual The ABMS architectural components define core architectural functions These core functions can be provided by a huge range of software tools These core functions can be implemented in many different combinations, for example: Some ABMS tools unify the user interface and simulation engine functions into a single package Some user interface tools use completely different mechanisms for input collection and output reporting These components are not intended to define a single rigid ABMS architecture, but rather they are intended to provide a solid conceptual framework for later learning and ABMS tool selection

7 Several ABMS Architectural Styles Are Commonly Used Tightly coupled architectures confine the user interface and simulation engine components into a single process space or program An example is a monolithic C program Another example is a basic Java console application Loosely coupled architectures divide the user interface and simulation engine components into separate process spaces or programs An example is a Java program with a Java Servlet interface Another example is a Microsoft Visual C++ program with a Visual Basic interface Distributed architectures spread the user interface and simulation engine components across separate processes on many computers An example is a Java Remote Method Invocation (RMI) program with a Java Servlet interface Another example is a Visual C++ Distributed Component Object Model (DCOM) program with a Active Server Pages (ASP) interface

8 Tightly Coupled Architectures Tend to Be Easier To Work With But Less Scalable Than the Other Architectures Tightly coupled architectures tend to be simpler than the other styles: They tend to have fewer required modules, since modules can simultaneously handle display, simulation, and storage They tend to have simpler communications between modules, since direct function calls are usually sufficient Since they tend to be simpler, systems with tightly coupled architectures are usually easier to develop and maintain than those designed using one of the other architectures However, since these architectures are not as well factored, they tend to be less scalable than the other architectures: Tightly coupled architectures are well suited to small-scale ABMS Tightly coupled architectures generally are not well suited to medium or large-scale ABMS

9 Loosely Coupled Architectures Tend to Sit Between the Other Styles In Terms of Development Challenge and Scalability Loosely coupled architectures tend to be be more complex than tightly coupled architectures: They tend to have more required modules, since display, simulation, and storage are separated for each program function They tend to have more complex communications between modules, since direct function calls alone are often not sufficient Loosely coupled architectures tend to be simpler than distributed architectures: They tend to have fewer required modules, since a single module usually provides the simulation engine functions They tend to have less complex communication within the simulation module since direct function calls are usually sufficient However, since the simulation engine is not as well factored as in distributed architectures, loosely coupled architectures tend to be less scalable on the high end Loosely coupled architectures are generally well suited to medium-scale but not large-scale ABMS

10 Distributed Architectures Tend To Be the Most Scalable But Also the Most Challenging to Develop Distributed architectures tend to be be more complex than loosely coupled architectures: They tend to have more required modules, since they have separate modules for various simulation engine functions, as well as for display and storage They tend to have more complex communications between modules, since direct function calls are usually not sufficient, even within the simulation engine However, since the simulation engine is better factored than in loosely coupled architectures, distributed architectures tend to be much more scalable Distributed architectures generally are well suited to largescale ABMS

11 A Tale of Two Models Design: Use a random distribution to gerne generate a random variate. Apply this variate to the subject heading, following a motion using the previous heading. The motion previously one referred to should use a distance of three. Repeat for the other direction of rotation. Bound the rotations by 50 degrees. Do this to wiggle. exclusive Code: to a15050 [ fd 1 rt random 50 lt random 50] end Excerpts from Model A Design: Use the following steps to wiggle: 1. Move one space forward in the current direction. 2. Try turning right by a random number of degrees between one and Try turning left by a random number of degrees between one and 49. Code: to wiggle ;; Move one space forward. forward 1 ;; Try turning right. right random 50 ;; Try turning left left random 50 end Excerpts from Model B

12 How Can Agent Environments Be Designed? There are many ways to proceed One suggested path is as follows: Define the relevant agents Define the relevant agent interactions Pick the simplest topology that will support the relevant agent interactions, unless there is a very specific reason to chose a more complicated one Add as little agent-environment interaction as possible to support the relevant agent interactions, unless there is a very specific reason to add more Test the resulting model Grudgingly add complexity to the topology and details to the agent-environment interaction until the model works as desired

13 How Can Agent Topologies Be Selected? Defining the topology of interaction is a process of abstraction: For example, few real-life interactions are actually defined by a grid However, a grid still might capture the relevant dynamics of the interaction of interest The design of agent environments is largely dictated by interaction topology and implementation concerns: Some topologies are more amenable to certain kinds of interactions Some topologies are more or less supported among various toolkits In particular, implementations become more complicated when visualization of custom environments is required Note that topology selections can cause artifacts such as agentenvironment couplings

14 V&V, V&V, V&V! Verification matches a model against its design Validation matches a model against its real world subject Design Model Subject Verification Validation According to many modelers, V&V is the single most important step in model development: Before appropriate V&V, models are toys After appropriate V&V, models are tools V&V can be a complex process: Law and Kelton s book describes model V&V in detail Today some basic ideas will be discussed

15 CYA ( Cover( Your Analysis ) One simple way to think about V&V is covering cases: Cases are reasonable combinations of inputs and outputs for a design, a model, or a subject In principle, a model is fully verified when all of the design cases correctly match model cases and vice versa In principle, a model is fully validated when all of the model cases correctly match real world cases and vice versa For many substantial models, fully explicit coverage is difficult if not impossible However, meaningful areas can be covered

16 V&V is Like Painting The set of all possible cases Parameter sweeps can be used to collect data for statistical analysis Cases based on known results and standard models can be covered Cases that are of special interest or likely to reveal problems can be covered Many other approaches are also possible, these are only some example suggestions See Law and Kelton for a more complete coverage

17 Use It (Properly) or Lose It! Even properly designed and developed models can be misused Properly using models properly requires attention to many issues including the following: The model s data requirements must be understood and met The model s design limits must be understood and followed The model s V&V limits must be understood and followed The model s stochastic requirements, if any, must be understood and met User education is key

18 Agents Exist Within Environments and Model Development Processes Agents exist within environments, including the following: Soups Grids Networks and graphs Irregular polygons Quasi-agent environments Agents exist within model development processes Both of these homes where discussed today

19 Now for More Fun! Let s do some additional hands-on exercises

20 Developing Agent Models with Repast Are there additional questions? Michael North