Taken from: http://www.earth.ox.ac.uk/~keith/moldy.html on Feb 2, 1997 ---------------------- # # ####### # ###### # # ## ## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ####### ####### ###### # 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 available by anonymous file transfer from Oxford. Connect to "earth.ox.ac.uk" using "ftp", with an account name of "anonymous" and your email address as password. The relevant files are all in the "/pub" directory and are * moldy-2.yy.tar.gz - The Unix distribution (also for MSDOS/Windoze) * moldy-2.yy.com - The VMS distribution * 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. I am also keeping a list of email addresses of anyone who uses the program for notification of updates, bugs and so forth. Please notify me if you would like to be added to this list, preferably by email to Keith.Refson@earth.ox.ac.uk. 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 stddef.h time.h replacement ANSI C include files for non-ANSI systems. stdlib.h string.h dumpanal.c dumpconv.c dumpext.c Source code for 'utility' programs. mdshak.c mextract.c getopt.c Support routine for utility progs. Makefile Make file for Moldy. 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 fig_*.ps Encapsulated Postscript versions of figures. fig_*.tex LaTeX annotation for 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 UNPACKING --------- 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. COMPILING --------- Here are some brief notes. There are more detailed instructions in the manual. A. UNIX Stage 1. You ought to be able to type "make moldy utilities" on just about any flavour of unix and build a working version. However if you want to get the best performance you will have to work a bit harder with compiler options. You may also find that the compile fails for obscure reasons. Don't worry, some compile options will probably sort that out too. Stage 2. Edit "Makefile", choose a suitable set of compiler options for your machine and uncomment them. Moldy has been test compiled on most modern workstations as well as vector super and minisuper-computers, so you only have to select the preset options. Stage 3. This section describes how to "hand-tune" compiler options. If you get this far you have probably got a different machine or compiler system from any of the tested ones. Moldy recognises a number of C preprocessor macros which adjust its expectations of the compiler and operating system. These are best defined using the "-DMACRO-NAME" option of most unix C compilers. MACRO Purpose ----- ------- The following two macros are used to select the ANSI C "stdarg" mechanism. Default is older "varargs" mechanism. __STDC__ Automatically defined by ANSI compilers in strict mode. ANSI Alternative for ANSI compiler in non-strict mode which does not define __STDC__. ANSI_LIBS Set this if your libraries and header files conform to those expected in the ANSI 89 Standard. Otherwise extra replacement routines and header files to remedy the deficiencies of older systems are included. Set this if at all possible. Only in an ANSI environment can you be sure that all needed headers and library routines will be present. The alternative is a kludge which works most of the time on most machines. This is automatically set in "defs.h" for some machines/compilers vhich are known to have ANSI libraries. USE_XDR Turn on support for the portable binary dump and restart files using the XDR mechanism. This is the only area where Moldy departs substantially from the ANSI C standard so it is optional. Nevertheless it is so massively useful that it is on by default. As this is not part of the standard it may not compile correctly on some systems if the compiler is in "strict ANSI" mode. Use the default or the "relaxed" or "extended" ansi mode often provided. You may well need to add a library to the link using the LDFLAGS variable in the Makefile. For example, solaris 2 on Suns needs the "-lnsl" option and SGI's need the "-lsun" option. You may also need to define some other macro to get the headers correctly included viz: _ALL_SOURCE (IBM RS6000) _HPUX_SOURCE (HPUX) These are needed to enable stuff needed for the XDR routines and headers on IBM and HP machines. N.B. These are actually set automatically in the Moldy header "defs.h" However other systems may require something similar . SPMD Compile for SPMD (Single Program Multiple Data) parallel execution. You must also specify one of the macros BSP, MPI or TCGMSG to select a message-passing library and have the appropriate include paths and libraries defined in the Makefile. BSP/MPI/TCGMSG/SHMEM (parallel.c only) These select the parallel interface library. Portable implementations of the first three are available for most parallel architectures, and MPI should be available on most true parallel machines. MPPMANY (Ewald.c only) Selects parallelization of some of the trig initialization code for the reciprocal-space sum. This is a loser on all but the highest-bandwidth parallel machines. It increases run time on the IBM SP2. However it DOES give a speedup on the T3D when used in conjunction with the SHMEM or BSP library interface. 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. RUNNING ------- Try it out by typing moldy control.water to do a 10 timestep simulation of water. PRINTING THE MANUAL ------------------- 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. PARALLEL VERSION ---------------- 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). Then define the macro PARLIBC in the Makefile to contain the "include" path for the library header files, and the preprocessor symbols SPMD and one of MPI, BSP and TCGMSG. The macro PARLIBL should be defined to link with the appropriate libraries. 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 find out how to set up a parallel run, consult the documentation for your parallel system, as this varies. 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. 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.