A Program to Model Gas Diffusion using
Cellular Automata
Daniel Newman
B.Sc. in Computing with Philosophy
2005/06
The candidate confirms that the work submitted is their own and the appropriate credit has been given
where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered
as plagiarism.
(Signature of student)
Summary
This project provides a model of gas diffusion using cellular automata. It attempts to justify why
cellular automata are suitable for modeling systems such as diffusion and then attempts to show the
the diffusion shows standard physical behaviour by comparing its results to the results of established
models of diffusion.
i
Acknowledgements
Thanks to Mark Walkley for all his help, especially for the MATLAB script he provided for the PDE
model. Thanks also to Matthew Hubbard for his comments regarding the mid-project report and during
the progress meeting.
ii
Contents
1 Understanding the Problem
1.1
Background Information on Cellular Automata . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
A definition of Cellular Automata . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2
Existing applications of cellular automata . . . . . . . . . . . . . . . . . . . .
2
1.1.2.1
The example of the “Game of Life” . . . . . . . . . . . . . . . . . .
2
Existing cellular automata software/hardware implementations . . . . . . . . .
3
1.1.3.1
Mercer’s cellular automata program . . . . . . . . . . . . . . . . . .
3
1.1.3.2
Resnick’s Decentralised systems . . . . . . . . . . . . . . . . . . .
4
1.1.3.3
CAM-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Background information on gas diffusion . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.1
Randomness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.2
The PDE model of Gas Diffusion . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.3
Conservation of Matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Advantages of implementing cellular automata as software . . . . . . . . . . . . . . .
6
1.3.1
Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.2
The cellular automaton be run several times . . . . . . . . . . . . . . . . . . .
6
1.3.2.1
Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.2.2
Modifications to rule-sets can be tested easily and quickly . . . . . .
6
1.3.3
Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.4
Data/results can be stored digitally . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.4.1
Automated statistical analysis of resutls . . . . . . . . . . . . . . . .
7
1.3.4.2
Electronic transfer of data . . . . . . . . . . . . . . . . . . . . . . .
7
cellular automata models of Gas Diffusion . . . . . . . . . . . . . . . . . . .
8
1.1.3
1.2
1.3
1
1.3.5
iii
1.4
Random numbers and psuedo random number generators . . . . . . . . . . . . . . . .
8
1.5
Why the problem will be tackled . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2 Producing a Solution
2.1
10
Minimum Requirements and Possible Further Enhancements . . . . . . . . . . . . . .
10
2.1.1
Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.2
Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
Deciding on a methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3
Project schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
Choosing the appropriate programming tools . . . . . . . . . . . . . . . . . . . . . .
12
2.4.1
Advantages of an object-oriented language . . . . . . . . . . . . . . . . . . .
12
2.4.2
Debugging and Testing Tools available . . . . . . . . . . . . . . . . . . . . .
12
2.4.2.1
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.2.2
Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.2.3
Existing libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4.2.4
Ease of testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Speed vs. Cross-platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Creating the cellular automata software . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.1
Classes used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.2
Generating one frame from the previous frame . . . . . . . . . . . . . . . . .
16
2.5.3
Deciding the Duration of the Simulation . . . . . . . . . . . . . . . . . . . . .
17
2.5.4
Testing it with “Life” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.5.5
Other Rule-sets added to test the program . . . . . . . . . . . . . . . . . . . .
18
Comparing our Cellular Automata program to CAM-6 . . . . . . . . . . . . . . . . .
18
2.6.1
Similarities between this project and CAM-6 . . . . . . . . . . . . . . . . . .
18
2.6.2
Differences between this project and CAM-6 . . . . . . . . . . . . . . . . . .
19
Generating Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.7.1
The Random Walk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.7.2
Producing a “random” pattern by hand . . . . . . . . . . . . . . . . . . . . . .
20
2.7.3
STIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.7.4
C’s “rand” function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4.3
2.5
2.6
2.7
iv
2.7.5
Mersenne Twister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.6
The Poisson Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.8
Implementing rule-sets that guarantee conservation of matter . . . . . . . . . . . . . .
23
2.9
Rule-sets to implement Gas Diffusion . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.9.1
1-D Diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.9.2
Diagonal Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.9.3
Rotational Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.10 Storing and Handling Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.10.1 Producing a Histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.10.2 Storing Results in a Database . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.10.2.1 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.10.2.2 Storing results in a text file . . . . . . . . . . . . . . . . . . . . . .
26
2.11 Visualisation of the data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.11.1 Technologies for displaying data on-screen . . . . . . . . . . . . . . . . . . .
26
2.11.1.1 Functions provided by Windows GDI . . . . . . . . . . . . . . . . .
26
2.11.1.2 Advantages offered by Microsoft DirectX . . . . . . . . . . . . . .
27
2.11.2 Echoing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.11.3 The function to draw the cellular automaton . . . . . . . . . . . . . . . . . . .
27
2.11.4 Customisable colour schemes . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.11.4.1 Enabling/disabling of echoing . . . . . . . . . . . . . . . . . . . . .
28
2.11.4.2 Black and white suitable for printers . . . . . . . . . . . . . . . . .
28
3 Evaluation
3.1
29
Overview of the evaluation criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.1.1
Criteria for cellular automata software . . . . . . . . . . . . . . . . . . . . . .
29
3.1.2
Criteria for database storage . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1.3
Criteria for the visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1.4
Criteria for the model of gas diffusion . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Established models of diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Trends apparent from visualising the simulation . . . . . . . . . . . . . . . . . . . . .
31
3.4
Evaluating the 1-D model against an existing mathematical model . . . . . . . . . . .
31
v
3.4.1
3.4.2
3.4.3
Software used to obtain the results of the PDE model . . . . . . . . . . . . . .
31
3.4.1.1
Parameters for the MATLAB Script . . . . . . . . . . . . . . . . . .
33
3.4.1.2
Other Features of the MATLAB Script . . . . . . . . . . . . . . . .
33
3.4.1.3
Storing the PDE model’s results in a database . . . . . . . . . . . .
34
The program to compare the results of the diffusion model and the PDE model
34
3.4.2.1
Tools used to create the program . . . . . . . . . . . . . . . . . . .
34
3.4.2.2
Methodology employed to compare the two sets of results . . . . . .
34
Interpreting the results of the comparison . . . . . . . . . . . . . . . . . . . .
35
3.4.3.1
How finding a Correlation between the number of steps in the cellular
automata model and the number of steps in the PDE model will show
that the cellular automata model is realistic . . . . . . . . . . . . . .
3.4.3.2
Appropriatenss of the PDE model for comparison due to its use of
averagesinstead of random Numbers . . . . . . . . . . . . . . . . .
3.4.3.3
35
Consequences if the 1-D Model’s results did not match those of the
PDE model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3.4
35
35
Cosequences if the 1-D Model’s results did match those of the PDE
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5
Results of the Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.6
How the work could be extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.6.1
Comparing 2-D rule-sets with a 2-D PDE model . . . . . . . . . . . . . . . .
37
3.6.2
Extending the cellular automata software to produce histograms of the 2-D diffusion models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.6.3
Varying the value of lamda for the Poisson clock . . . . . . . . . . . . . . . .
38
3.6.4
Implementing the STIR algorithm . . . . . . . . . . . . . . . . . . . . . . . .
38
3.6.5
Testing for a greater range of the number of uniformly spaced points in the PDE
3.6.6
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Run model a greater number of times to get a better average . . . . . . . . . .
38
vi
Chapter 1
Understanding the Problem
1.1 Background Information on Cellular Automata
1.1.1
A definition of Cellular Automata
The Cellular Automata system originated from von Neumann’s idea of “a fully discrete universe made
up of cells... this system of cells evolves, in discrete time steps, like simple automata which only know
of a simple recipe to compute their new internal state” [5, pp.3]. The collection of cells can be thought of
as a “board” [19]. A series of boards can be viewed successively to make up a frame-based animation.
When creating a new frame for this animation, the contents of each cell will be calculated using a
“recipe” which relates to the state of it and it’s neighbouring cells in the previous frame. Calculating
one cell’s new state should not affect the new state of any other cell; only the previous states of a cell
and its neighbours can be considered in this calculation, “similar to what happens in any biological
system, the activity of the cells takes place simultaneously” [5, pp.3-4]. Toffolit and Margolus describe
a cellular automaton as a “stylized universe” where “the laws of the universe are expressed by a single
recipe... thus, the system’s laws are local and uniform” [19, pp.6]. The contents of the board in the first
frame of the animation will be referred to here as the initial conditions and the contents of the board in
the final frame of animations will be referred to here as the results.
1
1.1.2
Existing applications of cellular automata
Toffoli and Margolus list some disciplines which have previously found applications for cellular automata as “pure mathematics” with “topological dynamics” and “electrical engineering” with “iterative
arrays” [19, pp.8]. Some other recipes or “rule-sets” [19, pp.28], that are well-established and have
known results, that will be considered in this project to test the cellular automata software include Conway’s “Game of Life” [19, pp.20], Vichniac’s “Annealing” [19, pp.41] and Toffoli and Margolus’ “Random Walk” [19, pp.102]. These rule-sets will be implemented for the purposes of testing the cellular
automata capabilities of this solution before any rule-sets for gas diffusion are implemented.
1.1.2.1 The example of the “Game of Life”
The “Game of Life” is one of the most well-known applications of cellular automata. The significance of
this “game” is twofold. Firstly, it shows the (theoretically infinite) size of a system that cellular automata
can be used to model. Secondly, it demonstrates how only a small number of rules are necessary to
simulate a system with rich behaviour.
The first point is that there is no theoretical limit on the number of cells contained within a system.
Each cell is only aware of the states of itself and its immediate neighbours. This means that the number
of cells that there are in the system will have no impact on the cells behaviour. However, having a larger
board may allow for more complex patterns to form. For example, a “glider gun” [19, pp.25] takes up an
area of 28 x 15 cells. Therefore, such a pattern would not be able to occur on a board smaller than this.
This is clearly a positive effect, which therefore cannot be seen as a weakness of a larger board compared
to a smaller one. One possible disadvantage would be the increased cost in terms of processing time.
However, this would not be unique to cellular automata models. The PDE model considered in this
document would also require greater processing time if it were to be applied to a larger set of points. It
may be the case that either the cellular automata models or gas diffusion of the PDE model cost less to
run for a board of up to a certain area, while once the board’s area exceeds this the opposite becomes
true.
The second point is that Conway’s “Game of Life” achieves its rich using only two rules (see below). Keeping the number of rules to a minimum has the advantage of making the behaviour easier
for others to understand and modify at a later date. The CAM-6 system used by Toffoli and Margolus to implement the “Game of Life” [19, pp.14] can take any number of rules and then use them to
2
create a “rule table”. The number of entries in this rule table will be 2 to the power of (the number
of immediate neighbours + 1). For example, for a neighbourhood consisting of the cell itself and its
north, south, east and west neighbours, there will be 2 5 (= 32) possible combinations. This number
of combinations is independent of the number of rules governing the system. This has the advantage
that even if a system requires a large number of rules, this set can be replaced with just 32 Boolean
entries. A rule table also has the disadvantage that it is not easy for humans to read. For example, the rules of the “Game of Life” are not so obvious to the reader when written as “088E8EE3
8EE3E330 8EE3E330 E330E000 8EE3EE30 E3303000 E3303000 30000000 8EE3EE33 0E330300
0E330300 03000000 0E330300 03000000 03000000 000000000” [19, pp.33].
In the “Game of Life”, every cell can be either alive or dead. After the “primeval soup” [19, pp.21]
for the first frame has been generated, typically by placing some live cells on the board at random
locations, the system’s behaviour is defined by just two rules:
“Death: A live cell will remain alive only when surrounded by 2 or 3 live neighbors; otherwise, it
will feel either ’overcrowded’ or ’too lonely’ and it will die. Birth: A dead cell will come to live when
surrounded by exactly 3 live neighbors. Thus, birth is induced by the meeting of three ‘parents”’ [19,
pp.20].
This simple “recipe” is known to produce many interesting patterns, which make it of interest.
Some of the well-known patterns, or “technologies” [19, pp.25], have been used in the testing phase
of the creation of the cellular automata software. These include a “glider”, which is “a small fluttering
object... which steadily scuttles away on a diagonal path until it crashes into something else” [19, pp.24].
Developing on from this, the “glider gun” was discovered by Bill Gosper to “at regular intervals shoot
a new glider along a well-defined path” [19, pp.25]. Another such technology is the “R-pentomino”,
known to take 1103 generations to become stable [3]. If the cellular automata software created for this
project functions correctly then when it is used to execute the “Game of Life” rule-set it should be able
to produce all of these technologies.
1.1.3
Existing cellular automata software/hardware implementations
1.1.3.1 Mercer’s cellular automata program
Mercer provides source code for a program to run the “Game of Life” cellular automaton [13]. This
software was created primarily for teaching purposes and so does not provide the stability expected in
3
more spohisticated cellular automata software. One such feature it lacks is the ability to cope when a cell
tries to read the contents of a neighbour whose coordinates lie outside of the constraints of the board.
In such an event, Mercer’s program terminates. For this reason, Mercer’s cellular automata software is
considered unsuitable for our requirements of being able to model gas diffusion since it is not typical
physical behaviour for the movement of the gas to suddenly cease to as would seem to be the case if the
cellular automaton suddenly terminated.
1.1.3.2 Resnick’s Decentralised systems
Resnick describes a “decentralized” system which has been used to model many types of behaviour
including that of termites [16]. This is achieved using a rectangular board but instead of storing objects
(in this case the termites) in the contents of the cells, each object is stored with fields such as X- and
Y-coordinates describing its position on the board. This provides conservation of matter by keeping
separate records of two objects which happen to occupy the same cell. However, when the board is
visualised with more than one object occupying the same cell it will appear that there are less objects
within the system that the number of objects stored would suggest. This would make Resnick’s system
unsuitable for modeling a system which required conservation of matter.
1.1.3.3 CAM-6
CAM-6 is a dedicated piece of hardware “that plugs into a single slot of the IBM-PC... and of driving software operating under PC-DOS 2” [19, pp.14]. CAM-6 provides its interpreted language called
“FORTH” in which Toffoli and Margolus have written rule-sets for diffusion, which shall be discussed
later in this document [19]. Although CAM-6 is able to use the monitor of the PC it is connected to
as a means for displaying the contents of a cellular automaton, it does not provide a means to save the
contents of the board to a non-volatile location such as a file on a disk. Being able to store the results
digitally by saving them to a file is necessary for testing an evaluation performed in this project. However, many other aspects of Toffoli and Margolus’ use of CAM-6 to model diffusion will be considered
in this project.
4
1.2 Background information on gas diffusion
1.2.1
Randomness
Gas diffusion, when viewed from a macroscopic level, appears to involve randomness, in the form of
Brownian Motion. The cellular automata rule-sets to be implemented in this project will therefore require some form of random number generator. Toffoli and Margolus argue that it is possible to generate
random numbers within a cellular automata system [19, pp.68]. If this is true then it would seem that
cellular automata provide a complete means to model gas diffusion. However, the CAM-6 system which
they have used for implementing diffusion models also allows for sources external to the system to be
used as “neighbours”, which could include an external random number generator [19, pp.57] and so in
this project it will be considered acceptable for external random number generators to be used within
cellular automata.
Since the cellular automata models of gas diffusion are going to involve a random number generator,
there will be noise in the data that will not be present in a system such as the PDE model, which deals
with averages and thus avoids noisy data. The steps that must be taken the account for this noise in the
data when comparing the results of these cellular automata models to the results of the PDE model will
be discussed in the Evaulation.
1.2.2
The PDE model of Gas Diffusion
Toffoli and Margolus argue that “behavior is completely specified in terms of a local relation, much as is
the case for a large class of continuous dynamical systems defined by partial differential equations” [19,
pp.5]. Such equations have been devised by Oran and Boris [14] which taken account of the features of
gas diffusion described above and an implementation of a partial differential equation (PDE) model has
been provided by Walkley, which approximates the diffusion equation
1.2.3
du
dt
=
d2
.
dx2
Conservation of Matter
A model of diffusion has to take into account the fact that matter must be conserved. The PDE model,
which will be used to evaluate our cellular automata models, begins at the point when “a finite amount
of a conserved quantity, with density p(x,t), is deposited at x = x 0 at time t = t0 ... The total integral of p
over all space cannot change with time” [14, pp.204].
5
An adaptation of this rule will be used for creating the 1-Dimensional model of diffusion. The rule
used for conservation of matter in the 2-Dimensional model of diffusion is more complicated. It must
allow for reversibility, since “as far as we know, reversibility is a universal characteristic of physical
law... A cellular automaton is a deterministic system... only if the system defined by the original rule is
also backward-deterministic” [19, pp.145-6]. There appears to be a conflict between determinism and
the randomness displayed in a “random walk”.
Toffoli and Margolus suggest a method to ensure that a rule-set provides conservation of matter for
all the particles represented as occupied cells with a cellular automaton [19, pp.77-80] which will be
discussed in Chapter 2.
1.3 Advantages of implementing cellular automata as software
1.3.1
Speed
CAM-6 provides performance comparable to that of a CRAY-1 [19, pp.14]. The time taken to generate
just one frame on a large board would make it impractical to compute the frames making up a cellular
automaton by hand. Creating frames by hand also allows the possibility of human error.
1.3.2
The cellular automaton be run several times
Visualisations of a simulation may need to be made available more than once, for example, for purposes
of demonstrating a model to more than one group of people. The following are some other purposes for
which a cellular automaton may need to be run more than once:
1.3.2.1 Repeatability
If the initial conditions (or the board at any other step) are stored then the automaton can then be run
multiple times from these conditions. For a deterministic system this will lead to the same output each
time. However, for a system which makes use of external factors such as randomness, the results may
be different in each run given the same initial conditions.
1.3.2.2 Modifications to rule-sets can be tested easily and quickly
If a rule-set needs to be modified, for example if a flaw is found in an existing rule-set or a new physical
law is established which makes the existing rule-set out-of-date then the new rule-set can be run and still
6
provide the advantage of the speed of the software compared to executing the new rule-set manually.
1.3.3
Visualisation
In the past cellular automata “have been much talked and written about, but until recently no one had
actually seen much of them” [19, pp.8]. Modern PC hardware provides the capacity to render each
frame of a cellular automaton on-screen as it is being generated in real time.
1.3.4
Data/results can be stored digitally
1.3.4.1 Automated statistical analysis of resutls
Toffoli and Margolus describe a method to generate a histogram of the results of a cellular automaton
from within the automaton itself [19, pp.77]. This produces a board wherein the height of each column
(in cells) in the histogram is equal to the number of occupied cells in that column in the results of the
automaton. Statistical analysis can then be performed on such histograms, as has been performed in the
Evaluation of this project.
1.3.4.2 Electronic transfer of data
By storing results electronically in the form of a database, the results can easily be duplicated to provide
backup copies of the data.
By storing the contents of all cells in the system at one point on time it is possible to create multiple
instances of the cellular automaton which continue running from this point but run one instance with
exactly the same cell contents as before and another instance where one small part of the system (such
as inverting one cell’s contents) has been changed and observing the differences in behaviour between
these two systems. Toffoli and Margolus suggest a way of using a visualisation to make this difference
more distinct; by using one colour on the display to represent cells that have the same contents in both
experiments and another colour to represent cells where their contents in one of the instances is different
to that of the other [19].
Electronic storage of data also allows for it to be easily imported into other systems. This may
be useful for performing statistical analysis on this data both to test and evaluate the behaviour of a
particular cellular automaton and also to extrapolate other information from this data, by using results
of a simulation implemented as a cellular automaton as evidence to support a hypothesis. Data may
7
also be imported into systems which do not directly relate to the particular cellular automaton which
generated the data being imported. For example, data from a cellular automaton implemented in this
project that made use of a random number generator was used for another research project related to
random number generating but not directly related to cellular automata.
1.3.5
cellular automata models of Gas Diffusion
Although a cellular automaton is not a continuous system, if it is to provide an reliable model of gas
diffusion then its results should approximately match those of the PDE model. The PDE model and
methods to compare its results to the results of cellular automata models of gas diffusion will be discussed in the Evaluation.
1.4 Random numbers and psuedo random number generators
A softwre implementation of a cellular automaton whose behaviour involved randomness would require
a source of random numbers. This could be achieved by using a psuedo random number generator,
which would have the disadvantage that it is not completely random. Toffoli and Margolus suggest as
an alternative to manually supply the system with random numbers by literally flipping a coin (which
would be more random that a psuedo random number generator) although they admit that would not be
practical as a means of supplying random numbers for to every cell on a board [19, pp.67-8].
1.5 Why the problem will be tackled
The aim of this project is to create a model of gas diffusion using cellular automata. One issue to be
addressed will be whether such a cellular automata model can be self-sufficient or will require the use of
external features such as a random number generator. Another will be how close this model is to actual
physical behaviour.
There already exist other means of modeling gas diffusion, such as the PDE model. Aswell as being
able to compare the results of a cellular automata model of gas diffusion to those of the PDE model, it
will also be possible to consider factors such as the cost of running both models. If the cellular automata
model can provide results in a shorter time than the PDE model then this may be considered one way in
which the cellular automata model is superior.
8
Toffoli and Margolus argue that cellular automata systems should produce results matching those of
other kinds of mathematical models. Their “behavior is completely specified in terms of a local relation,
much as is the case for a large class of continuous dynamical systems defined by partial differential
equations” [19, pp. 5]. Gravner disagrees: “cellular automata models are almost never able to make
precise quantitative predictions. Therefore, they are [only] suitable for modeling processes in which
basic undisputed laws are hard to come by” [7]. By evaluating the cellular automata models of diffusion
by comparing them to the PDE model it will be possible to see whether the cellular automaton’s has
matched the behaviour of physical systems.
9
Chapter 2
Producing a Solution
2.1 Minimum Requirements and Possible Further Enhancements
2.1.1
Minimum Requirements
1. Cellular Automata software that is able to produce frames at a greater rate than could be attained
by calculating the frames manually in order to justify the software’s creation.
2. Cellular Automata model of gas diffusion. The steps in going from the cellular automata software
to a cellular automata model of gas diffusion will be discussed in the Project Schedule section.
3. Storing the simulation results in a database.
4. Create a visualisation of simulation. This will most likely be contained within the same program
as the cellular automata software, although a possible enhancement may be for a visualisation to
be created from results which have been stored in a database.
2.1.2
Possible Enhancements
1. Advanced visualisation (e.g. with customisable colour scheme, 3-Dimensional graph to display
more than one bit plane for displaying a cell’s history).
10
2. Running the simulation several times using different random-number-generators, to test whether
this makes a difference on how closely results match those generated using differential equations
and to the noise level.
3. Writing a program to compare the results generated by cellular automata and differential equations.
2.2 Deciding on a methodology
The Agile programming methodology is appropraite for projects subject to “changing circumstances”,
where the requriements may change frequently [20, pp.3]. The requirements for this project have already been established and the only changes likely would be to implement features listed under Possible
Enhancements. The Waterfall method shall be favoured for this project because it allows tasks to be confined to a predefined schedule and works well with requirements that are well understood [12, pp.156].
2.3 Project schedule
1. Background reading on cellular automata
2. Write a skeleton cellular automata program
3. Background reading on sample applications of cellular automata (e.g. Conway’s “Game of Life”)
4. Get this program to support “Life”
5. Get this program to support other simple rules (e.g. “Annealing”)
6. Background reading on gas diffusion
7. Get program to model a “Random Walk” for one particle
8. Get program to model 1-D diffusion
9. Get program to model 2-D diffusion
10. Write a sample program to store results in a database
11. Get program to store diffusion results in a database
11
12. Compare program’s results to calculations using PDE model
13. Write up
2.4 Choosing the appropriate programming tools
2.4.1
Advantages of an object-oriented language
An object-oriented language is suitable for this project because it allows for one abstract class to be created which provides all the functionality required for any cellular automata rule-set to be implemented.
Classes which implement specific rule-sets can then be created which inherit all the base functionality
from this abstract class. This reduces the work-load and speeds up production because the code can be
re-used. Re-using this code also provides the advantage that it only needs to be tested once. The fields
and methods that this abstract class will contain will be discussed later.
2.4.2
Debugging and Testing Tools available
2.4.2.1 Security
Developing software in Java makes it “secure” since “execution of every Java program is under the
control of the JVM [Java Virtual Machine]” [18, pp.11]. A compiled C/C++ program does not necessarily contain any such safeguards to “prevent it from generating side effects outside of the system”
[18, pp.11]. However, Microsoft Windows NT and later versions of Microsoft Windows are also able
to offer securtiy to processes from outside interference. This can be achieved by specifying the desired
security attributes as a paramater to the “CreateThread” Windows API function [15, pp.1204]. Since the
base class from which all implementations of rule-sets will be descended (CAnimationFrame, discussed
later) will incorporate only low-level methods, the security and stability are not seen as high prioirities
in choosing a platform for the program and development tools.
2.4.2.2 Memory Leaks
The next frame in the cellular automata system is produced in the constructor method of the class representing the particular rule-set, which takes a pointer to the previous frame as its only parameter. Storing
this pointer to the previous frame then allows for a visualisation of one frame to include information
about the a cell’s state in the previous frame as well as its current state through a process known as
12
“echoing” [19, pp.22]. C++ allows for the easy storage of pointers. We can then apply the delete operator to this pointer when the frame is no longer required for the echoing. A cellular automaton is
theoretically capable of running for an infinite of frames so it may become necessary to apply the delete
operator to pointers to previous frames due to the memory limitations of system. Java does not store
pointers. Instead the Virtual Machine maintains an Object Reference. Although the Virtual Machine
ensures there are no memory leaks, it frees memory only once it is no longer referenced. It does not
allow for memory to be freed up as easily as the C++ delete operator does. Since a cellular system
which maintains a history of previous frames has the potential to take up a vast amount of memory, C++
will be favoured because of its delete operator.
2.4.2.3 Existing libraries
The Microsoft Windows API “provides a wealth of function calls that an application can take advantage
of” [15, pp.8]. These functions will have been tested by Microsoft before the release of each version of
Windows. It will also be assumed that the Java libraries have already been properly tested before their
release. Functions from these libraries used to create the cellular automata software will be considered
to not need any further testing.
2.4.2.4 Ease of testing
The JUnit framework was developed by “leaders in the Agile programming methodology” for testing
Java classes by facilitating “the building and frequent running of suites of test classes and regression
tests” [20, pp.952]. Testing with JUnit would be possible only if the software for this project was written
in Java. Since it has been decided that the Waterfall methodology is most suitable for this project, testing
of this nature will not be ideal.
Horton describes methods to test a class in C++ by instantiating it using input from an input stream,
calling the desired method for which the expected results are known, then outputting the results using an
output stream [9]. Although these methods are intended for use in testing projects created in Microsoft
Visual C++, they could also be applied to C++ source code developed without the Visual C++ IDE or
to a Java project since Java also provides simple input and output streams, namely the System.in and
System.out classes.
13
2.4.3
Speed vs. Cross-platform
The two object-oriented languages that have been considered for the project are Java and C++. Java
has the advantage that it is cross-platform. Speed is one of the requirements of this project. Since this
program is not intended to be made generally available, it is not seen as a requirement for the program
to be cross-platform.
One of the minimum requirements of the project is the ability to store results in a database. The
Java JDBC and C’s ODBC libraries contain tools for handling advanced database operations. However,
since only primitive data types such as integers and null-terminated strings are intended to be stored in
our results the C Standard Library routines for file input/output will meet our requirements as well as
the ODBC/JDBC libraries.
C and Java both provide random number generators. Since this project is about modeling gas diffusion from a macroscopic level it requires a random number generator. Toffoli and Margolus do propose
a method for a cellular automaton to generate its own random numbers and therefore not rely on an
external random number generator [19, pp.70], however, using this would assume that it does in fact
produce an acceptable degree of randomness. The exact algorithm used by C’s random number generator is dependent on the system that it is run on [1, pp.252]. The exact behaviour of Java’s original
random number generator is also dependent on the system. However, “Java 2, version 1.3 adds the
StrictMath class... the StrictMath version is guaranteed to generate precisely identical results across all
Java implementations” [18, pp.412]. Hard-coding a custom random number generator into the program
will be considered, which would also guarantee “precisely identical results” on all systems. For this
reason, the existence of a language’s own routines that work in the same way on all systems is not
considered essential.
Java programs make use of dynamic binding, while C++ programs make use of static binding. Of
these two, static binding is known to produce faster executing code. Executable code is known to produce faster performance than interpreted bytecode, even with “dynamic compilation” facility provided
by Sun’s “Just In Time compiler for bytecode” [18, pp.11]. Since an acceptable speed at which the
program can produce frames is considered a requirement of the project, C++ will be favoured over Java.
14
2.5 Creating the cellular automata software
2.5.1
Classes used
One abstract class wll be created to represnet one frame of a cellular automata system called “CAnimationFrame”. All of our implemtations of specific rule-sets can then inherit the functionality provided by
this class. The fields and methods this class will implement are:
• Width, Height: Storage of the width and height of the automaton. Both of these will be stored as
integers. These fields will have protected access. They will also be able to be read through the
use of accessor methods. However, they will not be able to be written from outside the class and
its descendants.
• Cell: Storage of an array of Boolean values representing whether each cell in the system is empty
or not. This array will have dimensions of the width and height specified above. The accessor
method for this array will incorporate a wrap-round device [19, pp.16]. As well as being a requirement of a true cellular automata system (unlike the one that Mercer proposes [13, pp.752]), the
wrap-round device prevents an out-of-bounds run-time errors occuring when this array is accessed
either by decendent classes or external methods such as those used to provide a visualisation of
the system.
• CreateArray: A method to create the array described above. This will require as parameters the
integer height and width of the array to be created, which will automatically be stored in the width
and height fields mentioned above.
• Previous: Storage of a pointer to the previous frame from which this one was created. Since the
frame that this pointer corresponds to will also have such a pointer, these pointers will provide a
linked-list of all the frames created in one run of the cellular automata system.
• InsertDot, InsertRectangle, InsertCircle, InsertCylinder: Inserting shapes such as dots (for the
“random-walk” rule-set), rectangles, (pixelated) circles and cylinders (for all of the implemented
diffusion rule-sets). The user is able to specify the size of the shapes inserted (except for the dot,
which may be thought of as a circle with a radius of one).
• Randomise, RandomiseWithCentre: Randomisation functions for the contents of the cells. Either
the contents of all the cells can be randomised or a randomised “cluster” [16, pp.59] of cells
15
(around a centre) can be added. A “cluster” is similar to our “circle” except that not quite all of
the cells within the circle’s radius will be filled [16, pp.59].
• RandomBool: Random number generating functions will be handled internally within the class.
This is because some of the random number generators to be implemented in this project need
access to the contents of the cell calling the random number generator and the contents of its
neighbours. By having one function to handle all random number generation, the rule-sets that
are implemented as descendants of this class can just see the function as a “black-box” and be
“concerned only with what goes in and what comes out. The inner workings are not important
to the black-box perspective” [10, pp.22]. The rule-set implementations only need to know the
fact that this function provides random numbers. This parameters this function shall take are
the X- and Y- co-ordinates of the cell that is calling this function. Since some of the random
number generators that shall be implemented in this project need this information and we wish
for implementations of specific rule-sets to be able to use the black-box perspective it will be
necessary for the function to always take these paramaters.
• A function to all the user to specify which random number generator to use.
• A saving functions so that the the results of a simulation can be stored in a database.
• A loading function so that a simulation can be continued at a later date or a specific set of initial
conditions can be used, for example, for experiment repeatability.
A UML representation of this class is provided in Appendix C.
2.5.2
Generating one frame from the previous frame
Each class to implement a rule-set must provide two constrcutor methods. The first method takes as
parameters the height and width of the board to create. This board is initially empty. Initial conditions
may then be entered using either by inserting shapes or by loading them from a file.
The second method constructor method takes as its only parameter a pointer to the previous frame
generated by the system. From this pointer, the width and height of the previous frame can be established
and passed to the CreateArray method that is inherited from the CAnimationFrame class. The contents
of each cell in the new frame can be determined by the contents of the cell and its neighbours’ previous
states in the Cell array of the previous frame. The pointer taken by this constructor method is to a
16
CAnimationFrame class. This allows for a frame of a particular rule-set to be generated from a frame
generated by a different rule-set. This will be useful for generating histograms of the results of other
cellular automata models.
2.5.3
Deciding the Duration of the Simulation
Mercer’s cellular automata program is theoretically of running for an infinite number of frames, just as
long as no cells reach the border [13]. Examples of such a rule would be where a cell’s contents are
always exactly the same as in the previous step, so as long as there are no alive cells neighbouring on
the border in the first frame, the system can run indefinitely. However, Toffoli and Margolus call such
systems “trivial” [19, pp.146] and no such rule could be designed for modelling gas diffusion.
Unlike Mercer’s program, the cellular automata software written for this project needs to be theoretically always capable of running for an infinite number of frames and, once put in motion, will do
so until the user interrupts the simulation by pausing it. In his C++ implementation of the “Game of
Life”, Mercer proposes an “isDone” method to be called after every single step, which “asks the user
if he or she wants to quit and returns true when the user responds positively or false otherwise” [13,
pp.751]. This would be impractical for the number of steps that the diffusion rule-sets implemented in
this project are intended to be run for. Macros are provided in the program to run a given rule-set for a
finite number of frames, for example, to automate experiments used in the evaluation of this project.
2.5.4
Testing it with “Life”
Some of the patterns known to occur in the “Game of Life” include the “R-pentomino” [3] and the
“glider” [19, pp.25], which later lead to Gosper’s discovery of the “glider gun” [19, pp.26]. Toffoli
and Margolus state that “on a lucky run we may find many gliders in the ocean at the same time”
[19, pp.25], and testing of the “Game of Life” implementation in this project has shown this to be the
case. The R-pentonino is known to produce patterns known as the “beehive”, “block” and “ship” when
run in Callahan’s cellular automata software [3], all of which are visible when the R-pentonino initial
configuration is used with the “Game of Life” rule-set implementation in this project. This is seen as
evidence that this rule-set has been successfully implemented here, suggesting that both the cellular
automata software itself works and that the “Life” rule-set has been successfully implemented on it.
17
2.5.5
Other Rule-sets added to test the program
The “Annealing”, “Cornering” and “Triangles” rule-sets have been implemented successfully in CAM-6
by Toffoli and Margolus [19, pp.38-43]. When they were later implemented in this project their visualisations (see Appendix D) were similar to screenshots supplied by Toffoli and Margolus (the screenshots
were not exactly the same due to the randomisation involved in generating the initial conditions for each
run of the system).
Since several established rule-sets have all shown the expected behaviour in this project it will be
assumed that the cellular automata software works correctly.
2.6 Comparing our Cellular Automata program to CAM-6
2.6.1
Similarities between this project and CAM-6
CAM-6 is a commercially-available cellular automata machine which Toffoli and Margolus have used
to attempt to model gas diffusion [19, pp.13]. Although CAM-6 provides its own language for the
creation of cellular automata rule-sets, the principles of the rule-sets Toffoli and Margolus describe for
modelling gas diffusion can also be implemented in C++, as will be demonstrated in this report. The
cellular automata software written for this project is similar to CAM-6 in the following ways:
1. Should the cell attempt to read another cell whose co-ordinates lie outside of the board, the softwre
makes use of a “wrap-around device... that is, the right edge of the sheet acts as if it were ‘glued’ to
the left edge... In more mathematical terms, the topology is that of a torus.”. Toffoli and Margolus
then give the analogy of a doughnut: “no amount of walking will allow one to find the ’edge of
the world”’ [19, pp.16]. Mercer suggests a system that “allows the outer rows and columns to be
used as a border in which no cell may be placed. The rules [of the Conway’s ‘Game of Life’]
no longer apply once the border is in a neighborhood. When this occurs, display a meaningful
message and terminate the program” [13, pp.752]. This is not suitable for some of the rule-sets
considered here. For example, after executing the gas diffusion rule-set for the number of steps
required in parts of this project, the law of averages state that some particles will have reached the
perimeter of the board before the desired number of steps have occured.
2. Both programs provide visualisations of the simulation using a “color map”. While CAM-6 allows
the assignment of up to 16 colours [19, pp.15], this project only needs to make use of four: one
18
for a cell which has just come to life, one for a cell which is alive and was alive in the previous
step, one for a cell that is dead but was alive in the previous step and one for a cell which is dead
now and was dead in the previous step.
2.6.2
Differences between this project and CAM-6
1. this project does not make use of a command interpreter. Since it is only intended to be used for
a few set of rules, these rules can be hard-coded into the program.
2. This project shall be implemented only as software. CAM-6 provides its own specialist hardware
for optimum performance. For a project the size of this it would not be practical to produce a
specifically designed piece of hardware.
3. CAM-6 calculates the state of a cell based on every possible combination of its neighbours based
on a specified recipe before the program is run, which it then stores these in a rule table [19, pp.15],
which can be accessed while the program is running. This is for the sake of faster calculations
at run-time. Since this project uses only small boards, the slight reduction in processing time for
each frame is not deemed necessary for the program to run smoothly on modern computers.
4. CAM-6 allows cells information about only those cells within a defined neighbourhood. “In
principle, a cellular automaton rule could make use of an arbitrarily large number of neighbors.
However, efficiency dictates a practical limit to the number and the span of direct neighbor connections” [19, pp.16]. However, the software written for this project allows cells read-only access
to any other cell within the board by specifying its relative X- and Y- distance from itself. CAM6’s command interpreter is designed to treat the names of a cell’s neighbours as variable names.
Since this project does not support any kind of scripting language, this read-only access can be
achieved by just supplying the X- and Y- offset of the cell whose state is to be read from the cell
requesting the read.
2.7 Generating Random Numbers
2.7.1
The Random Walk
The “Random Walk” provides an important blueprint of a diffusion model since it is governed by a
random process. A Random Walk involves a particle moving down the board at a rate of one square per
19
step. In each new frame a particle may move either down-left, down-right or straight down, depending
on the result of a random number generator [19, pp.102]. Implementing this rule-set allows for the
testing of random number generators in our program. The following are methods that will be considered
for generating random numbers within the program’s cellular automata environment:
2.7.2
Producing a “random” pattern by hand
Some of the models that will discussed below require some source of random numbers. Toffoli and
Margolus propose one impractical but conceptually very simple solution to this. This is to provide
the system by hand with a fresh random pattern. [19, pp.68]. This solution has the advantage that is
completely random in that the source of random numbers, the user, can be uninfluenced by the activity
of the cellular automaton. The main flaw with this method is that producing a random pattern by hand
is extremely slow [19, pp.69]; far too slow in fact for the number of times the program is intended to be
run to obtain the results. This method would not meet the requirement that the software must produce
frames at a greater rate than could be achieved manually.
2.7.3
STIR
The SITR method is a little different to a standard random number generator. While in a standard
random number generator “the value returned is not determined by the arguments (of which there are
usually none) but rather by some global conditions” [17, pp.104], The STIR algorithm works entirely
within the confines of a cellular automata system, so “behavior is completely specified in terms of a
local relation” [19, pp.5].
A random Boolean value is produced from “a continually stirred ‘bit soup’ containing a new random
pattern at each step” [19, pp.70]. This is achieved by applying the bitwise exclusive-or and and operators
to the contents of the cell’s neighbours in the previous step. “The XOR’s guarantee that in the long run
the soup will yield an even mix of 0’s and 1’s... by putting some nonlinearity in the rule, the AND
insures that the system won’t get stuck in a short cycle.” [19, pp.70].
One way to implement the STIR method would be to take the cell and its neighbours’ states in the
previous step, perform the AND’s and XOR’s on them and then return the result. However, once we
try to incorporate this algorithm into a very simple system, such as the Random Walk (see below), we
notice that, since the particle always has the same number of neighbours (zero), the stir algorithm will
always generate the same value when run on the this bit-plane.
20
When Toffoli and Margolus came up with the STIR method, they were intending it be used on the
CAM-6 system. This stores not one bit-plane, but four. This allows one bit-plane to be used to store
the contents of the cells which the system outputs to the user via a graphical display. It also allows
for another bit-plane to be used to store the bits that are used by the STIR algorithm. While our first
Random Walk model will only allow for one particle to be present on the board (i.e. first bit-plane) at
any given time, it is not affected by the contents of the other three bit-planes, other than in their being
used to implement the STIR algorithm. Many of the models that shall be considered below begin with
regular patterns, for example, the 1-D and 2-D models of diffusion begin with a solid stripe of particles
in the centre of the board. If in these models the STIR algorithm were applied to the bit-plane that
is displayed to the user, the “random” number generator would have a very low period. The period
would be one in the case of running STIR on the random walk, since it would return the same number
every time (see screenshot in Appendix). It would therefore seem that the only way to implement the
STIR algorithm would be to have another off-screen bit-plane which is initially populated at random
using another method. Toffoli and Margolus argue that “this soup will be immediately usable if we
start it with a random pattern containing 50% of 1’s; however, one obtains a usable soup from virtually
any initial pattern by pre-stirring for a few hundred steps” [19, pp.70]. However, “virtually any initial
pattern” does not include a plane almost exclusively containing zeros, as is the case with the visible
bit-plane of the Random Walk algorithm.
Using a bit-plane for the STIR algorithm in that way that Toffoli and Margolus describe allows
for repeatability of experiments, as described above. This can be achieved by using the same initial
population for each run of the experiment.
2.7.4
C’s “rand” function
Using a psuedorandom number generator “has one big advantage over a true random number generator:
The sequence of numbers it produces is repeatable” [17, pp.105]. Toffoli and Margolus discuss one
instance when it may be useful to be able to duplicate a “random” pattern so as to observe the effect
of replicating all conditions of a cellular automaton except for changing just one particle in the system
[19]. The software for this project program is written in C/C++ which provides its own function for
generating random numbers, rand. Rand supports the use of seeds through the C function srand. This
makes it adequate for providing repeatability of experiments. However, this is limited to executing the
“rand” function on the same system each time the experiment is repeated. On the same system “the
21
same sequence of values will always be returned from rand for a given value of seed.” C’s Standard
Library “describes an algorithm which may be used to implement rand and srand. In practice, most
implementations will probably use this algorithm” [1, pp.252]. However, the fact that the use of the said
algorithm cannot be guaranteed on all systems “rand” is considered unsuitable for creating a program
that can guarantee repeatability.
2.7.5
Mersenne Twister
The “Mersenne Twister” (MT) is a random number generator known to have a period of 2 19997 −1, much
greater than that of “rand” [11]. Whereas the “rand” function’s period of system varies from system to
system, the MT will be hard-coded into our cellular automata program so its output for a known seed is
platform-independent. This makes it superior to “rand” for providiing repeatability. For these reasons,
the MT will be used in this evaluation of project for generating random numbers.
2.7.6
The Poisson Clock
A Poisson clock is a mechanism “in which the updating of a cell... can take place at an arbitrary moment
along a continuous time axis... where events occur at random with a uniform distribution in time”. In
such a continuous system, “the probability that the next event will occur between times t and t + dt
equals λ e−λ t dt” [19, pp.87]. Since a cellular automaton is a discrete system, not a continuous one, we
cannot vary the length of dt, other than by increasing it by multiples of one step. If our system were
continuous then “the probability that two cells will be updated at exactly the same moment is zero”.
This would greatly simplify the “handshake protocols that may be necessary to insure respect of certain
constraints” such as the conservation of matter required by any model of gas diffusion [19, pp.87]. The
three methods for implementing a diffusion model using cellular automata described later in this report
all provide methods to guarantee the conservation of matter.
Implementations of rule-sets into the cellular automata software created for this project will be able
to make use of the Poisson clock through the RandomBool function of the CAnimationFrame class. The
function returning true is equivalent to the Poisson clock ticking; the function returning false is equivalent to the Poisson clock not ticking for that step. This RandomBool function has a 50% probability
of returning true each time it is called. This means that there is a 50% probability of the Poisson clock
ticking for each cell that calls it during each step.
22
2.8 Implementing rule-sets that guarantee conservation of matter
Toffoli and Margolus suggest a method for particle conservation within in a cellular automaton. Their
rule is as follows:
“- If I’m empty and my north neighbor is full, I’ll make a copy of its contents (I know he will erase
his).
- Conversely, if I’m full and my south neighbor is empty, I’ll erase my own contents (I know he will
make a copy of it).” [19, pp.78]
This handshake protocol can be adapted for all of the models of diffusion implemented in this
project by “north” and “south” neighbours for other relative positions of neighbouring cells. For onedimensional models this will involve the neighbours to the left- and right-hand side (which would be
referred to as east and west in the Moore and von Neumann neighbourhoods [19, pp.60]) and for other
local relative positions in the Diagonal Swapping and Rotational Swapping models.
2.9 Rule-sets to implement Gas Diffusion
Rule-sets have been implemented in this project by creating classes which inherit from the CAnimationFrame class all the basic functionality of a cellular automaton. The constructor method of each descendent class will then execute the rule-set based on the contents of the previous frame of the system,
which is supplied as its only parameter. No fields need to be added to the descendent classes since all
information about the cellular automaton is stored within the bit-planes fields in the CAnimationFrame
class.
2.9.1
1-D Diffusion
The 1-D model of diffusion will develop on from the Random Walk that was implemented to test the random number generators. Whereas the Random Walk involves the particle moving downwards through
the cellular automaton while it randomly moves to the left or right, a particle in the 1-D model can only
move one cell to the left, one cell to the right or not at all during each step; it cannot move vertically.
The Random Walk rule-set was intended to be run on systems containing only one particle. Running
this rule-set for a system containing more than one particle could cause loss of matter if two particles
attempted to move into the same cell. The 1-D model shall conserve matter by simulating the movement
of a particle through a cell swapping its contents with that of its neighbour, which together make up a
23
“block” [19, pp.104]. This swapping takes place only each time the Poisson clock ticks. Whether a cell
swaps with its left or its right neighbour shall depend on whether the system has up to that point been
run for an odd or even number of steps. This swapping is “data blind” meaning that “the exchange takes
place in the same way no matter what the contents of the block is. We could update the array without
even looking at it” [19, pp.104].
Toffoli and Margolus propose their “alternating block pattern” [19, pp.105] as way for the cellular
automaton to keep track of whether it has been running for an odd or an even number of steps. This
involves storage of a second bit-plane. We start off with this second bit-plane containing a 1 in every
other cell and all other cells containing a zero. Cells in the first bit-plane whose corresponding cells in
the second bit-plane contain a 1 will swap with the cell to their left; cells in the first bit-plane whose
corresponding cell in the second bit-plane contain a 0 will swap with the cell to their right. The contents
of every cell in the second bit-plane are XOR’ed at each step, so that whether a cell swaps with its left
or right neighbour alternates every step.
This rule-set guarantees conservation of matter by using the particle conservation method proposed
by Toffoli and Margolus and provides the randomness characteristic of Brownian motion through its use
of the Poisson clock.
2.9.2
Diagonal Swapping
Toffoli and Margolus also suggest the Diagonal Swapping [19, pp.120-9] rule-set to simulate diffusion
in two dimensions. Like the 1-D Diffusion rule-set, this rule-set implements an alternating block pattern.
Rather than dividing the board into horizontal blocks of two particles, it divides it into square block of
with a height and width of two cells. Whenever the Poisson clock ticks, the cell swaps its contents with
that of the cell diagonally opposite it within its block. This means that the cell in the top-left-hand corner
of the block will swap with the cell in the bottom-right-hand corner and the cell in the top-right-hand
corner will swap with the cell in the bottom-left corner.
Like the 1-D Diffusion rule-set, this rule-set also guarantees conservation of matter through the particle conservation method proposed by Toffoli and Margolus and provides the randomness characteristic
of Brownian motion through its use of the Poisson clock.
24
2.9.3
Rotational Swapping
Implementing both the Diagonal Swapping and Rotational Swapping rule-sets allows for comparisons
to be made to see if one provides a more accurate model of physical bahviour then the other. It takes
into account the possibility that one rule-set may model physical behaviour more closely than the other,
rather than forcing the assumption that if only one of these two two-dimensional models had been implemented and evaluated and was found to produce non-physical behaviour that there were no possible
rule-sets that would provide an accurate model of diffusion within a cellular automata.
Like the 1-D Diffusion and Diagonal Swapping rule-sets, this rule-set guarantees conservation of
matter by using the particle conservation method proposed by Toffoli and Margolus and provides the
randomness characteristic of Brownian motion through its use of the Poisson clock.
2.10 Storing and Handling Results
2.10.1
Producing a Histogram
A histogram can be produced of the contents of a cellular automaton by counting the number of particles
contained within each column. Toffoli and Margolus suggest that this can actually be achieved using
a rule-set to generate the histogram from the contents of a board generated by some other rule-set.
The rule to do this is that if a square is full and its south neighbour is empty then erases its contents.
If a square is empty and its north neighbour is full then copy its contents [19, pp.78]. This rule-set
guarantees conservation of matter. Once the histogram has been produced it can be saved to a database
and is suitable for other statistical analysis, as mentioned above.
2.10.2
2.10.2.1
Storing Results in a Database
ODBC
One method for storing the results in a database would be to use Embedded SQL. This is “the most
popular programming interface for accessing databases” [4, pp.383]. “Microsoft developed a callable
interface called Open Database Connectivity (ODBC).” ODBC allows “function calls to submit SQL
requests and retrieve results” [4, pp.385]. ODBC has the advantage that it “provides your application
with more flexibility. You link it once to the Driver Manager and the application can still access different
DBMS” [4, pp.386]. Using a standardised means for accessing data, such as SQL, has the advantage
25
that a separate program could easily import this project’s results, for example for performing statistical
analysis on results of the Diffusion models.
ODBC has the disadvantage of the Driver Manager’s overhead [4, pp.386], which is an issue since
the cost of running the model is a factor that is being considered when evauluating the cellular automata
models against the PDE model. It also has the disadvantage that aswell as the SDK having to be installed
on the system used to develop the program, the ODBC drivers must be installed on any system on which
the program is to be run.
2.10.2.2
Storing results in a text file
The software written for this project allows for the contents of the correct frame to be stored in a text
file. This text file will specify the height and width of the board and then, for each square in the cellular
automata board, whether it contains a particle. This method has been chosen due to its simplicity. It
has been tested by saving the contents of boards which are easy to recognise visually, such as a board
containing a solid square in the centre, closing the program and then opening the saved file at a later
date. Tests were considered a success once the same board contents appeared in the board that had been
loaded from a file as in the board before the file was created. This method is preferred over ODBC
because it is also simple for other programs to read this project’s results if they are stored in a text file
and does not introduce an extra cost in terms of programming time. Since this project is currently only
intended to be run in the Microsoft Windows environment, ODBC’s being an ANSI standard [4, pp.383]
is not seen as any advantage here.
2.11 Visualisation of the data
2.11.1
2.11.1.1
Technologies for displaying data on-screen
Functions provided by Windows GDI
The Graphics Device Interface (GDI) supports “device inependent graphics” and allows the user of
raster devices to “represent images as a rectangular pattern of dots” [15, pp.122]. This makes it suitable
for representing the two-dimensional board of a cellular automaton. GDI provides primitives to draw
areas filled with a solid colour [15, pp.122] such as a rectangle of a certain size which can be used
to represent a cell in the cellular automaton, with the colour of the rectangle drawn being determined
26
by the state of its corresponding cell. GDI allows for offscreen surfaces to be accessed via its “device
context” data structure [15, pp.75] so that only the fully-rendered image need be copied onto the screen.
This helps to minimise flickering on the screen.
2.11.1.2
Advantages offered by Microsoft DirectX
Microsoft DirectX provides an interface known as DirectDraw to provide faster access to offscreen surfaces than GDI. It provides its own implementation of many GDI functions, although the only one of
these functions required is the blit function. Although DirectX is notably faster for blit operations [6,
pp.23], such an operation will only be called once per frame so it is unlikely to give any noticable increase in the frame rate. For this reason, the cost in development of making use of DirectX technologies
will be seen as too great to justify the slight improvement in performance it offers.
2.11.2
Echoing
Putting together “a two-bit value from a new state and an old state” is referred to by Toffoli and Margolus
as “echoing” [19, pp.22]. It enables visual differentiation between “static objects” and “moving objects”
[19, pp.23] and enables visualisation of “trails” [16, pp.59]. Toffoli and Margolus also suggest that “one
could prolong the echo by using more auxiliary bit-planes to hold, in a pipelined fashion, an after-image
of the last few steps” [19, pp.23]. However, such a feature has not been seen as necessary for this project
and would require a greater amount of memory than the current implementation since the system would
have to maintain pointers to several of the most recent steps rather than to just the one previous step, as
in the current implementation.
2.11.3
The function to draw the cellular automaton
The process executed to represent the contents of the cellular automaton visually is as follows:
• The width and height of one cell on the screen (in pixels) are calculated by dividing the width
and height of the display (in pixels) by the number of columns and rows in the cellular automaton
respectively.
• A for-loop then cycles through each row and column in the cellular automaton and performs the
following for each cell:
27
– The colour used to represent that cell is determined by whether it is empty or occupied, and,
if echoing is enabled, whether it was empty or occupied in the previous step.
– The X- and Y- coordinates of the top-left-hand corner of the rectangle used to represent the
cell are calculated by multiplying the position of this cell in the Cell array by the width and
height of one cell (as determined earlier).
– A rectangle is drawn at these coordinates with the width and height determined earlier and
filled with the colour also determined earlier.
2.11.4
Customisable colour schemes
2.11.4.1
Enabling/disabling of echoing
By default, echoing is shown through the use of four distinct colours as follows:
• One for a cell that is empty currently and was empty in the previous step
• One for a cell that is empty currently but was occupied in the previous step
• One for a cell that is occupied currently but was empty in the previous step
• One for a cell that is occupied currently and was occupied in the previous step
A colour scheme that does not display echoing is also offered. This is achieved by representing cells
that have just become empty with the same colour as cells that have been empty for more than one step
and making cells that have just become occupied with the same colour as cells that have been occupied
for more than one step.
2.11.4.2
Black and white suitable for printers
Since each cell is visulalised on-screen as a rectangle of solid colour, it would be unsuitable for screenshots intended for print to have to make use of dithering to represent colours on a monochrome printer.
An option is provided to set the colour scheme to one that uses only black and white (which therefore
does not support echoing).
28
Chapter 3
Evaluation
3.1 Overview of the evaluation criteria
3.1.1
Criteria for cellular automata software
The cellular automata software provides the abstract class CAnimationFrame from which all rule-sets
can be developed. If this class implements all the functionality requried by a cellular automaton correctly then all of the rule-sets which have been implemented in classes which are descended from it
must be able to produce output known to match that of previous cellular automata systems which have
implemented the same rule-sets. The implementation of the output of the “Game of Life” has been thoroughly tested by comparing its output for established patterns such as the glider gun and R-pentomino.
The output has been seen to match the output displayed by Callahan’s software and the screenshots
provided by Toffoli and Margolus [19].
The software has on several occasions been run for several thousand steps. This is seen as evidence
that it is capable for running for the durations required by this project. Although it is impossible to test
whether the software can run a cellular automata simulation indefinitely by executing it, it is clear that
its duration exceeds that of the implementation provided by Mercer since particles have been observed
in the execution of the cellular automata software written for this project to reach on edge of the board
29
and then in the following step appear at the other edge of the board thanks to the periodic boundaries
implemented by the wrap-round device.
3.1.2
Criteria for database storage
The results that are stored in the database need to be readable to both the program comparing the results
to those of the PDE model and to any other programs intended for processing the results.
To compare the results of the cellular automata models to the results of the PDE mode will require
that the results of both models are loaded from a database by the program doing the comparison. For this
reason, successfully being able to perform such a comparison will be seen as evidence that the cellular
automata software has met its requirement of being able to store its results in a database and that they
have then been read successfully by the program comparing the sets of results.
Results from the Rotational Swapping model, after having been saved in a database, have been used
as data for research conducted by Brodlie and Lopes [2]. This is seen as evidence that the cellular
automata software has successfully stored results that have later been read by a program from outside
of this project.
3.1.3
Criteria for the visualisation
During the testing of cellular automata software, screenshots (see Appendix D) from implementations
of established rule-sets were seen to show results matched those from implementations of the same
rule-sets outside of this project. The fact that this is clear from screenshots generated by this cellular
automata software is seen as evidence that the visualisation of the simulation works as intended. The
software has been run on several different PC’s and the visualisations have functioned correctly in all
cases. This is seen as further evidence that the visualisation provided by the cellular automata software
works as intended.
3.1.4
Criteria for the model of gas diffusion
All of the rule-sets, when implemented in the cellular automata software are expected to model physical
behaviour accurately. This means that after the models have been run with a specific input, a histogram
of their output should be approximately close to that of histograms of the results of other established
models of diffusion when given the same input. However, just examining the input and output of the
system would be treating it as a “black box” [10, pp.22] and would potentially allow for the system
30
to produce non-physical behaviour while coincidentally producing results that match those of the established models. A case where this may have occurred for the Diagonal Swapping model will be
considered.
3.2 Established models of diffusion
A “PDE model” (provided by Walkley) will approximate Oran and Boris’s diffusion equation [14] using
uniformly spaced points with periodic boundaries. Once the PDE model has been implemented, a
Comparison Program will be written to compare its results with those of the cellular automata model.
3.3 Trends apparent from visualising the simulation
From watching a visulisation of the Diagonal Swapping model it is clear that the system is showing nonphysical behaviour. When the model is run with the initial conditions of the board being empty except
for one cylinder of particles then a visualisation of simulation does not show any obvious anomalies.
However, when the model is run with initial conditions of the board being empty except for a circle
of particles then it becomes apparent that there are certain cells that no particles will ever be able to
reach (see screenshots in Appendix D), which is seen as non-physical behaviour. The fact that certain
cells have never been occupied by particles in the entire run of the simulation is not apparent from
a one-dimensional histogram produced from the final positions of all the particles in the simulation.
However, this behaviour would be shown in a two-dimensional histogram showing the number of times
any particle’s final position had been in each cell after the simulation had been run multiple times.
3.4 Evaluating the 1-D model against an existing mathematical model
3.4.1
Software used to obtain the results of the PDE model
Three methods for implementing the PDE model have been considered. One method is to implement
the PDE model in C/C++. The other two methods involve implementing it in MATLAB.
If the code to run the PDE model is written in C/C++ then this code can be incorporated into the
GDcellular automata program, either by including this code at compile-time or by linking to a DLL containing the PDE code. One advantage of linking to a DLL is that the DLL can be patched at a later date
31
without the entire program having to be updated. However, since GDcellular automata is not intended to
be distributed or developed further than its current state, this will not be considered necessary. Creating
a DLL would also restrict the program’s execution to the Microsoft Windows operating system. This
would still leave the option of including the PDE code into the GDcellular automata program directly.
The C/C++ Standard Library ¡math.h¿ does not have any provides matrix functions adequate for the
needs of the PDE model. **Get quote about MATH.H**. Microsoft’s DirectX SDK provides some of
the matrix functionality we need through “helper functions... which are... easily integrated into your
application, and they provide a decent level of performance” [6, pp.195]. Matrix multiplication is provided by the “D3DMath MatrixMultiply” function which “multiplies two matrices together, returning
a concatenated matrix representing both of the input matrices” [6, pp.192]. However there are further
functions that are required for an implementation of the PDE model, such as a function for the creation
of an identity matrix.
Microsoft Visual C++ provides debugging tools to detect and isolate errors in source code [9, pp.13]
and tools to detect and isolate run-time errors such as “watching variables’ values” [9, pp.41] and “setting breakpoints” [9, pp.44]. However, testing beyond the scope of these available debugging tools
would be required if we wished to implement all the matrix functions required to implement the PDE
model in C/C++. As well as the ability to multiply to matrices together, MATLAB provides the three additional functions necessary to implement the PDE model. These are “linspace” to “generate an equally
spaced vector of n values between a and b” [8, pp.12] and “eye” and “zeros” to build “identities and
matrices of 0s and 1s” [8, pp.6]. Because these functions are provided by MATLAB it will be assumed
that they work as described and require no further testing. For this reason MATLAB will be considered
to be more suitable for implementing the PDE model than C/C++.
After a script (provided by Walkley) has been written to run the PDE model in MATLAB we then
have two options for how our Comparison Program is to access the results for comparison with the
results of GDcellular automata’s 1-D diffusion model. We can use an existing SDK to enable our
comparison program to call MATLAB functions directly ** Get quote about MATLAB C++ SDK **
or we can run the script from within the MATLAB environment, each time manually specifying our
required set of parameters. Using the SDK would require only one comparison program to be written,
which could automate the obtaining of data from the PDE model for its comparison to the data output
by the cellular automata model. A ”for” loop could be written in the Comparison Program that would
supply MATLAB with each of the required sets of parameters. However, since the PDE model calculates
32
the average position for each particle it is only necessary to run it once for each set of parameters. By
contrast, since the cellular automata model makes use of a random number generator, it will have to
run several times for each set of parameters and have the results of each run averaged in order for
a comparison to be made with the PDE model. Even after the cellular automata model’s results are
averaged, there may still be some anomalous data that biases its results.
3.4.1.1 Parameters for the MATLAB Script
• “n” - The number of co-odinate points to plot. This should correspond to the number of cells per
row in the cellular automata model.
• “nsteps” - The number of steps to run the model for.
3.4.1.2 Other Features of the MATLAB Script
As well as solving the partial differential equations provided by Oran and Boris for the given parameters,
then MATLAB script also has the following features the following features to make it suitable for
comparison with the cellular automata model:
• The 1-D gas diffusion cellular automata model requires each row of the board to be made up of
an even number of cells. To take account of this, the MATLAB script automatically converts
the number of points that it plots (which corresponds to the number cell in a row of the cellular
automata model) to an even number by subtracting one if necessary.
• The PDE will be have periodic boundaries. True cellular automata systems (unlike the simple one
that Mercer describes [13, pp.752]) must be periodic. In this project, the system is preiodic since
the board implements a wrap-round device like the one proposed by Toffoli and Margolus [19,
pp.16]. Having a wrap-round mechanism means that the greatest difference between a particle’s
final position after running the 1-D cellular automata model and its average position on the PDE
model is half of the width of the board, since any distance greater than half the row size between
the two points would result in the particle moving closer to the point from the PDE model from
the opposite direction.
33
3.4.1.3 Storing the PDE model’s results in a database
MATLAB provides functions for writing text-based and numerical output to a file. Once the script has
finished executing the model it will open a file for writing and then systematically output its results.
3.4.2
The program to compare the results of the diffusion model and the PDE model
3.4.2.1 Tools used to create the program
The Comparison Program’s function will only involve statistical analysis and therefore will not benefit from being written in an object-oriented language. Furthermore, programs that require a Virtual
Machine for their execution are known to run more slowly than programs which can be compiled for
a specific processor type and operating system. For these reasons the Java language will considered
unsuitable. The Comparison Program shall be written in C.
3.4.2.2 Methodology employed to compare the two sets of results
After running the PDE model for chosen numbers of steps, the number of steps in the cellular automata
model which produces the closest matching output shall be considered to correspond to the chosen
number of steps in the PDE model and will provide a ratio between the length of one step in the cellular
automata model and the length of one step in the PDE model.
The outputs will be compared by plotting histograms of the two models’ results with the x-axes
referring to the position of the column in the cellular automaton and a set of uniformly spaced points in
space respectively and the y-axes referring to the number of particles that finish in these columns/points
respectively. The average difference between the values of the y-coordinates for corresponding values
of x will then be calculated.
The cellular automata model shall be run systematically for known numbers of steps and the average
difference between the two sets of y-coordinates will be recorded. The number of steps that produces
the lowest average difference will be considered to be the best match for the given number of steps in
the PDE model.
34
3.4.3
Interpreting the results of the comparison
3.4.3.1 How finding a Correlation between the number of steps in the cellular automata model
and the number of steps in the PDE model will show that the cellular automata model is
realistic
The script provided by Walkley takes as input parameter the number of steps to run the model for. One
of the parameters it then outputs is the absolute time that the model has been run for (in fixed units of
time). By comparing the ratio of the number of steps the PDE model has been run for and the number of
seconds this corresponds to we can calculate the duration of one step in the PDE model (in the same fixed
units of time). Being able to successfully establish the duration of a step in the cellular automata model
will be seen as evidence that the cellular automata model provides a reliable model of gas diffusion over
time.
3.4.3.2 Appropriatenss of the PDE model for comparison due to its use of averagesinstead of
random Numbers
The PDE model calculates the average position that each particle will end up in after a given number
of time steps (where one time step is equivalent to a fixed amount of time). The cellular automata
model does not supply us with the average position a particle will end in. Instead it supplies us with
one of the possible positions each particle may end up in. In the cellular automata model a particle will
not necessarily end up in the same position on successive runs. For a given set of parameters, no set of
results from the cellular automata model can be considered more accurate than any other, so it would not
make sense to pick any one set of results from the cellular automata model to compare with the results
of the PDE model. To be able to compare the cellular automata model to the PDE model we need to
calculate an average of its results. Running the cellular automata model 100,000 times and averaging its
results should give a fair representation to each possible final position. A graph of these average values
should produce a smooth curve and can then be compared to the results of the PDE model.
3.4.3.3 Consequences if the 1-D Model’s results did not match those of the PDE model
The 1-D model of diffusion we have implemented here was based on a rule-set suggested by Toffoli and
Margolus [19, pp.102-8]. They have also shown there are at least two different methods for modelling
2-D diffusion using cellular automata. However, in one-dimension there can be only one direction in
35
which swapping can take place. A particle can be swapped with only either of its immediate neighbours
if the system is to accurately model physical behaviour, otherwise particles would be leaping from one
point in space without passing through the intermediary points between these two points. This would
suggest that the swapping algorithm used in both the 1-D model is the only method that can provide
an accurate model of physical behaviour. Because of this, finding that the 1-D Model’s results did not
match those of the PDE model would mean that diffusion could not be modeled on a one-dimensional
scale using cellular automata.
3.4.3.4 Cosequences if the 1-D Model’s results did match those of the PDE model
Examining a one-dimensional histogram of the results of the Diagonal Swapping system does not show
the non-physical behaviour it produces. However, producing a two-dimensional histogram does show
this fact because, unlike the one-dimensional histogram, the two-dimensional histogram provides information about every single cell. In the case of a one-dimensional model, a one-dimensional histogram will be able to provide information about every single cell in the system. For this reason, a
one-dimensional histogram will be considered an adequate means to compare the entire contents of the
simulation against the PDE model.
3.5 Results of the Evaluation
After the PDE model had been run for 100 steps for 150 uniformly spaced points it was found that
number of steps that the 1-D Diffusion model (for 150 columns accordingly) had to be run for to provide
the lowest average difference was approximately 46 steps. The average difference tended to increase
as the number of steps the 1-D Diffusion model was run for decreased below 45 or increased above
47. However, the average difference when the 1-D Diffusion model was run for 46 steps was actually
greater than for 45 or 47. For this reason, the ratio of 45 steps in the 1-D Diffusion mode to 100 steps
in the PDE model is only an approximation. 200 steps of the PDE model was approximately equivalent
to 92 steps of the 1-D Diffusion model and 250 steps of the PDE model was approximately equivalent
to 115 steps of the 1-D Diffusion model. These test cases all demonstrate a ratio between the number
of steps in the 1-D Diffusion model and the number of steps in the PDE model to be 0.46:1. The
continuity between these ratios would suggest that the 1-D Diffusion model is accurately modeling the
same physical behaviour as the PDE model and that there is a linear relationship between the duration
36
of the two models.
When the number of uniformly spaced points was increased to 300 there was not such a clear ratio.
In these test, 100 steps of the PDE model was closest to between 176 and 186 steps of the 1-D Diffusion
model. 200 steps of the PDE model was closest to between 340 and 360 steps of the 1-D Diffusion
model. From these ratios it may be that by doubling the number of uniformly spaced points in the
PDE model and the number of columns in the cellular automata model, the ratios between the numbers
of steps has quadrupled, although since the results of the comparison are much more vague for 300
uniformly spaced points, the establishment of such a ratio is far from conclusive.
Tables of the results of the average differences are provided in Appendix B.
3.6 How the work could be extended
3.6.1
Comparing 2-D rule-sets with a 2-D PDE model
If the one-dimensional diffusion model and one of two-dimensional diffusion models are run on boards
of the same number of columns the two-dimensional model will require more processing time than the
one-dimensional one since it has multiple rows to process. A two-dimensional PDE model will take
longer to execute than a one-dimensioanl one for the same reason. Due to the amount of processing
time needed to run and compare the two-dimensional models, such a task has not been possible within
the time constraints of this project.
3.6.2
Extending the cellular automata software to produce histograms of the 2-D diffusion models
The cellular automata software created for this project only supports two-dimensional boards. A histogram of the final positions of particles in one of the two-dimensional rule-sets over several runs would
require three dimensions; two to represent the cells on the board and one to represent the number of
particles which finished in that cell, so the histogram rule-set implemented in this project would be
unsuitable for creating histograms of the results of the two-dimensional models as it would be able to
show trends such as the non-physical behaviour observed in the Diagonal Swapping model.
37
3.6.3
Varying the value of lamda for the Poisson clock
The implementation of the Poisson clock described by Toffoli and Margolus in this project has a 50%
probability of ticking at each step [19]. It may be possible to bias the RandomBool function provided
by CAnimationFrame to other probabilites. The effect that this has on the ratios between the number of
steps in the 1-D Diffusion model and the PDE model could then be examined.
3.6.4
Implementing the STIR algorithm
An implementation of the STIR algorithm was attempted while testing random number generators with
the Random Walk. The implementation used the board on which the Random Walk took place as the
source of bits on which to apply the algorithm. Since the board for the Random Walk only contained
one particle, this attempt failed to provide any randomness at all. It may be possible to implement the
algorithm by making use of a second board to supply the bits, rather than retrieving them from the board
on which the model is being run.
3.6.5
Testing for a greater range of the number of uniformly spaced points in the PDE
model
The 1-D Diffusion model’s results were compared to those of the PDE model for 150 and 300 uniformly
spaced points. It was debated whether the ratios between the numbers of steps had quadrupled or not
due to the doubling of this number. If further time were available for evaluating the system a comparison
could be made for 600 uniformly spaced points to see if the ratio was eight or sixty-four times that for
150 steps, thereby settling whether the ratios had in fact quadrupled when the number of points was
doubled.
The fact that this could not be performed due to time constraints would suggest that cellular automata
models are inferior to the PDE model in terms of its cost to run.
3.6.6
Run model a greater number of times to get a better average
Averages were obtained from the 1-D Diffusion model for its evaluation after it has been run 100,000
times. Better averages could be obtained by running the model for a greater number of steps, however
this was not possible within the time limit of the project.
38
Bibliography
[1] Banahan, M., Brady, D., Doran, M., The C Book: featuring the ANSI C Standard, Second Edition,
Addison-Wesley (Wokingham, England), 1991
[2] Brodlie, K. and Lopes, A. Isopoints with uncertainty, IEEE Visualization Conference 2006 (submitted).
[3] Callahan, P, Wonders of Math - The Game of Life, http://www.math.com/students/wonders/life/life.html,
web page accessed on 8 Mar 2006
[4] Carrel-Billiard, M., Friess M. and Mauny, I., Programming with VisualAge for C++ for Windows,
Prentice-Hall (New Jersey), 1997
[5] Chopard B, Dupuis A, Masselot A, and Luthi P., Cellular Automata and Lattice Boltzmann Techniques: An Approach to Model and Simulate Complex Systems, 1998, unpublished manuscript
[6] Dunlop R., Shepherd D. and Matrin, M., Teach Yourself DirectX 7 in 24 Hours, Sams Publishing
(Indiana), 2000
[7] Gravner, J., Cellular Automata, http://www.tiem.utk.edu/ courses/course2/gravner/notes/lectures.ps,
web page accessed on 30 Jan 2006
[8] Higham, D. J. and Higham N. J., MATLAB Guide, Society for Industrial and Applied Mathematics
(Philadelphia), 2000
[9] Horton, I., Introduction to Microsoft Visual C++ 6.0 Standard Edition, Wrox Press, 1998
[10] Kulak, D. and Guiney, E., Use Cases: requirements in context, ACM Press (New York), 2000
39
[11] Matsumoto, M. and Nishimura, T., Mersenne twister: A random number generator (since
1997/10), http://www.math.sci.hiroshima-u.ac.jp/ m-mat/MT/ewhat-is-mt.html, web page accessed on 2 March 2006
[12] McConnell, S., Rapid Development: Taming Wild Software Schedules, Microsoft Press (Washington), 1996
[13] Mercer, R., Computing Fundamentals with C++ - Object-oriented Programming and Design,
MacMillan Press (London), 1999
[14] Oran, E. and Boris, J., Numerical simulation of reactive flow, Second edition, Elsevier (New York),
2001
[15] Petzold, C., Programming Windows, Fifth edition, Microsoft Press (Washington), 1999
[16] Resnick, M. Turtles, Termites and Traffic Jams, Seventh edition, MIT Press (Cambridge, Massachusetts), 2001
[17] Savitch, W., Absolute C++, Pearson Education (Boston), 2006
[18] Schildt, H., Java 2: The Complete Reference, Osborne/McGraw-Hill (Berkeley, California), 2001
[19] Toffoli, T. and Margolus, N., Cellular Automata Machines, MIT Press (Cambridge, Massachusetts), 1987
[20] Wigglesworth, J. and McMillan, P., Java Programming: Advanced Topics, Thomson Course Technology, 2004
40
Appendix A
Checking the program’s output was as expected for well-established rulesets before trying to implement
more diverse ones. Once I had created the skeleton of the CA program, the first ruleset that I implemented on it was the “Game of Life”. Lots of research on this ruleset had already been done which
meant that there was lots of data available for my program’s output to be compared to. For example,
patterns known to occur in the “Game of Life” include the “R-pentomino” [3] and the “glider” [19,
pp.25], which later lead to Gosper’s discovery of the “glider gun” [19, pp.26]. Toffoli and Margolus
state that “on a lucky run we may find many gliders in the ocean at the same time” [19, pp.25], and
this was also the case for my program’s implementation of this ruleset. If such patterns had not been
observed in my program, since the ruleset was already known to work, the bug would have to lie in
the CA software itself. Isolating such a bug before the other rulesets were implemented would avoid
confusion later on as to whether any unexpected results were due to bugs in the CA software of flaws
that needed revising in the design of the ruleset.
Over estimate processing time required to run simulations. The amount of processing time to compare the 1-D Diffusion model to the PDE model was under estimated. This meant that insufficient time
was allocated for this task. This could be avoided by estimating how long it would take to compare
the two models for one fixed amount of steps, then calculating for how many fixed numbers of steps
the two models would need to be compared and multiplying these values together. The amount of time
allocated for comparing the outputs would then need to be greater than this estimate to allow for any
possible delays.
41
Appendix B
The following tables show the average difference in the “u” values generated by the PDE model for
the given number of steps and the average number of particles in the corresponding columns in the CA
model for each of the specified numbers of steps:
Number of CA Steps
Avg. diff. between PDE and CA results
40
0.00752526
41
0.0068894
42
0.00671948
43
0.00603502
44
0.00595514
45
0.00563844
46
0.00577769
47
0.00542715
48
0.00584269
49
0.00550489
50
0.00615582
Table 3.1: For 100 steps in the PDE model with 150 uniformly spaced points.
42
Number of CA Steps
Avg. diff. between PDE and CA results
86
0.00548616
87
0.00491035
88
0.00508412
89
0.00442237
90
0.00484256
91
0.00441008
92
0.0047987
93
0.00435714
94
0.00490046
Table 3.2: For 200 steps in the PDE model with 150 uniformly spaced points.
Number of CA Steps
Avg. diff. between PDE and CA results
107
0.00506067
108
0.00515661
109
0.00457418
110
0.00476881
111
0.00434168
112
0.00452117
113
0.00441261
114
0.00446521
115
0.00421456
116
0.00444113
117
0.00426626
118
0.0045994
119
0.00452273
120
0.00487284
121
0.00509238
122
0.00527077
Table 3.3: For 250 steps in the PDE model with 150 uniformly spaced points.
43
Number of CA Steps
Avg. diff. between PDE and CA results
160
0.00363855
...
...
170
0.00238575
171
0.00226422
172
0.0022048
173
0.00220715
174
0.00204039
175
0.00202979
176
0.0019033
177
0.00204955
178
0.00182688
179
0.00190726
180
0.00175747
181
0.00187385
182
0.00177219
183
0.00186115
184
0.00185223
185
0.00195074
186
0.00193829
187
0.00205464
188
0.00210096
189
0.00216639
...
...
200
0.00364691
Table 3.4: For 100 steps in the PDE model with 300 uniformly spaced points
44
Number of CA Steps
Avg. diff. between PDE and CA results
330
0.00289029
...
...
340
0.00173639
341
0.0017577
342
0.00164073
343
0.0016835
344
0.00164367
345
0.00181935
346
0.00158022
347
0.00167298
348
0.00156947
349
0.00171528
350
0.00159839
351
0.00165139
352
0.00161824
353
0.00276887
354
0.0027449
Table 3.5: For 200 steps in the PDE model with 300 uniformly spaced points
45
Appendix C
46
Figure 3.1: A UML Class Diagram for the CAnimationFrame class
47
Appendix D
48
Figure 3.2: Initial conditions for a run of the Annealing rule-set
49
Figure 3.3: The Annealing model after 100 steps
50
Figure 3.4: Initial conditions for a run of the Cornering rule-set
51
Figure 3.5: The Cornering model after 100 steps
52
Figure 3.6: Initial conditions for a run of the Triangles rule-set
53
Figure 3.7: The Triangles model after 50 steps
54
Figure 3.8: Initial conditions of a circle of particles
55
Figure 3.9: A circle of particles after it has diffused for 4000 steps. Particles travel in diagonal lines
between the corners
56