Hide Notes 

Slide 1: Ascape: An Agent Based Modeling Framework in Java Presented at Agent Simulation: Applications, Models and Tools October 16, 1999 University of Chicago Miles T. Parker Software Engineer Center for Social and Economic Dynamics Http://www.brook.edu/es/dynamics/models/ascape mparker@brook.edu Copyright 1999 The Brookings Institution 1775 Mass. Ave. NW Washington, DC 20036 voice 202.797.6136 fax 202.797.6319
Slide 2: Ascape: An Agent Based Modeling Framework in Java Ascape is a toolkit created at Brookings to support the design, analysis and distribution of agent based models. Its principle design goals include abstraction and generalization of key agent modeling concepts, ease of use and configurability, best attainable performance, and deployment anywhere. Ascape was developed primarily to support our models of social and economic systems, which typically comprise agents with rules of behavior interacting in networks (e.g. regular lattices, random graphs, soups) but the framework may be adaptable to other model types. In addition to demonstrating Ascape design features and capabilities, we'll build (look at?) a simple model in Ascape, talk about future goals, discuss the use of Java for agent based modeling, and invite questions about Ascape and modeling design issues
Slide 3: Design Goals • • • • • • • Generalized Abstract Portable Easy to Use Expressive Robust Fast
Slide 4: Generalization • Obviously, applicable to many problem domains • As many common features as possible – – – – Charting Model Views Parameter management tools etc., etc. • Large libraries of common structures and behaviors
Slide 5: Abstraction • Should be possible to make significant changes in one aspect of model without affecting others – – – – Dimensions, Topology Rules Structure Rule Execution Order • Promote exploration and experimentation • Allows easy mixing and matching of model design and tools
Slide 6: Portability • Greatly facilitates sharing of projects, methods, and results with colleagues and the general public • Does not lock you into specific hardware or technology choices, except... • Java – Cross-platform really works – Web very important – All or nothing: code must be 100% Pure Java, no native code in core – Other solutions possible
Slide 7: Ease of Use • Basic assumption: Small population of ‘experts’, large population of potential ‘smart users’ • Avoid frustration barriers
Slide 8: Ease for Non-Coders • User configurable and modifiable – Of course, complete control of model parameters at runtime – No programming necessary for creating graphs, customizing views – Soon, should be no programming for changing basic rules and possibly structure • Long Term Goal: complete model development without coding – Not as hard as it might seem – But would require significant development resources
Slide 9: Ease for Coders • Relatively easy and straight-forward to develop – Should be possible for people with basic skills to build simple models from ‘off-the-shelf’ parts and progress from there – The most complex models should be reasonably straightforward, and the code should remain easy to work with and understand – As much functionality as possible should be provided ‘automatically’
Slide 10: Expressiveness • Should be able to specify and develop a model with the simplest possible high-level description without obscuring important details • Careful design can provide power and control • Possible problem: important details can be glossed over • Helps in Mapping to more general descriptions (XML!)
Slide 11: Robust • Tolerant of different styles and methods of use • Reports when broken • Breaks at Compile Time, not Runtime
Slide 12: Performance • For many models, performance is not a big issue....But we always seem to want more speed • Java performance good – – – – Speed now comparable to C++ in many applications Significant improvements in Java Environments Perception v. Reality Graphics still need work • Design often much more important than platform • Supporting pluggable views also helps
Slide 13: Structure • Scapes are Agents Agent Cell HostCell CellOccupant Scape ScapeGraph ScapeArray1D ScapeVector ScapeArray2D
Slide 14: Structure • There can be many different kinds of Scapes 1D Array Network Vector 2D Array
Slide 15: Structure • Example: Prisoner’s Dilemma Root Vector Lattice Host Cell Cell Occupant
Slide 16: Structure • Example: Long House Valley Root Zones,Etc.. Households Settlements Map (Hosts) Location Household Settlement
Slide 17: Behavior • Rules belong to Scapes Root Vector •{Iterate, •Notify Views} Lattice Host Cell Cell Occupant •{Random Walk, •Play Neighbors, •Fission, •Die}
Slide 18: Behavior • Eat your own dog food Root Vector •{Iterate, •Notify Views} Lattice Host Cell Cell Occupant
Slide 19: Behavior • Rules can propagate Root Vector •{Iterate, •Notify Views} Lattice •{Iterate..} Host Cell Cell Occupant
Slide 20: Behavior • Rules can propagate Root Vector •{Iterate, •Notify Views} •{Iterate..} Lattice •{Iterate..} Host Cell Cell Occupant
Slide 21: Behavior • Rules can be executed in Serial •Agent 1 Vector •Random Walk, •Play Neighbors, •Fission, •Die •Agent 2 •Random Walk, •Play Neighbors, •Fission, •Die •...
Slide 22: Behavior • Or rules can be executed in Parallel •Agent 1 •Random Walk Vector •Agent 2 •Random Walk •… •Agent 1 •Play Neighbors •Agent 2 •Play Neighbors •...
Slide 23: Behavior • Rules can provide information about themselves – Is Random – Can Cause Removal • Execute and Update – Example: Diffusion
Slide 24: Generalization/Abstraction • myCell.getCellsNear(2); Moore Von Neumann Graph Vector
Slide 25: Generalization/Abstraction • myCell.findMaximumWithin(FOOD, 2); Moore Von Neumann Graph Vector
Slide 26: Observation / Control • Views belong to Scapes Root Vector Control Panel Data View Lattice Overhead View
Slide 27: Observation / Control • Scapes can be their own views Root Vector Root Lattice
Slide 28: Observation / Control • After Iteration Report Update View Scapes (Subscapes) Scape Event View Event
Slide 29: Observation / Control • Subscapes report to their own views Report Update Scapes (Subscapes) View Scape Event View Event
Slide 30: Observation / Control • Scapes can send idle ticks Tick (Pause) View Scapes (Subscapes) Scape Event View Event
Slide 31: Observation / Control • When views have finished updating.. View Respond Updated Scapes (Subscapes) Scape Event View Event
Slide 32: Observation / Control • ..And all subscape views have responded to their scapes View Scapes Respond Updated (Subscapes) Scape Event View Event
Slide 33: Observation / Control • The cycle continues Report Update Respond Updated Views Scapes (Subscapes) Scape Event View Event
Slide 34: Observation / Control • Other scape events Report Update Tick (Pause) View Scapes (Subscapes) Request Setup Report Start Report Stop Report Quit Scape Event View Event
Slide 35: Observation / Control • Control Events Scapes (Subscapes) Request Start Request Stop Request Pause Request Resume Request Quit Scape Event View Event Control
Slide 36: Observation / Control • All Events Report Update Tick (Pause) Request Setup Report Start Views Scapes (Subscapes) Report Stop Report Quit Respond Updated Request Start Request Stop Request Pause Request Resume Request Quit Scape Event View Event Control
Slide 37: Performance Optimization • The best optimizations are natural outgrowths of abstract design – Example: storing neighbors
Slide 38: Performance Optimization • Example: storing neighbors Moore Von Neumann •neighbors = new Cell[4]; •neighbors[0] = getCellAt(x + 1, y); •neighbors[1] = getCellAt(x - 1, y); •neighbors[2] = getCellAt(x, y + 1); •neighbors[3] = getCellAt(x, y - 1); •neighbors = new Cell[8]; •For dx = -1 to 1 •For dy = -1 to 1 •… •End For •End For Graph •Edges = getEdges(); •For Each edge in edges •edge.getVertice() •End For Vector •neighbors = new Cell[2]; •neighbors[0] = getCellAt(x + 1); •neighbors[1] = getCellAt(x - 1);
Slide 39: Performance Optimization • Example: storing neighbors Moore Von Neumann Graph Vector
Slide 40: Performance Optimization • But others are not so obvious – Profiling can help – Example: Factor of a hundred improvement by eliminating unnecessary object instantiation • In general, shouldn’t be model developers job: frameworks allow optimizations to be transparent to users • Still some areas where developer’s intervention is needed, but make it optional – Example: Draw Updates
Slide 41: Performance Optimization • Example: Draw Updates Scan Buffer Draw Copy On Screen
Slide 42: Performance Optimization • Example: Draw Updates Scan Buffer Draw Update Requested On Screen Copy
Slide 43: Performance Optimization • Example: Draw Updates Scan (Cheap) Buffer Draw(Expensive) Update Requested On Screen Copy
Slide 44: Demonstrations • • • • Prisoner’s Dilemma Norms Firms Long House Valley
Slide 45: Build a Model!
Slide 46: Short-term Goals • Structure and Rule Browsing – Hierarchical (Explorer) style views – Ability to change any model state on the fly – Ability to easily add, remove and reorder rules • Support for Graphs – (Just waiting for a good model) • Complete abstractions for all Common Graphs • More rules and searching methods • Overhead view enhancements
Slide 47: Mid-term Goals • Mapping to Higher Level Descriptions (XML) • Switch to enumeration model throughout algorithms – – – – Cleaner More amenable to abstraction May be significant performance advantages A bit more of a conceptual load • New view styles – Image view already exists – 3D views, zooming views etc..
Slide 48: Long-term Goals • Non-discrete time and space • Different time and space resolution • Parallelization / SIMD – All in the engine
Slide 49: Long-term Goals • Scalability – Many, though not all, of our models have fairly small populations – Those with very large populations need special case anyway • trade models with over a million agents interacting – Rely on technology to innovate or grow us out of problems – If that doesn’t work…
Slide 50: Long-term Goals, cont... • Scheduling Sophistication – Our models typically use static, homogeneous, rules that are iterated against whole populations.