MOLDY
# # ####### # ###### # #
## ## # # # # # # #
# # # # # # # # # # #
# # # # # # # # #
# # # # # # # #
# # # # # # # #
# # ####### ####### ###### #
Copyright Keith Refson January 1990
All rights reserved
Moldy is a general-purpose molecular dynamics simulation program which I wrote initially for my own research into aqueous solutions at mineral surfaces. However it is sufficiently flexible that it ought to be useful for a wide range of simulation calculations of atomic, ionic and molecular systems.
Moldy is licensed under the GNU General Public License V2 (see file COPYING) except for the modules sgclib.c sginfo.h and sgio.c which are contributed from the SgInfo package by Ralf W. Grosse-Kunstleve and licensed under separate terms (see file LICENSE-SGINFO).
- moldy-2.yy.tar.gz - The Unix distribution (also for MSDOS/Windoze)
- moldy-2.yy.com - The VMS distribution
- moldy-2.yy.zip - The binary distribution for Windows 95/NT
- moldy-manual.ps.Z - The Manual in PostScript form. Note that the distribution files already contain the LaTeX source.
Please note that moldy is copyrighted and distributed under the GNU public license which is designed to encourage its distribution and modification. This is to ensure that the source code of moldy and any improvements made to it by anybody remains available to anyone who wishes to use it. If you change or improve Moldy, please tell me and if practical and appropriate I will incorporate your modifications into a future release. I hope that as time goes on Moldy will become yet more comprehensive as a result of your input.
There is a second list for discussion of simulations using Moldy, requesting help with problems and related issues called simply moldy. To join send an email message to [email protected] containing the word "subscribe".
Contents of the distribution:
accel.c algorith.c alloc.c ansi.c auxil.c beeman.c These files are the source code for Moldy. convert.c dump.c ewald.c force.c input.c eigens.c kernel.c main.c matrix.c output.c quaterns.c rdf.c restart.c startup.c values.c xdr.c parallel.c
defs.h messages.h 'Include' files for above files structs.h xdr.h config.h.in Prototype configuration file. Do not hand-edit.
stddef-subst.h time-subst..h replacement ANSI C include files for non-ANSI systems. stdlib-subst..h string-subst..h
dumpanal.c dumpconv.c dumpext.c Source code for 'utility' programs. mdshak.c mextract.c msd.c mdavpos.c ReadDCD.c ReadDCD.h
getopt.c Support routine for utility progs.
Makefile.in Make file prototype for Moldy. Do not hand-edit. Makefile.w32 Makefile for GNU make under Windows 32. Makefile.mak Makefile for Borland Turbo C.
configure Shell script to prepare for compilation.
aclocal.m4 Macros for preparing configure script. Not used. config.guess config.sub Called by configure script.
compile.com Master compile file for VMS. Calls all the others.
compile_moldy.com Compile file for "moldy" itself.
compile_utils.com Link file for "moldy" itself.
link_moldy.com Compile file for utilities.
link_utils.com Link file for utilities.
defcomm.com Defines comands - execute from your LOGIN.COM
moldy.tex LaTeX source for manual moldy.bbl figures/fig_.ps Encapsulated Postscript versions of figures. figures/fig_.tex LaTeX annotation for figures. figures/fig_*-eepic.tex Alternative version of figures in eepic form.
tips2.in tip4p.in methane.in mcy.in mgclh2o.in Example system specification files control.clay argon.in quartz-vbst.in
control.mgclh2o control.tip4p Example control files control.water control.clay control.argon control.tips2 control.quartz control.mgclh2o
water-example.out argon-example.out Output from example runs in manual tips2-example.out tip4p-example.out mgclh2o-example.out quartz-example.out clay-example.out
A. Unix distribution
This distribution of Moldy takes the form of a compressed tar archive. The archive is unpacked with % gunzip moldy.tar (.gz) or % uncompress moldy.tar (.Z) % tar xvf moldy.tar
B. VMS
The VMS version of Moldy comes as a DCL archive, moldy.com. To unpack: $ @moldy This creates all the files needed in the current directory.
Alternatively, versions of "uncompress" and "tar" are available for VMS, though they are not standard. If you have them then you can unpack the "moldy.tar.Z" archive (suitably renamed) in the same way.
C. Windows 95 The shareware program "winzip" available from good archive sites may be used to unpack either the ".tar.gz" source distribution, or the ".zip" binary+source distribution.
Here are some brief notes. There are more detailed instructions in the manual.
A. UNIX
This version of Moldy uses the GNU autoconf system to configure for compilation. In many cases it should be possible to do:
% ./configure % make
The "configure" script will determine the cababilities of the compiling system and create the files "config.h" and Makefile tailored to the system. It should recognise most major workstation types and supply a good set of optimization options for the usual C compiler.
You can change the default compiler or options by calling configure with the environment variables CC, CPPFLAGS, CFLAGS, OPT, OPT2, LDFLAGS or LIBS defined. Any values wou supply for these will override the built-in ones. eg
% env CC=gcc OPT=-O1 ./configure (c-shell) $ CC=gcc OPT=-O1 ./configure (bourne-shell/korn-shell/bash)
Configure should be able to determine the characteristics of an machine unknown to it and to create Makefile and config.h to build a working version. In that case you may need to "hand-tune" compiler or optimization options, which may be specified by setting the OPT and OPT2 environment variables. OPT2 is used to compile only the most performance-critical modules and usually will select a very high level of optimization. It should be safe to select an optimization which means "treat all function arguments as restricted pointers which are not aliased to any other object". OPT is used for less preformance-critical modules and may be set to a lower level of optimization than OPT2.
There is just one other option to "configure", "--enable-parallel". See the section below on compiling for parallelism for a description.
B. VMS (VAX/VMS and OpenVMS/AXP)
Just execute the "compile.com" DCL command file which will build Moldy and the utilities. All the required macros are set in "defs.h". It also executes the command file "defcomm.com" which defines the command symbols to execute the programs. It is a good idea to execute this file from your LOGIN.COM to make them available every time you log in.
N.B. Depending on how your VMS system is set up you may need to take additional steps to link moldy with the C runtime library. Consult your local documentation or systems staff. If the C library isn't linked by default the command
$ assign sys$library:vaxcrtl lnk$library
before the executing the compile command file
$ @compile
may well do the trick.
C. Windows 95/NT
i) Source distribution.
Moldy should compile using any good ANSI C compiler, but one of the
ports of the free GNU gcc compiler to Win95 is recommended. The
simplest is the "Mingw32" port available from
"http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/" which
contains executables of the compiler, libraries and GNU Make.
Just rename the supplied "Makefile.w32" to makefile and invoke "make".
There is a set of compiler options in Makefile.w32
which produce a reasonably fast and portable executable. (N.B. These
compilers etc can only be run from the MS-DOS command line window)
Moldy has also been compiled using WATCOM C and Borland Turbo C. There is a Turbo C makefile supplied called "Makefile.Mak" (although this has not been tested with a recent version). The compilation and installation procedure will vary according to the compiler.
ii) Binary distribution The file moldy-2.yy.zip contains ".exe" files for moldy and the utilities compiled with Mingw32/gcc as above which will run on a 486 or above. Just unpack the distribution into a convenient directory. The ".exe" files may either be left in place or moved to a suitable "bin" directory. The PATH should be set in autoexec.bat to include whichever directory the ".exe" files are kept in.
N.B. ALL PLATFORMS. It is important that the "dumpext" utility is found in a directory in the shell search path as it is invoked by several of the other utilities to read dump files. If this is not the case they will not work.
RUNNING
-------
Try it out by typing
moldy control.water
to do a 10 timestep simulation of water. (Under Windows 95, Moldy can only be run from a MS-DOS command-line window)
The LaTeX source, "moldy.tex" and bibliography file, "moldy.bbl" are supplied. If you have LaTeX, "latex moldy" a couple of times to get the cross-references correct and print the dvi file using dvips or dvi2ps, or whatever dvi output you normally use.
There is a "moldy.dvi" target in the make file so just "make moldy.dvi" ought to do the trick.
A. Distributed Memory ------------------
To build this version you must have one of the three supported
message-passing libraries installed on the target system. These
are the Oxford BSP library, MPI (the new standardised
message-passing library interface) and TCGMSG (the Theoretical
Chamistry message-passing system). For the Cray T3D, there is
also an interface to the SHMEM libraries which provides the very
fastest interprocessor communication. This may be used in
conjunction with the MPPMANY option in Ewald.c.
To configure for a parallel build, use the "--enable-parallel"
option to "configure". The syntax is
./configure --enable-parallel=<parsys>
where <parsys> is one of "mpi" "bsp" "shmem" or "tcgmsg". If
<parsys> is omitted the default is "mpi".
Sometimes this is all that is required for a parallel build -- if
the include files for the parallel system are in a directory
searched by the C compiled and the libraries can be found using
-l<parlib>. The Cray T3D/T3E and SGI Power Challenge and Origin
2000 systems fall into this category. Otherwise it may be
necessary to specify these by setting the environment variables
CPPFLAGS and LIBS, eg:
env CPPFLAGS=-I/usr/local/mpi/include
LIBS="-L/usr/local/mpi/bin -lmpi" ./configure
Some parallel systems such as the MPICH implementation of MPI
from Argonne National Laboratories supply a compiler script
called, in this case "mpicc". If you are using MPICH it is
sufficient to do:
env CC=mpicc ./configure --enable-parallel
Configure assumes that "mpicc" invokes the system C compiler
and adds the appropriate optimization flags. Other cases where
an alternate compiler specification is used are for the IBM SP2
where the command is "mpcc" and for the Oxford bsp library
which provides "bspcc".
The parallel performance increses with system size as the amount
of work in the force and ewald sum loops increases as a proportion
of the total work and with respect to the communication overhead.
A speedup of nearly 7 on an 8-processor IBM SP1 has been
demonstrated for the run "control.big", and in general the larger
the system the better the parallel performance. However it is
also possible to obtain a moderate speedup on a workstation
network using the MPICH implementation of MPI.
The parallel interface is contained within a single file
"parallel.c" and versions for other MP libraries should be
relatively easy to add with a few hours of programming effort.
Alternative Ewald:
------------------
There is an alternative version of Ewald.c which uses W. Smith's
RIL paralellization strategy in ewald-RIL.c. This uses far less
memory but at the cost of doing parallel communication in the
inner loops. This works reasonably on parallel machines
with very short latencies such as the Cray T3D, but on lesser
beasts it serializes the whole code!
B. Shared memory. ------------- The sources contain separate versions of ewald.c and force.c with the appropriate code and compiler directives for compilation on certain shared-memory parallel machines including Stardent Titan, Convex and Cray architectures. To use, you must REPLACE ewald.c and force.c with the file ewald_parallel.c and force_parallel.c respecively. You must also define the preprocessor symbol PARALLEL during the compilation (eg with the compiler option -DPARALLEL).
The code reads the environment to decide how many processors
to execute on. The name of the env variable is usually the
same one as the manufacturers use for the same purpose
NCPUS for the CRAY and THREADS on everything else. Use
the SETENV command (for c-chell) or the bourne-shell equivalent
to before starting a run.
Note. The Stardent Titan version does not work as shipped because
the system supplied version of "malloc" can not be safely called
from a parallel program. Contact the author for a "thread-safe"
version which can.
BUILDING FROM CVS
See separate file README.CVS