Questions

Answers

1. How do I obtain a copy of DL_POLY_4? [Top]
   
   To obtain DL_POLY_4 you must first register as a user on the DL_POLY web site. Follow the registration link on the home page. It is no longer necessary to sign any documents or pay any handling fees, provided you are an academic user, and there is no longer a distinction between a group licence or a single user licence. Every license is a singe license! Please note that the terms of older licences are still valid.
   
   In the past the licence was valid for a limited period of three years, during which time users could obtain upgrades and advice on request. This is no longer the case. The licence is now a version licence, which means it is perpetual. You need not renew your licence unless you want a new version. In other words every new version requires a new licence. We will maintain our advice services only for registered users who are EPSRC funded researchers based in the UK.
   
   Once you are registered, further information will be sent to you by e-mail on the downloading procedure.
   
   
2. Why Register? [Top]
   
   
   1. The simple answer is that the DL_POLY software is the property (and copyright) of the STFC in the UK and you shouldn't just take it without agreeing to our terms, which incidentally are not excessively restrictive.
      
      
   2. Legally, the terms of the licence are valid whether you have registered or not. Possession of the code does not exempt you from responsibility.
      
      
   3. The code is provided free of charge to academic users. Registration is the only price we levy.
      
      
   4. We need an up-to-date list of as many registered users as possible to justify the continued support of the development of the software by our sponsors.
      
      
   5. Registered users are kept informed of bugs and enhancements.
      
      
   6. Registered users get free advice on using the code.
      
   
   
3. How do I cite DL_POLY in publications? [Top]
   
   Please, do cite DL_POLY when you publish your results! All such citations serve to show the organisations that has funded us that our work is indeed promoting science. To cite, please use the DL_POLY name in your paper abstract and body, do refer to the following publication:
   
   I.T. Todorov, W. Smith, K. Trachenko & M.T. Dove, Journal of Materials Chemistry, (2006) 16, 1911-1918
   
   and optionally provide the address of the legacy website: http://www.ccp5.ac.uk/DL_POLY/ (link opens in a new window)
   
   Thank you for your citations!
   
   
4. How do I report problems with the DL_POLY software? [Top]
   
   Make sure the problem you have encountered is genuine, i.e. it is not due to lack of experience of using DL_POLY. Have you done all you could to solve this yourself? Are you using the most up-to-date version of the code available? Is your model system setup sane, i.e. CONFIG and FIELD (TABLE, TABEAM) are well defined? Are you driving the simulation safe enough, i.e. using a sane and reasonable (non-aggressive, non-contradictory) set of options and conditions in CONTROL? Have you been able to replicate or investigated the issue and its possible manifestations on higher or lower processor core counts and/or another hardware platform and/or with another compiler and/or with lower level of compiler optimisation? Have you checked if a similar issue has been reported on the DL_POLY Forum?
   
   If you are satisfied with the self-questioning above and confident that this is a real issue that is strongly related to a problem with the software code then get in touch with the authors by email. Please provide as much information as possible to demonstrate the problem. Include (or provide links for download) of all input and relevant output files. Outline the symptoms you observed and any relevant conditions and circumstances: platform, compiler, components, submission script, etc. Describe the nature of the research targeted by using the modelled system and how the model was generated. Last but not least, comment on what you think the problem may be related to (broken concept?) and suggest if possible where you think the code falters and why.
   
   
5. How can I choose the Ewald sum parameters? [Top]
   
   The Ewald sum can only be used in a three dimensional periodic system. There are three variables that control the accuracy: alpha - the Ewald convergence parameter; r_cut - the real space forces cutoff; and the k_max = (k_max1,k_max2,k_max3) - three integers effectively defining the range of the reciprocal space sum (one integer for each of the three axis directions). These variables are not independent, and it is usual to regard one of them as pre-determined and adjust the other two accordingly. In this treatment we assume that r_cut (defined by the cutoff directive in the CONTROL file) is fixed for the given system.
   
   The Ewald sum splits the (electrostatic) sum for the infinite, periodic, system into a damped real space sum and a reciprocal space sum. The rate of convergence of both sums is governed by alpha. Evaluation of the real space sum is truncated at r = r_cut, so it is important that alpha be chosen so that contributions to the real space sum are negligible for terms with r > r_cut. The relative error (epsilon) in the real space sum truncated at r_cut is given approximately by
   
   epsilon = erfc(alpha*r_cut)/r_cut or approximately
   epsilon = exp[-(alpha r_cut)²]/r_cut
   
   alpha is 3.2/r_cut or greater (too large a value will make the reciprocal space sum very slowly convergent). This gives a relative error in the energy of no greater than epsilon = 4*10^-5 in the real space sum.
   
   The relative error in the reciprocal space term is approximately
   
   epsilon = exp[- k_max²/(4*alpha²)]/k_max²
   
   where
   
   k_max = (2 pi/L) k_max
   
   is the largest k-vector considered in reciprocal space, L is the width of the cell in the specified direction and k_max is an integer.
   
   For a relative error of 4*10^-5 this means using k_max = 6.2*alpha (approximately). k_max is then
   
   k_max > 3.2 L/r_cut
   
   In a cubic system, r_cut = L/2 implies k_max = 7. In practice, the above equation slightly over estimates the value of k_max required, so optimal values need to be found experimentally. In the above example k_max = 5 or 6 would be adequate. One final word of warning. If your simulation cell is a truncated octahedron or a rhombic dodecahedron then the estimates for the k_max need to be multiplied by 2^1/3. This arises because twice the normal number of k-vectors are required (half of which are redundant by symmetry) for these boundary contributions.
   
   In practice, the simplest way to choose these parameters is to decide what real space cutoff is required (for example the same cutoff used for the short ranged forces), and the use the ewald precision directive in the DL_POLY CONTROL file. This directive is accompanied by a number specifying the acceptable relative error (e.g. 1.0e-5), which DL_POLY then uses to calculate the convergence parameter and reciprocal space cutoff as specified automatically by the three integer parameters (k_max1,k_max2,k_max3).
   
   Alternatively, DL_POLY users may specify the Ewald parameters themselves using the ewald sum directive in the control file. This requires four numbers: alpha, k_max1, k_max2 and k_max3. For example the directive
   
   ewald sum 0.35 6 6 8
   
   would set alpha = 0.35 A^-1, k_max1 = 6, k_max2 = 6 and k_max3 = 8. These parameters are obtained via the following recommended approach.
   
   Preselect the value of r_cut, choose a working a value of alpha of about 3.2/r_cut and a large value for the k_max (say 10 10 10 or more). Then do a series of ten or so single step simulations with your initial configuration and with alpha ranging over the value you have chosen plus and minus 20%. Plot the Coulombic energy versus alpha. If the Ewald sum is correctly converged you will see a plateau in the plot. Divergence from the plateau at small alpha is due to non-convergence in the real space sum. Divergence from the plateau at large alpha is due to non-convergence of the reciprocal space sum. Redo the series of calculations using smaller k_max values. The optimum values for k_max are the smallest values that reproduce the correct Coulombic energy (the plateau value) and virial at the value of alpha to be used in the simulation.
   
   Note that one needs to specify the three integers (k_max1,k_max2,k_max3) referring to the three spatial directions, to ensure the reciprocal space sum is equally accurate in all directions. The values of (k_max1,k_max2,k_max3) must be commensurate with the cell geometry to ensure the same minimum wavelength is used in all directions. For a cubic cell set k_max1 = k_max2 = k_max3. However, for example, in a cell with dimensions A = B = C/2 (ie. a tetragonal cell, longer in the c direction than the a and b directions) use k_max1 = k_max2 = k_max3/2. If too small a values for the k_max are used the Ewald sum will produce spurious results. If too large values are used, the results will be correct but the calculation will consume unnecessary amounts of cpu time. The amount of cpu time increases with increasing the product k_max1*k_max2*k_max3.
   
   The quickest check on the accuracy of the Ewald sum is to compare the Coulombic energy (U) and the coulombic virial (W) in a short simulation. Adherence to the relationship: U = - W shows the extent to which the Ewald sum is correctly converged. These variables can be found under the columns headed eng_cou and vir_cou in the DL_POLY OUTPUT file.
   
   
6. How does DL_POLY handle dihedral 1-4 interactions? [Top]
   
   DL_POLY can handle 1-4 terms in dihedral interactions in several different ways, and the user needs to decide how it is to be done. But to do this it is necessary to understand exactly what DL_POLY does. If the user is employing a standard forcefield such as GROMOS or AMBER, then the standard descriptions of these should be consulted for advice on what terms are to be included.
   
   DL_POLY normally calculates 1-4 interactions as part of the dihedral function, and not as a non-bonded term.
   
   Usually the 1-4 interactions are assumed to be standard VDW or electrostatic forces, but scaled by some number less than or equal to 1. The DL_POLY dihedral routine will handle these interactions itself, using the same methods as the non-bonded force routines, but independent of them. If a new 1-4 interaction is required, that is not one of the standard VDW or electrostatic terms, the 1-4 term can be described as a bond.
   
   If a 1-4 interaction is described as a bond, then DL_POLY will treat it as a bond, and normally will calculate no non-bonded terms (i.e. neither a VDW term nor an electrostatic term) between the two atoms concerned. The energy and virial are added to the bond energy and bond virial. This is to be expected since the interaction has been defined as a bond.
   
   However, if the bond is defined with a keyword that has a minus (-) sign as the first character, then DL_POLY does calculate the non-bonded terms between the two atoms (VDW and electrostatic). The user may not want this(!) and, for example, want to keep the electrostatic term but discard the VDW term. DL_POLY does not, at present, allow this and the user is forced to accept both these contributions.
   
   Of course, if the user does regard the 1-4 interaction as a bond, and calculate it using the bond force subroutine, then they may regard the bond as a complete description of the 1-4 interaction, including electrostatic terms. In which case, the problem is fully solved! This is a perfectly consistent way to proceed.
   
   
7. What are the units of the DL_POLY force field? [Top]
   
   Some preliminaries: The DL_POLY code works internally using atomic units, which define the mass_unit as 1 proton, length_unit 1 Angstrom, time_unit 1 picosecond, charge_unit 1 proton. The energy unit is then a combination of these:
   
   mass_unit*(length_unit/time_unit)² = 1.6605402*10^-23 Joules
   
   (This actually works out to be exactly 10 Joules/mole). The unit of force is:
   
   mass_unit*length_unit/time_unit² = 1.6605402*10^-13 Newtons
   
   For the purposes of input only DL_POLY will allow the energy parameters of the force field to be expressed in other units: eV, kJ/mol, etc. but these are immediately converted to DL_POLY energy units for use internally. Note that different distance,mass or time units are not permitted. The conversion from eV to DL_POLY energies is eV*9648.530821, which assumes the eV unit is the molar quantity (i.e. it is 96485.30821 Joules/mole)
   
   Regarding the electric field strength E, in MKS units this would be expressed in Newtons/Coulomb, which is converted to DL_POLY units by
   
   E(DL_POLY) = E(MKS)*1.60217733*10^-19/1.6605402*10^-13 = E(MKS)*9.64853082*10^-7
   
   (The number 1.60217733*10^-19 is the charge on one proton). It is the field value in DL_POLY units that should be entered into the FIELD file. HOWEVER, if you have set UNITS=eV at the top of the FIELD file then the field parameter must be entered in units of eV/Angstrom/proton, so noting first that E(MKS) may also be defined as:
   
   E(MKS) = Joules/(Coulomb*metre)
   
   E(MKS) = E(eV)*96485.30821/(6.0221367*10²³*1.60217733*10^-19*1.0*10^-10)
   
   with
   
   96485.30821 - conversion factor from eV to Jouls/mol
   6.0221367*10²³ - Avogadro's number
   1.60217733*10^-19 - electron charge (Coulombs)
   1.0*10^-10 - Angstrom unit (metres)
   
   All this turns out to be
   
   E(eV) = E(MKS)*10^-10
   
   You should use the E(eV) value in the FIELD file when you have specified UNITS=eV at the top of the file.
   
   
8. How do I use DL_POLY on a Windows PC? [Top]
   
   DL_POLY is designed for UNIX or LINUX systems, but it can be run on Windows PCs as follows:
   
   Firstly, you need to download the free CygWin (link opens in a new window) software from RedHat. Install this on your PC. It will provide you with a UNIX-like shell that runs under windows PC. Make sure when you download the default cygwin core you opt for the extra components: make (the source assembling and building command), gcc and gfortran (the standard GNU C and fortran compilers). Another fortran compiler you may want is the free G95 (link opens in a new window) compiler that also works with CygWin. You should install this after you have installed CygWin.
   
   When everything is installed, open the CygWin window, and download the DL_POLY software to your CygWin home directory. Unpack the files according to the DL_POLY instructions and compile the code in the source directory using the approptiate makefile from the DL_POLY build directory. The executable, DLPOLY.X for DL_POLY_CLASSIC or DLPOLY.Z for DL_POLY_4, which appears in the execute directory may be run by typing its name in the CygWin window. If you have also installed java on your PC, you can run DL_POLY from within the java GUI.
   
   
9. How should I choose between DL_POLY_CLASSIC and DL_POLY_4? [p]
   
   This is a question with many answers. The most straightforward answer is to say that DL_POLY_CLASSIC was designed for simulations of up to 30,000 atoms and on parallel computers using up to a 100 processors, whereas DL_POLY_4 was designed for simulations of the order of millions atoms of running on thousands of processors. If you are fortunate you will identify your requirement in these broad specifications, but often you will need to look closer.
   
   Sometimes, the matter can be decided by looking at the functionality of the two programs. The most significant functional difference between the two is that DL_POLY_4 does not have specific functionalities such as metadynamics, hyperdynamics and spectral shifts. Therefore, you can only use DL_POLY_CLASSIC in such cases. So beware. Other differences in functionality are spelled out in the DL_POLY manuals. Please, make yourself aware of them.
   
   Apart from functionality, the key criteria for choosing between the two programs are system size and the cut off you want to apply to the forces. (The latter refers specifically to the cut directive defined in the CONTROL file).
   
   Before going into the details of how these criteria affect your choice it needs to be made clear that neither program (but particularly DL_POLY_4) can be effectively deployed without some grasp of their limitations. It is incumbent on the user to get familiar with these. The result of ignoring this can be a waste of computing resources that borders on the criminal. You have been warned!
   
   DL_POLY_CLASSIC is usually the program of choice if you have fewer than 500 atoms per processor in your simulation and the modelled system is smaller than 30,000 atoms. It is when you have more than 30,000 atoms and less than 100,000 atoms that you must generally make a choice between DL_POLY_CLASSIC and DL_POLY_4. Ideally, you should be thinking about switching to DL_POLY_4 once you get to 30,000 atoms, but you may find some unpalatable compromises need to be made. This can be illustrated by a typical circumstance.
   
   Suppose you have a system of 64,000 atoms in a cubic MD cell that is 132 A in each direction. (i.e. volume 2.29*10⁶ Angstroms³). Suppose also that a cut off no less than 8.0 A is required. What is the maximum number of processors I can use to run this simulation?
   
   The first thing to note is that DL_POLY_4 is based on the link cell algorithm, which further requires that each processor is allocated a domain consisting of a uniform number of these link cells. This comes down firstly to working out how many link cells the simulation requires in each direction of the MD cell. This is given by the integer part of the cell width divided by the cut off distance i.e. 132.0/8.0, which is 16. (So in total, there will be 4096 link cells in this system, which is 16 cubed.) Now, not to compromise on performance, i.e. there is more computation than communication, requires the minimum sensible number of link cells in a domain is 27 (or 3*3*3 for the three different directions). Anything less than this means the link cell strategy is NOT EFFICIENT. Integer division of 16 by 3 gives 5, which implies a 5x5x5 domain decomposition of the simulation cell, which means 125 processors.
   
   However, this is not a perfect solution for machines where charging is based on multipoles of a number that leaves overhead of idle processors. For example, if charging is in multiple of 16 (12) then the user has to pay for 128 (132) processors to accommodate the job on the HPC cluster.
   
   It should be apparent from this calculation that there will be circumstances in which one could do better using DL_POLY_CLASSIC which has no restrictions like the above.
   
   Finally, beware of odd shaped cells. If your MD cell is seriously non-cubic (for example pencil like) see what the link cell decomposition is like as it may be compromising the efficiency of DL_POLY_4. Note however, that you are allowed to run slab calculations (large in X and Y, but thin in Z). DL_POLY_4 will accommodate those by constructing domains that divide XY space only.
   
   
10. Why doesn't DL_POLY calculate the total energy of each atom? [Top]
    
    The first thing to note is that the term total energy is ambiguous. You have to think precisely about what you want:
    
    
    1. The energy required to remove an atom from the structure to infinity;
       
       
    2. The atom's share of the energy by virtue of its interaction with other atoms in the system.
       
       
    The first definition is quite a sensible one if one thinks of things like ionisation energy, where similar considerations apply, and it gives an unambiguous meaning to the term atom energy, which has some physical basis. However...
    
    Most people, I suspect, think in terms of the second definition. This quantity is quite easy to obtain in a system where only pair-wise forces operate, if you make the arbitrary decision to allocate half the energy to each atom involved in a pair interaction. In systems where many-body interactions are involved, such as angle bending or dihedral (torsional) terms, it is less obvious that an equipartition of the interaction energy between the atoms involved is the right thing to do. One may have to look at each contributing term in the interaction to decide how the sharing is to be done - it certainly isn't as simple as dividing by 2! But in the end one has to ask: what does this atom energy actually mean?
    
    So the point is: though it seems a sensible thing to want to calculate, it is not immediately clear how it should be done. This is why codes like DL_POLY and MOLDY don't do this for you.
    
    Having said all this, one feature DL_POLY_CLASSIC does support is energy decomposition: the assignment of components of the configurational energy to types of molecule-molecule interaction. This is found in the solvation or decomposition options (see user manual).
    
    
11. How does the DL_POLY atom exclusion list work in shell model simulations? [Top]
    
    This is a tricky issue and its advisable to be clued up about it when using the shell model in DL_POLY.
    
    The purpose of the exclusion list is to disable the non-bonded interactions between specific atoms or sites in the same molecule, such as two atoms connected by a bond, or indeed, the core and shell belonging to the same atom. (Non-bonded interactions in this context include electrostatic interactions.) In such cases it is assumed that the interaction, if any, between two excluded atoms is dealt with elsewhere in the force field. All this is reasonably clear.
    
    Problems arise with the shell model because, apart from the core and shell of the same atom forming an excluded pair. Exclusions can also arise because the core or shell is connected to something else. The question is how to deal with the exclusions that may (or may not) be implied by one of the core-shell pair being so connected. The fact is that the use of cores and shells within molecules (as opposed to ions) is not defined anywhere (as far as we are aware) and it is uncertain what the correct procedure is. So to some extent users have to define this themselves.
    
    In what follows we will assume that a molecule is defined so that all molecular links arise between cores, i.e. cores are responsible for maintaining the molecular integrity. This simplifies the discussion somewhat, but remember that any conclusions drawn will be inverted if you use the shells to define the molecular integrity.
    
    It should be noted, firstly, that the normal intra-molecular exclusions applied to atoms (which in this context means cores) are as follows:
    
    
    1. atoms in the same constraint or extensible bond;
       
    2. atoms in the same angle potential;
       
    3. atoms in the same inversion angle potential;
       
    4. atoms in the same dihedral angle potential; (though there are special considerations applied to the 1-4 terms).
       
    
    The current DL_POLY exclusion list for cores and shell disables the following interactions:
    
    
    1. between the core and shell on the same atom (obviously);
       
    2. between a shell and any core connected to its own core by sharing:
       
       1. a constraint bond;
          
       2. a flexible bond potential;
          
       3. a bond angle potential;
          
       4. a torsion angle potential;
          
       5. an inversion angle potential;
          
       6. the same rigid body.
          
    
    Note that the exclusion list does not prevent any of the possible cross core-shell unit interactions of type core-shell and shell-shell or core-core depending on the intra-molecular interaction user specification input within the same intra-molecular entity. To prevent these in DL_POLY_CLASSIC it is necessary to define a harmonic bond with a zero force constant between all pairs of shells, which will exclude the interactions on this basis. Alternatively, in DL_POLY_4 one could use the exclude directive in the CONTROL file. If you, however, wish to include any core-shell or core-core interaction that would normally be excluded, it is necessary to define the required interaction as a non-zero bond potential.
    
    Admittedly, all this is rather cumbersome, but given that the atom exclusions are not universally defined for the shell model, and that the possibility exists that different implementations may well require different treatments, this offers a reasonable starting point for the accommodation of most variants.
    
    
12. How do I produce movies from DL_POLY trajectories? [Top]
    
    DLPOLY-XYZ movie player by Jen-Chang Chen
    
    Dear Dr. Smith,
    
    In order to see the simulation animation, I wrote a simple python script his2xyz.ps to convert the HISTORY file to a multi-frame XYZ movie file. The script, his2xyz.py, runs well on my Linux box. However, there is one inconvenient step; that user should add/modify the atom symbol in the atomList in this script. It's my pleasure to share this with you.
    
    After we have a multi-frame XYZ file, we can use XMakemol and VMD to see the animation. The URLs of these program are:
    
    XMakemol - http://www.nongnu.org/xmakemol/ (link opens in a new window)
    
    VMD - http://www.ks.uiuc.edu/Research/vmd/ (link opens in a new window)
    
    The enclosed pictures show the program snapshot of the sixth exercise, Diffusion in Zeolites (link opens in a new window), in the DL_POLY tutorial.
    
    
    
    
    
    Jen-Chang Chen
    
    
13. How do I use DL_POLY on a Mac computer? [Top]
    
    The old recipe of how to deal with installation of DL_POLY on MAC computers, given below, is still valid way to go ahead. However, we find more appealing to make use of
    
    MacPorts - https://www.macports.org/install.php
    
    which requires super-user credentials. After the MacPorts installation for the appropriate version of the OSX system the user will need to update and install a set of necessary components in order to enable fortran compilation and possibly execution in parallel environment. The set of components and thus of commands will vary according to the user's requirements, hence the list below is just an example of the commands to issue in a MAC terminal:

     sudo port selfupdate
         sudo port upgrade outdated
         sudo port install gfortran g95 gforth gcc49 libgcc
         sudo port install cctools cctools-headers
         sudo port install openmpi openmpi-gcc49
         sudo port selfupdate
         sudo port upgrade outdated
         

    Further to this, in order to simplify and abstract the process of compilation, the user is advised to create a ~/bin directory in their $HOME that needs to be added in front of the user local $PATH environment variable and create symbolic links to the default parallel compiler and runtime executables. For these, one needs the following lines in $HOME/.bash_profile:

     # Set PATH so it includes user's private bin if it exists
         if [ -d "${HOME}/bin" ] ; then
         PATH=${HOME}/bin:${PATH}
         fi
         

    as well as symbolic links in $HOME/bin of the sort:

     USER@MACHINE::~
         % ls -all ~/bin
         8 lrwxr-x--- 1 itt staff 35B 2 Oct 14:29 mpif90@ -> /opt/local/bin/mpif90-openmpi-gcc49
         8 lrwxr-x--- 1 itt staff 35B 3 Oct 17:25 mpirun@ -> /opt/local/bin/mpirun-openmpi-gcc49
         

    
    Alternatively, follow the revised recipe as advised by Dr. Erich A. Muller at Imperial College, London, UK & Alexandros Salapatas at the Institute of Microelectronics, NCSR "Demokritos", Athens, Greece.
    
    
    1. Initial magic words. Add to the /etc/profile (that is edit the file using sudo vi or some similar editing tool) and add the following lines

        /usr/local/bin
                /usr/local/mpich/bin
                

       At the end of the procedure, it should look like this:

        # System-wide .profile for sh(1)
                PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/mpich/bin"
                export PATH
                if [ "${BASH-no}" != "no" ]; then
       
                [ -r /etc/bashrc ] && . /etc/bashrc
       
                fi
                

    2. Install the Xcode tools from the installation CD that came with the Mac.
       
       
    3. Install a fortran compiler. The simplest working one is gfortran which is ready from the HPC for mac page: http://hpc.sourceforge.net/ (link opens in a new window) this amounts to downloading the appropriate for your mac OSX gfortran-appropriate.tar.gz file and following the instructions to install it.
       
       On a mac, the download unzips automatically. You can untar it by clicking on it (but don't do it!) or rather by using a terminal window, cd to the download folder and

        sudo tar -xzfv gfortran-appropriate.tar.gz -C/
                

       At this stage, reboot the machine and test the gfortran with a simple serial program of your choice.
       
       
    4. The DL_POLY (serial version) can be now compiled.
       
       
    5. Install MPICH2 (for the MPI to work).
       
       First make a folder to host it:

        sudo mkdir /usr/local/mpich
                

       Note: we are defining our installation directory as /usr/local/mpich If you use something else, change accordingly. Download the latest MPICH2 package mpich2-latest.tar.gz from www-unix.mcs.anl.gov/mpi/mpich2/ and follow the instructions in the manual to compile it on the mac. Basically, this amounts to placing the tar file in a folder in the directory (where it downloads) opening a terminal window, cd to the folder and then

        tar -xzfv mpich2-latest.tar.gz
                

       Here you can double click it if you wish to untar it. cd to the folder that you untared and run the configure script using the following options:

        - prefix=/usr/local/mpich
                --with-device=ch3:shm
                --with-pm=gforker
                

       that is, type

        ./config - prefix=/usr/local/mpich --with-device=ch3:shm --with-pm=gforker
                

       When it finishes, with no errors hopefully, type

        make
                

       and then

        sudo make install
                

       Note: You may want to ignore the "|& tee make.log" part of the commands supplies in the MPICH2 instructions
       
       Note: The compiled MPICH2 in the HPC website does not seem to support inter-processor communication, it connects via ethernet amongst the processor, resulting in a horrible loss of performance. This is why we need to recompile everything.
       
       At this time again, you may want to reboot your machine.
       
       
    6. Now DL_POLY can be compiled (in parallel).
       
       
    7. To run in parallel, you do not invoke mpd (as suggested in the mpi manual) but rather something like this:

        mpiexec -n 4 ./DLPOLY.X
                

       where 4 refers to the number of processors you wish to use.
       
       That seems to be all...
       
       Good luck!
    
    
14. Why is the Coulombic energy decomposition in DL_POLY_CLASSIC sometimes wrong when using the Ewald method? [Top]
    
    Sometimes when you use the solvation or decompose options with the Ewald sum in DL_POLY_CLASSIC you can get strange results. For example in a simple system like KCl you might define one molecular species as K⁺ and the other as Cl^-. In such cases you find that the Coulombic energy decomposition into the individual terms E_KK, E_KCl and E_ClCl do not compare with results from non-Ewald determinations. You may even find that the terms have the wrong sign according to physical expectation e.g. E_KK may be negative!
    
    Surprisingly these answers are not entirely wrong, you have merely posed the question incorrectly.
    
    Consider the term E_KK. This is supposedly the K-K contribution to the Coulombic energy. A moment's reflection should tell you that this quantity is infinite in the infinite lattice that the Ewald sum assumes. Whatever answer you get therefore depends on the method you chose to do the lattice sum. It so happens that the Ewald sum may return a negative number for this(!) but this is merely an artefact of how the lattice sum is done. None of the other methods in DL_POLY (or anywhere else) is likely to give an agreed answer, except by accident or through an underlying similarity in the method.
    
    Are the results obtained by DL_POLY therefore meaningless? The answer is no. You can still combine the numbers in meaningful ways. For example, the total electrostatic energy (E_c) for the KCl simulation cell is given by
    
    E_c = E_KK + E_KCl + E_ClCl.
    
    Also, the average energy of (say) a K⁺ ion (E_K) is given by
    
    E_K = (E_KK + 1/2E_KCl)/N_K.
    
    where N_K is the number of K⁺ ions. If you are familiar with the derivation of the Ewald sum you will recognise that these relationships must be true. (Otherwise the Ewald sum would be totally useless!)
    
    So while for charged molecular species the Ewald sum energy decomposition does not produce correct values for their corresponding energy components, certain important additive combinations of these quantities provide correct results and may be used with confidence.


15. What do I do when I get a NaN or Inf instead of a numerical value in OUTPUT? [Top]
    
    It is not the software fault that this happens. The authors have done their best to ensure that most disaster scenarios are handled in a controlled termination manner. However, an absolute fool-proofing is impossible.
    
    The most common reason for getting get a NaN or Inf, by and large, is having two or more particles being too close to (if not on top of) one another. In the very first instance, your safety belt is to make sure that you have the fcap (force capping) and zero (zero temperature optimisation) options in your CONTROL file. If you do and you are still in trouble then try switching off, one by one, all interaction components, starting with electrostatics, to determine the culprit one. After you have done this exercise you should have a greater understanding of the particular reason in your model set-up and/or input supplied to DL_POLY for the observed manifestation.
    
    If the problem is still persistent then you may find useful the DL_POLY FORUM facility where you could ask fellow modellers for help with your system. However, please, ensure you have sufficient knowledge of MD and good general understanding of the DL_POLY logic for system set-up, input handling and internal machinery. There is plenty of educational material linked to the DL_POLY website as well as a lot of in-depth information in the DL_POLY User Manual.
    
    Good luck!
    
    

[Top]