[extropy-chat] Nanotech educations

[Adrian Tymes]

--- Eugen Leitl <eugen at leitl.org> wrote:
> On Mon, Jun 28, 2004 at 08:16:12AM -0700, Adrian
> Tymes wrote:
> > Technically, 3d structure editors are a form of
> > Computer Aided Design.  I see what you mean, but
> you
> 
> Yes. But they're specialized to deal with full
> atomic detail, including
> realtime display, editing, and dynamics (VMD-NAMD)
> good enough to handle
> biomolecules. And they're programmable.
> Also, they're open source. And they scale to
> mesoscale. 
> 
> Any vanilla CAD is designed to deal with solids. It
> is the wrong-headed approach. 
> You can't hack it top-down to include atomic scale.
> You have to start with
> a system including atomic scale, and hack bottom-up.
> It's trivial that way.

<nods>  Just saying you might want to pick a more
descriptive term, is all.  Say, "solid model CAD"
versus "molecular CAD".

> If people are building standards, it costs you very,
> very little to make your
> voice heard. And it reflects quite some of the glory
> of the finished product.

Ah, but as you said, they're getting shunned for
lack of participation.  Which can make some
machine-phase people think their careers (or
reputations - sometimes the same thing in this field)
might be a bit at risk if their names were attached to
this.

> > And we need tools to perform those validations.
> 
> I mentioned these tools. Why hasn't any
> nanotechnology enthusiast picked up a
> package like Gamess?

Because they're busier hacking on the hardware.

> > Creating the tools seems to be a bigger problem
> than
> > using them to create the library once they exist.
> > (Not to mention, the details of the tools will
> tend to
> > shed light on the proper format of the library.)
> 
> The details of the tools only matter if your physics
> is wrong.

Actually, they matter even if your physics are right.
What's the architecture of your tool?  How does it
conceptually break things down?  What things are
typically handled automatically by the tool, versus
what things need to be specified by the user (and thus
in the data files)?

I emphasize *format* here.  True, data can be
tranlsated from format to format, so long as all the
data each format uses is there - but part of the
problem is determining exactly what data is needed in
the first place.  I don't mean the general type of
data, I mean specifications like you'd see out of IEEE
or the like.  And even if you have them today, there's
a good enough chance they'll be at least slightly
incorrect that to make the library today is to risk
having to entirely remake the library when the tool
(and its data format) comes along anyway...so why
bother?  (At least, this is how a lot of machine-phase
people think, if they seriously consider the problem
in the first place.)

> > Maybe just one or two reactions (bombardment with
> high
> > energy photons or electrons, and exposure to high
> > electrical current when bonded to a conductive
> > manipulator), with variations for different power
> > levels and different atoms.
> 
> You're not describing just "two reactions".
> Activating moieties with current
> is actually a good idea, but you have to include
> what you're zapping, how the
> orientation is controlled, and how much current you
> use.

True.  Would "one or two general types of reactions"
be more accurate?

> I wish the machine-phase people would get cracking
> at least at the
> theoretical stuff.

Machine-phase people are often attracted to the
machine phase because they want to get cracking on
what's actually there, and leave theory to other
people.  (I may be overusing this analogy, but it's
like the difference between the rocketry crews in
Mojave and those who hunt for dark matter.  Both tasks
have their importance, but they'll attract different
kinds of people.)

> Still, I see no movement at all on open source
> nanotechnology. The open
> source hackers don't understand the science and the
> challenge, the people who
> do are too few, and they apparently don't have the
> skills, or the time.
> 
> Do you now see why I'm frustrated?

Yes.  It's not an easy problem, but again, it looks
like the surest solution would be to come up with a
working assembler.  If this software problem really is
so huge, and if it looks like it won't seriously be
addressed until the hardware problem is almost dealt
with, then deal with the hardware problem, no?

Now, granted, that solution has major implications of
its own...but I'm no so sure that we aren't that far
away from being able to create the hardware of an
assembler *if we ignore the software issues for the
moment*.  The assembler might be nearly useless
without good software, true - but if creating it, even
in its useless state, seems to be a prerequisite to
getting the software problem addressed, then...