[extropy-chat] Nanotech educations

Eugen Leitl eugen at leitl.org
Tue Jun 29 14:26:48 UTC 2004


On Mon, Jun 28, 2004 at 09:29:26AM -0700, Adrian Tymes wrote:

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

You'll lose the scientists if you talk CAD. Molecular structure editor and
vizualization package would be more like it.

http://jmol.sourceforge.net/demo/nanotech/
http://www.ks.uiuc.edu/Research/vmd/
http://pymol.sourceforge.net/
http://starship.python.net/crew/hinsen/MMTK/

All these are great packages, and can be used as a point of departure for a
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

No one gets shunned -- don't you listen? MNT people don't participate there.
They're completely invisible. No one knows they're there.

> machine-phase people think their careers (or
> reputations - sometimes the same thing in this field)

Which reputation? Mainstream literature carefully avoids even using the name
Drexler in print. The conspicuous absence is quite obvious.

On a lark, I've just searched a decade's worth of Science magazine, and found
16 hits on "Drexler", of which 4 are irrelevant. Still, 12 citations/decade
is more than I expected.

> might be a bit at risk if their names were attached to
> this.

I have no idea what you mean by this. I wish any of the usual suspects from
http://discuss.foresight.org/critmail/sci_nano/ would crop up on
http://dirac.cnrs-orleans.fr/fsatom_wiki/MolecularMechanicsOpenStandards
 
> > > 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.

Nope. Of the usual suspects, only Zyvex does that. As far as I know (which
isn't much) nobody else is actively working on the Drexler/Merkle/Freitas
approach to molecular nanotechnology.

> 
> > > 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

I'm all gung-ho for holistic design, but you're getting this ass-backwards.
You can worry about the geometry if your reacting moieties do the dance.
Whether continuous or cyclic deposition, patron-belt or retracting tooltips,
IT DOESN'T MATTER AT THIS STAGE.

> 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)?

You have a library of deposition and abstraction reactions. You have the
trajectory, the steric constraints and the control signals and the logic
generating said signals (which is sequential with some local feedback for
extra precision).

This is the hard part. How to paint 3d stuff and generate instruction streams
from your description if screamingly trivial in comparison.
 
> I emphasize *format* here.  True, data can be
> tranlsated from format to format, so long as all the

Where are nano people discussing formats on CML, mmCIF, fricken OpenBabel of
all things? Where are they?

> 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

You're wrong.

> 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

We're not talking about a software library. We're talking about a reaction
library, which is a set of educts, products, and the moeities trajectory and
tool constraints. Which is very unlike shared object.

> 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.)

Excuse me, but if this is an accurate description of what "machine-phase
people" do, then they fully deserve to languish in obscurity.

(However, I don't think this description is entirely accurate).
 
> 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

There's almost nothing there as far as doing chemistry by manipulative
proximal probe is concerned. Because it is extremely demanding
instrumentally. Plus, very few people are seeing the point.

In comparison, computers are cheap. But nano geeks obviously don't grok
Gaussian and Gamess.

> 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.)

I'm not seeing many people doing theoretical work, and I'm seeing about
nobody hanging out in the metaphorical Mojave space port.
 
> 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

You will not get a working assembler in the lab, and you will not get a
working assembler in the virtual drydock, as long as you keep ignoring the
physics of the device.

Actually because I have to explain the painfully obvious demonstrates how far
we have yet to go. This is not at all good.

> 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...

Look: http://www.ks.uiuc.edu/Research/vmd/imd/

You can apply forces in realtime to a running simulation of a large web
biomolecule and watch it in 3d. The package is very well supported, supports 3d graphics
acceleration, and scales from single PCs to very large clusters.

There's a psfgen plugin, and VMD comes with Python built-in. You can pull in
most of MMTK with a finite amount of work. You can export any format you like
by calling an OpenBabel binary externally.

>90% of your NanoCAD functionality is there. Not done by machine-phase
people. Not used by machine-phase people. Probably not even known by
machine-phase people, I'd hazard.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.extropy.org/pipermail/extropy-chat/attachments/20040629/b2c162a9/attachment.bin>


More information about the extropy-chat mailing list