Researchers using molecular graphics are about to enjoy the benefits of three technical trends that will help us communicate with our data and with each other: the internet, visual object-oriented programming, and the merger of computer imaging and computer graphics. The internet, with its emphasis on communication, distributed resources, and computer architecture neutrality, has spawned the Java programming language. Only two years after its introduction, and through the fog of excitement, Java already is helping structural biomolecular scientists. We who depend on interactive viewing and control of three-dimensional data and models are uniquely limited by the text and static images that populated the web a year ago. Already, using just rudimentary Java tools, we can finally economically publish 3-D data and models; we can even e-mail them. Object-oriented programming promises --- with proper design --- to help us decompose computational biology modeling into components that can be reused and combined flexibly and robustly. Everyone who wants to study a protein backbone won't first have to write a PDB file reader that knows how to follow a peptide chain, dealing with missing residues and multiple atomic occupancies. Everyone who wants to study packing won't have to write a symmetry generator and collision detector. Visual programming, the interactive linking of program modules together using a graphical editing tool, can make the combining easier, especially for prototyping and idea-generation. The merging of computer imaging (image to image, image to data) and computer graphics (data to image) is driving graphics beyond its geometric line-and-polygon origins. Incorporation of imaging and texture-mapping into cheap 3-D hardware will help us apply traditional imaging tools, such as spatial filtering and shape description, to biomolecular analysis and design problems such as sequence conservation and electrostatic complementarity. Fortunately, existing scientific visualization environments, such as AVS, Iris Explorer, and IBM Data Explorer, offer a preview of the emerging capabilities and moreover point out problems and limitations we must address. In them, users drag processing ``modules" from a palette and connect their inputs and outputs to build networks that process and display data, programming with a mouse instead of a keyboard, and view the resulting images and geometry interactively and dynamically. The modules correspond to future Java components, Beans, with well-defined interfaces and machine-independent operation, aided by machine-specific compiled programs where necessary for performance or access to special hardware such as FFT cards or video input. This data flow/reference model is well suited to a complexity-hiding, object-oriented world where modules need to know nothing about their data irrelevant to their task. Visual WYSIWYG editors are already appearing that will let developers and users link components together, regardless of their locations anywhere on the web, and execute them locally or remotely. This approach's limitations do need to be considered carefully: in particular, the speed of sending data between components, the complexity of saving and restoring networks and state between work sessions, the security of confidential or proprietary data over untrusted channels, and the difficulty users have in selecting and understanding modules.

Back to Workshop Schedule

1996-1997 Mathematics in High Performance Computing