NAMOT Pre-Release 2.2.0-pre4 In OSX 10.8 (Maybe Older Versions)

A recent visit to the College of Nanoscale Science and Engineering (CNSE) at SUNY Albany inspired a few new DNA ideas that I decided would be greatly simplified by having NAMOT available again for design. Having failed at the base install of the NAMOT 2 version and, unfortunately, not having NAMOT available in Fink for a simple installation, the solution became to build the pre-release from scratch. Ignoring the many errors one encounters while walking through an OSX/Xcode/Fink/X11 bootstrap, the final procedure worked well and without major problem. As usual, the error messages at varied steps are provided below because, I assume, those messages are what you’re searching for when you find your way here.

0. Required Installations

You’ll need the following installed for this particular build. I believe XCode is the only thing that you’ll have to pay for (if you don’t already have it. I seem to remember paying $5 through the App Store).

1. XCode

The OSX Developer Suite – developer.apple.com/xcode

2. XQuartz

An OSX (X.Org) X Window System – xquartz.macosforge.org/landing/

3. Fink

An OSX port program for a host of Unix codes and libraries – www.finkproject.org

3a. GSL

The GNU Scientific (C and C++) Libraries – www.gnu.org/software/gsl. This will be installed with Fink.

3b. LessTif

An OSF/Motif clone (made available for OSX through Fink) – lesstif.sourceforge.net. This will be installed with Fink.

4. NAMOT2.2.0-pre4

The -pre4 is currently available (from 2003) from sourceforge.net/projects/namot/files/. I did not try -pre3 and had no luck with the official 2 release.

And, with that…

1. XCode

Blindly follow the install procedure. Several steps below deal with working around the default install locations (specifically, /sw).

2. XQuartz

If you don’t have XQuartz installed, you’re configure step…

cd Downloads
cd namot-2.2.0-pre4
./configure 

will produce the following error…

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
...
creating libtool
checking for X... no
checking for main in -lX11... no
NAMOT requires Xwindows

Blindly follow the XQuartz install process. After the installations, you’ll receive the same error as above. The –x-libraries= and –x-includes= additions to configure below direct the script to the proper libraries and includes.

./configure --x-libraries=/usr/X11/lib/ --x-includes=/usrX11/include/

Hopefully, you’ll find yourself past the first install problem and onto the second problem.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
...
creating libtool
checking for X... libraries /usr/X11/lib/, headers /usrX11/include/
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for main in -lX11... yes
checking for main in -lgslcblas... no
NAMOT requires GNU Scientific Library

3. Fink

The next two codes that need to be installed are the GNU Scientific Libraries and LessTif, both of which are much easier to install using Fink. It is generally useful for many other codes as well, so a good program for any computational chemist to have on hand. The install should be non-problematic despite having to build it from source in 10.6 – 10.8 (as of January 2013). If you build with all the default settings, you’ll have no trouble after.

cd Downloads
cd fink-0.34.4
./bootstrap 

I chose the default settings throughout.

Fink must be installed and run with superuser (root) privileges. Fink can automatically try to become root when it's run from a user account. Since you're currently running this script as a normal user, the method you choose will also be used immediately for this script. Available methods:

(1)	Use sudo
(2)	Use su
(3)	None, fink must be run as root

Choose a method: [1] 

...

You should now have a working Fink installation in '/sw'. You still need package descriptions if you want to compile packages yourself. You can get them by running either of the commands: 'fink selfupdate-rsync', to update via rsync (generally preferred); or 'fink selfupdate-cvs', to update via CVS (more likely to work through a firewall).

Run '. /sw/bin/init.sh' to set up this terminal session environment to use Fink. To make the software installed by Fink available in all of your future terminal shells, add '. /sw/bin/init.sh' to the init script '.profile' or '.bash_profile' in your home directory. The program /sw/bin/pathsetup.sh can help with this. Enjoy.

Then you run the final step in Fink below:

/sw/bin/pathsetup.sh

Which will produce the following two pop-ups notifying you of shell modifications.

3a. GSL

With the install of Fink, you need to install GSL and LessTif. If you try to install either immediately after installation…

fink install gsl

…you’ll receive the following error:

Password:
Scanning package description files..........
Information about 305 packages read in 0 seconds.
no package found for "gsl"
Failed: no package found for specification 'gsl'!

Required after the installation is a fink selfupdate.

fink selfupdate

As usual, follow the default settings…

fink needs you to choose a SelfUpdateMethod.

(1)	cvs
(2)	Stick to point releases
(3)	rsync

Choose an update method [3] 
/usr/bin/find /sw/fink -name CVS -type d -print0 | xargs -0 /bin/rm -rf
fink is setting your default update method to rsync
...
Updating the list of locally available binary packages.
Scanning dists/stable/main/binary-darwin-i386
New package: dists/stable/main/binary-darwin-i386/base/base-files_1.9.13-1_darwin-i386.deb
New package: dists/stable/main/binary-darwin-i386/base/fink-mirrors_0.34.4.1-1_darwin-i386.deb

Which then leads to a successful GSL install.

fink install gsl

Producing the following output…

Information about 12051 packages read in 1 seconds.
The package 'gsl' will be built and installed.
Reading build dependency for gsl-1.15-1...
Reading dependency for gsl-1.15-1...
Reading runtime dependency for gsl-1.15-1...
Reading dependency for gsl-shlibs-1.15-1...
...
Updating the list of locally available binary packages.
Scanning dists/stable/main/binary-darwin-i386
New package: dists/stable/main/binary-darwin-i386/sci/gsl-shlibs_1.15-1_darwin-i386.deb
New package: dists/stable/main/binary-darwin-i386/sci/gsl_1.15-1_darwin-i386.deb

Attempting a fresh build after the GSL step…

./configure --x-libraries=/usr/X11/lib/ --x-includes=/usrX11/include/

…then still produces the following error:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
...
checking for IceConnectionNumber in -lICE... yes
checking for main in -lX11... yes
checking for main in -lgslcblas... no
NAMOT requires GNU Scientific Library

As mentioned above, there are a few redirects that need to be made after the XCode / Fink install to put libraries and includes where, in this case, NAMOT expects them. To perform this task, we’ll be using symbolic links.

sudo ln -s /sw/include/gsl /usr/include/
sudo ln -s /sw/lib/libgsl* /usr/lib

Now attempting a build…

./configure --x-libraries=/usr/X11/lib/ --x-includes=/usrX11/include

Gets you past the GSL issue.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
…
checking for IceConnectionNumber in -lICE... yes
checking for main in -lX11... yes
checking for main in -lgslcblas... yes
checking for main in -lgsl... yes
checking for XShmCreateImage in -lXext... yes
checking for main in -lXt... yes
checking for main in -lXm... no
NAMOT requires Motif...try LessTif(http://www.lesstif.org)

3b. LessTif

The LessTif symbolic links work the same as the GSL symbolic links. This fink install may take a while.

fink install lesstif

Output below…

Information about 12051 packages read in 1 seconds.
The package 'lesstif' will be built and installed.
Reading build dependency for lesstif-0.95.2-4...
Reading dependency for lesstif-0.95.2-4...
Reading runtime dependency for lesstif-0.95.2-4...
...
Setting up lesstif (0.95.2-4) ...
Clearing dependency_libs of .la files being installed

Updating the list of locally available binary packages.
Scanning dists/stable/main/binary-darwin-i386
New package: dists/stable/main/binary-darwin-i386/x11/app-defaults_20010814-12_darwin-i386.deb
New package: dists/stable/main/binary-darwin-i386/x11/lesstif-bin_0.95.2-4_darwin-i386.deb
New package: dists/stable/main/binary-darwin-i386/x11/lesstif-shlibs_0.95.2-4_darwin-i386.deb
New package: dists/stable/main/binary-darwin-i386/x11/lesstif_0.95.2-4_darwin-i386.deb
./configure --x-libraries=/usr/X11/lib/ --x-includes=/usrX11/include/

But, unfortunately, the LessTif libraries are not in the expected locations.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
...
checking for IceConnectionNumber in -lICE... yes
checking for main in -lX11... yes
checking for main in -lgslcblas... yes
checking for main in -lgsl... yes
checking for XShmCreateImage in -lXext... yes
checking for main in -lXt... yes
checking for main in -lXm... no
NAMOT requires Motif...try LessTif(http://www.lesstif.org)

So we add the symbolic links…

sudo ln -s /sw/lib/libXm.* /usr/lib
sudo ln -s /sw/include/Xm /usr/include

Which, finally, runs configure…

./configure --x-libraries=/usr/X11/lib/ --x-includes=/usrX11/include/

…with no errors.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
...
config.status: creating docs/demos/curve/Makefile
config.status: creating docs/demos/dit/Makefile
config.status: creating docs/demos/Makefile
config.status: creating config.h
config.status: executing depfiles commands

NOTE: The make step with Python 2.6 produces the following error below. I did not diagnose this beyond the failure to build under 10.6. OSX 10.8 comes with Python 2.7, which did not produce this problem (I’m assuming this is the origin of the problem).

make

…will produce the following error at the pngwriter.c step.

/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..    -DLIB_HOME="\"/usr/local/share/namot\"" -DHELP_FILE_DIR="\"/usr/local/share/namot\"" -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config -g -O2 -c -o _pynamot_la-pngwriter.lo `test -f 'pngwriter.c' || echo './'`pngwriter.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -DLIB_HOME=\"/usr/local/share/namot\" -DHELP_FILE_DIR=\"/usr/local/share/namot\" -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config -g -O2 -c pngwriter.c -MT _pynamot_la-pngwriter.lo -MD -MP -MF .deps/_pynamot_la-pngwriter.TPlo  -fno-common -DPIC -o _pynamot_la-pngwriter.lo
pngwriter.c: In function 'dump_PNG':
pngwriter.c:28: error: 'png_structp' undeclared (first use in this function)
pngwriter.c:28: error: (Each undeclared identifier is reported only once
pngwriter.c:28: error: for each function it appears in.)
pngwriter.c:28: error: expected ';' before 'png_ptr'
pngwriter.c:29: error: 'png_infop' undeclared (first use in this function)
pngwriter.c:29: error: expected ';' before 'info_ptr'
pngwriter.c:30: error: 'png_byte' undeclared (first use in this function)
pngwriter.c:30: error: 'row_pointers' undeclared (first use in this function)
pngwriter.c:30: error: expected expression before ')' token
pngwriter.c:31: error: 'png_text' undeclared (first use in this function)
pngwriter.c:31: error: expected ';' before 'text_ptr'
pngwriter.c:39: warning: incompatible implicit declaration of built-in function 'memset'
pngwriter.c:39: error: 'text_ptr' undeclared (first use in this function)
pngwriter.c:47: error: 'png_ptr' undeclared (first use in this function)
pngwriter.c:47: error: 'PNG_LIBPNG_VER_STRING' undeclared (first use in this function)
pngwriter.c:48: error: 'png_voidp' undeclared (first use in this function)
pngwriter.c:57: error: 'info_ptr' undeclared (first use in this function)
pngwriter.c:60: error: 'png_infopp' undeclared (first use in this function)
pngwriter.c:82: error: 'PNG_COLOR_TYPE_RGB' undeclared (first use in this function)
pngwriter.c:82: error: 'PNG_INTERLACE_ADAM7' undeclared (first use in this function)
pngwriter.c:83: error: 'PNG_COMPRESSION_TYPE_DEFAULT' undeclared (first use in this function)
pngwriter.c:83: error: 'PNG_FILTER_TYPE_DEFAULT' undeclared (first use in this function)
pngwriter.c:85: error: 'PNG_sRGB_INTENT_ABSOLUTE' undeclared (first use in this function)
pngwriter.c:90: error: 'PNG_TEXT_COMPRESSION_NONE' undeclared (first use in this function)
pngwriter.c:93: error: 'PNG_TEXT_COMPRESSION_zTXt' undeclared (first use in this function)
pngwriter.c:104: error: expected expression before ')' token
make[2]: *** [_pynamot_la-pngwriter.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

The build on 10.8 continues as below, with a few warnings about the symbolic link usage that do not seem to affect the program usability (or continued build).

make

Results below…

make  all-recursive
Making all in src
source='namot_wrap.c' object='_pynamot_la-namot_wrap.lo' libtool=yes \
	depfile='.deps/_pynamot_la-namot_wrap.Plo' tmpdepfile='.deps/_pynamot_la-namot_wrap.TPlo' \
	depmode=gcc3 /bin/sh ../depcomp \
	/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..    -DLIB_HOME="\"/usr/local/share/namot\"" -DHELP_FILE_DIR="\"/usr/local/share/namot\"" -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -g -O2 -c -o _pynamot_la-namot_wrap.lo `test -f 'namot_wrap.c' || echo './'`namot_wrap.c

...

*** Warning: linker path does not have real file for library -lXm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libXm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /sw/lib/libXm.la

*** Warning: linker path does not have real file for library -lgsl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgsl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /sw/lib/libgsl.la

*** Warning: linker path does not have real file for library -lgslcblas.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgslcblas and none of the candidates passed a file format test
*** using a file magic. Last file checked: /sw/lib/libgslcblas.la

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module _pynamot.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

...

Making all in libs
make[2]: Nothing to be done for `all'.
Making all in docs
Making all in helpfiles
make[3]: Nothing to be done for `all'.
Making all in demos
Making all in 6way
make[4]: Nothing to be done for `all'.
Making all in bending
make[4]: Nothing to be done for `all'.
Making all in cube
make[4]: Nothing to be done for `all'.
Making all in curve
make[4]: Nothing to be done for `all'.
Making all in dit
make[4]: Nothing to be done for `all'.
make[4]: Nothing to be done for `all-am'.
make[3]: Nothing to be done for `all-am'.
Making all in etc
make[2]: Nothing to be done for `all'.

Finally, the install…

make install

Which produces the following:

Making install in src
/bin/sh ../mkinstalldirs /usr/local/lib
 /bin/sh ../libtool --mode=install /usr/bin/install -c  _pynamot.la /usr/local/lib/_pynamot.la
/usr/bin/install -c .libs/_pynamot.lai /usr/local/lib/_pynamot.la
/usr/bin/install -c .libs/_pynamot.a /usr/local/lib/_pynamot.a
ranlib /usr/local/lib/_pynamot.a
chmod 644 /usr/local/lib/_pynamot.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable
     during execution

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
...
/bin/sh ../mkinstalldirs /usr/local/share/namot
 /usr/bin/install -c -m 644 Namot2.512 /usr/local/share/namot/Namot2.512
 /usr/bin/install -c -m 644 Namot2.600 /usr/local/share/namot/Namot2.600
 /usr/bin/install -c -m 644 Namot2.700 /usr/local/share/namot/Namot2.700
 /usr/bin/install -c -m 644 icon1.xv /usr/local/share/namot/icon1.xv
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.

With luck, your launching of NAMOT will open XQuartz and produce a fully operational NAMOT session.

namot

And, for more assistance with producing DNA files for GROMACS, consider the Modifications To The ffG53a6.rtp And ffG53a5.rtp Residue Topology Files Required For Using GROMOS96-NAMOT-GROMACS v1, sed-Based Script For Converting NAMOT And NAMOT2 DNA Output To GROMOS96 Format For GROMACS Topology Generation v1, and sed-Based Script For Converting NAMOT And NAMOT2 DNA Output To ffAMBER Format For GROMACS Topology Generation v1 pages on this blog.

Finally! A Good Use For The Nano Gallery (Kudos To nanosonic.com)

An unlabeled version of the fused-diamondoid-carbon-nanotube-van-der-waals-crimp-junction found a home in the NanoSonic Nanotechnology Coloring Book, page 8 (I show it below (with mine shown a little more nano-sized)). I think that’s pretty hip.

Kudos to Tom Moore for pointing it out.

NanoHive@Home’s Published Results (Finally): Analysis Of Diamondoid Mechanosynthesis Tooltip Pathologies Generated Via A Distributed Computing Approach

Published in the Journal Of Computational And Theoretical Nanoscience. This paper has been as delayed in posting as the accepted article was long in printing, which was less time than the wait for the completion of the manuscript, which itself was massive compared to the time of the experiments themselves, which was fractional compared to how long it would have been without the NanoHive@Home crew that donated so much compute time to the project so long ago. First off…

Acknowledgements

This work would not have been possible without the enormous contribution of the NanoHive@Home participants, composed of over 6,000 worldwide volunteers and their computers.

For those that were part of the NHAH community and want to see what the final work looks like, please drop me a line [nhah@somewhereville.com] so we can properly settle up.

The Paper Itself

Analysis Of Diamondoid Mechanosynthesis Tooltip Pathologies Generated Via A Distributed Computing Approach

Damian G. Allis,a* Brian Helfrich,b Robert A. Freitas Jr.c, and Ralph C. Merklec

a. Department of Chemistry, Syracuse University, Syracuse, NY 13244, USA
b. Helcorp, Maplewood, NJ, 07040, USA
c. Institute for Molecular Manufacturing, Palo Alto, CA 94301, USA

The results of a combined molecular dynamics/quantum chemistry pathology study of previously reported organic (diamondoid) tooltips for diamondoid mechanosynthesis (DMS) are presented. This study, employing the NanoHive@Home (NH@H) distributed computing project, produced 80,000 tooltip geometries used in 200,000 calculations optimized at either the RHF/3-21G or RHF/STO-3G levels of theory based on geometries obtained from high-energy molecular dynamics simulations to produce highly deformed starting geometries. These 200,000 calculations have been catalogued, grouped according to energies and geometries, and analyzed to consider potentially accessible defect structures (pathologies) for tooltip geometries either binding a carbon dimer (C2) feedstock or not containing the transported dimer feedstock. The transport and deposition of feedstock and the stability of the tooltip between dimer “loading” cycles are important geometries that must be considered as part of a tooltip stability analysis. The NH@H framework is found to be a useful method both for the study of highly deforming covalent geometries and, using lower-temperature MD simulations, for generating and optimizing molecular conformations (demonstrated using biotin, n-heptane, and n-octane in this study). The results of the pathology survey are discussed and general considerations for the exploration of DMS tooltip usability are explored.

DOI:dx.doi.org/10.1166/jctn.2011.1792

A Few Visuals From The Article

The purpose of the study was to explore the conformation space of potential tooltips for use in mechanosynthetic operations. Anyone in the Advanced Molecular Manufacturing (AMM) community will recognize something like…

The tooltips themselves used for the deposition of carbon dimers were hammered on by the Q-SMAKAS (Quantum Search for Minimum Alternatives in Kinetically-Accessible Space) methodology (no, that wasn’t easy to make up), producing possible defect structures to explore how these tips might fall apart in an experimental apparatus. These tips were taken from the original survey paper [R. A. Freitas Jr., D. G. Allis and R. C. Merkle, “Horizontal Ge-Substituted Polymantane-Based C2 Dimer Placement Tooltip Motifs for Diamond Mechanosynthesis,” J. Comput. Theor. Nanosci. 4, 433 (2007)] and the DC10c study [D. G. Allis and K. E. Drexler, “Design and Analysis of a Molecular Tool for Carbon Transfer in Mechanosynthesis,” J. Comput. Theor. Nanosci. 2, 45 (2005) – and this one’s available as a free download from HERE]. Much to my surprise, there’s a section of a book available for background on google: Tip-Based Nanofabrication: Fundamentals and Applications, by Ampere A. Tseng.


Tip conformation survey. Click on the image for a larger version.

And for the non-AMM crowd, the same methodology of hammering on molecules in 3000 K to generate structural isomers can be employed at 300 K for the generation of conformational isomers, which was used to great success to explore the conformation-space of simple linear hydrocarbons and the far more interesting molecule biotin


Biotin conformation survey. Click on the image for a larger version.

And Some Pick Hits From The Discussion

4.1 Unloaded Tooltips And Ge-Ge Bond Formation

Any stabilizing interactions within the open tooltip may serve to increase the barriers to structural rearrangement, H migration, etc. between the time a C2 dimer is deposited on a workpiece and the time the tooltip is recharged with a new C2 dimer.

4.2 More Stable Pathologies And Transition State Barriers

The identification of a more stable structure does not provide any insight into the energy barrier over which an operational mechanosynthetic geometry must pass in order to convert into a non-operational geometry.

Identifying from among the failure modes within some energy range which of the operational tooltip structures that are accessible within a thermal regime in a working system is a time-consuming but very important subsequent step in any continued developmental survey of these tooltips.

4.3 Hydrogen-Inverted Tooltip Geometries And Larger Tooltip Frameworks

These largely-ignored tooltip pathologies are the results of hydrogen inversion, a type of defect that finds one or more H atoms inserting into the cage framework as a result of a methodological mismatch of atom momentum and classical time step in the MD simulations … Three common workarounds for large H atom displacements per time step are (1) the use of smaller time steps to recalculate the forces on the H atoms, (2) the artificial increase of the mass of the H atoms to reduce their net displacement over some set time step (such as re-massing H atoms to deuterium or higher), and (3) the subsuming of the H atoms into the associated “heavy” atom to remove the H motion entirely from the simulation.

4.4 The NH@H Network And “Best-Practices” Considerations

The NH@H tooltip pathology survey generated a considerable amount of data and, after the analysis of the resulting data, yielded a selection of tooltip pathologies to serve as the basis for subsequent studies of tooltip defect pathways… The speed of a calculation and, ultimately, the quality of the calculation for a particular analysis are dictated by the quality of the computers owned by the participants… The use of a survey of representative available computers at the start of a series of quantum chemistry studies can be of great benefit in identifying the constraints a researcher must place on their investigation.

4.5 Identified Minima vs. Accessible Minima

In the absence of transition state calculations or MD simulations on larger tooltip frameworks to remove degrees of freedom in some atoms, it is not known how many of these tooltips can be ignored simply for energetic reasons — either due to large rearrangement barrier energies or due to one-step inaccessibility because of the presence of multiple barriers to complete a rearrangement to a predicted minimum.

4.6 Hydrogen Migration

In most stable tooltips, H migration is assumed to be the most accessible route to the formation of inoperative structures (what previous studies [R. A. Freitas Jr., D. G. Allis and R. C. Merkle, J. Comput. Theor. Nanosci. 4, 433 (2007)] have called “hydrogen poisoning”).

4.7 Ge-C Framework Bond Breaking

All of the tooltips in this study are designed to facilitate dimer deposition and tooltip retraction with the only modification to the covalent framework of the tooltip being the loss of the C2 dimer… The defects identified in the NH@H study with broken Ge-Cframework bonds may not themselves be accessible in isolation, but the additional bonding modes and resulting strain in the entire system as part of a mechanosynthetic operation makes such defect modes important in the overall design analysis of a diamondoid structure that is to be fabricated.

4.8 Combined Ge-C(framework) Bond Breaking And C=C π-Formation

The formation of broken Ge-C/C=C bond pathologies are noteworthy, both in the context of the operational issue described above and in the manner by which a symmetric bond breaking in these tooltips can produce very stable geometries that then require large transition state barriers to be present for the mechanosynthetic operability of the tooltip.

4.9 Ge-Ge Bond Formation

As noted in the Hydrogen Migration section, the formation of these strained bonds in the UT structures may not be detrimental to tooltip operation but may, by increasing the barrier to other defect modes, serve as a form of stabilization during the time between deposition and C2 dimer recharging.

4.10 C2 Positional Variation

Remarkably, despite the high temperatures and otherwise large deformations identified in many of the tooltip structures, specific structural deformations at the Ge-[C2 dimer]-Ge position were identified in only a few cases from the MD-based quantum chemistry optimizations… Here and generally, both the quality of the basis set and the inclusion of electron correlation (by way of the B3LYP density functional) are expected to make a considerable difference in the accuracy of the estimated relative energies.

4.11 Conformational Differences

In most rigid tooltip designs, the identification of conformational minima is interesting but otherwise not of significance, as conformational flexibility at the tooltip base is, like H inversion, removed from all structures as a result of embedding the structure within a larger and more constraining tooltip framework… This approach to tooltip design optimization via conformational control of the base has not been considered in previous studies and is one of the more interesting results to emerge from this initial NH@H study.

Additional Assorted

A few documents from the original website are reposted here in PDF format for historical purposes (providing a bit more context. If you were part of the original @Home crowd and participated in any of the forum discussions, all of the text above likely makes some amount of sense).

2011december10_NanoHive1andNanoHiveAtHome.pdf [download]
2011december10_QSMAKAS.pdf [download]

NanoHive-1 (NH1) is a modular simulator created by Brian Helfrich which is used for modeling the physical world at a nanometer scale. The intended purpose of the simulator is to act as a tool for the study, experimentation, and development of nanotech entities. NanoHive-1 is a GPL/LGPL licensed open-source development – you can download and use it for free. NanoHive-1 can be run stand-alone, or easily integrated to support other applications such as CAD tools.

NanoHive@Home (NHAH) is a distributed computing system also created by Brian Helfrich based on the BOINC platform that was used for large-scale nanotech systems simulation and analysis; drawing its computing power from otherwise idle computers sitting in people’s homes. The goal of NanoHive@Home was to perform large-scale nanosystems simulation and analysis that was otherwise too intensive to be calculated via normal means, and thereby enable further scientific study in the field of nanotechnology.

The Tooltip Failure Mode Search Project, conducted by Brian Helfrich and Dr. Damian Allis ran on NHAH from February 2007 through May 2007. It utilized computing cycles donated from over 6,000 computers worldwide and reached a peak performance of nearly 3 teraFLOPS. Here are links to the explanations and results of the project:

Explanation
Results