Main Page | Report this Page
 
   
Science Forum Index  »  Nanotechnology Forum  »  Military and nanotech
Page 2 of 3    Goto page Previous  1, 2, 3  Next
Author Message
Joann Evans
Posted: Mon Sep 29, 2003 8:19 am
Guest
erincss wrote:
Quote:

Joann Evans

And what's to keep others (openly or not) from doing the same
research?

Nothing apart from resources, talent, and tools.

There may be classified military-industrial think tanks that have general
purpose assemblers in their hands, or at least diamondoid composite-making
assemblers, and its kept under wraps for obvious reasons.

It doesn't really change my question, though. The most important
tools of nanotech research (AFMs and the like) are not in the massively
difficult category of, say, uranium isotope seperation. Computer
processing power will continue to improve and be accessable to all (and
indeed, will likely be the first real nanocech market), the resources
are hardly on a par with, say, the Apollo program, espically if you're
willing to accept a slower pace than a 'crash' program.

The human talent will hardly be lacking, either. There are frequent
'how can I best study/train/take relevant courses about nanotechnology?'
questions here, already. The more it becomes part of the public
consciousness, the more will see it as a useful research/applications
career.

No government program could somehow buy up all the requirements of a
signifigant nanotech program (and what influence it could have would
only be in its own country) and keep it to itself, espically if it hopes
to remain an unseen 'black' program.

The real concern here is that if any such program came to pass, and
actually developed general purpose assemblers and the software to use
them in a wide variety of ways (which could be the hardest part), there
would be the great temptation to *use* that ability, as any number of
other open and covert programs would be out there, and close on their
developmental heels, wether they (or their competitors) knew it or not.
If things can really move as fast as others in this thread have
suggested, there's little use in developing the ability, then sitting on
it 'until you need it,' as you could unknowingly be vastly surpassed, in
fairly short order.
Guest
Posted: Mon Sep 29, 2003 8:22 am
On Sun, 28 Sep 2003, Robert I. Eachus wrote:

Quote:
Oh, my definiition of a nanofab is a co-operating assembly of tools
which can replicate itself and make other nanotech products.

Ok. Clear enough.

Quote:
I have. One simple example is the protein folding work currently
being done. How many molecules could you check a year, say twenty
years ago, for fitting a certain receptor site? How many per minute
today?

It is, as I said, not hard to find examples of research that can be made
1000 times (your original claim) times faster now than a short time ago.
This is trivialoly true for any research which consists *purely* of
doing a certain amount of maths, like your example above.

It does not follow that all research, or even research in general speeds
up by the same factor. If it *did* then we should observe that current
research progresses about a factor of 1000 quicker than it did in 1988,
and that half of all research was done in the last two years. None of
which appear reasonable claims.

Quote:
Let's say that with today's software and hardware it is possible to
design an assembler in 20 years. In 18 months, it will only take ten
years, three years from now? Five years, for a total of eight. Wait
another eighteen months, and you have 4 1/2 years of waiting and 2 1/2
years of work for a total of 7. But that assumes that only the
computer hardware improves. Let's also improve the quality and
performance of the software.

Here you demonstrate how absurd your own claim is. If today we could
start a 20-year project to create a assembler, and the speed is
linearlily limited by the available computing-power (that is double
computing-power = double speed) like you assume above, then we get the
following progressively ridicolous conclusions:

* If we do nothing for 3 years, then start a project, the project will
take 5 years. (like you state above)

But also;

* If we simply do nothing for the next dozen years, then the entire
project can be completed in a month, even a short one like february
would suffice.

Thus I must ask: Do you *REALLY* believe this ? That computing-power is
the only thin limiting the speed of research and that increasing it
would lead to a linear increase in research-speed ?

Quote:
Part of the number theory has been accomplished by "pure" research
that could be done walking through the woods, or sitting on a log.
But another part of the work has involved lots of number crunching.

Now we're getting somewhere. This I agree with: *PARTS* of research are
sped up enormously by the availability of fast computers, other parts
are not much affected at all ("could be done walking through the
woods"). So, for example, a project that today requires 50/50 of
computer-time and "in woods" time, would, if we had infinitely fast
computers be twice as quick as it is today. (I am here assuming that
fast computers alone don't imply strong A.I., if it does, and the
computer can also take the virtual "walk in the woods" the equation
obviously changes)


Sincerely,
Eivind Kjrstad
Robert I. Eachus
Posted: Tue Sep 30, 2003 8:37 pm
Guest
ekj@ekj.vestdata.no wrote:

Quote:
Now we're getting somewhere. This I agree with: *PARTS* of research are
sped up enormously by the availability of fast computers, other parts
are not much affected at all ("could be done walking through the
woods"). So, for example, a project that today requires 50/50 of
computer-time and "in woods" time, would, if we had infinitely fast
computers be twice as quick as it is today. (I am here assuming that
fast computers alone don't imply strong A.I., if it does, and the
computer can also take the virtual "walk in the woods" the equation
obviously changes)

Am I a person, a computer, or both? I am not being facetious. I have
done a lot of research where the Aha! time was very small compared to
the effort that goes into envisioning the problem and visualizing what
goes on. I would probably buy into a model where a factor of 100
improvement in computing resources (and maybe a factor of 5 in
visualization/display resolution) allows for cutting the "thinking" time
in half. What matters is not the ratios or HOW computer resources are
used to improve the speed and quality of the thinking. Just that it
does. Once you acknowledge that it does, the rest follows.

Does it? As I said, I have seen it myself in my own research. Work
that was laborious and painful years ago is now almost trivial. On the
Apollo Guidance Computer project I worked with integrated circuts that
had (was it 8 diodes and 3 transistors?) to implement a NAND gate.
Today cutting edge logic chips (CPUs) have about 100 million
transistors. And a design team about the same size.

I will grant you that part of the problem of designing a general purpose
assembler is "think time". Some of that thinking has been done. A lot
more remains. But the scaling that has to be applied to those solutions
is the chief consumer of computing power. Some of it can be traded off
for elegant design--read think time. Much of it cannot.

Let me take the real problem we want to solve and propose a strawman
solution:

1. This is how we will pick up atoms from the feedstock.
2. This is how we will sort atoms in the feedstock by atomic number (and
possibly isotope).
3. This is how the atoms will be transported from the feedstock to the
workface.
4. This is how the atoms will be attached to the workface.
5. This is the atmosphere and temperature in the work area.
6. This is how programming is fed to the assembler.

Now I take some engineering experience and say I need to move X number
of atoms per second from the feedstock to the workface, and remove a
total of Y watts of heat from the workface, and Z watts from the
assembler itself. I'll assume for now that 6 includes checking the
programming to insure that I am not making gray goo or the like, and all
done.

Worst case there are maybe a dozen Aha! type insights that have to occur
to convert that strawman into a complete blueprint for an assembler. To
be honest, there are actually two sets of these problems. One for the
aparatus used to create the first assembler, and one for the first
assembler itself. But my real point is that the number of inventions
required by a "proof of principle" implementation is quite small. The
amount of engineering work to convert that framework into a useful
assembler is horrendous. Given the right engineering tools, going from
an atom at a time proof of principle device to one that is
simultaneously moving millions of atoms is where most of the computation
comes in.

And just like with the computer resources, at some point you stop trying
to improve the design and build it. In fact, let me go a lot further,
and ask the question: How many atoms per second must an assembler place
to be worth building now?

There is a different breakdown of the problem where atoms are assembled
into subassemblies, and those subassemblies are put together to create
the final product. In fact, the feedstock may include small assemblies.
Above I ignored that issue. In this question, it gets factored out.
However you build things, the figure of merit for an assembler or a
nanofab is the number of atoms per second it can assemble. If you think
it is a better unit of measure, answer in moles per second. ;-)

We may not yet be at the point of having all the answers, but we are
almost to the point of having asked all the right questions.

--
Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle." -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig
Chris Phoenix
Posted: Sat Oct 04, 2003 5:36 pm
Guest
"Robert I. Eachus" wrote:
Quote:
But if you want to argue that my "weekend" is overstatement, but a month
is more than enough, fine. But I do think that several days is
sufficient. Yes, if lab2 develops a technology with a faster initial
doubling time, they may catch up. But as I said, once you get a working
assembler or nanofab you almost instantly get a whole lot smarter. The
amount of computing resources you will be able to throw at improving
your designs will result in significant improvements in hours, even if
the initial doubling time is a day or more.

That assumes you have software waiting and ready to run on your improved
computer resources. No, more than that--it assumes that lab2 doesn't
have *better* software waiting to run on its systems--or the systems it
buys or steals from lab1. Given how slow we've been to innovate in
software, I haven't been assuming an immediate software-based speedup.
But maybe I'm missing something; I'm very open to argument on this
point.

I have been thinking mainly in terms of what a basic MNT capability
could do in terms of developing products. For that, it could take a
month to reach superpower status--if good CAD software and good
nanofactory blueprints were ready and waiting.

My argument has been: What could you run on much-faster computers that
would give you a huge advantage in MNT infrastructure? Keeping in mind
that on several counts, the products of basic Merkle-style diamondoid
fabricators (limited MNT, LMNT) are already within an order of magnitude
of peak theoretical performance.

But now you've got me thinking. On several other counts, like
fabrication speed and energy cost, LMNT is far from the limits. If you
had software that could design a new fabricator that was 100 times as
efficient and 10 times as fast... then nanofactory bootstrapping time
could go from a month to half a week.

And it's also possible that increased complexity would make a big
difference. I've been contemplating human-scale products that could be
specified with a TB or so of information. Obviously, these would be
extremely redundant, and capable of being designed by a human driving a
CAD system and using preexisting libraries. A general automatic design
capability could cut it down to a weekend. But is such a thing possible
without general AI, which I think would take a long time to develop no
matter how much crunch power you had?

Quote:
Oh, my definiition of a nanofab is a co-operating assembly of tools
which can replicate itself and make other nanotech products. I tend to
think that the first "assemblers" will be in this form. Hundreds or
thousands of co-operating tools. They may be used to build Drexlerian
assemblers, or more elegant nanofab arrays.

I vote for the more elegant nanofab arrays. Nanofactories, more or less
as described in Nanosystems, are clearly the way to go. Far more
efficient to control.

Quote:
So that is the situation right now. The starting gun has sounded, and
the best use of resources right now is perfecting molecular modelling
software for massively parallel supercomputers.

Hm. You're assuming here that the main problems will be chemical. I'm
not so sure. Once you have a few (dozen, hundred) diamondoid reactions,
that's all you need to make any shape you want. Beyond that, it's all
CAD of one flavor or another.

Of course, CAD isn't especially hard either; in fact, it should be
pretty straightforward. (But not just by reusing today's software.)

The only big problem I can see is in developing the lab techniques to do
the bootstrapping. If that turns out to be simple... then we'll get MNT
quite soon after that's realized.

(The second best use of
Quote:
resources is work on subassemblies. Much easier to build a large system
out of hundreds of thousands of subassemblies than billions of atoms.)

Billions, you say? That's a very small system in human terms. How do
you build a system out of quadrillions of systems? With
super-assemblies... with CAD.

Quote:
The best use of our time here? Probably thinking about the ethical and
social implications. When the full nanotech revolution does arrive,
there won't be any time left to think about which way we should be
heading.

YES! YES! Absolutely true, and absolutely important.

Quote:
And having been through a couple of similar revolutions, trying
to predict too far beyond the revolution is worthless. Indeed, I would
say that the definition of a social/moral/scientific/commercial
revolution is that you can't predict anything too far ahead. It is not
the effect of the revolution on the answers that is so devastating to
predictions, it is the effect on the questions. If you don't know what
questions to ask, how can you guess the answers?

Hm. The revolutions you mention do not encompass every facet of human
life. MNT might. So if you're right (and I think you are), then what's
the best we can do? Try to create the best foundation for
whatever-comes-after? Try not to be killed in the earliest stages? (If
MNT in a week makes you the only world power, then no one can afford to
let anyone else develop it--and there are enough nukes to enforce that.)

Chris

--
Chris Phoenix cphoenix@best.com http://xenophilia.org
Center for Responsible Nanotechnology (co-founder) http://CRNano.org
Chris Phoenix
Posted: Sun Oct 05, 2003 11:48 am
Guest
As they say on Slashdot, "Mod parent up!" IMO, Robert has given an
excellent analysis of what it'll take to build an assembler.

I want to support his point from a slightly different angle. I'm in the
middle of an interesting book called "Discovering", in which which one
character in a conversation raises the point that basic scientific
revolutions are not accelerating, and lists (in his opinion) the few
candidates for scientific revolutions in this century. Another says,
"What about computers?" And the first replies, "That's just
technology."

The point here is that developing assemblers is, at this point, almost
entirely a problem of "just technology". And even if science isn't
accelerating exponentially, many relevant aspects of technology
certainly are--and are accelerating rapidly enough that we have to take
them into account in speculating about MNT timelines.

Earlier in the conversation, Robert had said that the time to develop an
assembler might be cut in half every eighteen months, starting with 20
years today. Eivind challenged that, pointing out that it implied that
in twelve years, the project might take one short month.

Well, it wouldn't surprise me if something like this were the case! I'd
expect a slightly longer doubling time, but when you consider how far
we've come in the last dozen years, and how many enabling technologies
we're on track to develop in the next dozen, and how many paradigms will
have shifted by then (making it much easier to think properly about the
problems), the only thing that could keep it from being done in a few
months with the near-magical technology we'll have then is if there's
something fundamentally hard about it that we've all been missing for
the last decade.

Yes, I said near-magical technology. Twelve years ago, Google,
multi-tip dip-pen nanolithography, and covalent silicon mechanochemistry
would have seemed close to magical. A dozen years from now we'll have
two-way voice systems that can tell you the answers to most questions
(including lit-search questions, logistical questions, and some
synthesis questions) as fast as you can speak them. Not to mention,
assuming Scott Mize of AngstroVision is telling the truth, non-proximal
deep-sub-wavelength 3D optical sensing--probably with sub-nanometer
voxels by then.

Chris

"Robert I. Eachus" wrote:
Quote:

ekj@ekj.vestdata.no wrote:

Now we're getting somewhere. This I agree with: *PARTS* of research are
sped up enormously by the availability of fast computers, other parts
are not much affected at all ("could be done walking through the
woods"). So, for example, a project that today requires 50/50 of
computer-time and "in woods" time, would, if we had infinitely fast
computers be twice as quick as it is today. (I am here assuming that
fast computers alone don't imply strong A.I., if it does, and the
computer can also take the virtual "walk in the woods" the equation
obviously changes)

Am I a person, a computer, or both? I am not being facetious. I have
done a lot of research where the Aha! time was very small compared to
the effort that goes into envisioning the problem and visualizing what
goes on. I would probably buy into a model where a factor of 100
improvement in computing resources (and maybe a factor of 5 in
visualization/display resolution) allows for cutting the "thinking" time
in half. What matters is not the ratios or HOW computer resources are
used to improve the speed and quality of the thinking. Just that it
does. Once you acknowledge that it does, the rest follows.

Does it? As I said, I have seen it myself in my own research. Work
that was laborious and painful years ago is now almost trivial. On the
Apollo Guidance Computer project I worked with integrated circuts that
had (was it 8 diodes and 3 transistors?) to implement a NAND gate.
Today cutting edge logic chips (CPUs) have about 100 million
transistors. And a design team about the same size.

I will grant you that part of the problem of designing a general purpose
assembler is "think time". Some of that thinking has been done. A lot
more remains. But the scaling that has to be applied to those solutions
is the chief consumer of computing power. Some of it can be traded off
for elegant design--read think time. Much of it cannot.

Let me take the real problem we want to solve and propose a strawman
solution:

1. This is how we will pick up atoms from the feedstock.
2. This is how we will sort atoms in the feedstock by atomic number (and
possibly isotope).
3. This is how the atoms will be transported from the feedstock to the
workface.
4. This is how the atoms will be attached to the workface.
5. This is the atmosphere and temperature in the work area.
6. This is how programming is fed to the assembler.

Now I take some engineering experience and say I need to move X number
of atoms per second from the feedstock to the workface, and remove a
total of Y watts of heat from the workface, and Z watts from the
assembler itself. I'll assume for now that 6 includes checking the
programming to insure that I am not making gray goo or the like, and all
done.

Worst case there are maybe a dozen Aha! type insights that have to occur
to convert that strawman into a complete blueprint for an assembler. To
be honest, there are actually two sets of these problems. One for the
aparatus used to create the first assembler, and one for the first
assembler itself. But my real point is that the number of inventions
required by a "proof of principle" implementation is quite small. The
amount of engineering work to convert that framework into a useful
assembler is horrendous. Given the right engineering tools, going from
an atom at a time proof of principle device to one that is
simultaneously moving millions of atoms is where most of the computation
comes in.

And just like with the computer resources, at some point you stop trying
to improve the design and build it. In fact, let me go a lot further,
and ask the question: How many atoms per second must an assembler place
to be worth building now?

There is a different breakdown of the problem where atoms are assembled
into subassemblies, and those subassemblies are put together to create
the final product. In fact, the feedstock may include small assemblies.
Above I ignored that issue. In this question, it gets factored out.
However you build things, the figure of merit for an assembler or a
nanofab is the number of atoms per second it can assemble. If you think
it is a better unit of measure, answer in moles per second. ;-)

We may not yet be at the point of having all the answers, but we are
almost to the point of having asked all the right questions.

--
Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle." -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

--
Chris Phoenix cphoenix@best.com http://xenophilia.org
Center for Responsible Nanotechnology (co-founder) http://CRNano.org
Robert I. Eachus
Posted: Sun Oct 05, 2003 11:52 am
Guest
Chris Phoenix wrote:

Quote:
That assumes you have software waiting and ready to run on your improved
computer resources. No, more than that--it assumes that lab2 doesn't
have *better* software waiting to run on its systems--or the systems it
buys or steals from lab1. Given how slow we've been to innovate in
software, I haven't been assuming an immediate software-based speedup.
But maybe I'm missing something; I'm very open to argument on this
point.

I have a mental model that goes like this. There are several key
technologies that are needed to get to the goal of Drexlerian nanotech,
or assemblers or efficient nanofabs, or whatever. Different approaches
have different key technologies so any list I could make would be either
too broad, or too narrow. But as some point someone is going to look
around, say I have piece C, such and such a group has piece B, and third
group has the best version of piece A. Let's schedule a meeting and
look into co-operation.

At that point things are going to shift into high gear. Oh, and one of
the key pieces, no matter how you plan to get to point N, is the ability
to "automatically" design subassemblies, and test them in simulation.
By automatically design, I mean specify say an arm that can move this
far in these dimensions, and have the software come up with an assembly
that meets the design criteria. Better is to allow the software to make
tradeoffs in the interface. In other words, I want to put this arm
here, but not change the structural properties of the surface it
attaches to. The arm design can "reach back" into its structural
support and replace atoms with other atoms, as long as it maintains the
structural properties of the support surface.

Can this be done? Sure. But when and how and by whom? That is the
tough question. Right now two of the most computationally intense parts
of making new microprocessors are called AAPS (alternating aperature
phase shift), and OPC (optical proximity correction). The dimensions of
the elements in the critical layers of a modern CPU are smaller than the
wavelength of the light used to create the images on the lithographic
resist. Right now Intel is working on Prescott, a 90 nm part with
stressed silicon, and AMD is working on reducing its Hammer series to 90
nm SOI. Both are using 193 nm Argon fluoride excimer lasers as light
sources. So how do you beat Rayleigh's criteria by that much?

AAPS works by having parts of the mask shift the light 90 degrees one
way, and the light on the other side of a line by 90 degrees in the
other direction. Where you want the line to show up the interference
from the light on either side puts an interference fringe exactly where
you want the (dark) line. Optical proximity correction involves drawing
not the shapes you want, but transformed shapes like serifs on type
faces that the blurring caused by working on the edge of the finest
possible resolution causes.

End of microlithography lesson. Wink But the trick of course, is doing
both AAPS and OPC at the same time, with a mask set that has billions of
elements. (Prescott has over 100 million transistors, and each
transistor has over a dozen design elements, plus all the
interconnections.) The answer of course, is you use supercomputers,
stacks of them, to get the final mask sets. How is designing an
assembler, or any complex nanotech device going to be different. You
have to do the "drudge work" of understanding every component of every
part, and creating a model that has the "near field" interactions with
other parts. Then you set boundary conditions, optimize, adjust where
there are problems, optimize again and so on. It is not enough to model
every part in a vacuum, they will be part of a complex system, and you
are going to have to model the system as a whole.

So back to the original question, anyone who does that drudgery and
builds those models has part of what is needed. But the other part is
farms of supercomputers that can be used to compute and validate
designs. (Supercomputers that are appropriate for this task tend to
come in clusters of processors. When these are used for batch
processing like this they are called renderfarms, or compute farms,
since your desktop workstation/supercomputer "farms" the work out.)

Quote:
I have been thinking mainly in terms of what a basic MNT capability
could do in terms of developing products. For that, it could take a
month to reach superpower status--if good CAD software and good
nanofactory blueprints were ready and waiting.

As I said, I think that having the ability to do just that is going to
be vital to getting to full nanotech in the first place. Maybe you
could get there using an army of designers with regular workstations,
but I think that approach will take much longer.

Quote:
My argument has been: What could you run on much-faster computers that
would give you a huge advantage in MNT infrastructure? Keeping in mind
that on several counts, the products of basic Merkle-style diamondoid
fabricators (limited MNT, LMNT) are already within an order of magnitude
of peak theoretical performance.

Not the problem! Right now a lot of good people are doing good work on
design elements and components. Where you need the heavy lifting is
when you start putting the pieces together. If this arm will stick to
that beam when they get too close together, and they do in operation,
the design of one or the other has to be changed. Vacuum welding or
adsorbed gases are going to be problems that have to be addressed before
you build any real device.

Quote:
But now you've got me thinking. On several other counts, like
fabrication speed and energy cost, LMNT is far from the limits. If you
had software that could design a new fabricator that was 100 times as
efficient and 10 times as fast... then nanofactory bootstrapping time
could go from a month to half a week.

And it's also possible that increased complexity would make a big
difference. I've been contemplating human-scale products that could be
specified with a TB or so of information. Obviously, these would be
extremely redundant, and capable of being designed by a human driving a
CAD system and using preexisting libraries. A general automatic design
capability could cut it down to a weekend. But is such a thing possible
without general AI, which I think would take a long time to develop no
matter how much crunch power you had?

As I said, it is not AI you need, it is just an awful lot of drudge work
developing the component models. If you want to think in terms of say,
Tinker Toys, if you built a library of components, someone could design
a device out of those components. The second generation is to merge
some of these pieces into subassemblies and "round the edges" to make a
better stronger, more compact or whatever component that can then be
added to your component library.

Right now microprocessors are designed the same way. There is a
hierarchy: The microprocessor, functional units, register level, gate
level, logic level, component level. During development, designers work
at all levels and the computers keep it all consistant. If there is a
problem, buck it back to a design engineer working at the right level of
abstraction. So the computers don't do the creative work, they "keep
score" and insure that all of the various requirements at each design
level are met.

Quote:
I vote for the more elegant nanofab arrays. Nanofactories, more or less
as described in Nanosystems, are clearly the way to go. Far more
efficient to control.

I think that is the way to go at first. Later I think that working in a
fluid medium and relying on brownian motion to get feedstock from here
to there, with possibly some centrifuging etc., will be faster and more
efficient at mananging heat.

Quote:
Hm. You're assuming here that the main problems will be chemical. I'm
not so sure. Once you have a few (dozen, hundred) diamondoid reactions,
that's all you need to make any shape you want. Beyond that, it's all
CAD of one flavor or another.

Of course, CAD isn't especially hard either; in fact, it should be
pretty straightforward. (But not just by reusing today's software.)

Another hobby horse. Most people don't know it but the electronics
industry really runs off a language called VHDL. It was originally
designed as a variant of Ada for designing and testing highly complex
(50k devices back then) integrated circuts. But the huge advantage was
the ability to set up a hierarchy of design levels and to work at any
particular level. (And of course, if a company announces a new IC, the
first thing they ship is the VHDL model, possibly at several design levels.)

Is VHDL the perfect language for developing nanotech? No. It is hard
to explain why if you haven't worked with VHDL designs.

The problem is that VHDL is sort of 2 1/2 dimensional. Two dimensions
are used for layout, and the third dimension is used for both layering,
and abstraction levels. You could say that this fits well with the way
components, and printed circut boards are designed, or you could say
that the language affects the way electronic systems are designed and
built. For nanotech, I think we really need a 3 1/2 dimensional
language. In other words a design language that lets you think in terms
of three dimensional components, then flip through stacks of abstraction
levels. The picture of your design as electric fields, atoms,
components, subassemblies, subsystems, etc., needs to be different views
of the same (software and eventually hardware) object.

Quote:
The only big problem I can see is in developing the lab techniques to do
the bootstrapping. If that turns out to be simple... then we'll get MNT
quite soon after that's realized.

(The second best use of
resources is work on subassemblies. Much easier to build a large system
out of hundreds of thousands of subassemblies than billions of atoms.)

Billions, you say? That's a very small system in human terms. How do
you build a system out of quadrillions of systems? With
super-assemblies... with CAD.

We don't disagree. My point was that for even the smallest possible
assembler, we are better off using heirarchical design systems. For
anything you can actually see, the design may require half a dozen
levels of design abstraction.

Quote:
The best use of our time here? Probably thinking about the ethical and
social implications. When the full nanotech revolution does arrive,
there won't be any time left to think about which way we should be
heading.

YES! YES! Absolutely true, and absolutely important.

We are well behind the curve here, and it is going to take some awfully
smart people working full time on ethical and social problems to avoid
complete chaos. Just thinking of things that may happen is going to be
tough enough, let alone figure out whether they will be good or bad.
Remember the communicators on the original StarTrek? How big is your
cellphone? Does it include a camera that sends stills and video?
Captain Kirk's communicator was probably bigger than your cellphone, and
didn't include a camera, or text messaging, or games or...

Does a built-in cell phone count as telepathy? How good does the
encryption protocol and other safeguards need to be. Should there be
laws against accepting video calls on your built-in cellphone while
driving? Or will the cars all drive themselves and talk to each other
using your choice of ultrasonics, infrared, radio, or lasers.

Quote:
Hm. The revolutions you mention do not encompass every facet of human
life. MNT might. So if you're right (and I think you are), then what's
the best we can do? Try to create the best foundation for
whatever-comes-after? Try not to be killed in the earliest stages? (If
MNT in a week makes you the only world power, then no one can afford to
let anyone else develop it--and there are enough nukes to enforce that.)

Nuclear weapons have been obsolete since the first Gulf War. That is
not to say that North Korea developing nuclear weapons is not a problem.
Any weapon in the hands of the insane is dangerous. But the issue is
that someone developing MNT doesn't need a huge facility. Brains are
the major requirement, and supercomputers, which are now commodity items
are the second. (Even Dell is selling supercomputer clusters now. And
seriously large supercomputers with over 100 processors fit in a couple
of standard 19" racks.)

If the development of MNT is forced underground the results IMHO would
be catastrophic. The only people working on it would be people we
wouldn't want to have it. If it stays aboveground, and the groups
working on it agree on some ethical principles, then they will
cooperate, giving them the edge over the underground efforts. (But
espionage could be a wild card.)

--
Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle." -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig
Chris Phoenix
Posted: Mon Oct 06, 2003 9:00 pm
Guest
"Robert I. Eachus" wrote:
Quote:
Chris Phoenix wrote:
.... Given how slow we've been to innovate in
software, I haven't been assuming an immediate software-based speedup.
But maybe I'm missing something; I'm very open to argument on this
point.

I have a mental model that goes like this. There are several key
technologies that are needed to get to the goal of Drexlerian nanotech,

I think this is a topic change. I'm not complaining--they're both
worthwhile topics. But we were talking about post-MNT speedups, and now
we're talking about how MNT can be approached. Or am I making an
artificial distinction, and you're still talking about post-MNT speedup?

Quote:
But as some point someone is going to look
around, say I have piece C, such and such a group has piece B, and third
group has the best version of piece A. Let's schedule a meeting and
look into co-operation.

My mental model is a bit different, as it focuses on the point where
someone decides to look around. At some point, someone is going to
realize that MNT is going to be very important. They will start asking
questions about what it would take to build it. As soon as you fund a
half-dozen engineers and scientists to, as you say, look around, I'm
worried that they will find all the pieces ready for them.

So the looking-around process isn't continuous. It starts as a result
of a policy decision. And I think that, even with today's status of
enabling technologies, most of the pieces will be found as soon as
someone seriously looks. At that point, there'll be a sudden concerted
(and probably secret) effort to develop the rest of the pieces.

Quote:
At that point things are going to shift into high gear.

So is this the point where a very short time period is enough to put the
winner far ahead of the loser? I don't think the situation is *that*
bad yet; there'll be a lot of lab work and a lot of engineering still to
do. But I'm probably misunderstanding you.

Quote:
Oh, and one of
the key pieces, no matter how you plan to get to point N, is the ability
to "automatically" design subassemblies, and test them in simulation.
By automatically design, I mean specify say an arm that can move this
far in these dimensions, and have the software come up with an assembly
that meets the design criteria.

I'm not sure this is either necessary or possible. At the nanometer
scale, you can't design the mechanics without looking at the chemistry.

And you can't automate the chemistry design in any interesting and
predictable ways. There's a long conversation we could have here, and
probably should at some point. But basically, the available chemistry
will probably be pretty limited at first, which limits the design
choices to the point where a human can make them. And the mechanics for
a basic Merkle-style fabricator will be pretty simple as well. It may
be that genetic algorithms can come up with designs fitting lots of
constraints; I said "and predictable" so that I wouldn't exclude GA's.
But I think you need a design metalanguage both for GA's and for
rule-based systems, and I think building a design metalanguage would be
more of a pain than doing simple designs by hand.

Why am I focusing on a basic Merkle-style fabricator? Because it's
really all we need. We can build a tabletop factory out of that, a few
other nanoscale components, and a lot of bulk-diamond mechanical
engineering.

Quote:
Better is to allow the software to make
tradeoffs in the interface. In other words, I want to put this arm
here, but not change the structural properties of the surface it
attaches to. The arm design can "reach back" into its structural
support and replace atoms with other atoms, as long as it maintains the
structural properties of the support surface.

This is what I mean about automated chemistry design not being easy.
You can only replace atoms if you can do the mechanochemistry to build
the result. That multiplies the number of reactions you need by quite a
high factor. If early mechanochemistry were flexible, you'd be right,
but I think it won't be.

Quote:
.... You
have to do the "drudge work" of understanding every component of every
part, and creating a model that has the "near field" interactions with
other parts. Then you set boundary conditions, optimize, adjust where
there are problems, optimize again and so on. It is not enough to model
every part in a vacuum, they will be part of a complex system, and you
are going to have to model the system as a whole.

Or you overdesign and reduce the number of things you have to worry
about. Today's lithography can't afford to overdesign. In MNT, even
early MNT, I think you can. Maybe I'll turn out to be wrong, and
stiffness constraints will kill any design that's not maximally packed
and interactive. But the designs I've seen (by serious designers, not
"artist's conceptions") are not so tightly packed. Yes, there will be
some analysis required, but in general, part-by-part will be enough.

If I understand correctly, this question is pretty important; it
determines whether a massive supercomputer (and associated software!)
will be necessary for MNT, or whether just plain linear engineering will
be enough. This ripples through the rest of the problem. Do you need
very good models, or can you use approximate models and patch them when
they break? Do you need to train designers in an alien way of
designing, or just give them new parameters? How brittle are your
designs, and how hard to debug, and how easy to tweak? How well can you
predict the capabilities of products before you build and try them?

Quote:
I have been thinking mainly in terms of what a basic MNT capability
could do in terms of developing products. For that, it could take a
month to reach superpower status--if good CAD software and good
nanofactory blueprints were ready and waiting.

As I said, I think that having the ability to do just that is going to
be vital to getting to full nanotech in the first place. Maybe you
could get there using an army of designers with regular workstations,
but I think that approach will take much longer.

OK, now I understand why you've been thinking that ultracomputers will
greatly accelerate MNT design. If the designers have already been using
a heavily supercomputer-aided approach, then they'll certainly be able
to plug the ultracomputers in and work faster.

But will an army of designers take longer? If the designs are really
complex systems, they will. But if they're just complicated, I think
the human designers will be faster. The supercomputer team will still
be refining their models and defining their languages while the
tinkering team is already downloading designs to be built.

Quote:
Not the problem! Right now a lot of good people are doing good work on
design elements and components. Where you need the heavy lifting is
when you start putting the pieces together. If this arm will stick to
that beam when they get too close together, and they do in operation,
the design of one or the other has to be changed. Vacuum welding or
adsorbed gases are going to be problems that have to be addressed before
you build any real device.

If you run into that sort of problem too much, then you just stretch the
design to give you more empty space to work in. And if that makes it
too floppy, you just dump it in an appropriate cryogenic system.

BTW, vacuum welding is a phenomenon of metals. With covalent parts, you
have to worry about surface reconstruction and other bond
rearrangement. But in general your parts won't want to bond to each
other. It takes something like 20 GPa of pressure to make graphite
cross-bond into diamond. And your diamond surfaces can be
hydrogen-terminated.

You do have to take van der Waals force into account.

Quote:
As I said, it is not AI you need, it is just an awful lot of drudge work
developing the component models. If you want to think in terms of say,
Tinker Toys, if you built a library of components, someone could design
a device out of those components.

I like Tinker Toys. I think that even at the lowest levels, we'll want
to use levels of abstraction.

Your "awful lot of drudge work" sounds like armies of workstations. And
your supercomputer system sounds a lot like AI.

Quote:
The second generation is to merge
some of these pieces into subassemblies and "round the edges" to make a
better stronger, more compact or whatever component that can then be
added to your component library.

Right now microprocessors are designed the same way. There is a
hierarchy: The microprocessor, functional units, register level, gate
level, logic level, component level. During development, designers work
at all levels and the computers keep it all consistant.

This is why a solid-geometry CAD system like today's won't be nearly
sufficient.

BTW, the hierarchy continues through software: device driver, operating
system, library, application data model, GUI.

Quote:
If there is a
problem, buck it back to a design engineer working at the right level of
abstraction. So the computers don't do the creative work, they "keep
score" and insure that all of the various requirements at each design
level are met.

As a (former) software engineer, I can tell you that levels of
abstraction work even without such tight communication between the
levels. The results may not be as reliable... but the product
generally gets out the door in semi-usable form.

So I'm not sure that the CAD software has to do as much scorekeeping as
you're used to.

Quote:
I vote for the more elegant nanofab arrays. Nanofactories, more or less
as described in Nanosystems, are clearly the way to go. Far more
efficient to control.

I think that is the way to go at first. Later I think that working in a
fluid medium and relying on brownian motion to get feedstock from here
to there, with possibly some centrifuging etc., will be faster and more
efficient at mananging heat.

Thermodynamics says that, in theory, there's no difference in
efficiency. For example, for getting an object from point A to point B
in a certain time, Stokes drag force takes exactly as much energy as
Brownian motion plus bit-per-gate positional latches. I think what'll
win in the end is the one we're more comfortable designing with. Which
is nanofactories. At least until computers do the designing.

Quote:
[VHDL] For nanotech, I think we really need a 3 1/2 dimensional
language. In other words a design language that lets you think in terms
of three dimensional components, then flip through stacks of abstraction
levels. The picture of your design as electric fields, atoms,
components, subassemblies, subsystems, etc., needs to be different views
of the same (software and eventually hardware) object.

We'll need something like this. How well can this hide sets of
components while still representing their aggregate properties? How
well can it derive properties from lower-level properties?

I'm close to your position here, that the system needs to do
scorekeeping and allow design changes to echo up and down the tree. The
difference is that I'm picturing the changes only propagating in one
direction: someone builds a (possibly parameterized) library of parts
and devices, and someone else comes along and uses them for higher-level
purposes. Perhaps it's simply the difference in culture between
software and hardware engineering. We softheads take what we're
given--the language spec, the hardware, even the libraries--and build
what we can on top of it. I had no idea that hardware design was so
interactive. Perhaps it's simply that hardware is closer to the edge of
performance, while software simply expands to fill the available
memory. Or that hardware takes three months to fab, while software
compiles in minutes.

So this argues that either approach can work, as long as what you're
building isn't cutting-edge. The software approach produces less
efficient products, but allows more idiosyncratic designs. And MNT
will, for at least a few years, have far more performance available than
designers will know what to do with. So I suspect the software approach
will dominate MNT engineering, possibly even down to the smallest
levels.

Quote:
We don't disagree. My point was that for even the smallest possible
assembler, we are better off using heirarchical design systems.

Do you mean, hierarchical with two-way feedback and conflict resolution
among the levels implemented in the software and work flow? (Hardware
style?) I think this will be overkill. Or just hierarchical in the
sense that the mechanical designers don't have to worry about every
detail of atomic placement? (Software style?)

Quote:
For
anything you can actually see, the design may require half a dozen
levels of design abstraction.

At least!

Quote:
We are well behind the curve here, and it is going to take some awfully
smart people working full time on ethical and social problems to avoid
complete chaos. Just thinking of things that may happen is going to be
tough enough,

That's why I think we need CAD software ASAP, so we can start designing
hypothetical but realistic products in detail, and start to get a handle
on what we're dealing with.

There are several other reasons for producing CAD software pre-MNT. Not
in any particular order...

1) Whoever does MNT will build their own if it doesn't already exist.
An open source CAD project gives the rest of us a chance to avoid
complete irrelevance and powerlessness.
2) It'd be nice to design and deploy humanitarian products ASAP.
3) It may help to nucleate the development of MNT.
4) It may inform the policymakers who have to decide whether to fund
MNT.

This will likely become a position of CRN: that building open-source MNT
CAD software ASAP is a good idea for a variety of reasons.

Quote:
Or will the cars all drive themselves and talk to each other
using your choice of ultrasonics, infrared, radio, or lasers.

Just say "TCP/IP" and let the network worry about the physical layer.
:-)

Quote:
[MNT development wargames/arms race/preemption]

But the issue is
that someone developing MNT doesn't need a huge facility. Brains are
the major requirement, and supercomputers, which are now commodity items
are the second. ....

If the development of MNT is forced underground the results IMHO would
be catastrophic. The only people working on it would be people we
wouldn't want to have it.

I'm not saying it would be forced underground. (Though I expect any
nation developing it as a military priority to keep it pretty well
secret.) I'm saying that detection of an MNT program about to succeed
could be seriously destabilizing. This could happen through a secret
program being discovered, or by a country that's been ignoring it (such
as the U.S.) suddenly waking up and discovering that it's about to be
left behind.

Quote:
If it stays aboveground, and the groups
working on it agree on some ethical principles, then they will
cooperate, giving them the edge over the underground efforts. (But
espionage could be a wild card.)

As my previous paragraph implies, I don't think underground/aboveground
is the most useful distinction. I think the main determining factor
will be whether MNT's significance is felt mainly on geopolitical
(national) dimensions, or whether those effects can be swamped by other
kinds of development, like international, commercial, or Open Source.

Chris

--
Chris Phoenix cphoenix@best.com http://xenophilia.org
Center for Responsible Nanotechnology (co-founder) http://CRNano.org
Robert I. Eachus
Posted: Thu Oct 09, 2003 6:54 am
Guest
Chris Phoenix wrote:

Quote:
I think this is a topic change. I'm not complaining--they're both
worthwhile topics. But we were talking about post-MNT speedups, and now
we're talking about how MNT can be approached. Or am I making an
artificial distinction, and you're still talking about post-MNT speedup?

Something like that. As I see it, when you get close to your goal, the
support technology you have developed will have accelerated things
tremendously pre-MNT. In a race of a billion miles, the winner may not
be the guy who is going the fastest at the end of the race, but it is
definitely the way to bet. And if the second place finisher is going
faster, it won't be by that much. There will also be lots of racers
still clustered around the starting line--or within a couple hundred
million miles of it. Compared to the top finishers, they will be crawling.

But I also assume that once you get close to your goal, there will be a
feedback effect. In other words the prototypes and subsystems you build
will result in some acceleration before you finally put the last piece
in the puzzle. To take a simple example, lets say you have a process
that allows you to produce sections of silicon wafers with a single
molecular layer surface. (In other words, not just a single crystal
with no surface defects, but no steps due to partial layers of atoms.)

Say that the rest of your process for building nanotech devices starts
with one of these wafers and builds billions of individual devices on it
which co-operate to fabricate devices at a molecular level. You also
have a computer system which can input programming to one of these
fabrication devices. You don't have an assembler, you don't even have a
proof that an assembler can be made. But you do have a system which
will allow you to fabricate all sorts of interesting stuff, including
assemblers once you finish the design. You can even build specialized
devices that are not general purpose assemblers, but are designed to
produce instances of one nanotech structure as long as they don't break
or run out of (possibly specialized) feedstock. Again not an assembler,
but for many purposes, highly useful.

Or how about an array of (computer) processors that keeps adding
additional processors and memory at the edges of the array. Sometimes
quantity has a quality all its own. ;-)

Quote:
My mental model is a bit different, as it focuses on the point where
someone decides to look around. At some point, someone is going to
realize that MNT is going to be very important. They will start asking
questions about what it would take to build it. As soon as you fund a
half-dozen engineers and scientists to, as you say, look around, I'm
worried that they will find all the pieces ready for them.

So the looking-around process isn't continuous. It starts as a result
of a policy decision. And I think that, even with today's status of
enabling technologies, most of the pieces will be found as soon as
someone seriously looks. At that point, there'll be a sudden concerted
(and probably secret) effort to develop the rest of the pieces.

Same model different viewpoint. I am pretty sure we are not to that
point yet. In ten years, I am pretty sure we will be beyond it. Oh,
and there are several hundred groups out there doing the looking around.
I don't know most of them, I don't even know many of them. But I do
know enough that I assume the delta between "nanotech time," when all
the major pieces are possible, and full nanotech appearing will be at
most two or three years.

But I do think that independent of how much computer power is needed to
solve the final design problems, we are now at the point where we know
what the computers that will be used will look like, and we can buy
them, or if you prefer to be a pessimist their little brothers today.
If you have government-sized funding you can order systems like Red Tide
today. This is a 10,000+ Opteron processor system with an option for
more than doubling its size. AMD and Intel are planning to start
selling dual-core processors in 2005, Sun is expected to start selling
its dual-core UltraSPARC IV soon, and IBM is already shipping Power4
dual-core systems. (Dual core systems have two CPUs on one chip sharing
the on-die cache memory.) In any case, lots of companies are buying the
current generation of mini-super machines for laboratory use.

The easy way to translate all that is that in two years, a Red Tide or
Earth Simulator class system will cost less than half as much, or for
the same money you can get more than twice as much computer--in the same
space. More important, you can buy a "mini-super" for a couple hundred
thousand dollars that is "only" in the hundred GigaFLOPS or so range.
That is enough to do all the software development, design and simulation
of prototype devices in the couple of million atom range.

Quote:
So is this the point where a very short time period is enough to put the
winner far ahead of the loser? I don't think the situation is *that*
bad yet; there'll be a lot of lab work and a lot of engineering still to
do. But I'm probably misunderstanding you.

Nope. Right now it is possible to start on the lab work and
engineering. Or more appropriately, several dozen groups have started
doing the preliminary lab work and engineering. But for now, those
groups look at the finish line, and at how fast they are moving, and
don't see any rush. But I keep looking at how fast the distance to the
finish line is shrinking.

For decades now, the high pole in the tent has been simulating assembler
class products. Speaking from both a computer software and hardware
background it is not possible to build a working assembler class device
unless you can model it and test and debug the model. Imagine you have
your first assembler prototype. It is a cube 0.01 millimeters on a
side--and it doesn't work. What do you do? Fire up the on-board
diagnostics? You had better be pretty close to perfect if you expect to
get anything other than garbage out.

Now imagine instead, you have a complete design, and a simulator that
can "run" it at one simulated picosecond per second. Even that may be
too fast. But you can examine internal states, run diagnostics and see
what happens, set break points and save states so that you can resume
from that point later on, and so forth.

Now you can debug your design, and then--assuming you have a way to
build an instance of your design--you know it will work relatively well
from the start. You may still find a few design glitches to fix in rev.
1, but it will work.

Quote:
Oh, and one of
the key pieces, no matter how you plan to get to point N, is the ability
to "automatically" design subassemblies, and test them in simulation.
By automatically design, I mean specify say an arm that can move this
far in these dimensions, and have the software come up with an assembly
that meets the design criteria.

I'm not sure this is either necessary or possible. At the nanometer
scale, you can't design the mechanics without looking at the chemistry.

And you can't automate the chemistry design in any interesting and
predictable ways. There's a long conversation we could have here, and
probably should at some point. But basically, the available chemistry
will probably be pretty limited at first, which limits the design
choices to the point where a human can make them. And the mechanics for
a basic Merkle-style fabricator will be pretty simple as well. It may
be that genetic algorithms can come up with designs fitting lots of
constraints; I said "and predictable" so that I wouldn't exclude GA's.
But I think you need a design metalanguage both for GA's and for
rule-based systems, and I think building a design metalanguage would be
more of a pain than doing simple designs by hand.

I think we agree. It is that word "simple" that is the point of
departure...

Quote:
Why am I focusing on a basic Merkle-style fabricator? Because it's
really all we need. We can build a tabletop factory out of that, a few
other nanoscale components, and a lot of bulk-diamond mechanical
engineering.

...I think that the design problems for even a Merkle-style
fabricator will take a full set of design tools, design rule checkers
and so on. Remember that around 50,000 transistors the IC industry
passed the point where hand-design and no automated rule-checking
failed. Fortunately the era of automated design and rule-checking had
already begun.

Quote:
This is what I mean about automated chemistry design not being easy.
You can only replace atoms if you can do the mechanochemistry to build
the result. That multiplies the number of reactions you need by quite a
high factor. If early mechanochemistry were flexible, you'd be right,
but I think it won't be.

We definitely agree to disagree. The amount of computing required to
compute the chemistry of a system of say 10,000 atoms is large. But
compared to other computational challenges I see, it is in the noise.
(I am assuming that we have a computational model for an infinite flat
surface, and we are going to perturb it and see what happens.)

Quote:
If I understand correctly, this question is pretty important; it
determines whether a massive supercomputer (and associated software!)
will be necessary for MNT, or whether just plain linear engineering will
be enough. This ripples through the rest of the problem. Do you need
very good models, or can you use approximate models and patch them when
they break? Do you need to train designers in an alien way of
designing, or just give them new parameters? How brittle are your
designs, and how hard to debug, and how easy to tweak? How well can you
predict the capabilities of products before you build and try them?

Now we are on exactly the same wavelength. There are always tradeoffs
in designs. One way you overengineer and accept the cost of more
material to simplify design problems, the other way, the cost per unit
of excess weight/mass/volume is so high that you are willing to spend
extra design resources to refine the design.

Where will nanotech wind up? My assumptions:

1) Costs to build prototype devices using atom-by-atom placement will be
high. To pick a number, say one cent per atom in the finished prototype.

2) The time required to build prototype devices will be a function of
their complexity. I assume that to some extent you can build
sub-assemblies then fasten them together--but that adds design complexity.

3) At a give level of robustness, there will effectively be an absolute
limit on the number of atoms in a completed device for a given process.
Again, the sub-assembly approach will help, but at the cost of more
design complexity.

You see where all this is leading. If you take the robust, wide open
spaces approach, you might be able to get by with today's computers--and
come up with a design that will cost $10 billion dollars and take 20
years to build. I spend five years working on tooling and design rules,
then feed my design to, perhaps, a billion dollar computer array. Six
months later I start building my prototype which will take 2 years and
cost another billion dollars. Once I have my cheap, fast assemblers, I
can offer to build your prototype for you.

Oh, and there is one last detail. I may be wrong, but I think that the
progress in microelectronics is such that, if basic research stopped
today, the industry would coast along to the point where MNT is
possible. And if they don't stop working on basic research, they may
get there first. Today you can go out and buy a nice microprocessor
from any one of several chip manufacturers. It will use 0.13 micron
design rules, and contain about 50 million transistors. In a few months
you will be able to buy a Prescott from Intel or a San Diego from AMD.
Both with 90 nanometer design rules, but Intel will be using strained
silicon, while AMD is using silicon on insulator technology.

In late 2005 or early 2006, you should be able to get 65 nm design rule
processors from both companies. At this point in time AMD and IBM are
working together on strained silicon on insulator for 65 nanometers and
Intel is working on strained fully depleted silicon on insulator for the
same 65 nm node. Then in 2007 they both expect to get to 45 nanometer
design rules. The interesting question right now is whether F2 excimer
lasers will be ready for the 45 nm node, or companies will have to
switch to EUV lithography, which has to be done in a vacuum. In any
case prototype EUV equipment is available now, and will be ready in time
for the 45 nm node. The prototype system uses a 13 nm lightsource that
should be good down to say, the 7.5 nm node. Of course, if
microelectronics gets that far, how will you tell their products from
mature nanotech?

Quote:
OK, now I understand why you've been thinking that ultracomputers will
greatly accelerate MNT design. If the designers have already been using
a heavily supercomputer-aided approach, then they'll certainly be able
to plug the ultracomputers in and work faster.

But will an army of designers take longer? If the designs are really
complex systems, they will. But if they're just complicated, I think
the human designers will be faster. The supercomputer team will still
be refining their models and defining their languages while the
tinkering team is already downloading designs to be built.

As I said, I watched this with microelectronics. Established
semiconductor companies kept doing things the way they always had, until
it was just too unwieldy. When they shifted to computerized tools the
improvements were astonishing, and of course once the design tools were
migrated to the first generation of computerized design chips, the
designers--and the industry--never looked back. If you have been around
long enough, this occurred with chips like the Intel 80386 and the
Motorola 68020. To give you some idea of the suddenness of the change,
Stratus was building a new generation of computers around the 68020.
The first memory subsystem used 16k memory chips, spread over three PC
boards, the second generation was planned to use 64k chips, and one PC
board, and our brand new Sequent multiprocessor for doing the design.

The first memory subsystem was an 18 month effort and the final
debugging almost held up the announcement of the Stratus 2000 series.
The 64k chip memory board design was completed in three months,
including three ASICs, and the first rev. worked perfectly. At this
point about a dozen Stratus 2000 systems had been shipped with the "old"
memory subsystems. Over the next few months we upgraded them in place
(without shutting them down, this is Stratus!) just to get those
potentially buggy boards out of the field. (I won't go into the gory
details, but the 16k memory boards were right on the edge of timing
tolerances, and the 64k boards had extremely low jitter since the board
traces had been designed to be close to all the same length.)

This effect was noticed all around the industry. If you look at the gap
between the Intel 80286, 80386, and 80486, or between the Motorola
68010, 68020, and the 68030 you will see what I mean. Now, let me turn
this around. How much computing power will an assembler or nanofab need
built in? I could imagine trying to do it with a (much faster) version
of an Intel 80386 or Motorola 68020, plus all the support chips, memory
and nonvolatile storage. I can't imagine it can be done with less. So
even if the non-computing parts of this project were trivial, I can't
imagine trying it without automated tools. (Yes, you could put the
computer "off-chip" for prototyping purposes. But the resources
required to decode and distribute data to and from a remote computer are
probably about the same as the minimum I set above.)

Quote:
BTW, vacuum welding is a phenomenon of metals. With covalent parts, you
have to worry about surface reconstruction and other bond
rearrangement. But in general your parts won't want to bond to each
other. It takes something like 20 GPa of pressure to make graphite
cross-bond into diamond. And your diamond surfaces can be
hydrogen-terminated.

Understood. You are in your KISS mode, and I am willing to use over
half the periodic table if that will help make things smaller. In fact
the real joker in the deck may be merging molecular electronics and
mechanical nanotech to build hybrid sensors. But there I go again. I'm
trying to send (electronic) signals around using Tour wires instead of
(single walled) nanotubes, and build sensors out of a couple dozen
atoms. You are probably planning on nested nanotubes as a rod, and
pushing or rotating them to carry data.

Quote:
I like Tinker Toys. I think that even at the lowest levels, we'll want
to use levels of abstraction.

Your "awful lot of drudge work" sounds like armies of workstations. And
your supercomputer system sounds a lot like AI.

Actually there is a class of supercomputer called an array of
workstations. But I am actually planning to use clustered systems,
which is sort of the next level of integration. But yes, levels of
abstraction, lots of them. But no, my proposed use of supercomputers is
definitely not AI. It is just a lot of brute force finite-element
modeling and design tool rule checking. (It seems funny to talk about
applying finite-element analysis. When the elements are real, atomic
elements, the finite-element model is no longer an approximation.)

Quote:
This is why a solid-geometry CAD systems like today's won't be nearly
sufficient.

I have mentioned that before. It is now possible to start writing the
requirements for a nanotech design language. Since I have been a
language designer for a lot of my career, I immediately want to start
committing specifications. But someone needs to get the right people
together to hammer out the right set of requirements. Committing design
too before the requirements are all known is always a mistake. Just
having a good language requirements spec would be say 10% of the way
from here to nanotech, and going from requirements to specification and
an implementation would be worth at least another 20%. But I am not
being an optimist. I have been through that process several times, and
even with government money and your pick of experts, it takes years.

Quote:
As a (former) software engineer, I can tell you that levels of
abstraction work even without such tight communication between the
levels. The results may not be as reliable... but the product
generally gets out the door in semi-usable form.

So I'm not sure that the CAD software has to do as much scorekeeping as
you're used to.

In terms of software engineering roles, I am probably best categorized
as a language lawyer, a compiler guru, an algorithms expert, and a
software architect. Those roles tend to get me mixed up in the biggest,
nastiest software design problems around. Nanotech has exactly that
smell. For the past 20 years or so I have been involved mostly with
Ada, with a fairly heavy dose of PL/I, APL and a few other languages. I
also got dragged into the VHSIC problem early and worked on VHDL for a bit.

Quote:
We'll need something like this. How well can this hide sets of
components while still representing their aggregate properties? How
well can it derive properties from lower-level properties?

Object-oriented design has a nice fit. But the trick is going to be
building the "vertical" relations between the various abstraction level
views of an object into the design system while not obscuring the
"horizontal" spatial relations between objects. Since both these views
are going to be important, I think the design language is going to have
to go to a lot of effort to make them equally accessible. I can already
see that I am going to want a code browser that lets me walk up and down
a hierarchical decomposition, while being able to browse sideways into
logically related objects or physically adjacent objects. Oh, and
interfaces will have to be objects that overlap/share space with
multiple objects. There I go committing design when I don't have the
requirements yet. (Even though I was really thinking about design tools
there.)

Quote:

I'm close to your position here, that the system needs to do
scorekeeping and allow design changes to echo up and down the tree. The
difference is that I'm picturing the changes only propagating in one
direction: someone builds a (possibly parameterized) library of parts
and devices, and someone else comes along and uses them for higher-level
purposes. Perhaps it's simply the difference in culture between
software and hardware engineering. We softheads take what we're
given--the language spec, the hardware, even the libraries--and build
what we can on top of it. I had no idea that hardware design was so
interactive. Perhaps it's simply that hardware is closer to the edge of
performance, while software simply expands to fill the available
memory. Or that hardware takes three months to fab, while software
compiles in minutes.

There you go again, thinking I am a hardware designer. Yes, I do have a
lot more of a hardware background than most software engineers. But my
knowledge of the process of hardware design is from working with the
designers on developing requirements for design tools. My experiences
has been that hardware developers want simpler and more robust tools
than software engineers, because once they have them, they will drive
the tools a lot harder than a software engineer. Oh, and the hardware
engineers have a much larger budget for both software and computer
hardware than us poor software schmucks. ;-)

Quote:
Do you mean, hierarchical with two-way feedback and conflict resolution
among the levels implemented in the software and work flow? (Hardware
style?) I think this will be overkill. Or just hierarchical in the
sense that the mechanical designers don't have to worry about every
detail of atomic placement? (Software style?)

Somewhere in between. The thing that working with hardware engineers
has taught me is that in hardware there are physical limits. That is
where the hardware engineers tend to rely on tools most. The closest
thing in software is hard real-time scheduling. You have a timing
budget and you have to distribute it to the code modules such that
everything fits in the overall budget. In hardware you typically have
timing budgets AND you have physical limits on board space, the number
of traces you can run without going to a 6-layer board from a four-layer
board, power budgets, and so on.

The hardware engineer wants to be able to spend his time fixing budget
and layout problems, not finding them. So you get in the habit of
designing design tools so they do all that bookkeeping without any
effort on the hardware engineer's part. Of course, when the parts don't
fit on the PC board, the software tells him and now it is his problem.
(To clarify, a board layout program will try to find a good layout. But
you also put in some sanity checks so that you tell the hardware
engineer that the problem is unsolvable before spending hours trying to
route a board that all the component won't fit on.)

Quote:


For
anything you can actually see, the design may require half a dozen
levels of design abstraction.

At least!

Yep! I had in mind things like memory chips. Processor design you get
into dozens of design levels, but memory is fundamentally lots of copies
of a fairly simple design. (And the logic to tie them all together.)

Quote:
1) Whoever does MNT will build their own if it doesn't already exist.
An open source CAD project gives the rest of us a chance to avoid
complete irrelevance and powerlessness.
2) It'd be nice to design and deploy humanitarian products ASAP.
3) It may help to nucleate the development of MNT.
4) It may inform the policymakers who have to decide whether to fund
MNT.

This will likely become a position of CRN: that building open-source MNT
CAD software ASAP is a good idea for a variety of reasons.

Good position. As I say, I think that a good common design language
will help. in addition to making it easier to do design, it will make
it easier for others to review designs. I assume that you are a
believer in code reviews from some of the things you said. That is one
of the things I like about Ada. Since it makes it easier to read other
people's code, good programmers want their code reviewed, so they make
it pleasant to read.

I had a rule not to review C code after two in the afternoon. I didn't
want to be in rush hour traffic too soon afterwards. And I actually
made that rule while reviewing some of the best written C code I have
ever had the pleasure of reviewing. Well designed and written, and
nicely formatted. But flipping through the header files to figure out
which order macros definitions occurred in? For the fifth time because
the .h files were encountered in a different order in this function?
Aaagggrrrh!

Quote:
Or will the cars all drive themselves and talk to each other
using your choice of ultrasonics, infrared, radio, or lasers.


Just say "TCP/IP" and let the network worry about the physical layer.
Smile

Thanks, I needed that. ;-)

Quote:
I'm not saying it would be forced underground. (Though I expect any
nation developing it as a military priority to keep it pretty well
secret.) I'm saying that detection of an MNT program about to succeed
could be seriously destabilizing. This could happen through a secret
program being discovered, or by a country that's been ignoring it (such
as the U.S.) suddenly waking up and discovering that it's about to be
left behind.

Yep, and the right way not to wake up when Sputnik is beeping overhead
is to stay on track and not get mired in politics.

Quote:
As my previous paragraph implies, I don't think underground/aboveground
is the most useful distinction. I think the main determining factor
will be whether MNT's significance is felt mainly on geopolitical
(national) dimensions, or whether those effects can be swamped by other
kinds of development, like international, commercial, or Open Source.

I agree. I want open/commercial not secret/government/military. And
I've been there, done that, and got the coffee mug on both. The mindset
you often encounter on government programs thinks in terms of control
and turf. Such people are also to be found inside many large
companies--the government definitely doesn't have a monopoly on it. I
worry that one such person in the wrong place could take an entire
program in the wrong direction. I want this done by goal oriented
people, not people who will try to grab and control the territory you
need to cross to get to the right destination.

--
Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle." -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig
John Poindexter
Posted: Fri Oct 10, 2003 10:45 am
Guest
Chris Phoenix <cphoenix@best.com> wrote in message
news:<bl1d0u025c7@enews3.newsguy.com>...
Quote:
ekj@ekj.vestdata.no wrote:

On Thu, 25 Sep 2003, Robert I. Eachus wrote:

What has this to do with nanotech? The first assembler (or
nanofactory) will be built by a group that will be moving so much
faster in terms of technical progress than the rest of the world that
there will be no comparison.

Why ? You seem to have forgotten to include any trace of reasoning for
this bald-faced claim. It's a fact that there is today multiple teams
working on multiple technologies nessecary to reach full nanotech. What
leads you to the conclusion that all but one of these will neccesary
fade to irrelevance even before the construction of a replicator ?

Here, I have to tentatively agree with Robert. Not because multiple
teams will fade to irrelevance, but because there'll probably be only
one team succeeding at it. Developing MNT will require innovation: not
invention, but things like realizing easier ways to do mechanochemistry
in ultra-clean environments. It's possible that the final required
innovations will be published, but I doubt it; anyone working on MNT
will know what they have, and will be pretty secretive.

Another factor is that there may not be many teams working on it.
Certainly in the West, everyone seems convinced that it's a pipe dream
and there's no point even looking. I don't know if this is true in the
East. But it seems quite possible that one nation will develop it
before most others even think to ask whether they should be studying it.

Even if the winning team takes the weekend off to celebrate, and the
"second place" team finishes before Monday, the nanofab working over the
weekend will probably give the first place team a thousand times the
industrial base of the second place team.

(i.e. you're saying that given two teams, one that's had a nanofab for
1000 days, and one that's had a nanofab for 999 days, it's a given that
the first team will be more technically advanced. I don't think you've
supported this at all.)

Here, I think you're both half-right. If the "second place" team
finishes a day later, but their nanofactories are twice as fast, their
productivity will quickly outstrip the "first place" team.

But if the "first place" team finishes even a month or two ahead of the
"second place" team, the obvious thing to do is to build lots of weapons
and destroy the other teams.

This assumes that you can go from basic self-duplicating fabricator to
building complex products in a matter of months. I think you can, with
enough pre-design--which would certainly be funded by anyone who
understood MNT enough to fund an MNT project.

This also assumes that the developer will be military-minded; a
commercial developer would not go to war, but would file lots of
patents, grab lots of market share, and try to squish their competitors
economically.

What if the dividing line between a "commercial" and a "military"
developer is not that sharp, i.e. the military-industrial complex?

"Fascism should more properly be called corporatism, since it is the
merger of state and corporate power." - Benito Mussolini
Chris Phoenix
Posted: Sat Oct 18, 2003 9:51 am
Guest
John Poindexter wrote:
Quote:

Chris Phoenix <cphoenix@best.com> wrote in message
....
This also assumes that the developer will be military-minded; a
commercial developer would not go to war, but would file lots of
patents, grab lots of market share, and try to squish their competitors
economically.

What if the dividing line between a "commercial" and a "military"
developer is not that sharp, i.e. the military-industrial complex?

"Fascism should more properly be called corporatism, since it is the
merger of state and corporate power." - Benito Mussolini

Good question. An institution with a blurry line between commercial and
military is likely to be quite dangerous. Check out our new paper on
military, commercial, and information systems, and why it's a very bad
idea to mix them (but each one is necessary):

http://CRNano.org/systems.htm

Basically, military and commercial systems have incompatible sets of
ethics, and if an organization tries to be both, it'll find it very easy
to do unethical things. (Jane Jacobs calls this a "monstrous moral
hybrid.")

One might also look at the prison-industrial complex (which lobbies to
put more people in jail) or monopolies like the RIAA.

Chris

--
Chris Phoenix cphoenix@best.com http://xenophilia.org
Center for Responsible Nanotechnology (co-founder) http://CRNano.org
Rory McLean
Posted: Thu Oct 23, 2003 1:48 pm
Guest
In article <bmrnic01nv7@enews4.newsguy.com>, Chris Phoenix
<URL:mailto:cphoenix@best.com> wrote:
Quote:

John Poindexter wrote:

Chris Phoenix <cphoenix@best.com> wrote in message
....
This also assumes that the developer will be military-minded; a
commercial developer would not go to war, but would file lots of
patents, grab lots of market share, and try to squish their competitors
economically.

What if the dividing line between a "commercial" and a "military"
developer is not that sharp, i.e. the military-industrial complex?

"Fascism should more properly be called corporatism, since it is the
merger of state and corporate power." - Benito Mussolini

Good question. An institution with a blurry line between commercial and
military is likely to be quite dangerous. Check out our new paper on
military, commercial, and information systems, and why it's a very bad
idea to mix them (but each one is necessary):

http://CRNano.org/systems.htm

Basically, military and commercial systems have incompatible sets of
ethics, and if an organization tries to be both, it'll find it very easy
to do unethical things. (Jane Jacobs calls this a "monstrous moral
hybrid.")

One might also look at the prison-industrial complex (which lobbies to
put more people in jail) or monopolies like the RIAA.

Very interesting paper, and in some respects a minor revelation.

As I understand it you are saying that society can be considered
to be made up of organisations with several different, and in
fact incompatible, ethical systems, and that any credible design
for safe use of nanotech must take this into account.

I note you only consider three classes of organisation, Military
(Guardian), Commercial and Information.

If nanotech is as far-reaching as expected to be, it will touch
all parts of society, and I wonder if you need to consider the
ethical systems of other classes of organisation, such as
Religious and Hobby/Social, and from a negative point of view,
Terrorist. I don't think these neatly fit into any of the three
you have given. I still think it's a good starting point, though.


If there is a desire to restrict the distribution of products
built by say a nearly universally distributed table-top
nanofactory, then a number of things need to be considered:

== Only verified product designs should be built.

== Only products compatible with the ethics of the organisation
should be built.

== Product designs should only be used in accordance with the
associated agreement with the design's publisher.

For example, the nanofactory will only build designs water-marked
as verified, which will probably require several layers of
strong, dynamic, encryption to implement.

There will be a need to model the ethics of organisations,
compare these with the design aims of the product, verify the
product requester is a member of a given organisation, etc. Of
course, this doesn't in any way restrict the mis-application of
products, given human ingenuity, but will hopefully keep
dangerous industrial or military nanotech out of the domestic
kitchen.

If a product is released as freeware, then the nanofactory is not
allowed to charge for its manufacture. Relabeling and selling
someone else's product will probably need some sort of design
comparison scheme, with AI or human assistance, to prevent. If a
design is released explicitely not for military, or commercial,
or whatever, use, then such organisations should be prevented
from making it. A verifiable degree of responsibility might be
needed for some products, such as not generally allowing children
to produce powerful medicines


All the above will, I believe, need some sort of Agreement
Modelling, so it is clear and explicit on what basis a product
design can be used. This will have to be a lot more precise than
the sort of thing that the legal system handles, and as a basis
you might consider an Agreement to be rather like, for example, a
communication protocol. One part of an Agreement should be what
is to happen if the Agreement is broken by either side, which in
human terms might be to take something to arbitration.


What is proposed above would allow anyone to work on nanotech
product designs, simulate them as much as they liked, maybe even
test manufacture them in a controlled environment (such as a
remote-accessed testing facility), but only distribute them
widely in a controlled way.


Given the power of nanotech to alter physical objects, it is
possible that the traditional way of trying to restrict use of
systems by restricting the hardware will not be workable, and any
restrictions will need to be in the software, protected by
complex, self-checking, and interlocking strong encryption.

So, if you try and hack a nanofactory to run any product design,
without it being verified, the fact that the software wont run on
the hacked hardware might be the only real protection you could
put in place.

This is not quite the same issue, however, as the need to
carefully consider organisational ethics, product design
distribution, and the agreements that a nanofactory has with it's
users, discussed above.


Quote:
Chris Phoenix cphoenix@best.com http://xenophilia.org
Center for Responsible Nanotechnology (co-founder) http://CRNano.org

--
Rory McLean
rory@romsys.demon.co.uk
Chris Phoenix
Posted: Mon Oct 27, 2003 8:46 am
Guest
"Robert I. Eachus" wrote:
Quote: