Lab 3: Vectors and Crystals

Maths Lab 3 is available at http://metric.ma.ic.ac.uk/chem/1998/Mathslab3.nb.

Maths Lab 3, the first after the two-session introduction to Mathematica, deals with the topic of vectors or, more specifically, with the use of vector addition to characterize space lattices and crystals. Students get

· a printed Mathematica notebook, crystal.nb, containing text and code;

· access to an online copy of this notebook;

· access to an online version of the notebook containing only the code.

Figure 1 shows where Mathslab3.nb leads: the graphic that students are asked to produce as the final exercise in the assignment. It's a unit cell of the gallium arsenide crystal; the smaller spheres on the vertices and faces (shown red if you're viewing in color) represent gallium atoms, and the larger (green) spheres within the cell, arsenic atoms. I've shown the unit cell in two forms: the one on the left is the working version, in which simple Point primitives have been used to create the spheres, and that on the right is the presentation version, in which these have been replaced by translated Sphere objects, built using the Graphics`Shapes` package.

Figure 1. Conventional unit cell of the gallium arsenide crystal, working and presentation versions.

Specialist molecular modeling software exists for generating graphics like these, including at least one Mathematica package that I'm aware of (there may be more). With these, users can quickly create on-screen models of molecules and crystals, models whose graphical quality is often superior to Figure 1 (certainly to the working version, which is all our students are formally required to produce) and which, in many cases, they can dynamically manipulate on the screen. We made a deliberate choice to use none of this software, and indeed, we didn't even write a package. We require our students to build up this graphic pretty much from scratch, and a laborious business it is.

First, they have to generate the grey bounding lines whose intersections define the lattice points. There are slick ways of doing that in Mathematica, but we haven't used any of them: the code for these lines is

They then have to build the lattice points (where the grey lines intersect, and where they'll eventually be putting the gallium atoms) as explicit linear combinations of three standard primitive vectors, namely , and . The next task is to create a molecular basis, consisting of a gallium atom and an arsenic atom, and place a translated copy of this basis at each of the lattice points. Some of the arsenic atoms then fall outside the unit cell, and these have to be removed. Finally, the covalent bonds between the gallium and arsenic atoms (shown as yellow lines in the figure) have to be created and added to the picture. For some parts of this task, we make very strong suggestions about what to do and how to do it; other parts are somewhat less structured and students are required to develop their own strategies.

Why do it that way, one may ask? Why not hide some of this machinery in a package, or behind a function that automates some of it? Why use mathematical software at all, when specialist applications exist, aimed at chemists and chemistry students?

This is not a course in crystallography, but in mathematics for chemists. The "machinery" is precisely what's important here. Moreover, the appeal of Mathematica is that it offers us, the designers, so much freedom to decide what we automate and what we make an explicit part of the task. For example, we felt that building the lattice points out of linear combinations of the primitive vectors was central to the aims of this piece of work, so we provided no code for this bit except a simple visualization tool based on the Graphics`PlotField3D` package. On the other hand, clearing away those arsenic atoms that happen to lie outside the unit cell is really just tidying up, and we therefore provide students with a suggested way of doing this that is slightly slicker and more automatic.

This code snippet, with its use of a logical function to Select from a list, is actually a little difficult for many students this early in the first year (the exceptions tending to be those with a liking or aptitude for programming). Nonetheless, we made the decision not to hide it, and the same is true of all the code in the Maths Labs, some of which, especially in the later sessions, is a good deal more involved than the above. This design constraint, voluntarily submitted to, places a fairly strict limit on how sophisticated our models and simulations can be, something that becomes especially clear in the next section.