Philosophy…

Writing computer code for physics research is quite different to a lot of commercial software development (in a number of ways, which I might at some point write about in detail here).

For example, graphical output. In most consumer software, it’s usually pretty important to at least have a nice-looking graphical interface for the user. In special cases, e.g. games, the graphical (and aural) feedback is pretty much the whole point of the software, so it’s obviously important to get it right.

In scientific simulation, graphical feedback often doesn’t have quite the same status because it’s not normally the main output of the software. Instead, the main purpose of the code might be to produce huge data files which can then be analysed to measure various properties of the simulation’s ‘trajectory’, (e.g. temperature, pressure, structure) producing results broadly analogous to those taken in a real-life experiment. Whether or not the program looks good while it produces this trajectory is less important, and because speed and efficiency is usually such a key consideration in simulations, anything that might introduce an unnecessary overhead (e.g. graphics) is usually turned off.

However, in another way, graphics play an even more important role in scientific simulation — bug checking. In contrast to consumer software, where a bug might not matter as long as it has no observable effect or doesn’t crash the program, the value of scientific simulation code is completely tied up in knowing exactly what the code is doing. It’s no good thinking that a bug doesn’t matter as long as the results come out as expected, because the whole point is that you don’t know in advance what the results will be, and you’re interested in how they might differ from expectations. An interesting simulation result is no use at all if you’re not sure that the code, in microscopically fine detail, is doing what you say it is — the point of the simulation is to find out how large-scale effects emerge from known small-scale dynamics and if those small-scale dynamics are subject to errors and bugs, you probably won’t discover anything useful.

So, by visualising your simulation, you can check for bugs which might not be obvious during analysis. You can check that the individual particles or molecules or whatever are acting believably, as you programmed them to, and then be a lot more confident in any large-scale, emergent effects that you discover.

Also, more importantly, it looks cool.

OVITO

For a while I’ve been looking for an easy to use and powerful visualiser for atomistic simulations. I’ve used some not particularly fancy home-made code for this but wanted something more versatile that was still able to handle tens of thousands of particles.

So, OVITO which uses OpenGL rendering and is completely free and cross-platform, is perfect. I wrote some code that quickly converts my simulation’s data files (‘trajectories’) into a format readable by OVITO, loaded them in, and now I can spend all day making videos instead of doing real work. This program also easily allows special effects like color-coding particle properties, structure analysis, rotation/slicing of the simulation box etc., so it’ll be handy for preliminary analysis as well as making illustrative videos for seminars and so on.

An example

I recently posted about gas-liquid phase separation, specifically ‘spinodal decomposition’ in which the phase separation happens quickly throughout the whole system, rather than by nucleating at a specific site. A while ago I tried running something similar but in the presence of a template for crystal growth (i.e. a regular lattice at one end of the simulation box). This templated growth is another main focus of the project so we thought it might be interesting to combine the two ideas.

A video, produced with OVITO:

What seems to be happening for the parameters I’ve used is that the template causes a crystal to grow but, as was discussed in this paper, the crystal can’t locally coexist with the liquid, even though the liquid has a roughly similar density to the crystal. Instead, the crystal needs to coexist with the very-low-density gas phase, so it coats itself with a thick layer of gas which ‘shields’ the crystal from the liquid as it grows. It’s a ‘split interface’ (Crystal-Gas-Liquid) similar to those discussed here and may substantially slow down the growth of the crystal. Experimentally, this means that little crystallites form which effervesce, or bubble, as the gas bubble they keep trying to form around themselves floats away. It’s an inherently nonequilibrium effect because, at equilibrium, the gas-liquid separation disappears and you’re left with just two phases: a crystal and a very tenuous vapour. The effect of ‘metastable’ (nonequilibrium) phase transitions like the gas-liquid separation is a key focus of my work.