_underway_in_Caribbean_c1985.jpg)
Over the summer I am teaching myself a bit of the Lattice Boltzmann simulation method, and rewriting my second-year computing teaching, to be in Python and use Jupyter notebooks. As always with my coding, I am getting problems with numbers that should be positive (such as a density) being zero or negative, which fatal consequences for that run. In parallel, I am doing a bit of trawling the web to see, and learn from, what other people do, when they teach computational physics using Python and Jupyter notebooks.
These two came together nicely, when I came across some teaching notebooks by Garth Wells at the University of Cambridge. The introductory notebook is very nice, and gives a fascinating example of what can go wrong if your code divides by zero. When I teach students, I often encourage students to try things, as the worst that can happen is that the code crashes, and that does not matter. You then just try and work out where the problem is.
But this is for students’ codes that are just doing standard stuff, such as integrating a differential equation. The example given by Garth Wells, is of a problem in the software that was running the systems of 10,000 tons of the USA Navy cruiser USS Yorktown. The software divided by zero, went down like a pile of cards, and the entertaining Wikipedia page on this records that what happened next is disputed, but that it seems the cruiser was becalmed for at least two hours. The software was running Windows NT (this was the 1990s) so presumably they had to switch it off and on again.
I think this is a nice example, that is great for showing students who want to go on to code more seriously, for example as a job, that the outside world really cares about a well written code that does stuff like check for zeros before division. The Wikipedia article is silent about this, but I can imagine some admirals etc would have asked some hard questions of whoever wrote the code responsible for this debacle.
Chance & Necessity 