Nano Technology

Abstract
Eric Drexler has proposed a hypothetical nanotechnology based on diamond and investigated the properties of such molecular systems. While attractive, diamond nanotechnology is not physically accessible with straightforward extensions of current laboratory techniques, we propose a nanotechnology based on functionalized fullerenes and investigate carbon nanotube based gears with teeth added via a benzyne reaction known to occur with C60. The gears are single-walled carbon nanotubes with appended o-benzyne groups for teeth. Fullerenes are in widespread laboratory use and can be functionalized in many ways .Companion papers computationally demonstrate the properties of these gears and the accessibility of the benzyne/nanotube reaction. This paper describes the molecular design techniques and rationale as well as the software that implements these design techniques. The software is a set of persistent C++ objects controlled by TCL command scripts. The C++_TCLinterface is automatically generated by a software system called TCL_C++ developed by the author and described here. The objects keep track of different portions of the molecular machinery to allow different simulation techniques and boundary conditions to be applied as appropriate. This capability has been required to demonstrate (computationally) our gear's feasibility. A new distributed software architecture featuring a WWW universal client, CORBA distributed objects, and agent software is under consideration. The software architecture is intended to eventually enable a widely disbursed group to develop complex simulated molecular machines.


Contents
Introduction
Fullerene Nanotechnology
Design Software
Current Software Architecture
Proposed Future Software Architecture
Self replication and Nanotechnology
Applications
Conclusions
1) Introduction
Eric Drexler has proposed a hypothetical nanotechnology based on diamond and there is informed speculation that this technology could have tremendous aerospace applications. Unfortunately, no one knows how to build diamonoid components in the laboratory. To gain the benefits of nanotechnology, a more accessible chemical basis is needed. We have chosen to investigate fullerene nanotechnology and develop software to support this work. Software development is at a very early stage. This paper is a status report, not an exposition of finished work.
2) Fullerene Nanotechnology
A nanotechnology based on fullerenes has been suggested by others. C60 and other cage-like fullerenes provide points, carbon nanotubes provide lines, and these can -- in principle -- be combined to create three dimensional objects. Since fullerenes can be functionalized by a wide variety of molecular fragments [Dresselhaus 96], a wide array of objects with many properties may be created. The first systems we have investigated are various gears built out of single walled carbon nanotubes with o-benzyne groups attached to form the teeth. [Thess 96] has demonstrated a 70% yield in carbon nanotube production so the tube should be synthetically accessible, although generated (10,10) tubes whereas most of our simulations use (14,0) tubes. has shown that benzyne reacts with C60 to form a 1-2 bond between six membered rings and quantum calculations suggest that a similar reaction should take place on carbon nanotubes, although 1-4 bonds are slightly preferred. Adding aromatic rings to the tube should give us relatively stiff molecular gear teeth, and this has proved to be the case.
A typical gear configuration
Using the NanoDesign design and simulation software described below, [Han 96] has shown that -- assuming you believe the force field -- a number of gear and gear/shaft systems will function mechanically in a vacuum. These simulations used a software thermostat and motor, but there is reason to believe that physical implications of these functions can be provided. Preliminary simulations suggest that cooling is possible using an inert atmosphere. Experimental evidence and simulation suggest that lasers may be used to rotate the gears.



The tube is functionalizing with positive and negative charges in appropriate locations and the lasers are used to create a rotating electric field.
3) Design Software
The simple molecular machines simulated so far can be easily designed and modeled using ad hoc software and molecule development. However, to design complex systems such as the molecular assembler/replicators envisioned by the NASA Ames Computational Molecular Nanotechnology Project, a more sophisticated software architecture will be needed. The current NanoDesign software architecture is a set of c++ classes with a tcl front end for interactive molecular gear design. Simulation is via a parallelized FORTRAN program which reads files produced by the design system. We envision a future architecture centered around an object oriented database of molecular machine components and systems with distributed access via CORBA from a user interface based on a WWW universal client.
4) Current Software Architecture
The current system consists of a parallelized FORTRAN program to simulate hydrocarbon systems. Supramolecular conformations come from xyz files (the force field does not require a bond network in the input) produced by a c++ and tcl program using the TCL_C++ interface generator. The software also creates FORTRAN files with indices into an array of atoms indicating where each component (e.g., gear teeth) begins and ends. The user creates tcl files with tcl functions to create and modify c++ objects.


Current NanoDesign software architecture.
For example, this tcl fragment creates a buckytube:
# create a buckytube
set tube [aBuckytube]
# it will be 14,0 tube
$tube setRingCircumference 14
# make it 21 rings long
$tube setRingLength 21
# set the FORTRAN variable name for the tube
$tube setVariableName "tube"
# tell c++ to create the tube
$tube build
# write the confirmation into a file
$tube writeXyz "tube.xyz"
# write the FORTRAN declarations and index assignments into a file
$tube write FORTRAN variables "tube.f"
See here for details on the FORTRAN output.
TCL_C++
C++ was chosen for molecular design for its object oriented properties and high performance. However, c++ is a compiled language so changes to the code take a bit of time. This is inconvenient when designing molecular systems; an interpreted language would be better. Tcl is meant to be used as an embedded interpreted command language in c and c++ programs. Tcl is a full-featured language with loops, procedures, variables, conditionals, expressions and other capabilities of procedural computer languages. C++ programs can add new tcl functions to any tcl interpreter linked in. Thus, tcl gives us an interpreted interface to the c++ class library so molecules can be designed at interactive rates. Note that both Cerius2 and Insight/Discover commercial computational chemistry packages use tcl for their command language.
The Visualization Toolkit project [Schroeder 96] discovered that a tcl interface to a large c++ class library can require substantial programmer effort to write the glue that allows tcl to control c++ classes. The vtk project avoided this by writing a partial c++ header file parser that reads the c++ header file for a class and automatically generates the tcl interface code. We wanted more control over which c++ member functions were tcl accessible, so the TCL_C++ system requires a file for each c++ class to define which member functions, variables, and constants are tcl accessible. This file is read by a tcl interpreter with tcl procedures defined to generate c++ code to allow another tcl interpreter to control the c++ class in question. Fortunately, although TCL_C++ itself was hard to program, it is easy and convenient for a programmer to use. For details of TCL_C++ see here.
5) Proposed Future Software Architecture
Future distributed NanoDesign software architecture. Note that each box may represent many instances distributed onto almost any machine.
The current NanoDesign molecular design software appears to the user as an interpreted language based on tcl. This is very effective for design of simple parts and systems. To design and computationally test complex replicators will require a more sophisticated system similar to the mechanical CAD systems available in the commercial marketplace. Furthermore, it would be of substantial practical advantage if the design team could be geographically dispersed. Therefore, we are investigating an software architecture based on a universal client (for example, a WWW browser), CORBA distributed objects, an object oriented database, and encapsulated computational chemistry legacy software. We are also interested in using command language fragments to control remote objects. Software that communicates this way is sometimes called agents


Universal Client
With the advent of modern WWW browsers implementing languages such as Java and JavaScript, it is possible to write applications using these browsers as the user interface. This saves development time since most user interface functionality comes free, integration with the WWW is trivial, and the better browsers run on a wide variety of platforms so portability is almost free. VRML can be used for 3D graphics and plug-ins such as the recently announced Biosym/MSI, Inc. molecule browser provide crucial functionality without much work.
Recently, Netscape, Inc. announced that the Netscape WWW browser would be made CORBA (see below) compliant offering a standard way to communicate between application code loaded by the browser and databases and computational chemistry software resident on servers and supercomputers. Previously, only the stateless http protocol was available to web browsers. Hopefully, other companies in the extremely competitive WWW browser market will follow suit.
These developments suggest that a single program can function as the user interface for a wide variety of applications, including computational nanotechnology. These applications load software (e.g. Java applets and JavaScript) into the browser when the user requests it. The applications then communicate with databases and remote objects (such as encapsulated legacy software) to meet user needs.

CORBA (Common Object Request Broker Architecture)
The universal browser is of little use in developing complex molecular machines if it cannot communicate with databases of components and systems and invoke high performance codes on fast machines to do the analysis. CORBA, a distributed object standard developed by the OMG (Object Management Group), provides a means for distributed objects -- for example the universal browser application, a database containing an evolving molecular machine design, and simulation codes -- to communicate and control each other. The simplest description of CORBA is that each object is represented by an interface described by the CORBA IDL (interface description language). Operations and data defined in the IDL may be accessed by other CORBA objects on the network. System software (called ORBs -- object request brokers) is responsible for communicating between objects whether they be on the same machine or widely distributed. See [Siegel 96] for a description of CORBA.
Object Oriented Database
To develop complex molecular machines, databases of components and processes as well as complex databases describing individual systems will be required. Object oriented databases appear to be better than relational databases for design systems for products such as aircraft and molecular machines.
Encapsulated Computational Chemistry Legacy Software
Like most research centers, NASA Ames has a number of very capable codes that do not fit the object model. However, it is often possible to create a c++ object that 'encapsulates' the legacy software. That is, the c++ object has methods that reformat their parameters, execute the legacy software, reformat the result and return it. When the legacy software does IO, the encapsulating object must intervene between the legacy software and the CORBA system. This technique allows existing codes to operate within an object oriented framework with minimal modification.
Agent Style Communication
In this context, agent software means software components that communicate by sending programs to each other. When each component is controlled by a command language, this is relatively easy to implement. Thus, a user interface component could control the tcl/c++ design software by writing a tcl command file and sending it to the design software for execution. This approach to software is powerful but not yet well understood.
6) Self replication and nanotechnology
A crucial objective of nanotechnology is the ability to make products inexpensively. While the ability to make a few very small, very precise molecular machines very expensively would clearly be a major scientific achievement, it would not fundamentally change how we make most products.
Fortunately, we are surrounded and inspired by products that are marvelously complex and yet very inexpensive. Potatoes, for example, are made by intricate molecular machines involving tens of thousands of genes, proteins, and other molecular components; yet the result costs so little that we think nothing of mashing this biological wonder and eating it.
It's easy to see why potatoes and other agricultural products are so cheap: put a potato in a little moist dirt, provide it with some air and sunlight, and we get more potatoes. In short, potatoes are self replicating.
Just as the early pioneers of flight took inspiration by watching birds soar effortlessly through the air, so we can take inspiration from nature as we develop molecular manufacturing systems. Of course, "inspired by" does not mean "copied from" Airplanes are very different from birds: a 747 bears only the smallest resemblance to a duck even though both fly. The artificial self replicating systems that have been envisioned for molecular manufacturing bear about the same degree of similarity to their biological counterparts as a car might bear to a horse.
Horses and cars both provide transportation. Horses, however, can get their energy from potatoes, corn, sugar, hay, straw, grass, and countless other types of "fuel." A car uses only a single artifical and carefully refined source of energy: gasoline. Putting sugar or straw into its gas tank is not recommended!
The machines that people make tend to be inflexible and brittle in response to changes in their environments. By contrast, living biological systems are wonderfully flexible and adaptable. Horses can pick their way along a narrow trail or jump over shrubs; they get "parts" (from their food) in the same flexible way they get energy; and they have a remarkable self repair ability.
Cars, on the other hand, need roads on which to travel; have to be provided with odd and very unnatural parts; are often difficult to repair (let alone self repairing!); and in general are simply unable to cope with a complex environment. They work because we want them to work, and because we can fairly inexpensively provide carefully controlled conditions under which they can perform as we desire.
In the same way, the artifical self replicating systems that are being proposed for molecular manufacturing are inflexible and brittle. It's difficult enough to design a system able to self replicate in a controlled environment, let alone designing one that can approach the marvelous adaptibility that hundreds of millions of years of evolution have given to living systems. Designing a system that uses a single source of energy is both much easier to do and produces a much more efficient system: the horse pays for its ability to eat potatoes when grass isn't available by being less efficient at both. For artificial systems where we wish to decrease design complexity and increase efficiency, we'll design the system so that it can handle one source of energy, and handle that one source very well. Horses can manufacture the many complex proteins and molecules they need from whatever food happens to be around. Again, they pay for this flexibility by having an intricate digestive system able to break down food into its constituent molecules, and a complex intermediary metabolism able to synthesize whatever they need from whatever they've got. Artificial self replicating systems will be both simpler and more efficient if most of this burden is off-loaded: we can give them the odd compounds and unnatural molecular structures that they require in an artifical "feedstock" rather than forcing the device to make everything itself -- a process that is both less efficient and more complex to design.
The mechanical designs proposed for nanotechnology are more reminiscent of a factory than of a living system. Molecular scale robotic arms able to move and position molecular parts would assemble rather rigid molecular products using methods more familiar to a machine shop than the complex brew of chemicals found in a cell. Although we are inspired by living systems, the actual designs are likely to owe more to design constraints and our human objectives than to living systems. Self replication is but one of many abilities that living systems exhibit. Copying that one ability in an artificial system will be challenge enough without attempting to emulate their many other remarkable abilities.
Self replication is an effective route to truly low cost manufacturing. Our intuitions about self replicating systems, learned from the biological systems that surround us, are likely to seriously mislead us about the properties and characteristics of artificial self replicating systems designed for manufacturing purposes. Artificial systems able to make a wide range of non-biological products (like diamond) under programmatic control are likely to be more brittle and less adaptable in their response to changes in their environment than biological systems. At the same time, they should be simpler and easier to design. The complexity of such systems need not be excessive by present engineering standards.
7) Applications
In the coming decades nanotechnology could make a supercomputer so small it could barely be seen in a light microscope. Fleets of medical nanorobots smaller than a cell could roam in our bodies eliminating bacteria, clearing out clogged arteries, and reversing the ravages of old age. Clean factories could eliminate pollution caused by manufacturing. Low cost solar cells and batteries could replace coal, oil and nuclear fuels with clean, cheap and abundant solar power. New inexpensive materials over fifty times stronger per kilogram than those used in today's rockets could open up space and make lunar vacations no more expensive than vacations to the South Pole. Material abundance for all the people of the earth could become a reality.
Not long ago, such a forecast would have been ridiculed. Today, the President of the United States has called for a $500 million National Nanotechnology Initiative and invites us to imagine "...materials with ten times the strength of steel and only a small fraction of the weight -- shrinking all information housed at the Library of Congress into a device the size of a sugar cube -- detecting cancerous tumors when they are only a few cells in size." Scientists around the world agree this is all possible (though with big disagreements about exactly how long it will take and exactly what it will look like).
At its heart, the coming revolution in manufacturing is a continuation of trends that date back decades and even centuries. Manufacturing has been getting more precise, more diverse and less expensive for over fifty years. Looking ahead, in a few decades we'll be able to manufacture products with the ultimate in precision: the finest features will be made from individual atoms and molecules -- the fundamental building blocks of matter from which all the objects in the world around us are made. The diversity of products will be staggering: we'll be able to make almost any arrangement of atoms consistent with physical law. And we'll be able to make things inexpensively -- a dollar a kilogram or less.
8) Conclusions
The NanoDesign software is intended to design and test fullerene based hypothetical molecular machines and components. The system is in an early stage of development. Presently, tcl provides an interpreted interface, c++ objects represent design components, and a parallelized FORTRAN program simulates the machine. In the future, an architecture based on distributed objects is envisioned. A key requirement for this vision is a standard set of interfaces to various computational chemistry capabilities (e.g., force fields, integrators, etc.). A standard set of interfaces would allow vendors to supply small, high quality components to a distributed system. AcknowledgmentsI would like to thank my colleagues at the Molecular Engineering Laboratory at the University of California at Santa Cruz, led by Dr. Todd Wipke, for many fruitful discussions and an environment tremendously conducive to molecular design