EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

1

For your final coursework, you need to select one of the problems listed in this document, and write a
Python program to solve it. The details of what you need to do depend on the problem, but if you need any
clarification you can ask me by email. The final Tuesday morning session (14th December) is a workshop to
help you with these projects - here you can get staff/GTA support in debugging. I’m also of course available
by email and Teams if you want to discuss your ideas and help pick good solutions. We can help you with
design, debugging, ideas etc – but we won’t write your code for you.

All of these projects are (deliberately) open-ended – there is a ‘basic problem’ to be solved, but scope to
take things further and do more, to score extra marks. As always, this is strongly encouraged!

Some of these projects are Earth-science themed, but many are not. This does not of course matter. The
goal here is to demonstrate your coding ability. All skills learned on (for instance) a word-search solving
project are very much transferable to real scientific problems.

As well as normal comments, your program also needs a brief (20 lines max.) explanation of how it works
(to help guide markers, and to enable you to flag up bits that you are proud of and you want to make sure
aren’t missed). This should be done with comment lines at the start of your program – if you have multiple
.py files, put this at the top of the ‘main’ file (i.e. the one that should actually be run to use the program).

Some general advice: start with algorithm design, and start by getting the basic version of the program
working. Bells and whistles can be added later. Test your code as you go, and build it up a bit at a time.

Marks scheme: This coursework is marked out of 40. Program functionality (i.e. does it work?) is worth 16 marks plus
the * value of the problem (see below), so if it does the minimum required by the project specification, it will score at
least 40%. Non-functioning programs will not (normally) score 0 – their score will depend on how serious the bugs
stopping them working are. Layout, style, output presentation (comments, sensible variable names, no/few pep8
warnings, output clear and in good English, etc.,) are worth 8 marks. The remaining marks (16 if the project was not
*ed) are for going beyond the basics and adding extra stuff – this is optional, but you are encouraged to try! There is
no fixed scheme for these marks – they will be awarded at my discretion, depending on how hard they were, how well
they work, how much of a good idea they were, etc. Please bear in mind that this marking scheme is intended to
generate final marks distributions on the normal university scale, where 70%+ is first class (i.e. very good), and is not
meant to be easy to get. I expect the mean mark to be in the mid-low 60s – so if you do end up with something like
25/40 (=63%) – you are doing fine! Anything over 28/40 is first class.

* values: Some projects are fundamentally harder than others. These are flagged with a * and a number, e.g. *5. This
means that the ‘basic functionality’ mark for completing this project is 5 marks higher than normal, so 21 not 16.

Plagiarism: This is independent work, and you are expected to do it yourself. Directly copying code (from someone
else, or an online source, or my samples, or anywhere) without citation is not allowed. Working in a group to
produce identical or very similar code is also not allowed – this is not group work. Copying or collaborating like this
comes under the heading of plagiarism, and the consequences can be serious – they start at scoring zero for the
assignment, and can be applied to the person whose code was copied as well as the person doing the copying. This
doesn’t mean that you can’t ask me (or each other) for help, suggestions, hints, advice, or debugging assistance, or get
ideas from websites! You just can’t submit code that you have not written and designed yourself, without
acknowledging the input from the other source.

If you are not sure whether or not you are crossing the line from ‘help’ into ‘plagiarism’ – just add a
comment to explain what you have done!

Use comments to cite sources. The exact form of the citation does not matter, but it must be sufficient for the
marker to identify the person who provided the code, or to find the code if it’s from the internet. Make sure it’s
clear where the ‘borrowed’ code starts and where it stops – it’s not sufficient to say at the start of a file ‘some of this
code was written by X’. For instance, all three of the following citations provide sufficient detail.



EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

2

# This function taken from http://www.codinggeeks.com/python/maths-functions,
example #4.

# Code from sample program ‘fibonacci.py’ (session 4 of this course)…
[… lines of code]
# End of code from ‘fibonacci.py’

# Next three functions written by Joseph Bloggs

If you have a block of code mostly taken from another source, but with some minor modifications made by you, or you
have a block that you worked on the design of with someone else, just flag that up with something like…

# Next 10 lines from http://www.codinggeeks.com/python/maths-functions, example #4 – with
minor changes to variable names

… or

# This block of code designed in discussion with another student, Joe Bloggs, but coded
by me alone

… [lines of code]

# end of co-designed code


It’s NOT a good idea to identify your code with line numbers. You might think that a comment like this is OK

# Lines 13-19 are from example 23 of http://www.codinggeeks.com/python/list-
methods

… and it IS fine if the line numbers are right… but it’s too easy to add code to your program that changes the line
numbering, and then forget to update the citation!

Feedback and marks return: We normally guarantee that coursework will be marked and returned with feedback
within two weeks. Work submitted at the end of term is an exception however, as many markers will have out-of-
term time commitments. These projects will also take a while to mark! We will get the marks and feedback to you as
soon as possible at the start of the spring term. We will aim for this to be during the first (exam) week, but it might be
a little later.

Submit your program by ESESIS as a single .py file (OR a single .zip file if you need to submit
multiple .py files and/or data files your program needs to run that weren’t supplied by me) by
Friday 17th December, at 4pm. Normal late submission rules apply.

Answers to some possible questions:

(1) Can I do a project not on this list?
No!

(2) Can I do more than one of these?
Yes, but I can only give you marks for one! If you do two, I will mark both and give you the higher of the two marks,
but this is unlikely to be a good way to get marks. Just do one well. Note that for (1) and (2) – the wordsearch ones – if
you do both I would count a wordsearch generator as a (good) ‘extra’ for the wordsearch solver.

(3) I’m not sure what to do but I am worried they are all hard
Do one of the ones without a * - so (4) or (9) - and start early so you can ask for help. These two are similar in coding
difficulty, but 4 is ‘conceptually’ simpler, so if you are really worried, do that, though (9) probably has more options
than (4) for ways you could extend it. Note that you can score just as highly for a project without a * as one with a *
value if you add extra features. Start by getting the basics working, then add extra things if you have time.
EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

3

1. Creating ‘wordsearch’ puzzles (*1)

Basic functionality: Write a program that creates wordsearch puzzles (see
https://en.wikipedia.org/wiki/Word_search if you don’t know what I mean). It should get a list of words to
place, get a grid-size for the puzzle and eventually output the full wordsearch grid. Input and output can be
whatever you think is appropriate – you can use the input function, or read data from files – whatever you
think is best. Files can be any format, though if you use files for input you should explain what input file
format your program needs in your starting comments. Output can also be to the screen, to a file, etc.

For the ‘basic’ program you only need to produce wordsearches were words run horizontally and vertically,
and they don’t need to run ‘backwards’.

Some ideas for harder things to try to add: Words can run in any directions (including diagonals, and
including backwards). The same letter in the grid can get used for multiple words. Program handles grids
that are too small to fit all the words in with a sensible error message. Program has ‘difficulty’ settings (e.g.
different likelihood of words running in harder-to-read directions, increased scattering of the grid with
‘partial’ versions of the words at high difficulty settings, etc.).

2. Solving ‘wordsearch’ puzzles (*3)

Basic functionality: Write a program that can solve wordsearch puzzles, i.e. when given a wordsearch grid
and a series of words to find in the grid, it will check whether they are all there, and show the user, in some
way, where they actually are. As with (1) above, input/output can be in any form you think is sensible. The
basic version of this program needs only deal with words running horizontally and vertically, that aren’t
running backwards.

Some ideas for harder things to try to add: Deal with diagonal/backwards words. Detect and tell the user
when words appear more than once. Output the solved grid in a graphical way using matplotlib (e.g.
colouring the words). List and/or graph the number of partial occurrences for each word (e.g. if looking for
‘python’, list the number of occurrences of ‘pyth’, ‘thon’, ‘tho’ etc.)

3. Geological map creator (*9)

Basic functionality: Write a program that lets users specify a sequence of geological formations (with
thicknesses and names), together with a dip angle and direction, and some way to specify an overall
vertical position for the sequence (e.g. the height of the base of the bottom layer above sea level at the
centre the map). It should then create a geological map from this data, showing how the formations would
intersect a flat topography - either as an image to be output via imageio, or using matplotlib.

Some ideas for harder things to try to add: The basic program is already hard here, but you could also add:
surface topography (input in any way you like – the simplest would be to use a greyscale image to define
heights), faults through your sequence, igneous intrusions within your sequence, cross sections. Adding
folds would be VERY brave – I’ll be seriously impressed with anyone who gets that working.

4. Encrypter / Decrypter

Basic functionality: Write a system that lets users encode text messages into some encrypted (i.e. secret
code) form, and can then decrypt (decode) them as well. The text could come from direct input or be read
from a text file – whatever you think best. Likewise the output could just be printed, or could go to a file.
EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

4
You will either need two programs (one to encrypt and another to decrypt), or one program in which the
user can choose which they want to do. There are a whole load of possible encryption algorithms – the only
stricture here is that you should write your own code to do this, rather than using any pre-existing modules
or code that does encryption/decryption. A simple option would be a ‘shift-cypher’, (e.g. where A becomes
B, B becomes C etc.), but there are many more complex and less crackable options you could use, including
versions of the approach used in the World War 2 enigma code machines. Feel free to research ideas and
come up with something clever!

Some ideas for harder things to try to add: Use a really clever and hard-to-crack encryption algorithm. Use
multiple algorithms one after the other for extra security. Use an algorithm that requires a numerical or
text-phrase ‘key’ (so you need to know the key as well as just having the program to decrypt).

5. Bridge (the card game) dealing statistics (*2)

Basic functionality: Contract Bridge (see https://en.wikipedia.org/wiki/Contract_bridge) is a card game for
four players, which begins with each player being dealt a 13-card hand from a standard 52-card pack of
playing cards. Bridge players analyse their hand by, among other things, looking at the total number of
‘High Card Points’ (calculated as 4 points for an ace, 3 for a king, 2 for a queen, 1 for a jack), looking for suits
with 4 or more cards, and ‘void’ suits in which they have no cards. Write a program that simulates a very
large number of bridge deals, and uses these deals to estimate the probabilities of any particular hand
containing (a) at least one three-card suit, (b) at least one four-card suit, (c) at least one void suit, and (d)
enough ‘high card points’ to open the bidding (which is 12 points). The program can output its findings in
any way you see fit.

Some ideas for harder things to try to add: There are many ways to provide more statistics of course – for
instance you could analyse the probability distribution of every possible number of high card points (0-40).
Or the probabilities of suits with every possible number of cards (0-13). You could even look at the
probability of some outcomes given others (e.g. given that you have a suit of 5 cards or more, what is the
chance that you also have a void suit)? You could provide graphical output of statistics with matplotlib.
Bridge is a partnership game where your hand must be played in conjunction with that of one particular
other player. This means you could also usefully look at questions such as ‘If I have 6 or more cards in one
suit, what is the chance that my partner has at least 4?’. Note that a full understanding of this very
complicated game is not expected – if you try to fully learn bridge to do this assignment, you will run out of
time!

6. Drainage pattern analysis (*7)

Basic functionality: You are provided with a ‘DTM’ file dtm50.txt,
which represents digital terrain model data (heights) at 50m intervals
over a 10km x 10km square of hilly terrain in Scotland. The values are
space-separated (not comma separated), and are in logical order (so
the each row is 200 heights above sea level, in meters, from west to
east, and rows are arranged from north to south. The data is visualised
on the right as a greyscale image, where white is high and dark is low.
Write a program that treats this area as a 200 x 200 grid of squares,
each with a height obtained from the DTM data, and uses this to
analyse which squares are likely to experience relatively high and
relatively low waterflow. Use a simple waterflow model, where rainfall is evenly distributed across the area,
and water always moves from one square to the lowest adjacent square (so always moves North, South,
East or West). To simulate what happens to rain falling on each square, determine its path by repeatedly
tracking its movement downhill, until it moves into a square on the edge of the grid (where you cannot
EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

5
calculate flow direction properly). If there are two equally low possible directions, your simulation should
choose one at random. Your simulation will also need to make sure that the path cannot visit the same
square twice, or find some other way to make sure that it cannot get into a ‘loop’. Your program will need
to keep track of how many of these ‘water paths’ pass through each square to assess its relative waterflow.

Your program’s output should be a 200x200 pixel image file, in which areas of high flow are brighter than
those of low flow.

Note that this is genuine real-world data* – and our model is simple. This means that results might not look
‘perfect’. One issue is that this dataset actually includes a lake, which may or may not become obvious as
you look at the output.

*nearly - one thing that HAS been ‘fixed’ is that there are no ‘sink points’, i.e. there are no squares which
are lower than all surrounding squares, where water flow could get ‘stuck’.

Some ideas for harder things to try to add: The basic program is hard already! You could implement more
complex models (e.g. movement is also allowed diagonally). You could try to programmatically identify the
lake, and deal with it in some clever way. I’ll leave you to come up with more…


7. Langton’s Ant (*4)

Basic functionality: Langton’s Ant is a scheme for a ‘cellular automaton’ – a
virtual ‘ant’ that moves over a grid using well-defined rules, turning grid-cells
black or white. It exhibits complex emergent behaviour patterns. See the
Wikipedia entry ‘Langtons Ant’ for more details of exactly what these rules
are and how it works. The base functionality for an Langton’s Ant program is
simply to simulate the ant’s motion over a number of iterations specified by
the user, then output (in some way) the resulting grid of black and white
squares – you could do this as a grid of text characters on screen, the same to
a file, or you could generate an image using the imageio module and output
that.

Some ideas for harder things to try to add: Output the grid at regular
intervals as well as at the end. Implement some of the more complex ant schemes mentioned on the
Wikipedia page (e.g. multiple ants, different colours). Find an external module that will let you make a
video of the ant moving over time, rather than just a single image.

8. Battleships game (*4)

Basic Functionality: Create a version of the game Battleships – see
https://en.wikipedia.org/wiki/Battleship_(game). Battleships is a simple turn-based strategy-type guessing
game for two players. In your version, the user will be playing against the computer, and the specification
will be as below (there are many variants of battleships out there).

The game is played on two 8 x 8 grids, one owned by each player. Before the game starts, each player
places five ships onto their grid: a Carrier (5 squares long), a Battleship (4 squares), a Cruiser (3 squares), a
Submarine (3 squares), and a Destroyer (2 squares). Note that there are restrictions when placing ships –
ship can’t “hang off” the side of the board, nor can they be placed on top of other ships. The computer
should automatically place their ships, while users should be provided with some way to place their own
ships in positions of their choosing. Each player can only see the ships on their own grid. The program
EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

6
should however display both grids to the player (in some way), as shot positions will need to be marked on
the opposing player’s grid.

Figure 1: An example of a legal ship setup.

1 2 3 4 5 6 7 8
A De
B Ba Ba Ba Ba De
C
D Ca
E Ca Cr Cr Cr
F Ca
G Ca
H Ca Su Su Su

After set-up, each player takes turns shooting at the other player by declaring coordinates for one shot on
their grid – e.g. “A-4” or “B-6”. If there is nothing at the chosen coordinate, the shot has missed –
otherwise, it is a hit. If the hit resulted in a ship being sunk (all of its squares have been hit), then the player
should be informed of this. Your program will need to display (in some way) all shot positions so far on both
grids, perhaps marked with an X for a miss and an O for a hit. Your program should also provide a message
to the user after each shot, telling them whether the shot is a hit or a miss, and whether a ship has been
sunk.

The user’s shot coordinates should be obtained using keyboard input. The computer, for the basic version,
can select a random grid square for its shot, although it should be intelligent enough to not shoot at the
same square twice.

Figure 2: Example of the player’s view of the computer’s grid after eight turns. Xs indicate misses, while Os
indicate hits.
1 2 3 4 5 6 7 8
A X
B X
C O
D O
E X X
F X
G X
H

An additional rule in our version is that the user has access to a satellite, which they can only use once per
game. They use the satellite as an alternative to firing a shot. When they use the satellite, a radar scan is
performed centered upon a specific square. Your program should then tell the user how many ship-squares
(sunk or unsunk) are present in the 9 squares centered on their target square. In the basic version of the
program, the computer does not use the satellite. For example, using the satellite on E-3 in Figure 1 should
inform the user that there are 4 ships detected in the surrounding area.

The game finishes when one side has sunk all the other’s ships. At this point your program should provide
the user with a suitable victory or defeat message.

EART40003 Programming for Geoscientists M.D.S. 2021

Final Coursework – the Mini Project (40% of course)

7

Some ideas for harder things to try to add: The base program is already pretty long and can be difficult to
visualize. Some other features you could try to add are other Battleship variants. For example, in some
variants, each player can fire a number of shots equal to the number of ships that are still alive (e.g., you
start with five shots – when one of your ships is sunk, you go down to four shots, and so on). You can also
choose to provide the player with special abilities other than the satellite – for example, a Torpedo that
flies across a row or column until it hits a ship. Be creative!

If you’re feeling particularly adventurous, you may wish to give the computer some rudimentary AI – for
example, in Figure 2, a human would try and shoot at B-5 in order to completely sink the ship at that
location. Could you instruct the computer to do the same?

9. Mineral identification ‘expert system’

Basic Functionality: Create a program that helps users to identify minerals on the basis of common
properties (hardness, color, streak, cleavage, luster). Use the tables given at
https://www.oakton.edu/user/4/billtong/eas100lab/mintable.htm for data - you will need to find some
way to provide this to your program in a usable format (e.g. create a csv file with the data in a more
machine-readable format). Note that in these tables H is hardness (on the Moh scale), and luster is not
given in the table, but is either ‘metallic to submetallic’ or ‘non-metallic’ (table 1 is minerals with the
former, table 2 is minerals with the latter).

Your program should ask the user a series of questions about these properties for the mineral they are
trying to identify. It should use the answers to present either one ‘most likely’ mineral, or perhaps a list of
possibilities, or a message saying that you can’t find any mineral that matches their answers. You can
assume that your user knows what these properties mean, and is able to testing for them and answering
questions about them.

Note that while some properties (e.g. hardness) are straightforward, others (e.g. colour, cleavage) are not.
You will need to look at the data and work out a sensible way to categorise these in your data and in your
questions.

Some ideas for harder things to try to add. The simplest versions of this program are not especially hard,
but there is LOADS of scope for taking it further – this is one of the more open-ended project choices. You
could add more minerals, with data from another source. Use some of the ‘other properties’ to add more
questions and distinguish between similar materials. Present an image for the minerals found. Where you
can’t identify the mineral precisely, give a list in descending probability order of what it might be. Display all
possible minerals at each stage of questioning, and show them being eliminated as questions are answered.
Ask questions in an order that tries to minimize the number of questions asked. There are many other