What software tools would be useful?
Russell Wallace
Following on from the brief subthread about software tools, I'll ask
this question, as a programmer with only an educated layman's
knowledge of subjects like chemistry and mechanical engineering: What
improvements in software tools would be most useful to the people
actually working on nanotechnology?
For example, I'm interested in AI; one of the things that might be
worth doing would be automatic or semi-automatic design of molecular
machines. But would the people doing the work prefer the effort to be
spent on better user interfaces for manual CAD tools? Or better
information retrieval systems? Or something I haven't thought of?
--
"Always look on the bright side of life."
To reply by email, remove the small snack from address.
John S. Novak, III
In article <clr7f...@enews3.newsguy.com>, Russell Wallace wrote:
>
> Following on from the brief subthread about software tools, I'll ask
> this question, as a programmer with only an educated layman's
> knowledge of subjects like chemistry and mechanical engineering: What
> improvements in software tools would be most useful to the people
> actually working on nanotechnology?
> For example, I'm interested in AI; one of the things that might be
> worth doing would be automatic or semi-automatic design of molecular
> machines. But would the people doing the work prefer the effort to be
> spent on better user interfaces for manual CAD tools? Or better
> information retrieval systems? Or something I haven't thought of?
already familiar with them, as I'm sure at least some readers aren't--
it helps to think of CAD software as large systems of software, rather
than as monolithic block packages.
I'm a microwave design engineer, so I have a lot of experience with
microwave design software; I have less experience with other software
regimes, but I'm not completely ignorant, either. So, I'll talk a
little about the systems I've used and been in contact with, and then
try to extrapolate to what nanotech design software might look like.
A caveat up front, though: The design systems I'm talking about are
relatively mature environments. Where they're not mature
environments, they're at least mature tasks-- people have been making
high frequency microwave electronics since World War II, and the
design tools have been evolving as long as we've had computers to help
us. It will take time to get nanotech design tools to the same level.
So. What do we want from design tools? After thinking about this for
a few days, I informally place tasks into four large, somewhat
overlapping, baskets:
1) Manual design
2) Automated design
3) Simulation
4) Abstraction and integration
In general, when one gets a design requirement for a system, one tends
to start at a relatively high level, and break the design up into
blocks. Expertise, either human or artificial, will make some
educated guesses at how well the blocks can and should be designed,
and those guesses are used as the highest level of the design.
(As a real world example, microwave filters are a pretty well known
field, although they are still researched. Given a set of
requirements, a human expert can give a good guess as to the general
design techniques required and the general size of the filter. An
artificial expert can do something similar, but they're still a bit
more limited.)
This is abstraction and integration-- we're abstracting the
requirement of the smaller blocks and then integrating them back
together and seeing if the system work. We'll probably go through
several levels of this, pushing farther and farther down into real
details.
At each stage, we want to use the automated design tools (of which
artificial experts are one form) to take careof the boring, the well
known, or the mind-numbingly tedious. When we can't do that, we want
to be able to manually design the elements we need, and combine those
with other parts of artificially designed work. And at all levels, we
want to simulate the results.
The farther down we dig, the closer we get to simulating actual
physics; the higher up we climb, the more we depend on the essential,
abstract results of lower level simulations, automations, and designs.
Ideally, we'd like to simulate every design at the basic physics
level, but that's just not going to happen.
So again, a mix of human and artificial expertise to go only as far
down that tree on only as many of the branches as is reequired.
Sometimes we can't go deep enough because even tiny little slices of
simulation at the basic physics level is too expensive; sometimes
we're forced to go too deep because haven't the expertise to be
confident about the abstractions we'd like to make.
In electromagnetics, for instance, it'd be a dream to be able to do a
basic physics, fully three dimensional simulation of a complete
design. We'd like this because EM and microwave designs, by their
nature, tend to intefere with one another in subtle ways.
But we simply don't have the computational power to do that
for even modest designs; only for relatively small slices of designs.
So we rely on expertise for two things: intelligent problem
partition, and simulation confidence-- can we simulate these three
blocks, each at computational cost N, and abstract them upwards and
simulate again at cost N? Or are we required to combine all the
blocks in the lower level simulation, at a cost of 10*N or even 100*N?
It's a real suck day in the design lab when we just don't know, and we
have to build the damn thing to find out. (Actually, we need to build
the damn thing anyway, because the simulators are never perfect
anyway, but this just makes the prototype phase more painful and drawn
out.)
So for electromagentic and microwave design, we'll start with block
diagram simulators, partition, abstract and integrate, move down to
microwave circuit simulators (specialized beasts that use meticulously
worked out closed form approximations to electromagnetic devices) and
then increasingly arcane levels of physics simulation until we get to
the full out computationally expensive three dimensional simulations.
I know that at least some other disciplines use similar approaches.
There's a nice little article in the IEEE Transactions on
Nanotechnology from earlier this year (vol 3, number 1) by S. C.
Henderson, et al, entitled, "Incorporating Standard CMOS Design
Process Methodologies into the QCA Logic Design Process."
(Here, CMOS is "compementary metal-oxide semiconductor," a standard
semiconductor design technology; QCA is "quantum-dot cellular automata,"
an elegant design technique that fits the definition of nanotechnology
only by the scale of its features.)
The paper outlines a similar hierarchy for CMOS design to the one I've
described above for electromagnetic design. It's just as
hierarchical, starting from the block diagram level, and going all the
way down to a SPICE circuit simlator, the level which a total
integrated simulation would be far too expensive. They also point to
a way to bootstrap QCA CAD sotware development by "piggybacking it"
onto CMOS packages: Since the goal of both design techniques is the
same-- logic design-- their upper hierarchies can be the same. Only
the lower levels, the ones that depend on device physics directly or
indirectly, need to be redesigned.
(Interestingly, the same issue has another article by K. Walus, et al,
entitled "QCADesigner: A Rapid and Simulation Tool for Quantum Dot
Cellular Automata." This paper looks at a potential lower level
simulator for QCA designs, although I doubt they intended it to be
inserted wholesale into the CMOS hierarchy. The tool they developed
has a homepage and a free downloadable versin, here: http://qcadesigner.ca/ )
So, with all of that having been said about conventional CAD tools,
what do I think nanotech design tools will look like? It's tempting
to say that nanotech design tools will just involve straightforward
models of quantum mechanics or chemistry or some such, without
realizing that you could make similarly absurd and impractical
statements about microwave design ("it's just a simulation of
Maxwell's Laws!") or logic design ("it's just a transistor
simulator!")
In reality, I think the broad outlines will be the same: Abstraction
and integration, where the devil is in the intelligent partitioning;
design automation for the mind-numbingly tedious or well-understood
details; manual design for the novel or finicky structures;
simulation, to make sure it works. Except, moreso than before.
Consider something staggeringly complex by modern standards but (one
would like to think) trivial by the standards of 2044: Something like
a Freitas Respirocyte: http://www.foresight.org/Nanomedicine/Respirocytes.html
(By the way, why hasn't anyone made a nice simple PDF out of that?)
Freitas gives conservative estimates that a full respirocyte system
(that is, one functioning respirocyte) is about 27 billion atoms, two
thirds of which are the "design" and one third of which are the gas
and other transient atoms that the device is designed to process. I'm
sorry, but *no one* is going to do a QM or chemical synthesis in
detail on 27 billion atoms. Not going to happen.
But the lower level components do need increasing levels of
simulation. The whole device runs on a glucose conversion engine,
which is going to require careful checmical, structural, and thermal
simulations. Sorting rotors, pressure transducers, and the like are
going to require mechanical and thermal simulation. Freitas' concept
includes a novel communication system depending on mechanical
compressive pulses, which will require a novel and very accurate
mechanical simulation married to a more typical communication and
logical simulator. A variety of sensors are included, opening up
many, many simulations, from very precise checmical sensors to the
pressure sensors mentioned just above, and others. Onboard computers
will need their simulations in design. Finally, the hull will need a
variety of structural and mechanical simulations.
Some of those are going to involve their own levels of abstraction and
integration. Worse, some are going to require co-simulation ,to make
sure that there aren't dependcies that simply aren't obvious at the
partition levels I've described.
I can't even begin to imagine the kind of software necessary for the
design of something like a vasculoid. My mind just starts to shut
down at the complexity required.
It's only a couple dozen paragraphs to describe, but the actual
development of software like that will be profoundly time-consuming
and profoundly expensive. Almost every sentence of the two paragraphs
of the Freitas Respirocyte example is a large software engineering
project in itself. Just like similar systems for existing CAD
packages have been in the past. Luckily, though, once the industry
moves from theory and basic science to applied science and engineering
design (whenever that finally starts to happen, whether it's 2010 or
2030) the wealth generated from those products will be enough to
warrant the investment.
--
John S. Novak, III j...@cegt201.bradley.edu
The Humblest Man on the Net
Russell Wallace
On 31 Oct 2004 05:14:04 GMT, j...@panix.com (John S. Novak, III) wrote:
>If you're talking about CAD tools-- and especially if you're not
>already familiar with them, as I'm sure at least some readers aren't--
Yep, both of these are the case :)
>1) Manual design
>2) Automated design
>3) Simulation
>4) Abstraction and integration
[rest of excellent explanation snipped]
Thanks! That makes sense.
So the next step then would be to find out what the current state of
the art is in tool support for each of these activities as applied to
nanotechnology, and where improvements are both easiest and
potentially most helpful. (I'm biased towards #2 due to my background
in AI, but I'm prepared to look at the possibility that e.g.
improvements in support for #1 might at this time be lower-hanging
fruit.)
John S. Novak, III
In article <cm5s4...@enews3.newsguy.com>, Russell Wallace wrote:
>>1) Manual design
>>2) Automated design
>>3) Simulation
>>4) Abstraction and integration
> [rest of excellent explanation snipped]
> Thanks! That makes sense.
education is that, no matter how simple and obvious something may
seem, it's likely to actually be very complex and largely hidden from
view. This applies not only to science and technology, but even to
things like artwork and finance.
But because the details are skillfully hidden from view, it all seems
so simple. Nanotech is not only not an exception, it's worse--
nothing seems complex to non-practitioners, because not many of the
details actually exist, yet.
But they will.
> So the next step then would be to find out what the current state of
> the art is in tool support for each of these activities as applied to
> nanotechnology, and where improvements are both easiest and
> potentially most helpful. (I'm biased towards #2 due to my background
> in AI, but I'm prepared to look at the possibility that e.g.
> improvements in support for #1 might at this time be lower-hanging
> fruit.)
"As applied to nanotechnology" is probably going to leave you with a
bunch of "not much." I'd start my survey journals like the IEEE
Transactions on Nanotech (because I subscribe to it) and similar
non-IEEE journals (to which I don't subscribe, and so I'd be
interested in what you come up with, as far as the best
journal-hunting locations.) I'd probably then start looking at the
biochemical engineering literature. I know there's a book out there
on genetic algorithms in molecular drug design, for instance (perhaps
my Christmas present to me) and the associated journals that
footnotes point to.
I also think that manual design is, in fact, a lower hanging fruit
right now. But a closely related part of automated design is the
spectacularly un-sexy but critically important area of "design rule
checking." (If I had one CAD-related wish for microwave design, a DRC
would be a strong contender.) It does no good to design structures if
they're inherently unstable. I have nowhere near enough chemistry
insight to tell you what DRCs would look like, though.