Design software is arguably the chief limiting factor in the rate of progress toward advanced nanotechnologies, and this makes it a topic of central importance. Questions of design and modeling also touch on diverse topics: technology objectives, scientific knowledge and unknowns, research directions that deserve many millions of dollars of funding, and specific problems that some of you may wish to address in your spare time. As time goes on, there will be more and more results to report.
I’ll be discussing design software problem in a series of posts that look at different levels.
Fundamental aspects:
- The case for software as the chief limiting factor on the rate of progress
- Similarities in design software for structures and mechanisms at all scales
- Differences in design software for atomically precise structures
- Why search algorithms are crucial for design in this domain
- Why modeling and simulation requirements are often misjudged
Specific technologies and needs:
- Descriptions of the state of the art in various areas of design and modeling
- Promising new algorithms for design and modeling
- Specific problems that need work, ranging from small coding projects through dissertation topics
Big initiatives that could make a big difference:
- Requirements for an open-source platform that could speed the integration of today’s fragmented tools for molecular modeling and design
- Requirements for an open-source data-sharing platform that could help integrate scientific knowledge into a form that accelerates progress in technology
There’s a lot of information out there, much that can be done if we develop a better understanding of what we have and what we need. I look forward to your contributions.
{ 1 trackback }
{ 5 comments… read them below or add one }
The Chad 02.23.09 at 8:56 pm UTC
because you would be working with vastly different scales in the same software (or designed item), the design software really needs to combine programming with CAD. It’s one thing to design a small molecule to be built, but quiet another to build a computer or algae or CNT’s.
The design software needs to create a kind of DNA for whatever is being built, with repeating processes being told when to stop, then new processes modifying that finished component.
Eric Drexler 02.23.09 at 11:12 pm UTC
Yes, design and fabrication are closely linked, since fabrication constraints are basic to design, and the best way to specify automated fabrication procedures is as part of the design workflow. CAD tends to evolve into CADAM, computer aided design and manufacturing.
Repetition can be distributed over both space and time. In systems-level design concepts for high-throughput molecular manufacturing schemes (the kind that would be at the far end of a long chain of intermediate technologies), the typical approach to making large numbers of identical components uses large arrays of processing lines, each containing a series of specialized machines. E-drexler.com offers a video and discussions of architectures and scaling relationships for this sort of manufacturing process. This sort of system would be very efficient and very nonbiological.
Guy Giesbrecht 02.24.09 at 3:08 am UTC
One of the big problems I witnessed when I was following Tom Moore in his experiments with NanoEngineer1 was the egregious dependencies on various third party software engines. If the whole thing had been designed in java or any other single language/platform it would’ve been a simple matter to compile new open source versions. But the cumbersome dependencies and licensing/versioning issues made it all but impossible for someone to write new plugins or applications. A simple method like that used by graphics and audio editing software to install plugins through a plugin directory and minimal interface extension is a must. Hierarchical modular design methods should also be followed closely. After all, that’s also going to be needed in the actual nanomachine design so it should be a protocol in the software design too.
Abstract issues like spatial placement, scaling and recursion are already handled in many other modeling systems and methods for dealing with these issues are actually fairly standardized algorithms. As for scheduling issues, I’d like to point out the very fine work being done at BioSpice: http://biospice.sourceforge.net/ which draws its inspiration from the SPICE integrated circuit design simulator.
Will Ware 02.25.09 at 7:44 pm UTC
It’s common to mentally equate “CAD software” with a Solidworks-style graphical user interface. That model might hit a wall regarding the complexity of designable structures. The field of software engineering has spent decades dealing with the problem of unbounded complexity. Nobody can yet afford to build physical objects of unbounded complexity, but bits are cheap enough to do this, and have been for a while.
Software engineering tools will continue to evolve but they already handle systems too complex to be fully grokked by any single engineer. Programming languages use various paradigms to support multiple layers of abstraction. Bug databases and testing protocols help with reliability. Version control systems help to isolate and diagnose problems and maintain a detailed workflow history for a large team.
CAD software shouldn’t (imho) be envisioned in terms of a single GUI. People will add features for group collaboration, or grayed-out solids to hide the details in subcomponents, but eventually we’ll need CAD software that looks more like a full programming environment. Individual GUI tools could be used within that environment but they wouldn’t constrain it to a single workflow paradigm.
Eric Drexler 02.27.09 at 12:01 am UTC
@ Guy Giesbrecht — As I said in a private email, thanks for the comment and information. I look forward to following up on this.
@ Will Ware — Yes, I strongly endorse the vision of an open-source system that serves as a platform for extension and collaboration. Among other things, this means providing useful tools for visualization and manipulation, easy-to-use interfaces for plugins, etc., while imposing a minimum of constraints.