Transcript 1. Intriduction to Java Programming for Beginners, Novices

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:
x
x
x
x
x
x
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.
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 timesteps (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 rolledback if necessary, including any messages sent.
As you can imagine, this gets fairly complicated, and these
algorithms only really work where there is history pathindependence 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.
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
Space
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.