ABM: Issues Dr Andy Evans

Structuring a model Models generally comprise: Objects. Environment. I/O code. Data reporting code. Some kind of time sequencing. Some kind of ordering of processing within a time step. Some kind of decision making and/or rulesets. In agent models these are all relatively explicit.

Structural issues with modelling Model Construction Frameworks Decision making frameworks

Structural issues with modelling Artefacts Timing Data Geography Model Construction Frameworks Decision making frameworks

Artefacts Say we had a time step in which cells became x when a neighbour up and left was x. If we calculate from the top left corner and run across each row, we get this: We see that in one time step, the third cell shouldn’t be x. We’d get a different result if we ran from the lower right. xxx x x x

Artefacts With CAs this seems simple. In the Excel CA a couple of practicals ago, we saw that you generally copy the entire grid, then put changes into another grid temporarily while doing the calculations. This is then copied back into the CA array when everything is complete. This prevents you acting on changed neighbours. However, with large agent models we don’t want to be copying the whole system each time. So, we might just wait until the end of a step and update everything. This is certainly one solution.

Synchronous scheduling In general models will have a global time sequence of time- steps (sometimes called ticks in Logo-based systems) maintained by a clock. The agents are told to enact their behaviour at given time-steps by a scheduler. When there is one global time and all agents act at this speed, none getting ahead in the sequence, this is known as synchronisation. All agents broadly see it as the same time. Synchronisation doesn’t, however, need every agent to do something each time-step: this would unnecessarily increase processing requirements. Different agents may run on different timescales (every five ticks, for example).

Event-based scheduling Different agents may run based on event triggers. In general, these still work within a synchronised time-series. Either way, as with our array problem, we need to make sure updates of contacted agents are either complete or stored for later depending on our model. However, this is often a hard choice. Does a housebuyer always arrive too late to put in an offer? Sometimes they must arrive in time. In general, therefore, we randomise the order of agent steps.

Parallel synchronisation As it is for agents, so it is for parallel models – only more so. Parallel developers think hard about synchronisation. Most models adopt conservative synchronisation of more or less strength, that is, there is some central scheduler that coordinates jobs around the global time. We need to avoid processes happening out of sync for most systems. This is particularly the case in geographical systems, which tend to be based on Markov processes / causality.

Lookahead However, some processing can be done without communication. It is also the case that events/processes can be stacked and run through in sequence at whatever speed a processor can until it needs to respond. The difference between now and the first necessary communication out is known as the lookahead. A lot of effort goes into working out what this is and how much can be done in it.

Optimistic scheduling Optimistic scheduling plays fast and loose with the amount that is done in this time, but then recovers if a critical causal event needs to be injected into a process. For example, in the Time Warp Algorithm, processing is rolled- back if necessary, including any messages sent. As you can imagine, this gets fairly complicated, and these algorithms only really work where there is history path- independence in the system.

Monte Carlo sampling It is also the case that if we have input data repeatedly entering the model, this can lead to harmonic artefacts. Data running through the system can lead to internal dynamics that cycle at the same periodicity producing artefacts; this is particularly problematic with self-adjusting systems. We need some randomisation. In general we sample input data randomly, even if we act to include certain periodicities (e.g. seasonal). We sample weighted by distribution – so-called Monte Carlo sampling. The same thing happens with geographical variation, so we randomly sample agents occurring in space too (though more rarely based on a distribution).

Stochastic models Deterministic models always end up with the same answer for the same inputs. Stochastic models include some randomisation, either of data or behaviour. As we have seen, these are usually quantified by repeated runs. However, sometimes we want to run under the same “random” conditions (e.g. to understand some behaviour). Standard computers without external inputs never generate truly random numbers – they are random-like sequences, adjusted by some random seed. If we record the random seed, we can re-run the “random” model exactly.

Space Boundary types: Infinite. Bound. Torus. Other topologies. Organisation: Continuous. Grid (square; triangular; hexagonal; other) Irregular areas, or quad-tree. Network Neighbourhoods: Moore Von Neumann Diagonal Euclidian Network

GIS and Agent Systems Problem is GIS inherently static GIS data model represents a single point in time Some work into a temporal GIS data model, but no widespread solutions But time essential in an ABM: Need to link GIS and ABM Two approaches: loose vs tight/close coupling

Tight Coupling GIS and ABM communicate directly. At each iteration the ABM updates GIS on new system state. GIS can display model state dynamically.

Loose Coupling GIS prepare input for model and display/analyse results. Model does not need to communicate with GIS directly. Quick: ABM not constrained by speed of GIS.

Issues Ideally, then, we need: A clock/ scheduler, if we’re not calling each agent every time-step (and/or some kind of event-watching system). Some way of randomising sampling of agents/agent locations. Some way of running Monte Carlo sampling of both inputs and parameters. A variety of projections/space types/boundaries.

Helpful Easy I/O. Saving model sequences as video. Connectivity to R, Excel, GISs etc. Options for distributing and describing models. Easy GUI production and visualisation of data. Given all this, the thought that someone might build an agent framework that does all this for you sounds increasingly good of them.