Section 17.1.2.  O

O was designed by Alwyn Jones to overcome some of the drawbacks associated with using Frodo. These problems had arisen because of the history of the program. In particular, O was designed to use a general-purpose memory allocation system to store any kind of model-related data. This would allow the display of any number of molecules and the use of databases for modelling. Although the latter had been introduced in a Frodo variant (Jones & Thirup, 1986), O was designed to take the concept of database use further, some would say to the extreme. Furthermore, O was designed to make it easier for different developers to work on the code without interfering with each other. In the event, only Morten Kjeldgaard and Jin-Yu Zou made any developments with the program.

Much of the data used by O are kept in a memory allocation system, the O database. This database is used to save parameters used by the program (including such things as keywords), macromolecular coordinates and information derived from them (such as graphical objects). As such, the program has no built-in limitations concerning what can be saved and used. A set of coordinates can be downloaded from the Protein Data Bank (PDB) (Bernstein et al., 1977) and stored as a series of vectors that describe the sequence, the residue names, the coordinates, the atom names, the unit cell etc. Some of these vectors contain residue-related data (e.g. the sequence), others contain atomic data (e.g. the atomic temperature factors), while yet others concern the molecule as a whole. The program therefore uses a strict naming convention in handling these data. Each molecule has a name, and the program then forces its own nomenclature for the standard atomic, residue and molecular properties. The user remains free to create new data outside O, bring them into the program by adopting the naming convention, and then make use of them to generate or manipulate graphical images. For example, a series of amino-acid sequences can be aligned with a computer program outside O and information on the degree of sequence conservation can be generated as a series of O data blocks. These can then be read into O and used to colour a Cα trace of a model, for example.

The program also has a strong macro capability that can be used to configure quite complex interactive tasks. It can also be used by a programmer outside O to generate data and a series of instructions for later interactive use.

Similarly, data generated within O can be exported to O-aware programs, significantly reducing the complexity of some crystallographic calculations. For example, real-space averaging of electron-density maps requires, as a minimum, both a series of operators describing the noncrystallographic symmetry (NCS) and a mask. These can be generated from scratch in O and improved and used by O-aware programs without the crystallographer needing to be concerned about the myriad details of axis definitions, rotations and translations.

Plotting is carried out within the O system via an intermediate metafile. When a user creates objects for display within O, calls are made to a set of low-level routines that create the OpenGL instructions on the workstation. Some objects are described in their entirety within the O database, but others are not. Molecular objects fall into the former category, whereas electron-density maps fall into the latter. There are two sets of plot commands, therefore, that are appropriate for each class. To plot an object made from a molecule, the user merely issues a command, and the appropriate metafile is written out, complete with viewing data. To plot other things, the user activates the command and then starts creating objects. Every time a low-level graphics routine is called, something gets written into the metafile. This is terminated with a command. The metafile contains much extraneous data, for example, instructions to the O pulldown menu system. However, it is built up from objects that are arranged in a hierarchy, where the highest-level object is called . Some objects, therefore, call instances of others, while other objects contain graphics instructions that define line start and end points, for example.

This metafile can be processed, and so far three different programs are available. OPLOT (written by Morten Kjeldgaard) generates PostScript output, carrying out a full traversal of the object hierarchy. The other two programs do not carry out such a traversal, but merely process the objects specified by the user. One (written by Mark Harris and Alwyn Jones) generates output suitable for input to the ray-tracing program PovRay (see http://www.povray.org ). The third program (written by Martin Berg) generates VRML output suitable for web-based viewing.

O is in continuous development, and interested readers are encouraged to visit the various internet sites that we maintain. There they will find detailed descriptions of the O command set, as well as various introductory exercises for learning how to use the program. The following publications describe various aspects of O-related features and methods: