FMD

Fast Molecular Dynamics

A Programmer's Guide

For FMD Version 1.11.5

17 March 2000

Document Maintained by James A. Lupo


Since fmd is derived from namd, Version 1.4, the following holds:

The FMD code is being developed under the CCM-4 CHSSI effort of the DOD High Performance Computing Program. This effort supports the Computational Chemistry and Materials Science (CCM) computational technology area. A partial list of Participants in the effort include: Dr. Ruth Pachter, Dr. James A. Lupo, Dr. Alan M. Mckenney, Dr. Soumya Patnaik and Dr. Zhiqiang Wang (AFRL/MLPJ); Dr. Mark Gordon (Iowa State University); Dr. Lennart Johnsson (University of Houston); Dr. Sarm Krimm (University of Michigan); Dr. Betsy Rice and William Mattson (ARL); and Dr. Greg Voth (University of Utah).

FMD is derived, in part, from the source code of the NAMD program, and is redistributed under the modification and redistribution terms of the NAMD license agreement. The NAMD license agreement states:

Copyright (C) 1995-96 The Board of Trustees of the University of Illinois. All rights reserved.

NOTICE: The program NAMD is *not* in the public domain. However, it is freely available without fee for education, research, and non-profit purposes. By obtaining copies of this and other files that comprise the NAMD program, you, the Licensee, agree to abide by the following conditions and understandings with respect to the copyrighted software:

  1. The software is copyrighted in the name of the Board of Trustees of the University of Illinois (UI), and ownership of the software remains with the UI.
  2. Permission to use and modify this software and its documentation is hereby granted to Licensee. In addition, permission to copy this work and any derived works is granted to Licensee, provided that
    1. the copyright notice and this permission notice appear on all such copies,
    2. that proper credit be given by citing:

      M. Nelson, W. Humphrey, A. Gursoy, A. Dalke, L. Kale, R. Skeel and K. Schulten, Intl. J. Supercomput. Applics. High Performance Computing, Vol 10, #4, pp.251-268, 1996.

    3. that no charge be made for such copies,
    4. that programs derived from NAMD be given a different name.
  3. Some of the code and executables used by NAMD may have different restrictions.
  4. Licensee may not use the name, logo, or any other symbol of the UI nor the names of any of its employees nor any adaptation thereof in advertizing or publicity pertaining to the software without specific prior written approval of the UI.
  5. THE UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THE SOFTWARE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY.
  6. The UI shall not be liable for any damages suffered by Licensee from the use of this software.

The fast fourier transform routines, comprising the source code contained in the FFT subdirectory, are from the double precision version of FFTPack as distributed via Netlib. It is apparently Version 4, dated 1985, as authored by Paul N. Swarztrauber of the National Center for Atmospheric Research, Boulder, Colorado. NCAR is sponsored by the National Science Foundation. No restrictions were found in the the Netlib distributions of either the single or double precision versions.

This should be considered a working document, and as such should be associated with the specific version of FMD it is released with. It need not describe depricated features in previous versions, nor correctly describe those in future versions. The information contained within represents only part of the overall FMD effort. It has been adapted, in part, from the documentation released with NAMD 1.4.

Introduction

The program fmd is a parallel molecular dynamics program. It is designed for high-performance simulations in material science. A general structure based on a small set of generic objects for communication between processors, calculation of atomic forces, and integration of the equations of motion allows fmd to adopt different algorithms for these aspects of the molecular dynamics calculation.

The program uses a spatial decomposition scheme to distribute atoms among processors. The model is broken down into uniform cubes of space referred to as patches. A set of patches is assigned to each processor. Patches are dynamically redistributed during the simulation to achieve approximate load balance. The program is message driven, meaning that the order of computation is determined by the arrival of messages indicating that the data necessary for a given computation is available. Scheduling tasks in this manner allows for the greatest possible overlap of communication and computation. fmd uses the same force field and input files as the program xplor. It will produce trajectory files in DCD and HDF format, and is able to communicate with the DICE visualization environment.

This document is the Programmer's Guide to fmd, and complements the User's Guide. It is intended to provide a detailed guide to exactly what fmd does, how it does it, and why it does it a particular way. The document is divided into several chapters. Chapter 2 details exactly what fmd computes. It includes details of and derivations for the CHARMM/X-PLOR force field and the integration scheme used. Chapter 3 outlines the design considerations that went into fmd. It covers the overall design of the program, including details of it's multi-threaded, message-driven operation and it's related spatial decomposition scheme. Chapter 4 discusses the basics of working with fmd, including how to set up a working directory for the program, the coding conventions used, and the details of the user input file used to run fmd. The last section of the guide is the longest and most detailed. This section provides the implementation details of fmd, including a detailed description of every C++ class used in the program. Armed with this information, a user should be able to understand how fmd works, and modify it to test new algorithms and methods.

Computational Details

This section details exactly what fmd calculates during a simulation. The first section describes the various components of the force field used, the second describes the integration method, and the third section describes the units and constant values used by the program.

Force Field Details

The force field used by fmd is compatible with the force fields used by the programs xplor (see section References) and charmm (see section References). The force field includes energy terms for electrostatic and van der Waals interactions, linear bonds, angular bonds, dihedral bonds, improper bonds, hydrogen bonds, and constraints. The total energy function used by fmd can be expressed as:

E(total) = E(elec) + E(vdw) + E(bond) + E(angle) + E(d/i) + E(constraint)

The following sections describe the individual energy terms in detail, as well as how the forces associated with each term are determined.

Electrostatics

The electrostatic interaction is determined by the electrical charges on a pair of atoms and is described by Coulomb's Law: (see Postscript version for equation) where

Epsilon_14

= Scaling factor for 1-4 interactions. This is equal to 1.0 for any interactions other than a modified 1-4 interaction. The value used for modified 1-4 interactions is specified in the user input file using the 1-4scaling parameter.

C = 2.31e-19 J nm
q_i, and q_j = charges on atoms i and j, as specified in .psf file.
Epsilon_0 =

dielectric constant specified by the user input parameter dielectric

(see Postscript version for equation)
(see Postscript version for equation)

By differentiating the formula for Coulomb's Law, we arrive at an equation for the force due to the electrostatic interaction: (see Postscript version for equation). where

(see Postscript version for equation).

van der Waals

The van der Waals interactions describe the forces resulting from local interactions of atoms. The van der Waals energy between two atoms i and j is given by: (see Postscript version for equation)

The constants A and B are specified for any pair of atoms in the parameter file using an NBFix entry. With this command, values of A and B for normal interactions and modified 1-4 interactions are specified explicitly. If an NBFix entry is not found for an atom pair, the constants are calculated using the parameters Sigma_ij and Epsilon_ij as read from the parameter file, using the equations: (see printed manual for equations) are calculated from the Sigma and Epsilon values specified for the atom types of atoms i and j by the NBOnd data records in the parameter file using the equations: where

Epsilon_i, Epsilon_j = Epsilon values for atoms i and j.

The values of Epsilon and Sigma for a given pair can be related to the minimum energy and distance, E_min and R_min by the equations: (see Postscript version for equations)

For modified 1-4 interactions, the Sigma_ij and Epsilon_ij are calculated as above, except that the Sigma_i^14 and Epsilon_i^14 entries from NBOnd records in the parameter file are used.

The force for the van der Waals interactions is obtained by differentiating the energy function:

Bonded Exclusions

Certain pairs of atoms are excluded from electrostatic and van der Waals calculations because of the bonded interactions. The rules to apply in choosing bonded exclusions are specified by the user input parameter exclude. The choices for exclusion policy are none, 1-2, 1-3, 1-4, and scaled1-4. With none, no atom pairs are excluded and all interactions are calculated. With 1-2, only atoms that are connected via a linear bond are excluded. The 1-3 policy excludes pairs of atoms that are connected via a linear bond to a common third atom, as well as those excluded by the 1-2 policy. The 1-4 excludes atoms that are connected via three bonds, as well as those covered by the 1-2 and 1-3 policies. The scaled1-4 policy is similar to the scaled1-4 policy, except it applies a scaling factor to the forces between atoms connected by three bonds.

Switching Functions

Truncation of the electrostatic and van der Waals forces is handled in one of two ways by fmd. The default way is to simply set the force and energy to zero (truncate) if the interaction distance between two atoms is greater than that specified by the user input parameter keyword cutoff. If the interaction distance is less than cutoff, the forces are calculated as usual. This method leads to discontinuity in the force field, however. As the interaction distance between two atoms changes from greater than to less than cutoff, the electrostatic and van der Waals energies suddenly jump from 0 to some finite value.

The other means of dealing with truncation in fmd is via switching functions. These functions are designed to bring the forces and energies smoothly to zero at the cutoff distance over some user specified interval. This reduces the discontinuity effects introduced by truncation, but does not fully eliminate them. The switching functions used are equivalent to those used in the xplor program when the VSWitch and SHIft options are specified. In fmd, switching is controlled by the user input parameter switching.

There are different switching functions used for the electrostatic and Van der Waals interactions. For the electrostatic interaction, the energy function is modified to be: (see equations in printed manual)

For van der Waals interactions, the energy function is modified to be: (see Postscript version for equations) where SW is the switching function defined as: (see Postscript version for equations) where R_on is a constant set by the user input parameter switchdist, and R_off is specified by the parameter cutoff.

Since the energy functions are modified by multiplying by a function of r, the forces applied are also affected. The electrostatic force under switching becomes: (see Postscript version for equations)

Similarly, the van der Waals forces are modified to be: (see Postscript version for equations)

Bonds

Bonds describe the connection between two atoms. The bonds are modeled as springs, so the energy between any two atoms i and j is given by: (see Postscript version for equations) where k is the spring constant and r_o is the rest distance. These constants are read from the parameter file.

The force for a bond is found by differentiating the equation, giving: (see Postscript version for equations)

Angles

Angles describes the interaction of two atoms connected to a common third atom. The two atoms are modeled by a spring dependent on the angle between them. If the atoms are identified by i, j, and k, with atoms i and k connected to atom j, then the energy is given by: (see Postscript version for equations) where (see Postscript version for equations) are the spring constant and rest angle, respectively. These constants are read from the force field parameter file, and must be specified for each unique interacting pair. The angle, Theta_ijk is calculated from the equation: (see Postscript version for equations)

In order to determine the forces acting on the three atoms involved an angular bond, the gradient of the energy function must be determined. The derivation begins with the following: (see Postscript version for equations) For convenience, let (see Postscript version for equations) Then the reader can easily show that: (see Postscript version for equations)

Dihedrals

Dihedral and improper dihedral angles model the interactions between 4 bonded atoms. They are modeled as a torsional spring between the planes formed by the first three atoms and the second three atoms. The energy for a dihedral or improper dihedral angle between atoms i, j, k, and l is given by: (see Postscript version for equations) where k is the torsion spring constant, Phi is the angle between the plane formed by atoms i, j, and k, and the plane formed by atoms j, k, and l; n is the periodicity constant for the bond specified; and Delta is the bond's phase shift constant. These constants are all specified in the force field parameter file. The angle is calculated from: (see Postscript version for equations)

To determine the force, the negative gradient of the energy must be found. It can be shown that: (see Postscript version for equations) where (see Postscript version for equations)

Using the formula given for Phi above, the gradient is given by: (see Postscript version for equations) But, this can lead to a singularity if sin(Phi) goes to 0. Therefore, following the method used by xplor, if sin(Phi) is nearly 0, then a third vector is defined by: (see Postscript version for equations) and given a new angle, sin(Psi) between (see Postscript version for equations) then the following can be shown to hold: (see Postscript version for equations)

By the expressing the vectors in terms of the coordinates of atoms i, j, k, and l, the forces can be expressed in one of two ways. In terms of the first formulation using vectors (see Postscript version for equations) the forces are given by: (see Postscript version for equations)

The second formulation is in terms of the vectors (see Postscript version for equations)

This formulation gives the forces as: (see Postscript version for equations)

Harmonic Constraints

Harmonic constraints provide a mechanism for holding certain parts of a molecule relatively immobile during a simulation. Specified atoms are allowed to move about a reference position under a harmonic force law. The constraint energy is given by: (see Postscript version for equations) where (see Postscript version for equations)

Once again, differentiation gives the force due to the constraint: (see Postscript version for equations)

The reference positions, force constraints, exponent, and atoms which are to be constrained are defined by the user using several input keywords. The keywords of interest include constraints, consexp, conskfile, conskcol, and consref.

Spherical Boundary Conditions

The spherical boundary conditions in fmd allow a molecule to be confined to a spherical region of space using a harmonic force near the surface of the sphere. One or two constraint functions may be applied. If two constraint functions are applied, and one is negative, a surface tension condition can be simulated. The potential energy equation takes the same form for each potential specified: (see Postscript version for equations) where (see Postscript version for equations)

Differentiating the potential equation gives the force equation:

(see Postscript version for equations)

A positive force constant will cause a force that moves atoms back towards the center of the sphere, and a negative force constant will force atoms away from the center of the sphere. Values of 2 or 4 are the only ones considered reasonable. The Combination of a negative 2 exponent with a positive 4 exponent, and suitably chosen force constants, can create a potential well near the surface of the sphere, simulating a surface tension effect.

The sphere may be automatically centered about the center of mass of the molecule, or may be specified by the user. The force constants, radii, and exponents for the potentials are defined by user input. The keywords of interest include sphericalbc, sphericalbck1, sphericalbcr1, sphericalbcexp1, sphericalbck2, sphericalbcr2, sphericalbcexp2, and sphericalbccenter.

Integrating the Equation of Motion

Integration of the equations of motion uses the velocity form of the Verlet, or leapfrog, method. Beginning at time step n, and given the mass (M), position (X), velocity (V), and force (F) acting on each atom, the following equations are used to obtain values for the next time step: (see Postscript version for equations)

While this is the most natural way to state the method, this is not actually the order things are performed in fmd. Instead, a normal time step will center velocities in time as follows: (see Postscript version for equations)

In order to keep the interface with the rest of the program more natural, the velocities at the half time step intervals will be stored internally in the Integrate object, and the velocities used by the rest of the program will be the velocities at each time step boundary.

There are slightly different formulations of the Verlet algorithm that rely on centering the positions in time, but it is felt such formulations suffer from a higher degree of round-off error than the velocity formulation.

Minimization

A fairly simple depth-first search is used to perform energy minimization. This method uses a modified form of the Verlet algorithm described in the Integration section above. The algorithm is modified in two ways. The first is that the velocity of the particles is set to zero after each time step. This means that direction of movement of each particle during an integration step will always be in the direction of the gradient, thus creating a depth-first search. The second modification is to place a bound on the movement of an atom during any time step, since a structure with very high potential energies may experience very rapid movement of its atoms during the beginning of minimization. The amount of movement per time step can be specified with the user input keyword maximummove. If no value is specified, a default value will be assumed as given by:

       0.75 x pairlistdist
       -------------------
          stepspercycle

which will insure that no atom can move more than 3/4 of the pairlist distance during a cycle. If greater accuracy in the energy calculation is desired, then maximummove should be set to a value smaller than this.

Langevin Dynamics

Simple Langevin dynamics can be performed with fmd. This consists of adding a random force and subtracting a friction force from each atom during each integration step. The random force is calculated such that the average force is zero, and the standard deviation is: (see Postscript version for equations) where (see Postscript version for equations)

The friction force that is applied is given by: (see Postscript version for equations)

In order to apply these forces, fmd uses the same third-order finite difference approximation in dt as does xplor. This approximation uses the following equations to update the atom positions and velocities: (see Postscript version for equations)

Velocity Rescaling

Equilibration to a desired temperature is performed by periodically rescaling the velocities of all particles such that a specified temperature , set by user input keyword rescaletemp, is achieved. This rescaling is accomplished by first applying the integration scheme to obtain a set of velocities for time step n. These velocities are then rescaled to the desired temperature by multiplying by a factor given by: (see Postscript version for equations) where (see Postscript version for equations)

Temperature rescaling will work with either normal dynamics or with Langevin dynamics. The number of time steps between rescalings is specified using the input keyword rescalefreq.

Units and Constants

This section presents the units and constants which appear in fmd. Some handy conversion factors are also presented.

Units

    Measure       Units
    ============================================================
    Length        Angstroms  (1.0e-8 m)
    Time          femto-seconds  (1.0e-15 s)
    Energy        Kilocalaries per mole  (2.3885e-04 J per mole)
    Mass          Atomic mass units  (1.660440e-24 g)
    Charge        Electron charge
    Temperature   Degrees Kelvin

Constants

    Name                    Value
    ==========================================================
    Boltzman's Constant     1.987191e-3 KCal/(mol degree-K)
    Avogadro's Number       6.022045e23 1/mol
    Coulomb's Constant      332.0636 (KCal Angstrom)/(mol e^2)
    Electron Charge (e)     1.6021892 Coulombs
    Pi                      3.1415926535898

Conversion Factors

    1 Kcal     = 4184.0 Joule
    1 AMU      = 1.6605655e-27 Kilograms
    1 Angstrom = 1e-10 Meters

Program Design Considerations

fmd uses a multi-threaded, message driven design built on top of a spatial decomposition of the molecular system to provide a high performance, scalable parallel application. This section contains a description of all aspects of this design and why it was used.

Process Description

fmd is a parallel message passing program. It consists of P processes, where P is the number of available processors. The process that resides on logical node 0 is referred to as the master process. It has responsibilities beyond those of the other processes for such things as startup, shutdown, I/O, and other tasks.

Communication between processes is accomplished using a Communicate object that resides in each process. This Communicate object provides an interface between the other objects in fmd and the actual message passing system being used. Thus, fmd can be ported to any message passing system by modifying the Communicate class. Currently, only MPI is supported by fmd. However, namd, the code from which fmd was derived, supports PVM.

Decomposition

The parallelization strategy of fmd is based on spatial decomposition. The space occupied by the model is divided into cubes of space called patches. Each patch has dimensions which are the electrostatic cutoff distance plus a small safety margin. These patches are assigned to physical processors in a many to one relationship. That is, multiple patches may be assigned to any given processor. Thus each process can be thought of as being a pseudo multi-threaded process, where each thread of control is a patch. As the simulation progresses, the number of patches assigned to each processor and the location of each patch will be dynamically adjusted to provide load balancing.

The mapping of patches to processors will be managed by a PatchDistrib object located on each processor. When a patch wants to send a message, it will first query the PatchDistrib object to determine the processor that the patch resides on. The patch will then send this message to the communicate object with both the appropriate patch and processor ID. Also, each message will have a tag specifying the purpose of the message and a time step identifier, to insure that if one patch gets ahead of other patches, messages will not be incorrectly used for the wrong time step.

Communications per Time Step

Each patch will be responsible for the atoms within its region of space. This means that it is responsible for storing the current position and velocity of each of these atoms, as well as gathering/computing all of the forces necessary to perform integration during each time step.

In order to gather and calculate the necessary forces, each patch will have to communicate with its neighboring patches. This communication will take place in cycles. Any patch reassignment occurs at the beginning of a cycle. At this time, any explicit calculation of long range forces are also accomplished. During the first time step after this reassignment, each patch will be responsible for again determining the interactions that it has with each neighboring patch.

Each patch is responsible for calculating all local electrostatic, van der Waals, and bonded interactions. These are interactions which involve only local atoms and therefore don't require any communication of coordinates. Each patch is also responsible for calculating the bonded forces for any bonds which contain any local atoms. This requires the atom coordinates from neighboring patches for any atoms involved in bonds with local atoms. This scheme also involves the duplicate calculation of these forces rather than the use of Newton's Third Law to reduce the computation. Due to the small number of these interactions and the sizeable complexity in dealing with all the possible combinations of atoms, bonds, and patches (consider a dihedral bond with each of its four atoms in a different patch), it is thought that this duplicate calculation does not result in significant overhead. Lastly, each patch is responsible for calculating the electrostatic and van der Waals forces between its local atoms and the atoms from some of its neighboring patches. These forces are then communicate back to the neighboring patches to exploit Newton's Third Law. The electrostatic forces between the local atoms and the rest of its neighboring patches will be calculated by the neighboring patches and the resulting forces will be sent back by those patches.

The PatchDistrib class will be responsible for maintaining a list of neighboring patches for each patch, and also assigning the communication direction between each pair of patches. Therefore, at the beginning of each time step, each patch will receive two lists of neighbors from the PatchDistrib object. One list will contain the neighboring patches that it will receive all atom coordinates from and the other will contain the neighboring patches that it will send all atom coordinates to. From the patches that the patch sends all of its atom coordinates to, it will receive coordinates for atoms participating in bonded interactions with its atoms. The determination of the direction of the communication between patches is part of the load balancing algorithm. The Figure 1 shows an example of patch assignments.

To try and overlap communication and computation as efficiently as possible, every calculation, including local interactions, will be triggered by an incoming message. To insure that messages will be handled in the most efficient manner, the messages will be prioritized. The highest priority messages will be those containing coordinates for electrostatic coordinates from other nodes. These messages will require calculation, and then an interprocessor message. The next most important is electrostatic coordinates from a local patch, since they will require a local communication. Next will be messages containing bonded coordinates, since they will require calculation, but no return messages. The messages containing forces calculated by a neighbor patch will be next, since these messages will again require calculation with no communication. The least important messages will be the messages sent from a patch to itself to trigger either local force calculation or integration, since these will required only local computation, without even the receipt of incoming coordinates.

Figure 1: Example of Patch Assignments to Processors

Communication Example

As an example, consider the two dimensional patches shown in Figure 2. Patch 5 would send all of its atom coordinates to some of its neighbors, say Patch 2, 3, 6, and 9. It would receive all of the coordinates from Patches 1, 4, 7, and 8. Based on the atoms received from Patches 1, 4, 7, and 8, Patch 5 would calculate the atoms that it needed to send to these patches so that they could compute their bonded interactions, and send these coordinates every time step. So during each time step, Patch 5 would send out atom coordinates to all 8 neighbors. To Patches 2, 3, 6, and 9, it would send all of its atom coordinates. To Patches 1, 4, 7, and 8, it would only send those coordinates necessary for bonded interactions. Patch 5 would expect to receive atom coordinates from all 8 neighbors. From Patches 2, 3, 6, and 9, it would only receive the coordinates necessary for bonded interactions. These coordinates would be used for force calculations and then discarded. No force messages would be sent back to these patches. From Patches 1, 4, 7, and 8, Patch 5 would receive all atom coordinates. Bonded, electrostatic, and van der Waals forces would be calculated, and the electrostatic and van der Waals forces would be communicated back to these patches. Patch 5 would also expect to receive a force message containing electrostatic and van der Waals forces from Patches 2, 3, 6, and 9.

Figure 2: Example Patch Communication

Load Balance

The PatchDistrib object will also be responsible for gathering load statistics for each node. Periodically, this data will be used to redistribute patches to maintain load balance among processors. For the first implementation, this reassignment will be done by sending all of the information to the master process which will determine what reassignments should be done. To avoid this becoming a point of synchronization, the data will be gathered during each cycle, but not used until the next cycle. For example, if each cycle consists of 10 time steps, then the data sent during time step 10 will be used to determine the redistribution that will occur at time step 20. It this system is found to be too slow, then statistics being sent and the reassignment being passed out can be staggered by 1 cycle. For example, if each cycle consists of 10 time steps, then at step 10 statistics would be sent in, and at step step 20 a reassignment would be passed back out. At step 30, statistics would be sent in, and at step 40, another reassignment would be sent out. The reassignments will include not just the movement of patches between processors, but also the switch of the communication direction between patches. A simple algorithm for this is if neighboring processors vary in time more than 25%, then a patch is exchanged between them. If the difference is less than 25%, then just the direction between patches would be changed until no more directions could be altered, then the patch would be exchanged. Also, there would have to be some logic to avoid moving the last patch off a processor, since this would definitely not help load balancing.

Node Algorithm per Time Step

The following is the logic that each processor will follow during a time step:

    for ( all patches )

    // This next will send out coordinate messages as well as send
    // a message from each patch to itself telling it to perform
    // the local force calculation.

    patch->send_messages ();

    while ( not all patches are done )
      {
         receive_msg ( msg );

         // patch->process_msg is the message processing routine for
         // for the appropriate patch.  Incoming messages will be one
         // of the following:
         //       * All coordinates
         //       * Bonded coordinates
         //       * Electrostatic and vdw forces
         //       * Local force self message
         //       * Integration self message

         patch->process_msg ( msg );

         // total_energies gets the energy totals from each patch and
         // sends it off to the master process for output.

         total_energies ();

         // Check the time step and send out the positions and/or
         // the velocities to the I/O object for output to the
         // trajectory files.

         if ( timestep matches frequency )
            send_pos_and_vel ();
      }

Node Process Design

Each node will have the following objects:

PatchList
This is the set of patch objects that currently reside on this processor.
Molecule
These are the parameters that define all the constants, bonds, and explicit exclusions for the model.
PatchDistrib
This object specifies what processor every patch in the system resides on, as well as the x, y, and z coordinates of each patch. It is also responsible for maintaining the neighboring patch list for each patch, and the redistribution of patches according to the load statistics.
I/O Mechanism
This object will be responsible for writing out things like the restart files and trajectory files. For the first implementation, this object will probably just send all of its information to the master process which will do the actual output. By isolating the I/O into its own class, parallel I/O could be done at a future date if possible/desired.
SimParameters
These are the global simulation parameters, such as the time step size, cutoff separation values, etc. This data is static. It is read by the master process and distributed to the other processes via messages.
Reassignment Object
This object will be responsible for gathering load statistics and participating in the reassignment of patches to processors. For the first implementation, this object will probably just send all of its data to the master process which will determine how to reassign patches, but by separating it out, it will be easier to implement a distributed reassignment algorithm in the future, if so desired.

Patch Structure

Each patch will have the following objects or data structures:

Coordinates
The coordinates of all local atoms
Velocities
The velocities of all local atoms
Forces
The forces acting on all local atoms
Set of Force Objects
These objects will be responsible for calculating the forces for various types of interactions, such as bonded, electrostatic, constraint, etc. Each object will hold the data necessary for computing it's particular type of interaction, such as pairlist for electrostatics, or a bonded list for bonded bond interactions. A description of the general interface for these objects is given in the Force Object Interface subsection below.
Integrator
This may or may not be an object, but will definitely provide a way to integrate the local atoms.
List of Neighboring Patches
This list allows the patch to know who it's neighboring patches are and what their patch identifiers are.

Force Object Interface

Each force object will have a set of interface routines that will basically perform the following functions:

Local Initialization
Given the local atoms, set up any data structures that will be necessary for computing the local interactions of the force being calculated, and then calculate these forces. Examples of the data structures that may need to be built include pairlist for electrostatics and a bond list for bond interactions.
Neighbor Initialization
Given the local atoms and a set of atoms from another processor, set up any data structures necessary and then compute the forces. This is basically the same as Local Initialization above, except that the atoms involved in the interactions are now from another processor. Also for the bonded force object, this routine will have to produce a list of local atoms that need to be sent to the neighboring patches so that they can complete their bond calculations.
Local Force Calculation
Given the local atoms and that Local Initialization has been done, compute the forces due to local interactions.
Neighbor Force Calculation
Given the local atoms, a set of atoms from a neighboring processor, and that Neighbor Initialization has been performed for this neighbor, compute the forces due to interactions with this neighbor.
Energy Calculation
Return the energy for this type of interaction for the current time step. This is probably not as much of a calculation as it is a reporting of an energy sum that has been kept during all of the force calculations.
Clean Up
Clean up any data structure that were built. This may be accomplished by freeing and reallocating force objects at each reassignment.

Full Electrostatics

fmd is able to calculate all electrostatic interactions. Two methods are provided for:

The full electrostatic calculation, whether using the full direct or a fast method, is organized within fmd on a per-node basis, in contrast to most other calculations in fmd, which are organized on a per-patch basis. In other words, there is one instantiation of the full-electrostatics class on each node. The interface between the patches and the full-electrostatics object on a node is handled as follows:

The FullDirect class uses the fmd messaging system, and expects fmd to call it with incoming messages for it. Fast methods are expected to do their own message-handling, and keep their messages separate from fmd's (e.g., by using different message type IDs.) Moreover, if the spatial decomposition used by the fast method does not happen to coincide with how the atoms are assigned to nodes, it is FMAInterface's responsibility to move the coordinates to and the forces from the appropriate nodes.

Due to the high cost of a single full electrostatics calculation, regardless of what method is used, electrostatic forces are incorporated using a multiple time step integration scheme. In this scheme, short-range electrostatic forces are directly calculated every time step. Every k'th time step, the full electrostatic algorithm is used to compute the remaining, or long-range, electrostatic forces. These values are then added to the short-range forces during each of the next k time steps. While these forces will become more and more inaccurate as k becomes larger, it is felt that the inaccuracies that are introduced are significantly less than those introduced by the discretization to a finite time step, provided the criterion which defines "short-range" is chosen sufficiently large.

The program on which fmd is based, namd, incorporated the Distributed Parallel Multipole Tree Algorithm (DPMTA) implementation of the FMA, which was developed by the Scientific Computing group at Duke University. The DPMTA library utilized PVM. The decision was made to build fmd on MPI, and adopt the Fast Multipole Method in Three Dimensions (FMM3D) implementation developed by the Air Force Research Laboratory (see section References), Wright-Patterson AFB, OH. The following subsection describes FMM3D and the version of the FMA interface used with FMM3D.

Partitioning of Forces into Long- and Short-Range

At each beginning-of-cycle step, the set of all possible pairs of atoms are split into short- and long-range. Those pairs of atoms with the two atoms closer than some @i{r(short)} are considered to be short-range interactions, and are are entered into a pairlist. This pairlist specify the interactions that are to be recomputed every timestep.

Note that this means that by the end of a cycle, some "long-range" atom pairs may in reality be closer than many "short-range" pairs. However, the force between these atoms will remain the same, as if they had not moved at all.

FMM3D Summary

The FMA is based on the idea of using power series to handle groups of long-range interactions and using Coulomb's law directly, referred to as the direct method, for handling the short-range interactions. More specifically: a cubic domain enclosing all the charges is divided up into 8^L smaller cubes, or cells. The partial electrostatic field within a given cell due to all charges within all "sufficiently distant" cells is represented by a local expansion, which is a power series in (r - c), where c is the center of the cell. Thus, the forces on a charge in the given cell due to charges in distant cells may be computed by evaluating the field at the location of the given charge. Forces due to charges the same or nearby cells are explicitly computed using the direct method.

The use of power series introduces one user-specified parameter: @i{p} , the order of accuracy for the series. The number of terms is O(@i{p}^2) , while the relative error is O((epsilon)^@i{p}) , where (epsilon) is a constant that depends on certain design decisions in the implementation. The choice of @i{p} is a trade-off between accuracy and execution speed.

p is specified by the user input parameter FMAmp.

To compute the local expansions, the FMA first computes for each cell a multipole expansion, which is essentially a power series in 1/(@b{r}-@b{c}) ; in contrast to a Taylor series, this series converges faster the farther r is from c. The multipole expansion represents the electric field far from its cell due to charges inside its cell.

The local expansions are then computed from the multipole expansions using a multi-scale approach whose computational cost is asymptotically proportional to the number of cells. This phase of the calculation, called the translation phase, requires a hierarchy of divisions into cells. The whole domain is the single level-0 cell. It is divided into 8 level-1 cells. Each level-1 cell is then divided into 8 level-2 cells, giving 64 level-2 cells altogether. This continues down to level L. (This is why the number of cells must be a power of 8.)

The choice of L does not (in principle) affect the accuracy, but it does affect the computational cost. The direct phase of the calculation costs roughly O(N^2 / 8^L) , while the translation phase is O(8^L f(p)) . L must be chosen to minimize their sum (the other phases are essentially independent of L), which in practice means to make the cost of the two phases roughly equal. Since changing L by one changes the cost of each by a factor of roughly 8, "roughly equal" means "within a factor of 10" or so.

L is specified by the user input parameter FMAlevels

Internal Detail -- Neighborhoods and Interaction Lists

An important design decision in an implementation of the FMA is the criterion for nearby vs. distant cells.

We refer to those cells that are near to a certain cell (including the cell itself) as the cell's neighborhood. One possibility is to use a 5 x 5 x 5 cube of cells with the specified cell in the center. Others include using a 3 x 3 x 3 , or all cells whose centers are within a specified number of cell widths from the center of the specified cell. Note that the dimensions of a neighborhood are always relative to the size of the cell it belongs to.

The choice of neighborhood involves a trade-off. The larger the neighborhood, the smaller (epsilon) will be, and the smaller p needs to be for the local expansions to attain a specified order of accuracy (thus reducing the computational cost), but the more interactions have to be handled by the direct phase.

Figure 3: Multi-scale approach to translations


The same consideration applies to the translation phase. The local expansion for some cell on some level i uses the local expansion for its parent cell, i.e., the level-i-1 cell that it lies in, the expansion being translated, or adjusted to account for the different cell center. However, since the parent cell's neighborhood is larger than the child's (the level-i cell's), using the parent cell's expansion alone would ignore the field due to charges that are in the parent's neighborhood but not the child's. Contributions to account for this must be added to the child's local expansion. The FMA uses the multipole expansions from cells covering this in-between region, the region that is in the parent's neighborhood but not the child's. The set of such cells for a given cell is called the cell's interaction list.

Figure 3 shows how this works. The cell with center P is the parent cell, the white and dark grey regions are its neighborhood, and the light grey region shows the cells whose charges contribute to its local expansions. The dotted lines show the division into child cells: the letter C is at the center of the child cell of interest, and the white region is C's neighborhood. The dark grey region is the region whose charges' electric field must be added to P's local expansion to get C's local expansion.

The effect on the cost is obvious: the larger the neighborhood, the larger will be the interaction list, and the larger the cost.

There is another design decision here. If the cells covering this in-between region include 8 children of a common parent cell, the multipole expansion for the parent may be used instead of those for the 8 children, for a reduced cost and increased (epsilon) . Figure 3 shows 16 such parent cells. (In the 3-dimensional version of figure 3, there are 98.)

FMM3D allows for a number of neighborhood-interaction list combinations, through the IPARAM argument. This argument cannot be set through a user input parameter, but can be changed by modifying the interface routine fmd_to_fmm3d (in the file fmd2fmm3d.c.) Some documentation is provided in the source code in the file fmm3d.c.

Design Decisions in FMM3D

In this section are briefly discussed some design decisions in the writing of FMM3D. Most are based on the expectation that FMM3D would be used in molecular dynamics applications.

The force parameters and other quantities used in molecular dynamics are not known to high accuracy; in addition, the approximations made in reducing the more complex quantum chemical behavior to a ball-and-spring model limit the accuracy obtainable. Thus, it was assumed that relatively small values of p would be used, typically in the range 4 to 10. This lead to the following decisions:

  1. For this range of p values, the FFT-accelerated FMA [GR 1988, "On the Efficient Implementation of the FMA"] is as fast or faster than the original three-dimensional FMA as described in [GR Vortex Methods]. The full source code of FMM3D allows for both the original ("slow") version, as well as the FFT-accelerated ("fast") version, plus a faster version of the original version (the "medium" version); however this choice must be made at compile time. As distributed with fmd, FMM3D is set to always compile to the fast version, and does not include those files that are used only by the other versions.
  2. In G & R's report on the FFT-accelerated method, they mention that the method is ill-conditioned: as p is increased, the accuracy first increases as the expansions converge, but then decreases, as round-off error begins to dominate. G & R's work-around is to use a "blocked" version of the method. Our experience is that for the range of p values mentioned above, round-off error is not significant. Thus, FMM3D does not implement blocking.

In chemical applications, the charge density does not vary greatly: there are regions with no atoms, and regions where there are atoms, and the atom density does not vary by more than a factor of 4 or so.

  1. For this reason, FMM3D does not use an adaptive version of the FMA, e.g., a 3-dimensional version of the 2-dimensional method described in [Carrier, Greengard, & Rokhlin].

Those who study the FMM3D source code will note that it includes facilities for computing van der Waals forces and excluding certain interactions. fmd is not set up to use these facilities, so the interface sets the input arguments to FMM3D to turn them off.

Tricks in FMM3D

Here are some brief notes on some details of the implementation.

Choosing Parameter Values for FMM3D

The following section describes some strategies for choosing good FMM3D parameter values.

FMAmp
This parameter should be set to attain the desired relative accuracy. Figure 4 shows the relationship between relative error and p for a typical case. Using a value of 6 gives about 4 decimal places of accuracy.

Figure 4: Typical Relative Error vs. p

FMAlevels
As mentioned in previous sections, this should be chosen to make the direct and translation phases roughly equal in cost. The total time and the times spent in each of the seven steps within FMM3D are show on output lines beginning with "FMM3D: CPU =" and "FMM3D: EL.=". These costs are directly related to the time taken to execute each phase, and are summarized in a group of output lines beginning with "FMM3D: Total Times". They show the total CPU and elapsed times in the translation and direct phases. If the total time in the translation phase is more than 10 times larger than the time in the direct phase, a hint is issued to reduce FMAlevels by 1 (the suggested value is given). On the other hand, if the translation phase time is less than 1/10 that of the direct phase, a hint is issued to increase the value of FMAlevels by 1 (again the value is given). There is no good rule for choosing a reasonable value of FMAlevels to start off with, as this is not only very problem-dependent, but also very computer-dependent. A value that is perfect for a certain calculation on an IBM SP2, for instance, results in the two FMAlevels-dependent phases differing by a factor of over 20 on an Intel 80x86 architecture. Experience so far has been that a value of 3 for problems under about 5,000 atoms and a value of 4 for larger ones generally does not cause FMM3D to run more than an order of magnitude or so slower than optimal. Values larger than 5 should be used with caution, as they will probably cause fmd to run out of memory.
StepsPerCycle
This is mentioned here because this parameter controls how often FMM3D is called. The choice of value involves another trade-off:
  1. smaller values of StepsPerCycle increase the cost of the calculation, but
  2. larger values allow the long-range forces to be less consistent with the atom positions. In extreme cases, a pair of atoms that are "long-range" can approach to closer than a van der Waals radius, with disastrous effects on the calculation.
FMAOn
This should always be set.

Design Decisions

This section contains design decisions that have been made for fmd that do not fit into other sections. Right now, this section is just a list of those decisions that are kept here to make sure they don't get lost. Hopefully, they will eventually become part of a more elegantly designed section.

Nitty-Gritty

fmd source files are kept in a CVS repository. The cvs command checkout will build a set of working files for you. If you are only interested in building an executable, you are referred to the Installation chapter of the User's Guide.

Source Tree Structure

The directory tree for fmd consists of a project directory containing configuration files and several subdirectories containing source files and architecture specific files. Here is what the directory tree looks like:

    ./FMD
    `-----ARCH
     |     `-----alpha-dec-osf4.0
     |     `-----t3e-cray-unicosmk2.0
     |     `-----mips-sgi-irix5.3
    `-----Data
    `-----Docs
     |     `-----Info
    `-----Misc
    `-----Src
     |     `-----Docs
     |     `-----FFT
     |     `-----FMD
     |     `-----FMM3D
     |     `-----Include
     |     `-----Misc
    `-----Validation
     |     `-----Canonical
     |      |     `-----P
     |      |      |-----`vr_00
     |      |      |-----`...
     |      |      |-----`vr_nn
     |      |     `-----S
     |      |      |-----`vr_00
     |      |      |-----`...
     |      |      |-----`vr_nn
     |     `-----Data
     |     `-----Jobs
     |      |     `-----P
     |      |     `-----S
     |     `-----Runjobs
     |      |     `-----LAM

The most important files in the project directory are the make and configuration files. These are discussed fully in the User's Guide. The GNU Autoconf program is used to generate the configure script, capturing all the architecture specific information needed for the programs to run on a variety of different workstations. The subdirectory ARCH should contain subdirectories with libraries and binaries built for various platforms. The contents of this directory may vary from installation to installations, depending on how the system manager has decided to install the programs, and what architectures are available.

The Data subdirectory contains sample user input files, PDB, PSF, and parameter files for several different models. The subdirectory Docs should contain Postscript versions of the User's Guide, Programmer's Guide, and Quick Reference Guide. It also contains a subdirectory called Info, with GNU-info formatted on-line documentation.

Src is the most important subdirectory for programmers, as it contains all of the source code necessary to compile fmd. Docs contains TeXinfo source files for producing printed or info documentation. The fig source files are also provided for generating the figures used in the documentation. The Quick Reference Guide is formatted as as plain TeX file. The FFT subdirectory contains the double precision version of FFTPack obtained from Netlib. FMD contains the fmd main source files, which FMM3D contains the Fast Multipole Method in 3D library files. Include contains all of the header files used in the system. Misc gathers all of the unusual files, such as GAWK scripts and other such things that aid in the building the distribution for a given system.

Style Conventions

CVS Keywords

Each file in the source directories begins with revision information and comments in the first few lines. Here is an example from the fmd.C file:

/*  $RCSfile: fmd_pg.texi,v $		-*-Mode: c++;-*-

    fmd - Fast Molecular Dynamics program
 
    $Revision: 1.46 $
    $Date: 1999/12/03 15:59:58 $

The first line should contain the RCSfile CVS keyword. Optionally, it may contain a GNU emacs mode flag so the emacs editor will enter the correct editing mode when the file is read. This is followed by comment lines which provide a basic description of what the file is for. Following these are two lines, one with the Revision CVS keyword, and the last with the Date CVS key word. Additional comments may follow this. A file revision history placed at the end of each file. This makes it much easier to scan a file for information without having to wade though a lot of change history. The revision history section in a make file looks like:

###################################################################
#
#  Revision History:
#
#  Log: fmd_pg.texi,v
#  Revision 1.14  1997/07/14 17:21:25  lupoja
#  Added BufferMPI description.
#
#  Revision 1.13  1997/07/10 13:58:31  lupoja
#  Added notes on FMM3D.
#
#  Revision 1.12  1997/07/08 18:49:04  lupoja
#  Consistent handling of iftex, ifinfo and ifhtml.
#
#  Revision 1.11  1997/07/07 15:52:09  lupoja
#  Added ifhtml conditionals to include GIF images of figures in the
#  HTML versions of the online files. - J. Lupo
#
#  Revision 1.10  1997/06/13 15:03:53  lupoja
#  Using email.texi to encapsulate response address.  Changed
#  installation instructions to reflect change from M4 to Autoconf.
#
#  . . .

Note that when adding files to the CVS repository, it is not necessary to specify what or if a comment character is necessary. CVS is smart enough to figure this out for itself.

File Names

Header Files

All .c and .C files should have a corresponding .h . With C++, however, it will be possible to have a header file without a corresponding .C file. All code in a header file should be placed between a security wrapper to prevent multiple inclusion. This would look like:

        #ifndef _HEADER_ID_
        #define _HEADER_ID_
        . . .
        #endif

Source Code Names

This table describes how various constructs in c and C++ source files should look.

Class Names
C++ classes should be defined in unique files, if possible, and have the same name as the file they are in. Thus, use the same naming convention for classes as for files.
Class Member Names
Variables which are members of a C++ class should start with a lower case letter, have every OTHER word in the name capitalized, and not use hyphens or underscores. An exception is single-word variables, which may start with a capital if preferred. Examples: bondLength, coorFilename, and Size.
Global Variables
Variables global to fmd (error and info message objects, etc.) should have fmd prepended to them. Example: fmdInfo.
Class Function Names
Functions which are members of a C++ class should all be in lower case, and use hyphens to separate the words in the name. Example: real bond_length (). Accessor functions which get and set a single item in a class should both be named the same, one with the relevant return type and no argument, one with relevant argument and either void return type or success (ie. T/F) return type. Example: float length(void); and void length(float). Accessor functions which get/set multiple items should have one named 'set_item' and the other 'get_item', where 'item' is whatever is being accessed.
Global Function Names
Functions global to fmd should have "fmd_" prepended to them. Example: fmd_die().
Macros
Macros should be in ALL CAPS.

User Parameters

fmd has a wide variety of parameters that the user can set at startup to control fmd's behavior. These options and variable settings determine the exact behavior of fmd, which features will be active or inactive, how long the simulation will run, etc. This section describes syntax expected, and what settings are available.

User Input File Syntax

Each line in the user input file consists of a keyword identifying the option being specified, and a value which is to be assigned to the option. The line can take one of two forms. The keyword and value can be separated by only white-space (ie. spaces and/or tabs), such as:

    keyword    value

or they can be separated by an equal sign and white-space, such as:

    keyword =  value

Blank lines in the file are ignored. Comments are prefaced with a pound sign (#), and may appear at the end of a line with a keyword- value pair:

    foo =      value1
    bar =      value2  # Here is a comment
    fie =      value3

    # Skip comment lines like this one or blank lines

It is important to note that keywords are case insensitive. Hence, entries such as coorTrjFile and coortrjfile are recognized as the same keyword. However, values ARE case sensitive. This is particularly important when you specify file names, as they must be written exactly as you expect to find them. There is one exception. The toggle values of off and on may be written with any capitalization desired.

Required User Parameters

This sections describes those options which a user is required to set. They define the most basic properties of the simulation to be performed.

NumSteps
Usage: Number of time steps
Acceptable Values: Any positive integer
Description: The number of simulation time steps that should be performed. The total amount of simulation time is numsteps x timestep.
Coordinates
Usage: name of PDB coordinate input file
Acceptable Values: Any legal UNIX filename
Description: The name of a file from which the initial atomic coordinates and data will be read. This can be an absolute path name, or a path relative to the directory from which fmd is executed. Only one file name may be specified.
Structure
Usage: name of PSF molecular structure file
Acceptable Values: Any legal UNIX filename
Description: The name of the PSF file from which the molecular structure will be read. This can be an absolute path name, or a path relative to the directory from which fmd is executed. Only one file name may be specified.
Parameters
Usage: name of force field parameter file
Acceptable Values: Any legal UNIX filename
Description: The name of a file from which the force field parameters will be read. CHARMM19 or CHARMM22 parameters are currently accepted. This can be an absolute path name, or a path relative to the directory from which fmd is executed. Only one file name may be specified per keyword, but multiple parameters keywords may be used to specify several different parameter files, if required.
     parameters  params1
     parameters  params2
     parameters  params3
The files will be read in the order they appear, and warning messages will be printed if duplicated values are found. The last value read is the the value used, so the order in which the files are specified could be important.
Cutoff
Usage: Cutoff, or local, interaction distance
Acceptable Values: float greater than 0, in units of @AA{}
Description: If FMM3D is used, this option defines the local interaction distances. Otherwise, this option specifies the distance at which electrostatic interactions are truncated.
Exclude
Usage: neighbor exclusion policy to use
Acceptable Values: none, 1-2, 1-3, 1-4, or scaled1-4
Description: Specifies which pairs of bonded atoms should be excluded from non-bonded interactions. With the value of none, no bonded pairs of atoms will be excluded. With the value 1-2, all atoms pairs that are directly connected via a linear bond will be excluded. With a value of 1-3, all 1-2 pairs will be excluded, along with all pairs of atoms that are bonded to a common third atom (ie. if atom A is bonded to atom B, and atom B is bonded to atom C, then the atom pair A-C would be excluded). With a value of 1-4, all 1-3 pairs will be excluded along with all pairs connected by a set of two bonds (ie. if atom A is bonded to atom B, and atom B is bonded to atom C, and atom C is bonded to atom D, then the atom pair A-D would be excluded). With a value of scaled1-4, all 1-3 pairs are excluded and all pairs that match the 1-4 criteria are modified. The electrostatic interactions for such pairs are scaled by the factor 1-4scaling. The van der Waals interactions are modified by using the special 1-4 parameters defined in the parameter files.
OutputName
Usage: base name assigned to the output files
Acceptable Values: Any legal UNIX file name prefix
Description: At the end of every simulation, fmd will write out 2 PDB files, one containing the final coordinates of all atoms, and the other containing the final velocities of all atoms. This option specifies the file name prefix that will be used to create the names of the two files. .coor will be appended to the prefix to create the name of the coordinate file, and .vel will be append to create the name of the velocity file. Thus, if one has:
     OutputName = /tmp/my_output
then the coordinate file will be named /tmp/my_output.coor and the velocity file will be named /tmp/my_output.vel. The format of the files may be set by outputformat, as described below.

Basic User Parameters

These are parameters and options that are not required, but will almost always be specified. These, along with the required options of the previous section, form the fundamental options for a simulation.

InitCoordsFile
Usage: Specifies initial coordinates.
Acceptable Values: any UNIX file name.
Default Value: (none)
Description: Specifies a binary or HDF coordinates data file which will override the coordinates found in the "coordinates" PDB file. The acceptable formats are binary, or HDF. If initCoordsFile is specified, coordinates must also be specified.
InitCoordsFormat
Usage: Specify format of the coordinates input file.
Acceptable Values: pdb, bin or hdf
Default Value: bin
Description: Specifies the format of a coordinates data file which will override the coordinates found in the "coordinates" PDB file. The acceptable formats are binary, or HDF.
InitCoordsDataset
Usage: Select HDF dataset from coordinates input file.
Acceptable Values: int >= 0
Default Value: 0
Description: Specifies which dataset should be read from an HDF format initCoordsFile. It defaults to 0. The data is checked to make sure coordinate data is being read. The setting is ignored if binary format is being used.
Title
Usage: Title for job
Acceptable Value: any printable character string
Default Value: none
Description: The string specified here will appear in the printout and in several files, such as the "dcd" and "hdf" format trajectory files.
Title2
Usage: Subtitle for job
Acceptable Value: any printable character string
Default Value: none
Description: The string specified here will appear in the printout and in several files, such as the "dcd" and "hdf" format trajectory files.
TimeStep
Usage: size of the time steps
Acceptable Value: float greater than 0 in units of femto-seconds
Default Value: 1.0 fs
Description: Size of time step to use when integrating each step of the simulation.
Temperature
Usage: initial temperature of the model
Acceptable Value: float greater than 0 in units of degrees Kelvin
Description: Sets the initial temperature for the model. Using this option will generate a random velocity distribution for the initial velocities for all atoms approximating the desired temperature. One of temperature or velocities must be defined to set initial velocities for the model. The options can not be used together. NOTE: if this file represents a continuation of a previous run, FirstTimestep must be set to something other than 0!
OutputFormat
Usage: Specify the format for the output files.
Acceptable Values: pdb, bin or hdf
Default: pdb
Description: By default, the .coor and .vel files written for output (see the outputname keyword) are in PDB format. This keyword allows them to be written in binary or HDF format. Both save space and preserve accuracy. The HDF format is machine independent.
Velocities
Usage: name of a file containing initial velocities for the run.
Acceptable Value: Any legal UNIX filename
Description: A file that contains the initial velocities for all atoms in the model. This is typically a restart file or final velocity file written by fmd during a previous simulation run. One of temperature or velocities must be defined to set initial velocities for the model. The options can not be used together.
VelocitiesFormat
Usage: Specify format of the velocities input file.
Acceptable Value: pdb, bin or hdf
Default Value: pdb
Description: This specifies the format of the velocities file. The bin and hdf formats both save space and preserve accuracy. The hdf format has the advantage of being machine independent.
VelocitiesDataset
Usage: Select HDF dataset from velocities input file.
Acceptable Values: int >= 0
Default Value: 0
Description: Specifies which dataset should be read from an HDF format velocitiesFile. It defaults to 0. The data is checked to make sure velocity data is being read. The setting is ignored if binary format is being used.
COMmotion
Usage: flag to allow center-of-mass motion
Acceptable Value: yes or no
Default Value: no
Description: This option determines if center-of-mass motion will be allowed or removed. If set to yes, center-of-mass motions will be allowed (ie. ignored). If set to no, center-of-mass motions will not be allowed. Once initial velocities are assigned, they will be adjusted so as to remove any center-of-mass rotational and translational motions.
RestartName
Usage: file prefix for restart file names
Acceptable Value: Any legal UNIX file name prefix
Description: Defines a file name prefix used to construct the names of velocity and coordinate PDB restart files. Names are built in the same way as for outputname. That is, .vel is appended to the prefix to create the velocity file name, and .coord is appended to create the coordinate file name. These files specified here differ from outputname files only in the number of times they are written during a simulation. outputname are written at the end of a simulation, restartname are written every restartfreq time step during the simulation. The final restartname files may or may not equal the outputname files. The files may be written in binary or HDF format if restartformat is set, as described below. If restartname is specified, then restartfreq must also be specified.
RestartFreq
Usage: frequency at which restart files are generated
Acceptable Value: integer greater than 0
Description: Specifies the frequency, in time steps, with which restart files are written. In other words, the restart files are rewritten every restartfreq time steps. If restartfreq is specified, then restartname must also be specified.
RestartFormat
Usage: Flag to specify restart file format.
Acceptable Value: pdb, bin or hdf
Default Value: pdb
Description: Specifies if the restart files should be written in PDB, binary or HDF (respectively) format. Both bin and hdf formats preserve accuracy and conserve space. In addition, the HDF format is machine independent.
Dielectric
Usage: dielectric constant for the model.
Acceptable Value: float greater than or equal to 1.0
Default Value: 1.0
Description: Sets the dielectric constant for the model. A value of 1.0 implies no modification to the electrostatic interactions. Any large value was cause a subsequent decrease in the electrostatic forces, scaling as 1/dielectric.
1-4Scaling
Usage: scaling factor for 1-4 interactions
Acceptable Value: float between 0.0 and 1.0
Default Value: 1.0
Description: Sets the scaling factor used for 1-4 interactions. This factor is only used when the exclude keyword is set to scaled1-4. In that case, this factor is used to modify the electrostatic interactions of 1-4 atom pairs. If the exclude parameter is set to anything but scaled1-4, this parameter is ignored.
CoorTrjFile
Usage: name of the coordinate trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name of the coordinate trajectory file. This a trajectory of all atom coordinates in one of two formats: binary DCD, as used by xplor; and NCSA HDF format. If coorTrjFile is specified, the coorTrjFreq must also be defined.
CoorTrjFreq
Usage: frequency in time steps for writting data to coordinate trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the coordinate trajectory file. In other words, every coorTrjFreq time step, the data is written. If coorTrjFreq is specified, then coorTrjFile must also be defined.
CoorTrjFormat
Usage: specifies format of the coordinate trajectory file.
Acceptable: "dcd" or "hdf"
Default: "dcd"
Description: The coordinate trajectory file can be written in X-Plor DCD format, or, if supported locally, the NCSA HDF format.
EnergyTrjFile
Usage: name of the energy trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name of the energy trajectory file. This is a time step history of the same 11 energy values writting to the output file, but in NCSA HDF format (requires that HDF support be enabled). The energy trajectory file header attributes document the order in which the energies appear. These can be displayed with the hdfdump utility. If energyTrjFile is specified, then energyTrjFreq must also be defined.
EnergyTrjFreq
Usage: frequency in time steps for writting data to energy trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the energy trajectory file. In other words, every energyTrjFreq time step, the data is written. If energyTrjFreq is specified, then energyTrjFile must also be defined.
VelTrjFile
Usage: name of the velocity trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name of the velocity trajectory file. This is a trajectory of all atom velocities is in one of two formats: binary DCD, as used by xplor; and NCSA HDF format. If velTrjFile is specified, then velTrjFreq must also be defined.
VelTrjFreq
Usage: frequency in time steps for writing data to the velocity trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the velocity trajectory file. In other words, every velTrjFreq time step, the data is written. If velTrjFreq is specified, then velTrjFile must also be defined.
VelTrjFormat
Usage: specifies format of the velocity trajectory file.
Acceptable: "dcd" or "hdf"
Default: "dcd"
Description: The velocity trajectory file can be written in X-Plor DCD format, or, if supported locally, the NCSA HDF format.
CWD
Usage: current working directory
Acceptable Value: Any legal UNIX directory name
Description: Sets the default directory for input and output files. If a value is give, all filenames that do not begin with "/" are assumed to be in this directory. For example, if we have:
     OutputName = job1/run3
     RestartName = /tmp/run3
     CWD = /scr
then the coordinate files would become
     /scr/job1/run3.coord
     /tmp/run3.coord
If no CWD is specified, then the file paths are not modified.
Seed
Usage: random number seed
Acceptable Value: Integer greater than 0
Description: Number used to seed the random number generator. This can be used so that consecutive simulations produces the same results. If no value is specified, fmd will choose a pseudo-random value based on the current UNIX system clock. The random number seed will be output during the simulation startup so that its value is known and can be reused if desired. NOTE: If Langevin dynamics are used in a parallel simulation, (ie. a simulation run on more than one processor), using the same seed will not guarantee reproducible results, as processor clock times may differ slightly.
OutputEnergies
Usage: frequency, in time steps, at which energies are printed
Acceptable Value: Integer greater than 0
Default Value: 1
Description: Specifies how frequency the energy values are to be written to the output file. It is done every outputenergies time steps. The default setting of every time step may produce huge amounts of output during very long simulations.
FirstTimestep
Usage: starting time step value
Acceptable Value: Integer greater than or equal to 0
Default Value: 0
Description: Time step value for first time step. This value is typically used when a simulation is restarted from a previous one. Thus a starting time step can be specified so all the time steps in the simulation are sequential. In fact, this variable MUST be set to something other than 0 if one truly intends a continuation run. Otherwise, there will be a small glitch in the way the velocities in do_integration are set at the half timestep boundary.
Switching
Usage: flag to control switching/shifting functions
Acceptable Value: on or off
Default Value: off
Description: Determines how the van der Waals forces behave at the cutoff value. If switching is set to off, then a truncated cutoff is performed. If switching is set to on, then smoothing functions are applied to both the electrostatic and van der Waals forces. For a complete description of the non-bonded force parameters, see below. If switching is on, then switchdist must also be defined.
SwitchDist
Usage: distance at which switching occurs, in units of @AA{}.
Acceptable Value: float greater than 0.0 but less than cutoff
Description: Distance at which the switching function used for van der Waals forces should begin to take effect. This parameter only has meaning if switching is on. The value of switchdist must be less than or equal to the value of cutoff, since the switching function is only applied on the range from switchdist to cutoff.
PairListDist
Usage: maximum distance between atom pairs for inclusion in pair lists.
Acceptable Value: float greater than cutoff
Default Value: cutoff
Description: During each cycle, a pair list is created containing pairs of atoms for which electrostatics and van der Waals interactions will be calculated. This parameter is used when switching is set to on to specify the allowable distance between atoms for inclusion in the list. This is equivalent to the xplor cutnb parameter. If no atom moves more than pairlistdist-cutoff during one cycle, then there will be no jump in electrostatic or van der Waals energies when the next pair list is built. Since such a jump is unavoidable when truncation is used, this parameter may only be specified when switching is on.
StepsPerCycle
Usage: time steps per cycle
Acceptable Value: integer greater than 0
Default Value: 15
Description: Number of time steps in each cycle. Each cycle represents the number of time steps between pair list generation and atom reassignment. If full electrostatics are active, it is also the number of time steps between full electrostatic evaluation. While acceptable levels of accuracy are possible for values of 10 - 15, there is a price to pay in energy conservations. With a value of 10, total energy losses of up to 2.4\%/ns have been observed. A value of 4 reduces the drift to less than 0.4\%/ns, and a value of 2 yields a drift below 0.004\%/ns.
Margin
Usage: extra length in patch dimensions
Acceptable Value: float greater than 0.0, in units of @AA{}
Default Value: 1.0
Description: An internal tuning parameter used in determining the size of the cubes of space that fmd uses to partition the system. The value of this parameter will not change the physical results of the simulation at all. Unless you are motivated to get the very best possible performance, just leave this value at the default.
SnapshotFile
Usage: legal UNIX file name
Default Value: none
Description: Name of a trajectory file to hold coordinates output over a specified range of time steps. If specified, requires snapshotstart and snapshotstop.
SnapshotFormat
Usage: specifies format of the snapshot file.
Acceptable: "dcd" or "hdf"
Default: "dcd"
Description: The snapshot file can be written in X-Plor DCD format, or, if supported locally, the NCSA HDF format.
SnapshotStart
Usage: integer greater than 0
Default Value: none
Description: Specifies the first time step in a snapshot interval.
SnapshotStop
Usage: integer greater than 0
Default Value: none
Description: Specifies the last time step in a snapshot interval.
AllForceTrjFile
Usage: name of the all-force trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name to use for the all-force trajectory file. The file contains the composite force on all atom in one of two formats: binary DCD, as used by xplor; and NCSA HDF format. If allForceTrjName is specified, the allForceTrjFreq must also be defined.
AllForceTrjFreq
Usage: frequency, in time steps, for writting data to all-force trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the all-force trajectory files. In other words, every allForceTrjFreq time step, the data is written. If allForceTrjFreq is specified, then allForceTrjFile must also be defined.
AllForceTrjFormat
Usage: specifies format of the all-force trajectory file.
Acceptable: "dcd" or "hdf"
Default: "dcd"
Description: The all-force trajectory file can be written in X-Plor DCD format, or, if supported locally, the NCSA HDF format.
ElectTrjName
Usage: name of the electrostatic force trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the prefix for the name of the electrostatic trajectory files. The short range contributions will be in "name.s", and the long range components in "name.l". These are trajectories of all atom forces in one of two formats: binary DCD, as used by xplor; and NCSA HDF format. If electTrjName is specified, the electTrjFreq must also be defined.
ElectTrjFreq
Usage: frequency in time steps for writting data to electrostatic force trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the electrostatic force trajectory files. In other words, every electTrjFreq time step, the data is written. If electTrjFreq is specified, then electTrjFile must also be defined.
ElectTrjFormat
Usage: specifies format of the electrostatic trajectory file.
Acceptable: "dcd" or "hdf"
Default: "dcd"
Description: The electrostatic force trajectory file can be written in X-Plor DCD format, or, if supported locally, the NCSA HDF format.
DiceFreq
Usage: specifies frequency, in time steps, for updating data for the DICE user interface.
Acceptable: Integer greater than 0
Default: 1
Description: Data sent to the DICE graphical user interface is updated independent of all other output frequencies. The value set here can be changed under DICE control.

FMM3D User Parameters

The FMM3D parameters control use of the three-dimensional fast multipole method for calculation of the long-range electrostatic interactions.

FMA
Usage: flag to turn FMM3D usage on or off
Acceptable Value: on or off
Default Value: off
Description: Specifies the use of the FMM3D algorithm for electrostatic force calculations if set to on, not used if set to off.
FMALevels
Usage: number of levels to use in the multipole expansions
Acceptable Value: integer greater than 0
Default Value: 3
Description: Sets the number of subdivisions applied to the spatial volume. Higher numbers result in smaller lowest order volumes, at the expense of greater energy requirements. This option is recognized only if fma is on.
FMAMp
Usage: number of multipole expansion terms
Acceptable Value: integer greater than 0
Default Value: 5
Description: Sets the number of terms to use in the multipole expansions. A higher number gives greater precision, but also requires more work. This option is recognized only if fma is on.
FMADegSep
Usage: set degree of separation for Anderson methods
Acceptable Value: integer equal to or greater than 0
Default Value: 0
Description: Specifies the degree of separation to use with the Anderson Non-Adaptive or Anderson Adaptive methods.
FMASuperNode
Usage: number of Anderson method super nodes
Acceptable Value: integer equal to or greater than 0
Default Value: 0
Description: Specifies the number of super nodes to use with the Anderson Non-Adaptive or Anderson Adaptive methods.

Harmonic Constraint Parameters

The harmonic constraint feature of fmd is controlled by its own set of input options. The implementation might be more correctly called harmonic restraints. It follows the implementation seen in xplor. Through the use of these options, harmonic restraints may be applied to any atom or set of atoms in a model.

Constraints
Usage: a flag to indicate if restraints are to be used.
Acceptable Value: on or off
Default Value: off
Description: The setting of this option turns application of harmonic restraints on or off based on the obvious value specified. If on is chosen, the parameters consref, conskfile, conskcol, and consexp will be recognized.
ConsExp
Usage: exponent value for the harmonic constraint energy function.
Acceptable Value: any positive, even integer
Default Value: 2
Description: Specifies the exponent to use for the harmonic constraint energy function. Only even values make any physical sense. Value is ignored if constraints is off.
ConsRef
Usage: name of PDB file containing constraint reference points.
Acceptable Value: Any legal UNIX file name.
Default Value: coordinates
Description: The atoms specified in this file will be constrained about the listed coordinates. If no keyword is specified and constraints is on, the same file used for coordinates will be read, indicating the atoms are to be constrained about their initial positions.
ConsKol
Usage: Column in PDB file containing constraint data
Acceptable Value: X, Y, Z, O, or B
Default Value: O
Description: Any floating point field in the PDB file may be used. That is, any of the X, Y, and Z coordinate, the occupancy (O) or the beta-coupling (B) column. A value of 0.0 for any atom means that it is not constrained. (Data format is \%6.2f. Occupancy data in columns 55-60, beta-coupling data in columns 61-66.)
ConsKfile
Usage: name of PDB file containing force constant values.
Acceptable Value: Any legal UNIX file name.
Default Value: coordinates
Description: Specifies the name of a PDB file containing the force constants for the harmonic constraints. If no value is given, than the coordinates PDB file is assumed to contain the constants.

Energy Minimization Parameters

fmd does have the ability to perform energy minimization using a steepest descent method. While this algorithm is not the fastest to converge, it is sufficient for most applications. There are only two parameters for minimization to set, one to specify that minimization is active, and the other to specify the maximum movement of any one atom.

Minimization
Usage: minimization control flag
Acceptable Value: on or off
Default Value: off
Description: Flag to turn minimization on or off in the obvious fashion.
MaximumMove
Usage: Maximum distant any one atom can move in a step
Acceptable Value: float distance greater than 0.0, in units of @AA{}
Default Value: 0.75*cutoff/stepspercycle
Description: Maximum distance that an atom can move during any single time step during minimization. This is to ensure that atoms do not go flying off into space during the first few time steps when the largest energy conflicts are resolved.

Langevin Dynamics Parameters

fmd is capable of performing Langevin dynamics, where additional damping and random forces are introduced into the model. This follows the same implementation as found in xplor.

Langevin
Usage: Control flag for Langevin dynamics
Acceptable Value: on or off
Default Value: off
Description: Activates Langevin dynamics in the obvious fashion. If set to on, then the parameter langevintemp must also be set.
LangevinTemp
Usage: temperature for the Langevin forces.
Acceptable Value: float greater than 0.0, in units of degrees Kelvin.
Description: Set the temperature to which atoms affected by Langevin dynamics will be set to. Through the addition of friction and random forces, this temperature will be roughly maintained across the atoms affected. This parameter is required if langevin is set to on.
LangevinFile
Usage: name of PDB file containing Langevin parameters
Acceptable Value: Any legal UNIX file name.
Default Value: coordinates
Description: Specifies the name of a PDB file containing the Langevin dynamics parameters. If no value is given, than the coordinates PDB file is assumed to contain the parameters.
LangevinCol
Usage: Column in PDB file containing Langevin parameters.
Acceptable Value: X, Y, Z, O, or B
Default Value: O
Description: Any floating point field in the PDB file may be used. That is, any of the X, Y, and Z coordinate, the occupancy (O) or the beta-coupling (B) column. A value of 0.0 for any atom means that it is not affected by the Langevin dynamics. (Data format is \%6.2f. Occupancy data in columns 55-60, beta-coupling data in columns 61-66.)

Temperature Rescaling Parameters

fmd allows equilibration of a system by means of temperature rescaling. Using this method, all of the velocities in the system are periodically rescaled so that the entire system is set to the desired temperature. The following parameters specify how often rescaling is to be performed, and the temperature to be used.

RescaleFreq
Usage: number of time steps between temperature rescaling.
Acceptable Value: integer greater than 0
Description: If non-zero, specifies the frequency, in time steps, at which the temperature will be rescaled. If specified, then specification of the parameter rescaletemp is required.
RescaleTemp
Usage: desired temperature for rescaling (equilibration).
Acceptable Value: float greater than 0.0, in units of degrees Kelvin.
Description: The temperature to use for rescaling. This, in effect, is a method of equilibrating the model at a desired temperature. The parameter is recognized only if rescalefreq is set.

Periodic Boundary Condition Parameters

The periodic boundary conditions (PBC) in fmd support periodicity in any combination of directions (ie. line, slab, or volume), and arbitrary triclinic unit cells. To use PBC's, the user must enable PBC support, specify four vectors which define the unit cell, and optionally, specify the periodicity type if something other than volume is desired. The current implementation does not support use of fast multipole methods, and uses the nearest neighbor approximation when computing non-bonded forces. The fast multipole method will eventually support infinite images.

UnitCell
Usage: Turns periodic boundary conditions on or off.
Acceptable Value: on or off.
Default Value: off.
Description: Enables or disables the use of periodic boundary conditions. If enabled, it will make sure the fast multipole methods are disabled.
UnitOrigin
Usage: Specifies origin of unit cell.
Acceptable Value: three floats.
Description: 0-origined vector defining the location of the vertex from which the axes of the cell originate.
UnitX
Usage: Specifies first basis vector of unit cell.
Acceptable Value: three floats.
Description: 0-origined vector defining the location of the end of one basis vector (or axis) of the unit cell. The basis vector runs from UnitOrig to UnitX.
UnitY
Usage: Specifies second basis vector of unit cell.
Acceptable Value: three floats.
Description: 0-origined vector defining the location of the end of one basis vector (or axis) of the unit cell. The basis vector runs from UnitOrig to UnitY.
UnitZ
Usage: Specifies third basis vector of unit cell.
Acceptable Value: three floats.
Description: 0-origined vector defining the location of the end of one basis vector (or axis) of the unit cell. The basis vector runs from UnitOrig to UnitZ.
Periodicity
Usage: Specify periodicity of unit cell.
Acceptable Value: x, y, z, xy, xz, yz, or xyz
Description: Specifies the dimensions in which the unit cell is periodic. It may be periodic along one dimension (x|y|z), two dimensions (xy|xz|yz) or all three dimensions (xyz). X, Y, and Z, of course, refer to the unit cell basis vectors, not the Cartesian basis.

Spherical Boundary Condition Parameters

The only boundary conditions currently supported by fmd are spherical harmonic boundary conditions. These boundary conditions can consist of a single potential, or a combination of two potentials active at the outer edge of the model.

SphericalBC
Usage: Control flag for spherical boundary conditions
Acceptable Value: on or off
Default Value: off
Description: Turns on spherical boundary conditions in the obvious fashion. If set, then sphericalbcr1 and sphericalbck1 must also be set.
SphericalBCr1
Usage: radius for the first boundary condition function
Acceptable Value: float greater than 0.0, in units of @AA{}
Description: Distance from the model's center of mass at which the first boundary condition takes effect.
SphericalBCk1
Usage: force constant for the first potential.
Acceptable Value: float not equal to 0.0
Description: Force constant to use for the first spherical harmonic potential. A positive value will force atoms back towards the center of mass, and a negative value will pull atoms away from the center of mass.
SpericalBCexp1
Usage: exponent for the first potential.
Acceptable Value: integer, greater than 0, and even.
Default Value: 2
Description: Exponent to use for the first boundary potential. The only likely values to use are 2 and 4.
SphericalBCr2
Usage: radius for the second boundary condition function
Acceptable Value: float greater than 0.0, in units of @AA{}
Description: Distance from the model's center of mass at which the second boundary condition takes effect.
SphericalBCk2
Usage: force constant for the second potential.
Acceptable Value: float not equal to 0.0
Description: Force constant to use for the second spherical harmonic potential. A positive value will force atoms back towards the center of mass, and a negative value will pull atoms away from the center of mass.
SphericalBCexp2
Usage: exponent for the second potential.
Acceptable Value: integer, greater than 0, and even.
Default Value: 2
Description: Exponent to use for the second boundary potential. The only likely values to use are 2 and 4.
SphericalBCCenter
Usage: x y z (coordinates).
Acceptable Value: 3 floats, any value.
Default Value: center of mass.
Description: Fix the center(s) for the spherical boundary conditions at a specific point. If not specified, the radii are computed from the center of mass of the molecule.

fmd supports the application of an external electric field. This, along with setting a dielectric constant for the model, allows for a wide variety of electrostatic conditions.

Applied Electric Field Parameters

EFieldOn
Usage: Control flag for applied electric field
Acceptable Value: on or off
Default Value: off
Description: Indicates that an external electric field is to be used. If set, then EField must also be set.
EField
Usage: Vector specifying an applied electric field
Acceptable Value: three floats, any value
Description: Specifies a three dimensional vector representing a constant applied electric field. Ignored if EFieldOn is not set "on", else it defaults to 0.

Equivalent X-PLOR Parameters

fmd was designed to provide many of the same molecular dynamics functions as found in xplor. Thus, there are many similarities between the types of parameters passed to both fmd and xplor. This table lists the fmd parameter and the equivalent xplor parameter.

Cutoff
xplor: CTOFNB
Description: When full electrostatics are not in use within fmd, these parameters have exactly the same meaning. It represents the distance at which the electrostatic and van der Waals forces are truncated. When full electrostatics are in use in fmd, the cutoff meaning still applies to the van der Waals forces. However, for electrostatics, it represents the local interaction distance within which interactions are directly calculated.
SwitchDist
xplor: CTONNB
Description: Distance at which van der Waals switching function becomes active.
PairListDist
xplor: CUTNb
Description: Distance between atom pairs which result in inclusion in pair lists.
1-4Scaling
xplor: E14Fac
Description: Scaling factor to apply to 1-4 pair electrostatic interactions.
Dielectric
xplor: EPS
Description: Dielectric constant to use.
Exclude
xplor: NBXMod
Description: These parameters both specify what atom pairs should be excluded from non-bonded interactions. The ability to ignore explicit exclusions is not present within fmd, thus only positive values of NBXMod have fmd equivalents. These equivalents are:
   NBXMod   exclude    Description
   ====================================================
     1        none     no atom pairs excluded
     2        1-2      only 1-2 atom pairs excluded
     3        1-3      1-2 and 1-3 pairs excluded
     4        1-4      1-2, 1-3, and 1-4 pairs excluded
     5      scaled1-4  1-2, 1-3, 1-4 pairs excluded,
                       1-4 pair interactions modified
Switching
xplor: SHIFt, VSWItch, TRUNcation
Description: fmd switching on is equivalent to xplor SHIFt and VSWItch on. Setting to off is equivalent to xplor option TRUNcation.
Temperature
xplor: FIRSttemp
Description: Specifies the initial temperature for random velocity distribution.
RescaleFreq
xplor: IEQFrq
Description: Number of time steps between velocity rescaling.
RescaleTemp
xplor: FINAltemp
Description: Temperature to use for rescaling (equilibration).
RestartName
xplor: SAVE
Description: File name for the restart files.
RestartFreq
xplor: ISVFrq
Description: Number of time steps between generation of restart files.
CoorTrjFile
xplor: TRAJectory
Description: File name for coordinate trajectory file.
CoorTrjFreq
xplor: NSAVC
Description: Number of time steps between writting of coordinates to trajectory file.
VelTrjFile
xplor: VELOcity
Description: Name of the velocity trajectory file.
VelTrjFreq
xplor: NSAVV
Description: Number of time steps between writing of velocities to velocity trajectory file.
NumSteps
xplor: NSTEp
Description: Number of time steps to perform.

Development Parameters

This is a collection of parameters that serve primarily as aids in code development, are experimental, or are of questionable usefulness. Use at your own risk if you find a need.

GlobalTest
Usage: Force global integration for testing purposes.
Acceptable Value: true or false.
Default Value: false
Description: Forces explicit global integration of all forces. This allows one to compare the "exact" solution with any of the approximate solutions.
LdbStrategy
Usage: Select load balancing strategy.
Acceptable Value: none, random, nolocality, bisection, or other.
Default Value: bisection
Description: Selects a method for load balancing. Execution statistics are gathered from the various nodes and used as input data to the chosen method.
LdbStepsPerCycle
Usage: Time steps between load reassignments.
Acceptable Value: Integer > 0
Description: Specifies the number of time steps between recalculation of the load balance. Must be specified if ldbstrategy is specified.
LdbSendStep
Usage: Time step in load balance cycle to set statistics.
Acceptable Value: ldbstepspercycle > Integer > 0
Description: Specifies the time step within a load balance cycle at which performance statistics are exchanged with other nodes. Must be specified if ldbstrategy is specified.
LongSplitting
Usage: Select long range force splitting method.
Acceptable Value: sharp, xplor, or c1
Default Value: sharp
Description: Selects from among three types of long range force splitting.
MTSAlgorithm
Usage: Select multiple time step algorithm.
Acceptable Value: naive, verleti, or verletx
Default Value: naive
Description: Selects among several methods for time step splitting.
PLMmarginCheck
Usage: Toggles testing of pairlist margins.
Acceptable Value: on or off.
Default: off.
Description: Performs extra calculations to see if any atom moves outside of the region specified when the pairlist was created. This can be a test of appropriate sized volumes or time step.
TCouple
Usage: Toggles usage of a temperature bath.
Acceptable Value: true or false.
Default Value: false.
Description: Specifies that the system should be coupled to an external temperature bath.
TCoupleTemp
Usage: Sets temperature of external bath.
Acceptable Value: Float > 0.0 in units of degrees Kelvin.
Description: Specifies the temperature of the external bath. This must be specified if tcouple specified as true.
TCoupleFile
Usage: Name of PDB format file with temperature coupling terms.
Acceptable Value: Any UNIX file name.
Description: Provides the name of a file, in ASCII PDB format, which contains the couple terms describing the external temperature bath. This must be specified if tcouple is true.
TCoupleCol
Usage: Column in PDB file containing bath coupling parameter.
Acceptable Value: X, Y, Z, O, or B
Default Value: O
Description: Any floating point field in the PDB file may be used. That is, any of the X, Y, and Z coordinate, the occupancy (O) or the beta-coupling (B) column. This must be specified if tcouple is true. (Data format is \%6.2f. Occupancy data in columns 55-60, beta-coupling data in columns 61-66.)
Dihedral
Usage: Toggle to control dihedral dynamics.
Acceptable Value: true or false
Default Value: false
Description: Enables dihedral angle dynamics. It sets up hard distance constraints based on biological dihedral structures.
Cold
Usage: Toggle to control Langevin dynamics with dihedral dynamics.
Acceptable Value: true or false
Default Value: false
Description: Enables the performance of over-damped Langevin dynamics in conjunction with the dihedral dynamics. Is recognized only if dihedral is true.
ColdTemp
Usage: Temperature for Langevin dynamics
Acceptable Value: Float > 0.0 in degrees Kelvin.
Description: Specifies the temperature for the Langevin dynamics used in conjunction with the dihedral angle dynamics. Must be specified if cold and dihedral are true.
ColdRate
Usage: Damping rate for Langevin dynamics
Acceptable Value: Float > 0.0
Default Value: 3,000.0
Description: Specifies the damping factor to be used with the dihedral and Langevin dynamics. It is ignored unless dihedral and cold are true.
ElectForceTrjName
Usage: The electrostatic force trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name of the electrostatic force trajectory file. ".s" is appended to give the file name for the short range component file, and ".l" is appended for the long range component file. These are trajectories of all atom long and short range forces in one of two formats: binary DCD, as used by xplor; and NCSA HDF format. If electForceTrjName is specified, then electForceTrjFreq must also be defined.
ElectForceTrjFreq
Usage: frequency in time steps for writing data to electrostatic force trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the electrostatic force trajectory file. In other words, every electForceTrjFreq time step, the data is written. If electForceTrjFreq is specified, then electForceTrjName must also be defined.
AllForceTrjFile
Usage: name of the all-force trajectory file
Acceptable Value: Any legal UNIX file name
Description: Sets the name of the all-force trajectory file. This is a trajectory of all atom composite forces in one of two formats: binary DCD, as used by xplor, and NCSA HDF. If allForceTrjFile is specified, then allForceTrjFreq must also be defined.
AllForceTrjFreq
Usage: frequency in time steps for writing data to all-force trajectory file
Acceptable Value: Integer great than 0
Description: Frequency, in units of time steps, at which data is written to the all-force trajectory file. In other words, every allForceTrjFreq time step, the data is written. If allForceTrjFreq is specified, then allForceTrjFile must also be defined.

HDF File Format

The HDF files generated by FMD use a common format. Each file contains a header made up of several file level attributes, and 3 data sets. There is one data set for the main data array, one for the elapsed time values, and one for the time step value. Each is an extensible array, with successive data dumps adding 1 to the index of the most significant dimension (the left-most dimension for C/C++ programmers).

The file header contains the following attributes:

title
The title taken from the "title" keyword.
title2
The subtitle taken from the "title2" keyword.
program
Name of the program - fixed as "FMD".
revision_id
The FMD revision number.
revision_date
The FMD revision date.
creator
The user name of the person running program.
date
The date the program was run.
type
Indicates output, trajectory, or restart.
class
Indicates data contents: coordinates, velocities, energies, etc. The name here is also used as the name of the main data array.
format
Indicates the format style of the file. This attribute is not present in FMD Releases 1.9.5 and earlier.
order
If an energy trajectory file, this attribute lists the order in which the energies and temperatures appear.

The three data sets are created using the value set in the class attribute, and the names "elapsed_time" and "time_step". In most of the trajectory files, the main data array takes the form data[time_index][atom_id][3], where the "time_index" dimension corresponds to the extensible dimension. For the energy trajectory file, the main data array takes the form data[time_index][energies]. In both cases, the data is of type float64. The "elapsed_time" data set contains elapsed time values, also of type float64, while the "time_step" data set contains int32 type values. Both of these data sets are organized in the form data[time_index][1]. Each new data dump results in the value of "time_index" being incremented by one. When the files are read, the "dim[0]" returned by the HDF library info routines is basically the number of dumps written to the file. Since all three arrays are extensible, the file size is limited only by operating system constraints.

Implementation Details

This chapter provides a detailed description of all aspects of the fmd implementation. This includes everything from the high level program structure to detailed description of each class that is used within the program.

Program Structure

Initialization

The first object created is the Communicate object, which makes sure the program is running on all other nodes in the parallel machine. When constructed, this object knows how many nodes are available, and the logical node ID of each node. Node 0 is the master node, and with N nodes assigned, the last node will be N-1.

The master node reads in all data, verifies structure and parameters, parses configuration file, and sends data to all other nodes. All nodes keep a full copy of the parameters and the complete structure of the molecule.

More ...

(More to come.)

Global Definitions

Global items are defined in common.h; global variables and functions are there declared extern. The global functions are in common.C; global variables are actually declared in fmd.C.

Global Functions

FMD_title(void)
Print out a title message. Really should only be called by the master node.
FMD_check_messages(void)
This checks the Inform message objects to see if they have any new messages, which are displayed if available. This should be called by the master node only, and should be called periodically, in some form of event loop.
FMD_quit(void)
Exits normally from fmd, with an exit code of 0.
FMD_die(char *)
Exits abnormally from fmd, printing a supplied error message. It also calls MPI_ABORT with MPI_COMM_WORLD so all associated nodes also terminate (though less gracefully).
BigReal fmdInfo
Inform object which takes informative messages and forwards them to the host node, where they are displayed.
Inform fmdWarn
Inform object for warning messages. Warning messages mention unusual occurrences, things that do not warrant stopping the simulation, but which might be useful to the user if problems occur later.
Inform fmdErr
Inform object for error messages. Error messages are typically items that prevent a simulation from starting or continuing.
Inform fmdDebug
Debugging message object. When debugging is enabled, messages sent to this object will be printed. Use this to display general debug information, not stderr or cerr.
Communicate *comm
Pointer to the main communication object, used to send messages between nodes.
Node *fmdMyNode
Node object present on each processor.
int fmdNumNodes
Total number of nodes involved in the simulation.

Global defines

PI, TWOPI, ONE, ZERO
Defined to set the proper accuracy; defined up to 15 places for double accuracy.
TRUE, FALSE, YES, NO
Boolean logic definitions.
BOLTZMAN
Boltzman's constant

Global typedef's

Real
Used for all computation storage, where a 'float' or 'double' might be used. Allows easy setting of accuracy/storage size preference.
Bool
Boolean logic objects (T/F).

Class Descriptions

This chapter contains descriptions for the different major classes used in fmd. These descriptions include the class name, interface, examples of use, and files involved. Note that the list of files involved in a class follows UNIX file names with wild card conventions (ie. foo.[Ch] is equivalent to foo.C and foo.h).

AngleForce

Purpose
The AngleForce class is used to calculate the forces and energies due to the angle between 2 bonds in a molecule. Since angles, dihedral angles, and improper angles are handled exactly alike, except for the force formulae, all three use the abstract base class MultiBond for everything except the calculation of the forces on an angle from the 3 or 4 atom positions. For a description of the public functions and use of AngleForce, see the Multibond class description, section MultiBond.
Files
AngleForce.[Ch], MultiBond.h, and structures.h
Constructor
[See section MultiBond.]
Destructor
[See section MultiBond.]
Method of Use
[See section MultiBond.]
Functions
[See section MultiBond.]

BondForce

Purpose
This class is used to calculate the forces and energies due to stretching or compressing bonds in a molecule. There is a BondForce object present in every patch and it is responsible for calculating the forces and energies due to bonds between two local atoms as well as between one local atom and one atom on a nearby patch. In contrast to MultiBond objects, if a bond connects atoms on two different patches, only one patch will compute the forces and energies, and it will send the force on the non-local atom to the other patch.
Files
BondForce.[Ch] and structures.h
Constructor
BondForce ( Patch *parentPatch, PatchList *parentList ) The parameters parentPatch and parentList allow the object to know who owns it.
Destructor
~BondForce()
Method of Use
BondForce objects have 7 public functions, in addition to the constructor and destructor:
 initialize_timestep(), set_recycle(),
 local_init(),  neighbor_init(),
 local_force(), neighbor_force(),
 get_energy()
At the beginning of each timestep, initialize_timestep() must be called to reset various flags. At the beginning of a cycle, if no atoms have been reassigned to or from this patch, set_recycle() may be called to avoid recomputing certain data structures; otherwise the object must be deleteed and recreated; there is currently no other way to indicate that the bond lists must be rebuilt from scratch. The next four functions -- local_init() through neighbor_force() -- update the local forces based on positions supplied to the functions, as data becomes available during the timestep. The functions local_init() and neighbor_init() are called during the first timestep in a cycle, and set up data structures in addition to computing forces. The functions local_force() and neighbor_force() only compute the forces. Fist, local_init() or local_force() must be called to compute the forces due to bonds which do not involve neighbor atoms. Then, each time a set of all coordinates from a patch (a message with tag NBCOORTAG) comes in from a neighbor patch, neighbor_init() or neighbor_force() must be called to update the forces due to bonds with atoms in that patch. The functions neighbor_init() or neighbor_force() should not be called for positions from a patch to which this patch sends all positions. These functions accumulate the forces on the neighbor atoms in a separate array of positions, so that these forces may be sent back to patch that sent all its positions (in a message with tag NBFORCETAG). The force computation is complete when positions or forces have been received from all neighbors with whom this patch shares any bonds. (No check is made for this.) There were several decisions made during the design of this object that should be reconsidered later. The main one is the way in which the bond list is built. Currently this relies on having a list of bonds that each atom is involved in. This is quite fast, but expensive and non-scalable in terms of memory usage. If the structure of the molecule were distributed rather than stored on every, this would become more reasonable.
Functions
void initialize_timestep ( void )
Get the object ready for a new time step.
void set_recycle ( void )
If no atoms have moved out of or into this patch since the last cycle, set_recycle() may be called as an alternative to deleteing and recreating the object. It should be called before the first local_init() or neighbor_init() call of the cycle.
void local_init ( int nlocal, int *localGlb, Vector *localx,
Vector *localf )
This function
  1. builds the bond lists, if it has not already been done this cycle.
  2. computes the data structures needed by local_force().
  3. calls local_force(localx,f) to compute the forces.
void local_force ( Vector *x, Vector *f )
Calculate those bond forces for this patch that do not require any neighbor atom positions. This function should be used during every time step of a cycle except the first time step. If this function is called before local_init(), then bad things will happen.
void neighbor_init ( int nid, int nremote, int nlocal,
int *remoteGLB, int *localGlb, Vector *localx,
Vector *remotex, Vector *f, Vector *remotef )

This function
  1. builds the bond lists and the hash table, if it has not already been done this cycle.
  2. computes the data structures needed by neighbor_force() for processing positions from neighbor nid.
  3. calls neighbor_force(nid,localx,remotex,f,remotef) to compute the forces due to bonds between one local atom and one atom on neighbor nid.
Note that the array of positions will generally include positions not used by this object. This does not matter as long as future calls to neighbor_force() have the same number of positions corresponding to the same atoms in the same order as the call to neighbor_init(). This function should only be called once per neighbor, only for a neighbor who does not call this function for coordinate messages from this patch and only during the first time step of each cycle.
neighbor_force ( int nid, Vector *localx, Vector *remotex,
Vector *f, Vector *remotef )
This function computes the forces due to bonds between one local atom and one atom on neighbor nid. neighbor_init() must have been called already, thus neighbor_force() must be called for every timestep except the first in a cycle.
BigReal get_energy ( void )
Get the bonded energy that has been accumulated during this time step.

BoundaryMap

Purpose
The BoundaryMap class implements a cell-linked list approach to managing neighbor lists. A BoundaryMap object contains the patchId and other information about any neighboring patches a given patch may have. It provides mapping of ghost patches to real patches when periodic boundaries are used. This is an efficient way of implementing different levels of periodicity, such as line (along one axis), slab (in one plane) or full (periodic in all dimensions). It acts in concert with NeighborList to construct the patches.
Files
BoundaryMap.[Ch]
Constructor
BoundaryMap ( void )
Destructor
~BoundaryMap ( void )
Method of Use
The BoundaryMap is created by a call to createBoundaryMap, which is passed the PatchDistrib object, an overlap array, the boundary condition type, and the number of patches in each dimension. This creates an array that represents the patches in the simulation and a border of ghost patches that represent the patches across the boundary conditions. The size of the border in each dimension is given by the overlap array. The BoundaryMap is used with the array operator [index], which will return the patch id of the patch associated with index. This is seen most clearly in the following figure. This is seen most clearly in the following figure. This is a two dimensional representation of the BoundaryMap with periodic boundary conditions in X and isolated boundary conditions in Y. The numbers in the squares are the patchIds. Negative one corresponds to no patch. The Ghost patches are shaded. There are several routines used to get the appropriate index: patchIdIndex( patchId ) will give you the index for a patch with the given patchId, coordIndex( i, j, k ) will give you the index of a patch that is in the i, j, k position of the simulation. Other information about a neighbor can be obtained from the BoundaryMap object. If an index corresponds to a ghost patch, Image(index) will return TRUE, and patchOffset(index) will return the vector offset in units of the simulation cell to add to the corresponding real patch to map it into the ghost patches position. If the simulation has isolated boundary conditions where there are no ghost patches, then Image(index) will be FALSE and patchOffset(index) will be the zero vector. The possible boundary conditions are isolated ( there is nothing beyond the edge of the simulation cell, or periodic ( beyond the boundary is another identical simulation cell). The two boundary conditions may be applied to any dimension regardless of the boundary conditions on any other dimension. The ID of the i'th neighbor is calculated as:
  neighborId [ i ] = map [ map.patchIdIndex ( patchId )
                           + neighborList [ i ] ]
Functions
const int createBoundaryMap ( PatchDistrib& pd, const int *overlap,
const int bt, const int xdim, const int ydim,
const int zdim )
Initializes the boundary map according to the boundary conditions specified. It loads up the image and offset data, returning 0 on success.
const int& operator[] ( const int index ) const
Returns the patchId for the given index into the boundary map.
const int patchIdIndex ( const int patchId ) const
Returns the patch index in the boundary map for the given patch ID.
const int coordIndex ( const int x, const int y, const int z ) const
Returns the boundary map index given the patch positional indices used by the simulation.
const int middleIndexOfMap ( int *coord ) const;
Returns the boundary map index of the patch closest to the center of the simulation. Used by NeighborList.
const Vector& patchOffset ( const int index ) const
Returns the vector to be added to the corresponding real patch which will map it into the ghost patch position required by the periodic boundary condition.
const int Image ( const int index ) const
Returns TRUE if and only if the neighbor patch is a ghost patch.

BufferMPI

Purpose
Implements a buffer object for MPI pack/unpack routines.
Files
BufferMPI.[Ch]
Constructor
BufferMPI ( void )
Destructor
~BufferMPI ( void )
Method of Use
Allocation of buffer space to hold data for MPI send's and receive's is an implementation depended function. MPICH is an example, following that of PVM, which allocations all space necessary, hiding this requirement from the user. The IBM SP MPI implementation allows for only 4096 bytes of buffer space. Larger spaces must be explicitly managed by the user. This class provides the tools for managing such buffers. It should be used to allocate, deallocate and manipulate all buffers used by for MPI activity. In particular, tests are provided to allow a user to verify that an MPI request has completed its use of a buffer before reusing the buffer.
Enumerations, Private
BufferState: ( UNINITIALIZED, RECEIVING, UNPACKING, FREE, PACKING, SENDING )
BufferMPIError: ( OK = 0, BUSY_BUFFER_ERR, BUFFER_STATE_ERR,
ENLARGE_BUFFER_ERR )
Functions, Private
void error_abort ( const char *mess, int error )
Triggers MPI_Abort if there is a serious error.
void err_if_busy ( const char *name )
An assertion, returning an error if the buffer is currently in use.
void init ( Bool must )
Make sure that state isn't UNINITIALIZED by the time we do anything. This is a kludge to handle certain MPI macros not being usable until after MPI_Init.
Functions
Bool is_busy ( void )
TRUE if the buffer is being used in an Irecv or Isend operation.
static int get_free_buf ( Bool wait, int nbufs, Buffer_MPI *bufs[] )
Return the index of a free buffer, waiting if specified. Returns -1 if no free buffer can be made available.
void wait ( void )
Wait for the buffer to be free.
reset_buffer ( void )
Resets position to start of buffer, and sets end-of-data to 0.
void set_communicator ( MPI_Comm comm = MPI_COMM_WORLD )
Sets the communicator to MPI_COMM_WORLD.
int get_size ( void )
Returns the allocated size of the buffer.
int get_data_size ( void )
Returns the number of bytes stored in the buffer.
void hex_dump ( void )
Print out the contents of the buffer in hexidecimal format. Used for debugging.
void print_buffer ( void )
Prints out the contents of the buffer. Only of real use if the buffer has been packed with strings.
int pack_buffer ( void *inbuf, int num, MPI_Datatype type )
Packs data into the buffer.
int send_buffer ( int node, int tag )
Initiates a send operation on the buffer. Returns the MPI error code.
void recv_buffer ( Bool wait, int node, int tag,
Bool &data_present, int &where_error, int &errno )
Read message if one is present. Since several MPI calls are used, "where_error" identifies the call if there is an error.
int unpack_buffer ( void *data, int len, MPI_Datatype type,
Bool &end_of_message )
Unpack a data item.

Collect

Purpose
The Collect class gathers the useful data produced by the patches. This data includes the sum of the various energy terms over all atoms, and the positions and velocities of each atom. The current implementation accumulates the data on the master node, then invokes the output object to report the data. The collection of energies is performed at every time step. Positions and velocities are collected at some frequency determined by the user. A spanning tree is employed for the the sum of energies to yield better scalability. Currently, positions and velocities are sent directly to the master node.
Files
Collect.[Ch]
Constructor
Collect ( int myNode, Output *output ) Initializes the spanning tree, and creates the output object only on the master node.
Destructor
~Collect ( void )
Method of Use
An instance of the Collect object exists on each node. The constructor builds the spanning tree which is used to propagate the energy data. The interaction between the Collect object and the rest of the program is as follows. At the beginning of each time step, the node object invokes the collect object on the same processor for time step initialization. During the time step, each patch then sends their data, when it is ready, to the Collect object. At the end of the time step, the PatchList object tells the Collect object to propagate the data collected so far (at this point all the patches contributed their data). The Collect object then carries out the gathering of data. For energy collection, the Collect object combines the partial results from its children (in the spanning tree) and propagates the combined result to its parent. The Collect object sends the positions and velocities directly to the master node. Once the data is assembled on the master node, then the output object is invoked.
Defined Constants
maxEnergyCount
Represents the number of energy terms. Currently, there are seven: bonded, angle, dihedral, improper, electrostatic, vdw, and kinetic.
Functions
void init_timestep ( int timestep )
Initializes the Collect object for a particular time step. This includes initialization of the data areas for partial results, and determining if the time step is okay for collection of positions and velocities.
void energy ( BigReal *energy )
Patches send their energy data to the output object through this function by supplying an array of energies. Each energy value is the sum over all the atoms that the patch owns.
void coordinate ( int timestep, int natoms, int *globalIndex,
Vector *coords )
Used by a patch to send its atoms' positions to the master output object. The patch must supply not only its atoms' positions, but also identify which atoms they are, via globalIndex. Collect then combines them on each node, and finally does a parallel collect operation to get all positions to the master node. Note that, in order for the positions and velocities collected during a given timestep to the same time, positions are sent at the beginning of a timestep and velocities at the end.
void velocity ( int timestep, int natoms, int *globalIndex,
Vector *vels )
Used by a patch to send its atoms' velocities to the master output object, in exactly the same way as coordinates() sends coordinates.
void long_force ( int timestep, int natoms, int *globalIndex,
Vector *f )
void short_force ( int timestep, int natoms, int *globalIndex,
Vector *f )
void all_force ( int timestep, int natoms, int *globalIndex,
Vector *f )
Used by a patch to send its atoms' long-range and short-range electrostatic forces and their total forces to the master output object, in exactly the same way as coordinates() sends coordinates.
void propagate ( int )
Function which triggers the process of collection across processors.

Communicate

Purpose
Abstract base class used to send messages between nodes of a parallel machine. Also responsible for initializing communications and verifying that processes are running on all available nodes. Uses can choose to have all messages sent immediately, or defer sending until a later time. Note that this object is still under construction.
Files
Communicate.[Ch]
Constructor
Communicate ( void )
Destructor
~Communicate ( void )
Enumerations
CommError
NOERROR, ERROR, NONODES, NOSEND, NORECEIVE
CommDir
SEND, RECEIVE
SendMethod
NOW, WAIT
Method of Use
To send data to another node, first a Message object is created, which is loaded with the data to be sent. Then the send routine is called with a pointer to the Message. This Message object is not copied, so the user must new a Message object before sending it via send. If a message is sent successfully, the Communicate object will automatically free up it's storage space; if it cannot be sent, the user is responsible for freeing the space. Each message sent to another node must have a user-supplied tag to uniquely identify the message for the receiver. This tag should be greater than or equal to 0. Some specific tags are used by other components of fmd, such as the Inform messages ( tags 1000, 2000, 3000, and 4000). When receiving a message, you can ask to receive a message from a given node with a given tag, or specify a wild card for either node or tag, by asking for a message with node of -1 or tag of -1. The Communicate object can send all messages as soon as they are provided, or wait until the routine send.all() is called, which will send out all cached Message objects. This is quite often preferable when several messages are to be sent to the same node; the Communicate class can combine these into a single message which is then broken into individual Message's by the receiver. By default, the send method is NOW, which means when a message is requested to be sent, it is indeed sent over the network. If the send method is WAIT, the message will be stored but not actually sent until send.all() is called. The send method can be set via the send_method routine. Also, there is a send_now function which will send a message NOW, regardless of the current send method setting. To receive a message, the receive routine is called, which returns a new instantiation of a Message object if a message has arrived, or NULL if no messages are available. Once a message has been successfully received, the user must retrieve data from it, and delete it. A message can also be broadcast to all other nodes, or to all nodes including the sender. Broadcasts always occur immediately; they are not combined with other messages.
Functions
int add_node ( void *id )
Adds a new node to the parallel machine. This is a relic of namd, on which fmd is based. It used PVM and could spawn additional nodes. fmd is based on MPI and does has all nodes assigned at program startup.
int debug ( void ) || void debug ( int )
Query or set the debug flag; when debugging is set, several debugging messages are printed to the console during communication.
CommError errorno ( void )
Returns the current error status, which is set after a send or receive call.
int nodes ( void )
Returns the total number of nodes available.
int this_node ( void )
Returns which node the process is on; nodes are numbered from 0 to nodes()-1.
SendMethod send_method ( void )
Query what the current sending method is, NOW or WAIT.
void send_method ( SendMethod )
Set the current sending method to either NOW or WAIT.
int send ( Message *msg, int node, int tag )
Send the given Message object. Whether it is actually sent at the time the routine is called or cached depends on the current SendMethod.
int send_now ( Message *msg, int node, int tag )
Send the given Message object now, regardless of the current SendMethod setting.
int send_all ( void )
Sends out all yet-unsent messages, grouping together into single messages all individual messages destined for the same node.
Message *receive ( int& node, int& tag )
Receives a message from the given node with the given tag. Node and tag may be set to -1, in which case they are wildcards and match anything. Returns a new Message object, for which the user is responsible for deleteing.
int broadcast_all ( Message *msg, int tag )
Sends ( immediately ) the given message to all nodes including the sender node, with the specified tag. Returns the number of nodes actually sent to.
int broadcast_others ( Message *msg, int tag )
Sends ( immediately ) the given message to all nodes except the sender node, with the specified tag. Returns the number of nodes actually sent to.
Derived Classes
CommunicateMPI ( CommunicateMPI.[Ch] BufferMPI.[Ch] )
MPI version of Communicate. Verifies that all nodes requested are available and communicating. If there is any problem, it assumes only one node is available.

CommunicateMPI

Purpose
MPI version of the Communicate object. Allows user to establish id's for available nodes, establish connections, and send/receive data. When created, this object checks to see if other nodes have been spawned yet; if no, this spawns them and confirms everything is running well.
Files
CommunicateMPI.[Ch]
Constructor
CommunicateMPI ( int *, char **[], int = 0 ) - The first two arguments echo the command line arguments. The last is used to set a debugging flag if not 0.
Destructor
virtual ~CommunicateMPI ( void )
Method of Use
This class is not really intended for direct use. Rather it is really intended as a helper class for the Communicate object.
Functions, Private
void pack_message ( Message *, int, Buffer_MPI * )
Takes data from the given Message, and packs it into the current send buffer. Each message is packed in this order:
 tag                                     (int)
 number of items                         (int)
 type of item 1                          (short)
 size of item 1, in number of elements   (int)
 item 1 data                             (various)
 ...
 type of item N                          (short)
 size of item N, in number of elements   (int)
 item N data                             (various)
Message *unpack_message ( Buffer_MPI *, int &tag, int &node )
Unpack the current receive message into individual Messages and MsgList structures, and look for a message with the given tag. Returns a MsgList struct for the first matching tag; other MsgList structs for the other messages in the big message are added to the received msg queue messages are in this format:
 number of individual messages   (int)
 sending node (0 ... N-1)        (int)
 data for message 1              (various)
 ...
 data for message N              (various)
Buffer_MPI *get_sendbuf ( void )
Gets a free send buffer, or else returns NULL.
Functions, Protected
virtual int do_send_queue ( int )
virtual int do_send_msg ( Message *, int, int, int delmsg=TRUE )
The destination node is the node of the first MsgList object; all MsgList objects following that one until the end of list, or the node number changes, are sent.
virtual Message *do_receive ( int &node, int &tag )
Receives message from specified node with specified tag.

ConfigList

Purpose
Reads information from either a configuration file or standard input and creates a searchable data base. Entries in the file are of the form "keyword = data", where the equals sign is optional. Blank lines are ignored, as are comments, which start with a "#". Multiple entries with the same keyword are allowed. Keywords are not case dependent.
Files
ConfigList.[Ch]
Constructor
ConfigList ( char * filename ) Here, filename is the name of the file to read. The constructor opens the file, reads and parses the information within, and closes the file. The "filename" for standard input is just a hyphen, "-" (this follows a somewhat standard UNIX idiom). It it could not open the file, then the member function okay(void) is set to FALSE, otherwise it is set to TRUE. Lines that could not be parsed are written to fmdWarn.
Destructor
~ConfigList ( void )
Method of Use
The constructor must be called with a file name, as in
   ConfigList config ( "bR.in" )
   if ( ! config.okay () )
      FMD_die ( "Could not read user input file." );
Information about a keyword can be retrieved with the find function. This returns a linked list of type StringList. For example, to get a list of all the force field parameter files:
   StringList *tmp, *params = config.find ( "parameters" );
   if ( ! params )
      FMD_die ( "No parameter files listed." );
   for ( tmp = params; tmp != NULL; tmp = tmp->next )
      cout << tmp->data << '\n';
Typedef's
StringList
A structure containing two data elements: data is a char * to the string value being stored, and next is a StringList * to the next element of the list. The list is NULL terminated. This typedef has its own constructor and destructor. The constructor takes a char *, creates space for the string, and copies it. The destructor deallocates that space. This structure is used to return the value(s) for a given parameter name.
Functions
Bool okay ( void )
Returns TRUE if the file could be opened, FALSE otherwise.
StringList *find ( char *keyword )
Returns a linked list of StringList containing all the data associated with the keyword. If there are no entries in the specified file that match that keyword, then the returned value is NULL. The order of the elements is the same as the order in the file. This function does not allocate any new space, so do not attempt to delete it.

ConstraintForce

Purpose
This class is used to calculate the forces and energies due to harmonic constraints applied to atoms in a molecule. There is a ConstraintForce object present in every patch and it is responsible for calculating constraints for all atoms in the list of constrained atoms.
Files
ConstraintForce.[Ch]
Constructor
ConstraintForce ( void ) The constructor sets the number of constrained atoms to zero and sets the array consAtom to NULL.
Destructor
~ConstraintForce ( void )
Method of Use
There are a small set of public routines which access this object: initialize_timestep(), get_energy(), init(), and force(). There are a few things that go on internally. init() is called during the first step of each cycle. It checks each atom to see if it is to be constrained, and if so, adds it to the list of constrained atoms. This list is referred to when force() and get_energy() are called.
Functions
void initialize_timestep ( void )
Sets the constraint energy to zero at the start of each time step.
void get_energy ( void )
Calculates the constrain energy due to all constrained atoms in a patch.
void init ( int numAtoms, int *atomInd, Vector *x, Vector *f )
This function is called during the first timestep of each cycle to initialize it. It scans through the current local atoms and determines which, if any, are constrained. It makes a list of all those that are along with their force constants and reference positions. This list is then used during all the other time steps to calculate the forces and energies.
void force ( Vector *x, Vector *f )
This function calculates the forces due to the harmonic constraints. It walks down the list of constrained atoms created by the init() function and calculates the energy and forces for each one.

DihedralForce

Purpose
The DihedralForce class is used to calculate the forces and energies due to the dihedral angle of each chain of 3 bonds in a molecule. Since angles, dihedral angles, and improper angles are handled exactly alike, except for the force formulae, all three use the abstract base class MultiBond for everything except the calculation of the forces on an angle from the 3 or 4 atom positions. For a description of the public functions and use of DihedralForce, see the Multibond class description, section MultiBond.
Files
DihedralForce.[Ch], MultiBond.h, and structures.h
Constructor
[See section MultiBond.]
Destructor
[See section MultiBond.]
Method of Use
[See section MultiBond.]
Functions
[See section MultiBond.]

ElectForce

Purpose
Class responsible for calculating all of the short range electrostatic and van der Waals interactions. This includes all electrostatic and van der Waals interactions within the cutoff distance. There is an ElectForce object present in every patch. It is responsible for all local interactions in the local patch, as well as interactions between local and remote atoms.
Files
ElectForce.[Ch]
Constructor
ElectForce ( Patch *parentPatch, PatchList *parentList ) The passed parameters let this object know about the object it owns.
Destructor
~ElectForce()
Method of Use
The public routines to access this class follow the general interface for force objects. There is a local_init() routine that initializes the object for calculation of local interactions and then calculates the force. This function is used only during the first time step of a cycle. The functions local_force() is then used during normal mid-cycle steps to calculate the local interactions. Similarly, the function neighbor_init() is used to initialized the object for interactions with a given neighbor, and neighbor_force() is used to calculate the interaction with a given neighbor during mid-cycle time steps. The function get_energy() is used to return the energy calculated during a time step. The function initialize_timestep() is used to get the object ready for a new timestep. Internally, this object relies on pair lists of interactions. A pairlist is built for the local interactions, and a pairlist is built for each neighbor that sends all of its atoms to this patch. Each pairlist is built by looking at every pair of atoms involved. First the Molecule class is queried to check for exclusions. Explicit exclusions, as well as bonded exclusions are checked. The bonded exclusions are applied according to the value of the exclude keyword in the user input file. If there are no exclusions, the distance between the two atoms is calculated and compared to the cutoff distance. If the distance is within the cutoff distance, then the pair needs to be calculated. At this point, the constant factor electrostatics, is computed and stored in the pairlist along with the computed van der Waals parameters A and B. From this point, the energy and forces can be computed by using the distance between the atoms and the pre-computed constants.
Functions
void initialize_timestep ( void )
Prepares the object for a new time step. This is basically just setting the accumulated energy to 0.
void neighbor_init ( int nid, int remoteNum, int *remoteGlb, Vector *remoteX, Vector *remoteF, int localNum, int localGlb, Vector *localX, Vector *localF )
Initialize the object for interactions with the neighboring patch specified by nid and then calculate the interactions with this neighbor, returning the forces on the local atoms. These are added to the array localF, and forces on the atoms from the neighbor are returned in the array remoteF. This basically involves building the pairlist, and as each pair is added to the pairlist, computing the forces and energies due to this interaction. The other parameters are: remoteNum is the number of atoms that the neighbor has; remoteGlb is the array of global atom indexes for the neighboring atoms; remoteX is the array of positions for the neighboring atoms; localNum is the number of atoms on the local patch; localGlb is the array of global atom indexes for the local atoms; and localX is the array of positions for the local atoms. This function should be called only during the first time step of each cycle.
void neighbor_force ( int nid, Vector *remoteX, Vector *remoteF, Vector *localX, Vector *localF )
Calculate the interactions with the neighbor specified by nid. The forces on local atoms are added to the array localF, and the forces on neighboring atoms are returned in the array remoteF. The arrays remoteF and localF specify the neighboring and local positions of the atoms. This function should only be called during mid-cycle time steps.
void local_init ( int numLocal, int *localGlb, Vector *x, Vector *f )
Initialize the object to calculate the local interactions and calculate them, adding the forces to the array f. This involves building the local pairlist and calculating the forces and energies for each pair. The other parameters are: numLocal specifies the number of local atoms; localGlb is the array containing the global atom indexes for the local atoms; and x is the array of positions for the local atoms. This function should only be called during the first time step of each cycle.
void local_force ( Vector *x, Vector *f )
Calculate the local interactions during a normal timestep. The forces are added to the array f. The current positions of the atoms are passed in via the array x.
BigReal get_energy ( void )
Return the energy calculated during the current time step.

FieldForce

Purpose
FieldForce calculates the energies and forces due to the electric field.
Files
FieldForce.[Ch]
Constructor
FieldForce ( void ) This is the constructor for the ForceField class. It just gets the eField vector from the SimParameters object and initializes the other attributes to starting values.
Destructor
~FieldForce ( void )
Method of Use
There are a small set of public routines which access this object: initialize_timestep(), get_energy(), init(), and force(). There are a few things that go on internally. init() is called during the first step of each cycle. It checks each atom and records its partial charge. These are used to compute the force for each time step in the cycle.
Functions
void initialize_timestep ( void )
Sets the constraint energy to zero at the start of each time step.
void get_energy ( void )
Calculates the electrostatic energy due to all atoms in a patch.
void init ( int numAtoms, int *atomInd, Vector *x, Vector *f )
Initialize the force object for a cycle. This lets the object figure out how many atoms there are and the charge on these atoms. Then it calculates the force and updates the force vectors passed in.
void force ( Vector *x, Vector *f )
Routine which does the actual force calculation.

FMAInterface

Purpose
The FMAInterface class provides the interface to the FMA code. It is responsible for gathering the coordinates from the patches on each node and passing them to the FMA implementation and then distributing the results from the FMA back to the patches when they need them. The version distributed with FMD uses FMM3D, if LRFM is defined, otherwise it does nothing. In contrast to some implementations, FMM3D has only one entry point, which does all initialization, calculation, and cleanup involved in computing all forces from all charges and positions.
Files
FMAInterface.[Ch]
Constructor
FMAInterface ( Bool IamMaster ) The FMM3D version basically just sets the class members to a defined state. (Note that FMM3D does not need any per-run initialization.)
Destructor
~FMAInterface ( void ) Releases any dynamically allocated memory in the object.
Method of Use
There are just a few public functions: execute_FMA(), deposit_coordinates, and get_patch_forces(). They serve as the means for getting data into and results out off the FMA library.
Functions
void execute_FMA ( void )
This function effects the calculation of the forces. It does this by calling an interface routine, fmd_to_fmm3d, which
  1. takes the coordinates and charges from each node and broadcasts them to all nodes, so that all nodes have all coordinates and charge strengths;
  2. calls FMM3D, which leaves all results on the master node; and
  3. scatters the results to the nodes where they belong.
Note that It assumes that all the necessary data from the patches has been gathered by the time it is called.
void deposit_coords ( int pid, int num, int *indexes,
Vector *x )
This function provides the mechanism for the patches on this node to deposit their coordinate data. It takes the atom indexes, and positions and places them into a linked list that is then used to retrieve the data.
void get_patch_forces ( int pid, Vector *f, BigReal &patchEnergy )
This function retrieves the results of the FMA calculation for a specific patch.

FullDirect

Purpose
The FullDirect class provides a means to calculate full electrodynamics.
Files
FullDirect.[Ch]
Constructor
FullDirect ( void ) The constructor calls the appropriate setup routine in the FMM3D library and sets up the necessary data structures.
Destructor
~FullDirect ( void )
Functions
void start_direct ( void )
This function starts the direct calculations going. It sends out coordinate messages to all the nodes that this node sends to and performs the calculations for pairs on this node.
void calc_with_node ( int node, Message *msg )
This function calculates interactions between this node and the node specified. It computes the interactions, adds the forces to the local force vectors, and sends a message containing the forces back to the other node.
void add_forces ( Message *msg )
This function adds forces that were calculated by another node.
void deposit_coords ( int pid, int num, int *indexes, Vector *x )
This function provides the mechanism for the patches on this node to deposit their coordinate data. It takes the atom indexes, and positions and places them into a linked list that is then used to retrieve the data.
void get_patch_forces ( int pid, Vector *f, BigReal &patchEnergy )
This function retrieves the results of the calculation for a specific patch.
void wait_for_calcs ( void )
This function is used when some patch on the node needs forces BEFORE they are computed completely. It sits and waits until all the messages necessary arrive.

GenericList

Purpose
GenericList<T> is a template class which implements a one-directional list in a somewhat more storage-efficient manner than, say, a simple linked list. Currently, it uses a two-stage table system. It is fully inlined, i.e., there is no .C file, only a .h file.
Files
GenericList.h
Constructor
GenericList ( int numEntries ) numEntries is the maximum number of atom entries that could be stored in this list. It is used to approximate how big the segments should be. An incorrect number here won't cause failure, but could cause the segment size to be too large or too small. This would lead to either wasted memory, or inefficient access
Destructor
~GenericList ( void )
Method of Use
The constructor must be called with an argument. GenericList only provides for one-way linear iteration through the list. Provision is made to add individual entries, but not delete them (the whole list must be reset or deleted and recreated.) Objects of type T are created, assigned, copied, and deleted in the usual fashion, so a default constructor, copy constructor, destructor, and assignment operator must be available (possibly just the compiler-generated ones.)
Functions
int size()
Returns the number of entries in the list.
void reset()
Reset the list to be used again. We don't free any memory, just reset the number of valid entries and the current traversal position.
void add ( Entry entry )
Add a new entry to the list.
const Entry *head ()
Reset the current traversal position to the beginning and return the first entry in the list, or NULL if the list is empty
const Entry *next ()
Get the next value in the in order traversal. Return NULL if the end of the list is reached.

GlobalIntegrate

Purpose
The class GlobalIntegrate is used to facilitate the testing and possible implementation of integration methods which require global information about all atoms. When global integration is performed, patches deposit their forces, velocities, and coordinates in a single set of global arrays, just like having one big patch.
Files
GlobalIntegrate.[Ch]
Constructor
GlobalIntegrate ( void ) The constructor calls the appropriate setup routine in the FMM3D library and sets up the necessary data structures.
Destructor
~GlobalIntegrate ( void )
Functions
void process_msg ( int /* node */, Message *msg )
This serves as our own little message center and will be expanded to handle messages between GlobalIntegrate objects on different nodes.
void deposit_atoms ( int pid, int num, int *indexes, Vector *px,
Vector *pv, Vector *pf, Vector *pvh, int cycle, int first, int tstep )
This is called by patches to drop off their atoms. When all of the patches are done, this triggers integration.
void return_atoms ( PatchInfo *cl )
This puts coordinates, etc. back on the given patch.
void do_integration ( void )
Call the appropriate integrator.
void do_verlet ( void )
Simple verlet integrator, for testing and as an example for those who wish to test integration methods. Copied verbatim as much as possible from Integrate.C.
void do_COLD ( void )
Performs Constrained Overdamped Langevin Dynamics. This method supposedly allows very long time steps. Constraints and a first order equation in time allow dihedral angle dynamics to be calculated exactly. The underlying integrator is a two-step Runge-Kutta. Only the even time steps, therefore, contain accurate information. So really, the timestep is twice as long but you've only done half as many as the output and parameters claim. It just makes more sense to equate a timestep with a single force evaluation. This method also allowed for minimal modification of fmd's control structure.
void do_dihedral ( void )
In the future this will perform some sort of full dihedral angle dynamics. Right now the method is slow and untested.
void do_hard_dist_constrs ( void )
This function, and its supporting functions, set up systems of hard distance constraints for (hopefully) all biologically relevant structures. The code is very fragile. Don't mess with it.

HashTable

Purpose
HashTable<T> is a template class which implements a simple hash table with entries of type T, and non-negative indices of type long. It is fully inlined, i.e., there is no .C file, only a .h file. The implementation is rather simple-minded, and ignores all of the literature on designing hash tables. It should not be used as a model for writing hash tables. Its only virtues are that it is simple (no divides needed) and that it is fast enough so that the total time spent in it is negligible compared with the rest of fmd. For example, the table length is always a power of 2, so that the hash is computed with shifts, adds, and masks. Collisions are handled by having the actual elements in the table array be pointers to linked lists of the entries that hash to the same array element. Because NameTable creates, deletes, and assigns objects of type T as if they were of a built-in type, if type T has a more complex structure, it must have constructors, destructors, and assignment operators as necessary to allow this sort of use. HashTable does not explicitly initialize the objects; if this is desired, a no-argument constructor must be supplied. Type T must also be able to convert 0 to type T. An additional feature is a "current entry" pointer. This internal pointer is set by functions that reference by an index to point to the most recently referenced entry, or set to a "reset" state if there is no sensible definition if the entry referred to by the index has been deleted or did not exist and was not created. It can also be explicitly reset, moved to the next entry in the table, and the current entry's index or value can be returned. It is also used as a "cache": if the same entry is referenced by index twice in a row, the cached values are used directly, rather than searching the table again.
Files
HashTable.h
Constructor
HashTable<T> ( nentries, maxindex ) Creates the table. nentries is a rough estimate of the number of entries expected; it is used to choose the size of the table array. If it is too big, the table will have many unused elements, and if it is too small, there will be more collisions and thus more searching of the linked lists. maxindex is the largest index value used that will be used, and is used to choose the hash function.
Destructor
~HashTable ( void ) Deletes the hash table and its entries.
Method of Use
The constructor must be called with the two arguments to create the table. The most common operation on the table will be subscripting (operator []), which returns a reference to the entry corresponding to the index supplied, creating one if necessary. Associated with this function are other functions that check for the presence of entries, create and delete them, and allow one to dump out the entries, etc. There are also "iterator" functions, which implicitly use the current entry pointer in place of an index.
Functions
T& operator []( long index )
Given an integer index value, this returns a reference (lvalue) to the entry with that index. If no entry existed for that index, one is created. The current entry pointer is set to this entry.
Bool exists( long index )
If the entry corresponding to the index already exists, set the current entry pointer to this entry and return TRUE, otherwise reset the current entry pointer and return FALSE.
void create( long index )
Creates an (empty) entry if none exists. In any case, set the current entry pointer to this entry.
void remove( long index )
Deletes an entry if it exists, otherwise it does nothing. Also resets the current entry pointer.
int nentries( )
Return the number of entries in the table.
void reset_iterator( )
Reset the current entry pointer.
Bool next( )
Move the current entry pointer to the next entry. If the pointer had been reset, set it to the first entry in the table. If there is no next entry, reset the current entry pointer and return FALSE. If there is a next entry, return TRUE,
long current_index( )
If the current entry pointer is set, return the index value for the current entry. If it is reset, call next() to advance to the first entry, and return its index value. If there is no first entry, return -1.
T current_data( )
If the current entry pointer is set, return the data value for the current entry. If it is reset, call next() to advance to the first entry, and return its data value. If there is no first entry, return T(0).
T* current_datap( )
If the current entry pointer is set, return a pointer to where the current entry's value is stored. If it is reset, call next() to advance to the first entry, and return a pointer to the value.
void dump_data( char *formatdata( T& data ) )
This function prints out all the table entries on the standard output, using printf(). The data objects are formatted using formatdata(), a user-supplied function. formatdata() must return a pointer to a character string, created with new[], containing the formatted data.

ImproperForce

Purpose
The ImproperForce class is used to calculate the forces and energies due to each improper angle, i.e., the non-flatness of each set of 3 atoms directly bonded to a fourth atom in a molecule. Since angles, dihedral angles, and improper angles are handled exactly alike, except for the force formulae, all three use the abstract base class MultiBond for everything except the calculation of the forces on an angle from the 3 or 4 atom positions. For a description of the public functions and use of ImproperForce, see the Multibond class description, section MultiBond.
Files
ImproperForce.[Ch], MultiBond.h, and structures.h
Constructor
[See section MultiBond.]
Destructor
[See section MultiBond.]
Method of Use
[See section MultiBond.]
Functions
[See section MultiBond.]

Integrate

Purpose
Integrates the equations of motion to calculate new positions of the atoms belonging to the parent patch. Every patch has an instance of this object. The current implementation used the velocity form of the Verlet-I or Leapfrog method.
Files
Integrate.[Ch]
Constructor
Integrate ( void ) New empty integrate, with no intermediate velocities.
Destructor
~Integrate ( void )
Method of Use
Every patch creates an instance of Integrate and uses the same integrate for its lifetime. The integrate is initialized by invoking init() and supplying the number of local atoms maintained by the patch. There are three more functions that are invoked by the patch: do_integration(), add_atoms(), and delete_atoms().
Functions
void init ( int )
Initializes the integrate object.
void add_atoms ( int, Vector * )
Augments the intermediate velocity vector du to new atoms. (Not yet implemented.)
int delete_atoms ( int, Vector * )
Shrink the intermediate velocity vector due to removed atoms. (Not yet implemented).
void do_integration ( Vector *x, Vector *v, Vector *f, int *global_nums, int tstep, int firsttstep )
Updates atom positions based on forces, timestep and velocity. Here x is the current position vector, v is the current velocity vector, f is the current force vector, global_nums is the array of global atom indexes for the atoms, tstep is the current time step we're in, and firsttstep was the time step this run started with.

Inform

Purpose
Sends messages from the current node to a single destination node, where they are displayed. When displayed, the messages indicate the type of message (informative, warning, error, or debug), the node which sent it, and the message text. An Inform object should be present on all nodes. All but one of the nodes will just forward their messages to the host node with logical ID 0. The host node will periodically check for messages, and print them out.
Files
Inform.[Ch]
Constructor
Inform ( char *name [, ison = 1 ] ) Creates a new Inform object, with the string identifier name. This identifier is the name of the object and is printed with every message. By default, messages will be printed. This can be changed by setting the optional argument ison to 0.
Destructor
~Inform ( void )
Method of Use
Each Inform object has an active message buffer. To put data into this buffer, use the << operator. For example:
inform << "Message number " << 2 << "\n Second line."
       << sendmsg;
The << operator will accept strings and all atomic data types (int, double, float, etc.). The sendmsg manipulator can be used to signal that the message is complete and should be sent. Its use is equivalent to doing the following:
inform << "Message number " << 2 << "\n Second line.";
inform.send ();
Newline characters in the message are used to break up the message into multiple lines when the message is printed out. When displayed, each line up to a newline is printed with a leading message. The above example, if executed from node 2 by an object named "Messenger", would produce the following output on the host node:
   Node 2:Messenger> Message number 2
   Node 2:Messenger> Second line.
Functions
void use_comm ( Communicate *c, int newnode = 0, int newtag = 0 )
Provides the Inform object with data needed to send messages. The given Communicate object is used to send messages to the destination node newnode, with the given tag newtag. This can be called at any time. By default, an Inform object has no Communicate object, and will send to node 0 with tag 0. If no Communicate object has been provided when a message is told to be sent, the message is printed to the console device.
void on ( int ) || int on ( void )
Turns an Inform object on/off, or queries whether the Inform object will send or display it's messages. By default, messages are sent.
void destination ( ostream * )
For the host node, set the destination ostream object to which messages are sent. By default, this is cout, but can be changed to anything, a log file for example.
int check ( void )
On the host node, this checks for any incoming Inform messages from the other nodes, and sends them on to the designated ostream. This must be called periodically to keep the incoming messages from accruing. For non-host nodes, this does nothing. The number of messages received during a check is returned.
int send ( void )
An Inform object has a current message buffer, to which data is added by using the << operator. Once a message has been set up, the send routine takes the current message and forwards it to the host node. On the host node, this results in the message being printed out immediately.

IntList

Purpose
Provides a flexible list of integers with constant time access to any element, and expandable storage that is transparent to the user. It is basically an array of integers where all the details are maintained internally.
Files
IntList.[Ch]
Constructor
IntList ( void )
Destructor
~IntList ( void )
Operators
The bracket operators can be used to access an element in the IntList in constant time, just as if it where an array.
Functions
int num ( void )
Returns the number of integers in the list.
void add ( int newint )
Adds a new integer to the list.
Bool unique ( void )
Compares elements of a list and returns true if each value appears only once.

IntTree

Purpose
Provides a specialized binary tree for integers. It could easily be changed for more general use, but at the moment, its sole purpose in being is to keep track of atoms that need to be sent as bonded coordinates. As such, IntTree takes a series of integers as input. It then stores only the distinct values as a binary tree. Upon request, all the values in the tree can be returned in the form of an array of integers. The IntTree class is used to track atoms that need to be sent to a neighbor as bonded coordinates. A single IntTree object is used and is passed to each of the bond force objects as they initialize themselves with a neighbor who sends all of their coordinates. Each object places the local atom indexes of the atom coordinates that need to be sent to the neighbor into the IntTree object. Since the tree only stores distinct values, after the object has been passed to all the force objects, the contents can be dumped to an array of integers that then represents all the atoms that need to be sent to this neighbor.
Files
IntTree.[Ch]
Constructor
IntTree ( void )
Destructor
~IntTree ( void )
Method of Use
There are only three public functions for this class: size, add_value, and make_array.
Functions
int size ( void )
Returns the number of nodes in the tree.
void add_value ( int intval )
Add a value to the tree. Since only distinct values are stored, if the value already exists in the tree, the tree remains unchanged.
int *make_array ( void )
Converts the values in the tree into an array of integers. If there are currently no values in the tree, then NULL is returned.

LintList

Purpose
Provides a simple, completely inlined implementation of a linked list of integers. It is not meant for, nor does it support, anything fancy. It just provides the ability to add items to the list and to traverse the list.
Files
LintList.h
Defined Constants
LIST_EMPTY - This is the value returned when the end of the list is encountered.
Constructor
LintList ( void )
Destructor
~LintList ( void )
Method of Use
There are only three functions used to manipulate this class. The function add() is used to add a new integer to the list. Additions are accomplished in constant time. The function head() returns the first value in the list and sets the current position in the list to be the head of the list. The function next() returns the next value in the list and moves the current position in the list to this element. Both head() and next() return LIST_EMPTY if the list is completely empty or if the end of the list has been reached. Thus, to traverse the list, head() is called once, followed by repeated calls to next() until the value of LIST_EMPTY is returned.
Functions
void add ( int addvalue )
Adds a value to the list. Items are always added to the tail of the list in constant time.
int head ( void )
Sets the current position to the head of the list and returns the value found there. LIST_EMPTY is returned if the list is empty.
int next ( void )
Increments the current position in the list and returns the value found there. If the end of the list has been reached, the value of LIST_EMPTY is returned.

LoadBalance

Purpose
The LoadBalance class is responsible for balancing the computational load between nodes.
Files
LoadBalance.[Ch]
Constructor
LoadBalance ( int myNode ) The constructor initializes the node's data structure.
Destructor
~LoadBalance ( void )
Functions
void init_patches ( int numPatches )
This function initializes the load balancing data structures for the patches.
void delete_patches ( void )
This function removes patches from a node.
void ldb_method1 ( vertex **VArray, int NumCells, int NumProcs )
This function attempts to balance the load of a number of processes over a smaller number of processors. Each node of this graph represents the computation load for a patch, and the between nodes represent the communications costs between the respective patches. Currently, this routine only uses the node load to calculate a mean load with some standard deviation., and then moves all nodes greater than some defined threshold to less heavily loaded nodes. The link information is ignored, so locality is not considered. Other functions are:
void down_heap ( procLoad *a, int n, int k )
int cmp_loads ( const void *p1, const void *p2 )
void deposit_load_stats ( LoadStats *lstats )
void send_load_info ()
int receive_load_info ( Message *msg )
void compute_patch_changes ()
void send_patch_changes ( int *numToRecv,
                          IntList *sendList,
                          IntList *destList )
void patch_changes_complete ( void )

LongForce

Purpose
LongForce provides the patch level interface to the long range electrostatics module. It provides the means to deposit patch data to the node level FMAInterface object and to return the forces to the Patch for use in the computations.
Files
LongForce.[Ch]
Constructor
LongForce ( int patchid )
LongForce ( int patchid, int n, Message *msg )
Destructor
~LongForce()
Method of Use
There are a small set of public routines which access this object: initialize_timestep(), end_cycle(), init(), initialize_first_timestep(), calc_eff_force(), get_long_force(), send_atom_info(), prepare_to_receive_atoms, receive_atom_info, send_forces, and save_state().
Functions
void calc_eff_force ( Vector *subForce, BigReal subEnergy )
This function calculates the effective long range forces which means gathering the total electrostatic forces and subtracting off local and excluded interactions.
void init ( int n )
Initialize this object. Basically, get the number of atoms in the patch and allocate some arrays.
void initialize_first_timestep ( int n, int *localGlb, Vector *x,
int step )
Initialize for first timestep in a cycle. This is when each patch needs to dump its coordinates to the FMAInterface object.
void initialize_timestep ( void )
Get the object ready for a new time step.
void get_long_force ( Vector *localF )
This is the function that adds the long range forces to the local forces. During the first timestep of each cycle, it first retrieves the forces needed from the FMAInterface object.
void end_cycle ( void )
This function deals with the end of an integration cycle. It adjusts forces according to the MTS scheme used and sets the appropriate flags.
void send_atom_info ( Message *msg, int numSend,
LintList *send_atoms )
This function sends the information for atoms that are leaving the patch. It builds an array of vectors based on the list of atoms passed in and puts this array into the Message.
void prepare_to_receive_atoms ( int numAdded, int numRemoved,
LintList *atomsRemoved)
This function reallocates the necessary data structures during atom reassignment. It allocates a new array for the half-step velocities, copies over old information that is to be preserved, and gets ready to receive new information that will be coming.
void receive_atom_info ( int nAtoms, Message *msg )
This function takes a message from a neighboring patch containing information about atoms that have migrated to this patch. It then uses this information to add the atoms its local list. The Message object is passed to us with the current position sitting at the beginning of the Integrator specific information. In this way, the Integrate object doesn't need to know what the Patch passes during atom reassignment and the Patch object doesn't need to know what the Integrate object passes during atom reassignment.
void send_forces ( int nAtoms, int *atoms )
This function deposits the long range forces in the Collect object so they can be gathered and output in a force trajectory file.
void save_state ( Message *msg )
Save the oldEffForce vector in the message buffer, so it can be retrieved after Patch migration due to load balancing.

Message

Purpose
Encapsulates data of various types that is to be sent to another node in a parallel environment. A Message object is created, filled with the data to be sent, and given to a Communicate object to be delivered. Each Message consists of one or more items of different types. A user can query how many items there are, the type and size of each item, and retrieve the items.
Files
Message.[Ch]
Constructor
Message ( void )
Destructor
~Message ( void )
Enumerations
Types: CHAR, SHORT, INT, LONG, FLOAT, DOUBLE, UNKNOW
Method of Use
The object can be used to either send data to another node, or to retrieve data that has been received from another node. To send a Message, first a new Message object is created, then data is put into the object using the put() function. For example:
Message *msg = new Message;
msg->put("Start of message.").put(5,intarray).put(3.14);
communicate->send(msg,node,tag);
The put() routine is overloaded to accept all atomic data types, either single value, or arrays (two arguments, number of elements and pointer to array). There are two ways to store the data for each item in the Message: make a copy of the data, or store a pointer to the data. By default, data you provide in a call to put() is copied into some new storage area allocated by the Message object. For scalar data, a copy of the data is always made. However, for arrays of data, you can instead choose to just have the #Message object store the pointer to the data that you provide in the put() call. Doing this eliminates the overhead of allocating new memory space and performing the copy, but requires you to make sure the data is still available when the Message is actually sent to the destination node (which could be some time after the creation of the Message). When just the pointer is stored, the Message object by default will not free up the storage when the Message is deleted, as it normally does for data it copies to its own storage. You can also choose to have the storage space for data you put() be freed up by the Message object when it is deleted. This might be advantageous if a Message is being constructed with data you have allocated earlier, but have no further need of other than sending it out. When calling put() for arrays of data, there are two optional parameters:
  1. An optional third argument which indicates whether to copy the data (TRUE) or just reference the data (FALSE) via the given pointer. This is TRUE by default (ie. by default, data is copied).
  2. An optional fourth argument which indicates whether to delete the storage space used by the Message for the data (TRUE) or just leave the storage space unchanged (FALSE). This option is ignored if the third argument is TRUE, that is, when a copy is made, the storage is always deleted (since it is allocated by the Message object in the first place). This is FALSE by default (ie. by default, if data is not copied, the storage is not deleted).
For versions of the put() routine for scalar data, there is only one argument ( the data ). There are no optional second and third arguments. For example, the command given just above copies the data from intarray, while this example just specifies the msg store the pointer intarray:
   msg->put(5,intarray,FALSE,FALSE);
   communicate->send(msg,node,tag);
When the Message is deleted, the memory pointed to by intarray is freed up for future use. There are two ways to get data form a Message:
  1. Basic loop. The items() routine will report how many data items there are. The type(n) and size(n) routines report the type and size (in number of elements) for each item, and each item can then be retrieved via the item(n) function.
  2. Iteration. Each Message object has a current item. The reset() routine sets the current item to the beginning of the Message. After this has been done, the type(), size(), and item() routines with no arguments will return data about the current item. To retrieve data and automatically move the current item to the next in the list use the get() routine. This will retrieve the data in the current item, place it in the storage given by the argument, and increment the current item.
Note that new items are appended to the end of a Message. It is possible to delete individual items from the message (using the del(n) routine), or delete all items in the message (with the clear() routine).
Functions
ostream &operator<<
The << operator can be used on an ostream object (such as cout or cerr) to print a summary of the current message. For example:
   Message msg;
   cout << "Contents of of the message:  " << msg;
int items ( void )
Returns the number of items currently stored in the Message. Items are numbered 0..items()-1.
int size ( int n = (-1) )
Returns the size ( in number of elements ) of the n'th item. If no argument is given, returns the size of the current item.
Types type ( int n = (-1) )
Returns the type (one of the enumeration Types) of the n'th item. If no argument is given, returns the type of the current item.
void *item ( int n = (-1) )
Returns a pointer to the n'th item data entry. Since the data can be of many types, it returns a pointer to void. If no argument is given, it returns a pointer to the current item's data.
Message &del ( int n = (-1) )
Deletes the n'th item's data storage. If no argument is give, it does so for the current item.
Message &clear ( void )
Deletes the storage for ALL items in the current message.
Message &reset ( void )
Resets the current item to be the first one in the message.
Message &skip ( void )
Moves the current item on to the next item in the message.
&back ( void )
Moves the current item back to the previous item in the message.
Message &current ( int n )
Sets the current item to be the n'th item in the message.
Message &put ( char * d )
Message &put ( <type) d )
Message &put ( int n, <type> *d, int copy = TRUE, int delstor = FALSE )
The put routine adds new items to the end of a Message. The first form adds a null terminated string, the second adds a scalar of type Types, and the thirds adds an array of type Types of size n. The third form has two optional arguments. copy indicates if a copy of the data is to be made. delstor indicates if Message is responsible for deleting storage when it is done.
Message &get ( <type> &d )
Message &get ( <type> *d )
The get routine retrieves the data from the current item, and copies it into the argument d. The caller must know what type of data is to be retrieved, and call get with the appropriate argument type. Space must be provided by the caller to store the retrieved data; it is NOT allocated by get. The first form retrieves a scalar value, the second a vector (array) value. If the type of the current item does not match the argument, or there is no current message, get does nothing. The size and type of the current message can be found with the size() and type() functions, respectively.

MessageManager

Purpose
Provides, as completely inlined class, an efficient storage mechanism for Messages that have been received. It allows the retrieval of a Message with a specific tag from any node in constant time. This is the case used to retrieve virtually all messages in fmd. It searches for messages with any tag but from a specific node or from any node with any tag in O(N) time, where N is the total number of messages currently stored. (There are currently no such searches done in fmd.) The class is currently implemented using an array of MessageQueue objects, where each queue stores messages with a specific tag. There is one such object for each tag used in the program. Therefore, all messages with a given tag are stored in a single MessageQueue object. Two MessageQueue objects are used by each Communicate class: one to store messages from other nodes, and one to store messages sent by patches on the same node.
Files
MessageManger.[Ch]
Constructor
MessageManager ( void )
Destructor
~MessageManager ( void )
Functions
int num ( void )
Returns the number of Message objects currently stored.
void add_msg ( MsgList *new_msg )
Add the Message enclosed in the structure new_msg. This addition is performed in constant time.
MsgList *get_head ( void )
Returns a pointer to the Message at the head of the queue and takes it off of the queue. If the list is empty, NULL is returned. This operation is performed in constant time.
MsgList *find_msg ( int tag, int node )
Finds the first message with the specified tag and node. If tag=-1, the first message matching node with any tag is returned.

MessageQueue

Purpose
The MesageQueue class is an almost completely inlined class that provides a FIFO queue of Message objects. The principle property of these queues is constant time addition of messages and retrieval of the head of the queue. Searches of the queue for messages with a specific property, such as node or tag value, are O(N), where N is the number of messages stored in the queue. The class is currently implemented as a doubly linked list. The class is presently used only by MessageManager, which uses these queues to efficiently search for stored messages.
Files
MessageQueue.[Ch]
Constructor
MessageQueue ( void )
Destructor
~MessageQueue ( void )
Functions
int num ( void )
Returns the number of Messages currently stored in the queue.
void add_msg ( MsgList *new_msg )
Add the Message enclosed in the structure new_message into the queue. The addition is performed in constant time.
MsgList *get_head ( void )
Return a pointer to the Message at the head of the queue and take it off the queue. If the list is empty, NULL is returned. This operation is also performed in constant time.
MsgList *get_msg_by_node ( int node )
Return a pointer to the first Message on the queue with the node indicated by node and remove it from the queue. If there is no Message on the queue with a node that matches, return NULL. This operation is accomplished in O(N) time.
MsgList *get_msg_by_tag ( int tag )
Return a pointer to the first Message on the queue with the tag indicated by tag and remove it from the queue. If there is no Message with matching tag, NULL is returned. This operation is accomplished in O(N) time. In the current implementation of MessageManager, this operation is never sued, but is provided for completeness.

Molecule

Purpose
The Molecule class is used to read in, store, and access the molecular structure. Information is read from an X-PLOR formatted .psf file. This information includes a list of all the atoms along with their mass and charge; lists of all bonds, bond angles, dihedral angles, and improper dihedral angles; and a list of explicit electrostatic exceptions. A Molecule object will reside on each of the processors, with the same data in each. The .psf file is read in on the master node, and the information is then distributed to the other processors.
Files
Molecule.[Ch], structures.h
Constructor
Molecule ( void )
Destructor
~Molecule ( void )
Method of Use
The function read_psf_file() is used to read in the structure file specified. This function should be called only on the master processor (node 0) to read in the .psf file specified in the user input file. The master processor then sends all the class data values with a call to send_molecule(), and the other processors receive them with a call to receive_molecule(). The Parameter object then verifies that all of the parameters needed by the .psf file have been read in.
Public Member Variables
int numAtoms
Number of atoms.
int numBonds
Number of bonds.
int numAngles
Number of bond angles (2 atoms joined to a third.)
int numDihedrals
Number of dihedral angles (4 atoms whose bonds form a chain.)
int numImpropers
Number of improper angles (3 atoms bonded to a fourth.)
int numExclusons
Number of explicit exclusions, as read from the PSF file.
int numConstraints
Number of constrained atoms, calculated from the constraint PDB file.
int numMultipleDihedrals
Number of dihedral angles whose force law has more than one term. (This happens only if (a) the same ordered set of 4 atoms appears twice or more in a row in the PSF file and (b) more than one set of parameter specs for this ordered set of atom types appears in a row in the parameter file.)
int numMultipleImpropers
Like numMultipleDihedrals, but for improper angles.
Public Functions
void read_psf_file ( char *name, Parameters *params )
Read in the .psf file specified by name and use the Parameters object params to verify that all of the parameters necessary for this structure have been specified. When the NTITLE block is read from the PSF file, the function checks for the presence of the keyword BASE64 anywhere in the lines. If found, all numbers are treated as if they were written in base-64 notation, using the character set "0-9A-Za-z@#".
void send_Molecule(Communicate *msg)
Send all values from the Molecule object to another node (usually from the master to the other nodes.)
void receive_Molecule(Message *msg);
Receive values from another node and initialize a Molecule object with them. If used correctly, the object should be effectively a copy of the one on the master node.
void build_constraint_params ( StringList *consref,
StringList *conskfile, StringList *conskcol, PDB *initial_pdb, char *cwd )
This function builds all the parameters that are necessary to do harmonic constraints. The first three arguments are the input configuration parameter values, the fourth is a PDB structure with initial positions (used if no consref file is supplied), and the last is the working directory.
void build_langevin_params ( StringList *langfile,
StringList *langcol, PDB *initial_pdb, char *cwd)
This function builds the array of b values necessary for Langevin dynamics.
langfile
Value of langevinfile from config file
langcol
Value of langevincol from config file
initial_pdb
PDB object that contains initial positions
cwd
Current working directory
Real atommass ( int anum )
Get the atom mass for a given global atom number.
Real atomimass ( int anum )
Get the atom inverse mass for a given global atom number.
Real atomcharge ( int anum )
Get the atom charge for a given global atom number.
Index atomvdwtype ( int anum )
Get the atom van der Waals type index for a given global atom number.
Bond *get_bond ( int bnum )
Get the bond object for a given bond number.
Angle *get_angle ( int anum )
Get the angle object for a given angle number.
Dihedral *get_dihedral ( int dnum )
Get the dihedral angle object for a given dihedral angle number.
Improper *get_improper ( int inum )
Get the improper angle object for a given improper angle number.
long get_atomtype ( int anum )
Retrieve an atom type, as an integer. To convert to a string, call Parameters::atom_type_name. This call can only be made on the master node.
LintList *get_bonds_for_atom ( int anum )
Returns a list of bonds which include the atom with global number anum.
LintList *get_angles_for_atom ( int anum )
Returns a list of bond angles which include the atom with global number anum.
LintList *get_dihedrals_for_atom ( int anum )
Returns a list of dihedral angles which include the atom with global number anum.
LintList *get_impropers_for_atom ( int anum )
Returns a list of improper angles which include the atom with global number anum.
Bool checkexcl ( int atom1, int atom2 )
Returns TRUE if the electrostatic force between the atoms with global number atom1 and atom2 is explicitly (via the PSF file) or implicitly excluded (according to the value of the configuration parameter Exclude.) 1-4 exclusions are considered only if Exclude is set to 1-4.
Bool check14excl ( int atom1, int atom2 )
Returns TRUE if the electrostatic force between the atoms with global number atom1 and atom2 is to be modified according to the value of the configuration parameter 1-4Scaling. Use this only if Exclude is to set to scaled1-4.
Bool is_atom_constrained ( int atomnum )
Returns TRUE if the atom with global number atomnum is constrained.
void get_cons_params ( Real &k, Vector &refPos, int atomnum )
Gets the constraint parameters ("spring constant" and reference position) for the constrained atom atomnum. Do not call this if the atom is not constrained.
Real langevin_param ( int atomnum )
Returns the friction coefficient for Langevin dynamics.
Real langevin_force_val ( int atomnum )
Returns the random driving force coefficient for Langevin dynamics.
Public Debugging Functions
void print_atoms ( void )
Print out a list of all the atoms read from the .psf file.
void print_bonds ( void )
Print out a list of all the atom bonds read from the .psf file.
void print_angles ( void )
Print out a list of all the bond angles read from the .psf file.
void print_dihedrals ( void )
Print out a list of all the dihedral angles read from the .psf file.
void print_impropers ( void )
Print out a list of all the improper dihedral angles read from the .psf file.
void print_exclusions ( void )
Print out a list of all the explicit exclusions read from the .psf file.

MultiBond

Purpose
The abstract base class MultiBond provides the code and data which are the same in the classes AngleForce, DihedralForce, and ImproperForce, which is to say, almost everything. The derived classes supply only
  1. the number of atoms per term (3 for AngleForce, 4 for the others), and
  2. a virtual function for computing the forces from the positions in one angle/dihedral angle/improper angle.
Note that since MultiBond is an abstract base class, any MultiBond object must also be an AngleForce, DihedralForce, or ImproperForce object. We will speak of MultiBond objects, with the understanding that actual objects will be an instance of one of the three derived classes just mentioned. We shall also use the term "multibond" to refer generically to an angle, a dihedral angle, or an improper angle. There is an AngleForce, a DihedralForce, and a ImproperForce object present in every patch, and each is responsible for calculating the forces due to angles of its type between local atoms, as well as between local atoms and atoms from neighboring patches. In contrast to BondForce objects, each MultiBond object processes every multibond involving an atom on its patch, but computes the forces only on its local atoms. Thus, each patch must send coordinates to and wait for coordinates from each neighbor with whom it shares a multibond.
Files
MultiBond.[Ch], HashTable.h, and structures.h
Constructor
MultiBond(Patch *parentPatch, PatchList *parentList) AngleForce(Patch *parentPatch, PatchList *parentList) DihedralForce(Patch *parentPatch, PatchList *parentList) ImproperForce(Patch *parentPatch, PatchList *parentList) The parameters parentPatch and parentList allow the object to know who owns it.
Destructor
~MultiBond() AngleForce, DihedralForce, and ImproperForce inherit the destructor.
Method of Use
MultiBond objects have 7 public functions, in addition to the constructor and destructor:
 initialize_timestep(), set_recycle(),
 local_init(),  neighbor_init(),
 local_force(), neighbor_force(),
 get_energy()
At the beginning of each timestep, initialize_timestep() must be called to reset various flags. At the beginning of a cycle, if no atoms have been reassigned to or from this patch, set_recycle() may be called to avoid recomputing certain data structures; otherwise the object must be deleteed and recreated; there is currently no other way to indicate that the multibond lists must be rebuilt from scratch. The next four functions -- local_init() through neighbor_force() -- update the local forces based on positions supplied to the functions, as data becomes available during the timestep. The functions local_init() and neighbor_init() are called during the first timestep in a cycle, and set up data structures in addition to computing forces. The functions local_force() and neighbor_force() only compute the forces. First, local_init() or local_force() must be called to compute the forces due to multibonds which do not involve neighbor atoms. Then, each time a set of coordinates comes in from a neighbor patch, neighbor_init() or neighbor_force() must be called to update the forces on local atoms, based on the coordinates that come in. The idea is that the forces for a given multibond are computed as soon as the messages received so far include all the atom positions needed for that multibond. The force computation is complete when coordinates have been received from all neighbors with whom this patch shares any multibonds. (No check is made for this.) Each patch accumulates the multibond potential energy for those multibonds whose first atom belongs to the patch; this assures that the sum of the multibond potential over patches will get the right answer, counting each multibond exactly once. The energy thus accumulated by a patch is returned by a call to get_energy(). To hold the atom positions for multibonds which have to wait for coordinates from a neighbor patch, a MultiBond object keeps a list with a structure for each such multibond. Each such structure has an entry for the position of each atom involved in the multibond. As each atom position comes in (via neighbor_init() or neighbor_force()), it is entered into the structures for the multibonds that include that atom. Once all the position entries have been filled in, the forces are computed. To match neighbor atoms with multibond structures efficiently, a MultiBond object also keeps, for each neighbor, an array of pointers, each of which corresponds to an atom whose positions it gets from that neighbor, and points to a list of the multibonds it appears in, if any. These arrays and lists are built by neighbor_init() during the first timestep of a cycle. Since neighbor_force() receives a bare array of positions, without atom numbers, it must identify the atom by its index in the position array. However, the multibond arrays initially only have global atom numbers. To convert from one to the other, yet another data structure is built: a hash table, indexed by global atom number, each of whose entries points to a list of multibonds which the atom with that global atom number appears in. neighbor_init() then uses the global atom number for each position received to pick out the list of multibonds for that atom. At the beginning of a cycle, an object knows which atoms belong to other patches, but not which patches those atoms belong to. It cannot send its positions to a particular patch until it has gotten positions from it to know which multibonds it shares with the local patch. The apparent deadlock is resolved by the fact that, for any pair of patches, one of the patches will send all its positions to the other without waiting for a request for specific positions. This is managed outside the MultiBond class; it is just that in the receiving patch, neighbor_init() will be called with all of the sending patches positions. The receiving patch then signals its caller which positions should be sent back. There are certain aspects of the current implementation of this object that are questionable. Currently, the most questionable is the way the angle list is constructed. It requires a list of the angles that each atom is involved in to be stored. This is fairly expensive in terms of memory, but quick. This scheme should be revisited some time later.
Functions
void initialize_timestep ()
Initializes various flags for a new time step. Must be called before anything else in a timestep (except set_recycle().)
set_recycle()
If the set of atoms in the patch has not changed since the previous cycle, set_recycle() should be called instead of deleteing and recreating the object, as "recycling" the object avoids having to rebuild all the data structures.
void local_init ( int nlocal, int *localGlb, Vector *localx,
Vector *f ); This function
  1. builds the multibond lists and the hash table, if it has not already been done this cycle.
  2. computes the data structures needed by local_force().
  3. calls local_force(localx,f) to compute the forces.
void local_force ( Vector *x, Vector *f )
Calculate those multibond forces for this patch that do not require any neighbor atom positions. This function should be used during every time step of a cycle except the first time step. If this function is called before local_init(), then bad things will happen.
void neighbor_init ( int nid, int nremote, int nlocal,
int *remoteGlb, int *localGlb, Vector *localx, Vector *remotex, Vector *f, IntTree *send_tree = NULL ); This function
  1. builds the multibond lists and the hash table, if it has not already been done this cycle.
  2. computes the data structures needed by neighbor_force() for processing positions from neighbor nid.
  3. if send_tree is not null, adds to it those atoms whose positions need to be sent to the neighbor nid.
  4. calls neighbor_force(nid,localx,remotex,f) to compute the forces due to multibonds which can only now be computed.
Note that the array of positions may include positions not used by this object. This does not matter as long as future calls to neighbor_force() have the same number of positions corresponding to the same atoms in the same order as the call to neighbor_init(). This function should only be called once per neighbor, and only during the first time step of each cycle.
neighbor_force ( int nid, Vector *localx, Vector *remotex, Vector *f )
Take the list of atom positions sent by neighbor nid and compute the forces due to multibonds which only now have all atom positions. neighbor_init() must have been called already, thus neighbor_force() must be called for every timestep except the first in a cycle.
BigReal get_energy ( void )
Get the multibond energy that has been accumulated during this time step.

NameTable

Purpose
NameTable implements a 1 to 1 mapping between (distinct) "names" (character strings) and indices. Names are allowed to have up to PACKEDNAME_MAX_NAME_LEN (4) characters, and the character set consists of space, A-Z (lower case is converted to upper case), 0-9, "'", "#", and "*". Index values for non-empty strings are always positive. Thus, a 0 index indicates an empty string.
Files
NameTable.[Ch]
Constructor
NameTable ( int initial_size = 64 )
Destructor
~NameTable ( void )
Functions
long index ( const char *name )
This function returns a table index for a character string. Distinct indices imply non-equal strings, ignoring case. The ordering of indices is *not* related to the ordering of strings.
long size ( void )
Returns the number of entries in the table.
char *name ( long index )
Returns a string containing the name corresponding to "index" if index corresponds to a name, otherwise 0 (null pointer). The caller is responsible for delete[]'ing the string.

NeighborList

Purpose
The NeighborList class works in conjunction with the BoundaryMap class to construct neighbor lists. This coupling automatically determines if neighboring patches are real or ghost.
Files
NeighborList.[Ch]
Constructor
NeighborList ( void )
Destructor
~NeighborList ( void )
Method of Use
The NeighborList object is created by a call to createNeighborList which is passed a three integer overlap array and a BoundaryMap. The overlap array gives the number of patches that must be considered neighbors in each direction. Therefore the number of neighbors in a single dimension j is twice the offset[j] plus one. The doubling factor on the offset comes from the offset being a measure of only one direction and there are two directions in every dimension. The addition of one to the doubled offset includes the central patch in the calculation of the number of patches in each dimension. The total number of neighbors is then the product of the number of neighbors in each dimension subtracting one to exclude the central patch, because a patch is NEVER it's own neighbor (the code will detect if this happens, issue an error message and abort the run). createNeighborList then calculates the relative offsets (in terms of the BoundaryMap indices) of these neighboring patches. This set of relative offsets is then used with the BoundaryMap to calculate the patchIds of the neighboring patches of any given patch. This is seen most clearly in the following figure. This is seen most clearly in the following figure. This is a two dimensional representation of the NeighborList. The shaded squares correspond to neighboring patches. This image can be overlayed on the BoundaryMap image and the shaded cells will lay on top of the neighboring patches in the BoundaryMap, which contains the appropriate patchId. See BoundaryMap for more infomation.
Functions
createNeighborList ( const int *overlap, const BoundaryMap& map )
Generates the neighbor list with the specified dimensions, in the integer overlap array, for the given BoundaryMap.
const int& operator[] ( const int index ) const
Returns the relative offset of the neighbor.
const int Length() const
Returns the maximum number of neighbors in the neighbor list.

Node

Purpose
The Node class is where all of the actual work for the simulation is done. It can be thought of as the main() routine which each processor runs. It contains all of the other objects to be used during the simulation and the highest level control structure for the simulation. One Node object will exist on each processor and will handle all of the activity for the simulation required of this processor.
Files
Node.[Ch]
Constructor
Node ( int id ) - where id specifies the logical node number of the processor this Node is on.
Destructor
~Node ( void )
Method of Use
Once the Node object is created on each processor, there are basically only two routines that called externally on each Node. One performs all of the necessary setup and is different for the master node and the client nodes. On the master node, the routine used is master_startup() and on the client nodes client_startup() is used. Once the Node object is started, the doSimulation() function is called, and the Node object then takes over the control of the simulation.
Objects with Node
The purpose of the Node object is to hold all of the other objects in the program and control their execution. The objects that are contained by each Node object are:
Molecule *stucture
Molecular structure read in from the .psf file.
Parameters *params
The energy parameters from the parameter file(s).
SimParameters *simParams
The global simulation parameters, such as time step size, number of time steps, etc.
PatchDistrib *patchMap
The mapping of patches to processors.
PatchList *patchList
The object which contains all of the Patchs that are assigned to this processor.
Functions
void master_startup ( int argc, char **argv )
Initialize the Node object on the master node. This involves starting up all the other objects, reading in the appropriate files, and then sending this information to all of the client nodes. The arguments argc and argv are used to obtain the user input file name that is passed on the command line.
void client_startup ( void )
Initialize the Node object on a client node. This involves allocating all of the objects and then receiving the information from from the master process.
void doSimulation ( void )
Function which controls the simulation.
void velocities_from_PDB ( Vector *v, char *fname )
This is a PRIVATE function used by the master node to determine the initial velocities for all the atoms from a PDB file. The name of the PDB file to be read is specified by fname and the array of velocity vectors to populate is given by v.
void random_velocities ( Vector *v, BigReal temp )
This is a PRIVATE function used by the master node to determine the initial velocity for all atoms using a random Maxwellian distribution. The temperature for this distribution is given by the temp argument, and the array of velocity vectors to populate is given by v.

Output

Purpose
The Output class is used to produce the useful output of fmd, such as the energy values for a time step, trajectory files, restart files, and the final position and velocity files. This object exists only on the master node, and is owned and operated by the Collect object.
Files
Output.[Ch], dcdlib.[Ch]
Constructor
Output()
Destructor
~Output()
Method of Use
There are only three public functions in the Output class. They are used by the Collect object to pass along values that is has collected. The Output object then takes this data and calls the appropriate private routines to actually output the data. There are only three public routines, and each is pretty self explanatory.
Functions
void energy ( int timestep, BigReal *energies )
Takes the energies for the time step specified by timestep in the array energies and outputs them, currently just to standard output. It also sums all the component energies to get a total energy sum, and computes and reports the temperature based on the kinetic energy.
void coordinate ( int timestep, int n, Vector *coor )
Takes the n positions for time step timestep from the array coor and calls the appropriate output routines to write them to the restart file, trajectory files, etc., as specified by the configuration parameters.
void velocity ( int timestep, int n, Vector *vel )
Takes the n velocity vectors for time step timestep from the array vel and calls the appropriate output routines to write them to the restart file, trajectory files, etc., as specified by the configuration parameters.
void short_force ( int timestep, int n, Vector *f )
Takes the n force vectors for time step timestep from the array f and calls the appropriate output routines to write them to the trajectory files, etc., for short-range electrostatic forces, as specified by the configuration parameters. Short_range electrostatic forces are the ones that are recomputed every timestep.
void long_force ( int timestep, int n, Vector *f )
Takes the n force vectors for time step timestep from the array f and calls the appropriate output routines to write them to the trajectory files, etc., for long-range electrostatic forces, as specified by the configuration parameters. Long_range electrostatic forces are the electrostatic forces that are not recomputed every timestep.
void all_force ( int timestep, int n, Vector *f )
Takes the n force vectors for time step timestep from the array f and calls the appropriate output routines to write them to the trajectory files, etc., for the total forces on the atoms, as specified by the configuration parameters.

Parameters

Purpose
The Parameters class is used to read in, store, and find parameters from xplor style parameter files. Parameters read in include those for forces due to bonds, bond angles, dihedral angles, improper dihedral angles, single atom van der Waals, and pairwise van der Waals. Multiple parameter files may be read, with the latest read values overriding any previously read. All of the parameters are stored in internal data structures that are efficient for later retrieval of these parameters, both during the reading of the molecular structure file, and during the simulation. A Parameters object will exist on each node. The copy on the master node is used to read the parameter files, interact with the Molecule object while the PSF file is read, and send the fully digested parameter information to the slave nodes. Thereafter, any object may access the parameters through the Parameters object on its node.
Files
Parameters.[Ch], structures.h, NameTable.[Ch]
Constructor
Parameters ( void )
Destructor
~Parameters ( void )
Method of Use
The Parameters object goes through three phases, during which the data are stored in two different kinds of data structure. The first set of structures are various kinds of tree structures which allow easy insertion of new parameters while maintaining an ordering which permits binary searches for lookups. (See Parameters.C for declarations of the node types.) The second set are linear arrays for all parameters, except van der Waals constants which are kept in a two-dimensional array. (See Parameters.h for declarations of the array element types.) Note that phases one and two are only performed on the master node. In the first phase, the parameter files are read, through one or more calls to read_parameter_file(). This puts the contents of the parameter files into the tree structures. The end of this phase is signaled by a call to done_reading_files(). In the second phase, the structure (PSF file) is read (see class Molecule.) During this phase, each atom, bond, angle, etc., is assigned a "type index," which is an index in the linear arrays that will be created at the end of this phase. The Molecule object calls functions with names of the form assign_*_index to get these type indices, and also let the Parameters object know which atoms, bonds, angles, etc., are actually being used, (so that it does not need to keep the entire contents of all parameter files.) The end of the phase is signaled by a call to done_reading_structure(). This call puts the parameters that are actually needed into linear arrays, indexed by the type index just mentioned. After this, the master Node object needs to call send_Parameters() to broadcast the parameter arrays and associated variables to the other nodes, and the slave Node objects need to call receive_Parameters() to get them and store them in the slave's Parameters object. Thereafter, the parameters are accessed through inlined functions which just look up the values in the linear arrays. Type indices are of type Index, which is currently typedef'ed to unsigned short, usually a 16-bit integer. However, the type indices in the tree structure nodes are currently declared short, which limits limits the code to 32,767 different bond types, angle types, etc., in most C++ implementations.
Phase 1 Functions (Master Node Only)
void read_parameter_file ( char * filename )
Read in all of the parameters in the file specified by name and store them for later use. This routine can be called multiple times with different file names.
void done_reading_files ( )
Signals that all parameter files have been read in. After this, the assign index functions may be called.
Phase 2 Functions (Master Node Only)
long atom_type_index ( char * id )
Returns the atom type index for an atom, given the type ID (1--4 characters) given in the PSF file. This ID must match one that appears in a parameter file, but there is currently no check for this (a new type index is assigned instead.)
char *atom_type_name ( long index )
Returns the atom type ID for an atom, as supplied by the PSF file, given the atom type index. The ID will be all upper case, and non-alphanumeric characters may be modified -- see NameTable.
Index assign_vdw_index ( long atomtype )
Return a Index for the van der Waals parameters for the atom type specified by atomtype.
Index assign_bond_index ( long atomtype1, long atomtype2 )
Return a Index for the bond parameters for a bond between atom types atomtype1 and atomtype2.
Index assign_angle_index ( long atomtype1, long atomtype2,
long atomtype3 )
Return a Index for the angle parameters for an angle between atom types atomtype1, atomtype2, and atomtype3.
Index assign_dihedral_index ( long atomtype1, long atomtype2,
long atomtype3, long atomtype4, int multiplicity )
Return a Index for the dihedral angle parameters for a dihedral angle between atom types atomtype1, atomtype2, atomtype3, and atomtype4. multiplicity is the number of times in a row that this particular dihedral (i.e., this particular sequence of atom numbers, not types) appears in the PSF file. The maximum multiplicity specified for a given dihedral type is what get_dihedral_params() will return as the number of sets of dihedral parameters to be used for this dihedral angle.
Index assign_improper_index ( long atomtype1, long atomtype2,
long atomtype3, long atomtype4, int multiplicity )
Return a Index for the improper angle parameters for an improper angle between atom types atomtype1, atomtype2, atomtype3, and atomtype4. multiplicity is the number of times in a row that this particular improper (i.e., this particular sequence of atom numbers, not types) appears in the PSF file. The maximum multiplicity specified for a given improper type is what get_improper_params() will return as the number of sets of improper parameters to be used for this improper angle.
void done_reading_structure ( )
Signals that the PSF file has been read in and all indices have been assigned. The linear arrays of parameters are created. Either send_Parameters() or receive_Parameters() (depending on the node) must be called after this After these calls, the parameter access functions may be called
void send_Parameters ( Communicate *comm )
Intended to be called on the master node only, this function sends a message with the data from the linear parameter arrays and the associated variables. done_reading_structure() must be called before this function. After this call, the parameter access functions may be called on any node.
Phase 2 Functions (Slave Nodes Only)
void receive_Parameters ( Message *msg )
Intended to be called on the slave nodes only, this function takes a message with the data for linear parameter arrays and associated variables, creates the parameter arrays, and puts the data into the arrays. After this call, the parameter access functions may be called on any node.
Phase 3 Functions (All Nodes)
void get_bond_params ( Real *k, Real *x0, Index index )
Retrieve the parameters k and x0 for the bond with index index.
void get_angle_params ( Real *k, Real *theta0, Index index )
Retrieve the parameters k and theta0 for the bond angle with index index.
void get_improper_params ( Real *k, int *n, Real *delta, Index index )
Retrieve the parameters k, n, and delta for the improper dihedral angle with index index.
void get_dihedral_params ( Real *k, int *n, Real *delta, Index index )
Retrieve the parameters k, n, and delta for the dihedral angle with index index.
void get_vdw_params ( Real *sigma, Real *epsilon, Real *sigma14,
Real *epsilon14, Index index )
Retrieve the single-atom van der Waals parameters sigma, epsilon, sigma14 and epsilon14 for the atom with index index. This is used for display and output (Molecule.C) purposes. In the MD calculation, get_vdw_pair_params is used instead.
VdwCoef *get_vdw_pair_params(Index ind1, Index ind2, Bool is14 )
Retrieve a structure containing the van der Waals parameters A and B for the atoms with van der Waals indices ind1 and ind2. If the atoms form a 1-4 pair and the configuration file parameter Exclude is set to 1-4scaled, TRUE should be passed as is14 to get the modified van der Waals parameters for the pair. (See Parameters.h for a definition of type VdwCoef.)
Debugging Functions (Master Node Only)
print_param_summary ( void )
Print out a summary of the number of each type of parameter that has been read in.
print_bond_summary ( void )
Print out a list of all the bond parameters known to this object.
print_angle_summary ( void )
Print out a list of all bond angle parameters known to this object.
print_dihedral_summary ( void )
Print out a list of all dihedral angle parameters known to this object.
print_improper_summary ( void )
Print out a list of all improper dihedral angle parameters known to this object.
print_vdw_summary ( void )
Print out a list of all van der Waals parameters known to this object.
print_vdw_pair_summary ( void )
Print out a list of all van der Waals pair specific parameters know to this object.

ParseOptions

Purpose
The class serves as a way to parse a ConfigList. It is designed to simplify the SimParameters class by providing a uniform mechanism for determining which options are valid at run time. It is rather limited as future fmd development will tend towards run-time communications with a more general controller. Hence, a general parser is not required. This class is used in four phases: set up the dependencies, verify the internal consistency, read in the ConfigList, and get or use the defined variables. The first stage tells the class which options are dependent on others. Only one dependency is allowed. The depended option is called the "child" and the option it is dependent upon is call the "parent". The dependencies can be expressed as a tree with the option "main" defined as the uppermost parent. Hence, all other options are dependent on "main". In addition, it can be used to define a range for which a given option is valid, as well as give its units. The second phase checks that all elements are derived from the "main", and that there are no loops. The third phase reads the elements from the ConfigList and sets the appropriate options. If desired, a pointer can be passed into ParseOptions which will also be set at this time. If options are out of range or too many are given, an error message is printed. If extra or unknown options are defined in the ConfigList, they are printed as warnings. The forth phase is used to read options which were set. This is in some sense optional, as the same information can be extracted through the variable pointer passed in during the third phase.
Files
ParseOptions.[Ch]
Constructor
ParseOptions ( void )
Destructor
~ParseOptions ( void )
Enumerations
Range
FREE_RANGE, POSITIVE, NOT_NEGATIVE, NEGATIVE,
NOT_POSITIVE
Units
UNIT, FSEC, NSEC, SEC, MIN, HOUR, ANGSTROM, NANOMETER,
METER, KCAL, KJOULE, EV, KELVIN, UNITS_UNDEFINED
Global Functions
const char *string ( Range r )
const char *string ( Units u )
Returns a name for the given range or unit.
BigReal convert ( Units to, Units from )
Returns the scaling factor needed to convert from units from to to.
Defines
PARSE_BIGREAL
Used to define a FLOAT without giving a pointer (same as "(BigReal *)NULL").
PARSE_FLOAT
Same as PARSE_BIGREAL.
PARSE_VECTOR
Used to define a VECTOR without giving a pointer (same as "(Vector *)NULL").
PARSE_INT
Used to define a INT without giving a pointer (same as "(int *)NULL").
PARSE_UINT
Used to define a UINT without giving a pointer (same as "(unsigned int *)NULL").
PARSE_BOOL
Used to define a BOOL without giving a pointer (same as "(int *)NULL").
PARSE_STRING
Used to define a STRING without giving a pointer (same as "(char *)NULL").
PARSE_ANYTHING
Defines a STRINGLIST.
PARSE_MULTIPLES
Defines a STRINGLIST that can have multiple elements (same as
"(StringList **)NULL, TRUE").
Method of Use
This parser can be used for data which is "dependent" on other data. For instance, the option fmalevels is dependent on the option fmaon; if the latter (the parent) is not given in the input file, then the former (the child) is never needed. There are two levels of dependency; "require" and "optional". In the given example, if it is required that fmalevels be given in the user input file whenever fmaon is true, then the appropriate code would be:
   ParseOptions opts;
   . . .
   opts.require ( "fmaon", "fmalevels",
                  "Number of FMA expansion levels" );
   . . .
The first term is a string (char *) with the name of the parent, while the second string is the name of the child. The name strings are not case sensitive. The third argument is the message string displayed when a warning or error occurs which involves the child option. The special parent name main is used for options which are not dependent on other options. Now if fmalevels is optional, the code would look like:
   ParseOptions opts;
   . . .
   opts.optional ( "fmaon", "fmalevels",
                   "Number of FMA expansion levels" );
   . . .
These functions are overloaded and can take several more parameters. The first passes a pointer of type (int *), (BigReal *), (Vector *), (char *), or (StringList *) to the ParseOptions class. Then, when the values are set from the ConfigList, this pointer is used to set the appropriate variable automatically. For the int, BigReal, and Vector types, the next term (if it exists) defines a default value which is used if the option is not defined in the user input file but the parent is. There is no way to give a default value for (char *) or StringList. The "set" for a (char *) is actually a strcpy(), so you need to have allocated the space. Using the same example, suppose the value of fmalevel is to be placed in the variable num_fma_levels. The following examples show the cases with and without a default value of 5 being specified:
   ParseOptions opts;
   int fma_levels;
   . . .
   opts.require ( "fmaon", "fmalevels", "Number of levels",
                  &fma_levels )
   . . .
   opts.require ( "fmaon", "fmalevels", "Number of levels",
                  &fma_levels, 5 )
   . . .
Functionally, there is no difference between "require" and "optional" if a default value is given. Also, if the pointer is NULL, nothing bad happens. This is useful if you want an option to have a range, but don't want to use it immediately. There is a special form of these functions for BOOL values. fmd does not have a real "boolean" variable; it uses "typedef Bool int", which is indistinguishable from int to the compiler. Since it is much nicer to be able to say "ffton yes" than "ffton 1", the functions "requireB" and "optionalB" were made. Boolean terms do more than define a "yes/no" value (which, by the way, is internally handled as an inter); they are also used to turn on other blocks of code. Now normally, if the option is defined in the user input file and other data is dependent on that parent, then those dependencies are checked. Using that definition, setting fmaon to either on or off will tell ParseOptions to check terms like fmalevels, which are dependent on that parent. To get around that problem, if a boolean value is a parent and is defined false, then it is undefined. This make "fmaon no" identical to not listing fmaon at all. Here is how the dependencies could look for fma:
ParseOptions opts;
int fmaon, fmalevels, fmamp, fmaffton, fmafftblock;
. . .
opts.optionalB("main","fma","Should FMA be used?",&fmaon);
opts.require("fma","fmalevels","Tree levels in FMA",
             &fmalevels,5);
opts.require("fma","fmamp","Number of FMA multipoles",
             &fmamp,4);
opts.requireB("fma","fmafft","Use FFT enhancements?",
              &fmaffton,FALSE);
opts.require("fmafft","fmafftblock","FFT blocking factor",
             &fmafftblock,4);
   . . .
By default, at most one option of a given name is allowed. If there are multiple definitions, ParseOptions prints that fact to fmdErr. Very few options allow multiple inputs of the same option; the only one at this time is parameters. The only way to define this is through the StringList version of optional/require. The first three arguments are identical to the other similar functions, and the fourth takes a "(StringList **)". The fifth argument, which by default is FALSE, defines if multiple instances are allowed. For example, the following allows multiple parameters keywords:
ParseOptions opts;
. . .
opts.require ( "main", "parameters",
               "One entry for each force field file",
               (StringList **)NULL, TRUE );
   . . .
Many types of input must be positive. For example timestep size and the number of steps per cycle. Range checking of this type and others can be done in the ParseOptions class with the range() function. This takes the option name and the range it can take (one of those in the Range enumeration list above). Here's an example of how to specify that fmalevels must be positive:
ParseOptions opts;
. . .
opts.range ( "fmalevels", POSITIVE );
. . .
Some of the options represent physical values, which have units associated with them. The options can assume that the input will always have a specified unit, and the user must use those units by default. However, if the parser understands some common units (like "fs" and "nm"), then the user can specify those directly. The function named units() gets and sets the units associated with the given option. During the parsing, the user input gets translated as need be so that it is in the specified units. Here's how the code could look:
ParseOptions opts;
. . .
opts.units ( "timestep", FSEC ); // femto seconds time steps
. . .
The following three keyword entries all specify a time step size of 1 fs:
timestep = 1
timestep = 1fs
timestep = 0.001ns
After the dependency, range and units functions are defined, the ParseOptions should be checked to ensure there are not cyclic dependencies and that all options are accessible from "main". This is done with the check_consistency() function. It returns TRUE if the system contains no errors. Once that is done, the values can be set via the function set(), which is passed the ConfigList. This does the dependency and range checks, as well as set any variables which may have been passed in via a pointer. If there was a range error, it prints (to fmdErr) the reason for the error as well as the message associated with that option. Errors related to units conversion are also printed at this time. If there was an option in the ConfigList that was not in the language, it prints (to fmdWarn) all such unknown options. It also prints (to fmdWarn) all options for which the keyword was known but was not required. The last several functions would look like:
ParseOptions opts;
. . .
if ( ! opts.check_consistency() )
  {
    fmdErr << "Internal parsing unsuccessful" << sendmsg;
    return 1;
  }
ConfigList clist ( "test.fmd" ); // open and read the file
if ( ! clist.okay() )
  {
    fmdErr << "Cannot read 'test.fmd'" << sendmsg;
    return 1;
  }
if ( ! opts.set ( clist ) )
  {
    fmdErr << "There were errors in the input file"
           << sendmsg;
    return 1;
  }
. . .
There are several ways to access the information. As mentioned earlier, it is possible to have variables set automatically via pointers passed during the dependency definition. It is also possible to use one of the get() functions. These all take as the first argument the name of the option and, for the second argument, a pointer to where the information should be stored. ParseOptions knows the data type of that option from the dependency definition and can perform type conversion for most cases; the exceptions are listed in the definition section. All these functions return 1 if the function was successful, and prints (to fmdWarn) a warning if a type conversion took place. There are two ways to access data with multiple values; as a "(StringList *)" or via a "(char *)". "get(char *s,int n=0)" takes as an optional parameter the index of the string to return in the StringList. The total number of elements in a StringList is accessible via num(). For example, the following code could be used to list the given parameter files:
   int num = opts.num ( "parameters" );
   char s[100];
   for ( int i = 0; i < num; i++ )
     {
       opts.get ( "parameters", s, i );
       fmdInfo << " " << s << sendmsg;
     }
Finally, defined() tells if a given option was defined during the set(), and exists() tells if a given option was stated in the dependencies.
Functions
void add_element ( DataElement * )
Adds a new element to the internal array. (See Internal Classes below).
int make_dependencies ( DataElement * )
Find if the new element is dependent on, or is depended on, any of the elements already in the array.
atoBool
Convert a string to Bool. Returns 1 if yes, on, or true; 0 if false, no, or off; and -1 if anything else.
Bool is_parent_node ( DataElement * )
Returns TRUE if the given DataElement has any children. Used to determine if a BOOLEAN which is false should be undefined.
int require ( const char *newname, const char *parent, const char *msg,
BigReal *ptr, BigReal default ) or
BigReal *ptr )
Define a required BigReal, with and without a default.
int require ( const char *newname, const char *parent, const char *msg,
Vector *ptr, Vector default ) or
Vector *ptr )
Define a required Vector, with and without a default.
int require ( const char *newname, const char *parent, const char *msg,
int *ptr, int default ) or
int *ptr )
Define a required int, with and without a default.
int requireB ( const char *newname, const char *parent, const char *msg,
int *ptr, int default ) or
int *ptr )
Define a required Boolean (variant of int), with and without a default. Looks for "yes/no", "true/false", or "1/0".
int require ( const char *newname, const char *parent, const char *msg,
unsigned int *ptr, unsigned int default ) or
unsigned int *ptr )
Define a required unsigned int, with and without a default.
int require ( const char *newname, const char *parent, const char *msg,
StringList **ptr=NULL, int many_allowed=FALSE )
A required option with a StringList return. If TRUE, the second argument allows a StringList with more than one element. There are no defaults for a StringList.
int require ( const char *newname, const char *parent, const char *msg,
char *ptr )
A required option with a (char *) return. There are no defaults for a (char *). If the option exists in the ConfigList, it is copied (via strcpy) to ptr.
int optional ( const char *newname, const char *parent, const char *msg,
BigReal *ptr, BigReal default ) or
BigReal *ptr )
Define an optional BigReal, with and without a default.
int optional ( const char *newname, const char *parent, const char *msg,
Vector *ptr, Vector default ) or
Vector *ptr )
Define an optional Vector, with and without a default.
int optional ( const char *newname, const char *parent, const char *msg,
int *ptr, int default ) or
int *ptr )
Define an optional int, with and without a default.
int optionalB ( const char *newname, const char *parent, const char *msg,
int *ptr, int default ) or
int *ptr )
Define an optional Boolean (variant of int), with and without a default (see requireB above).
int optional ( const char *newname, const char *parent, const char *msg,
unsigned int *ptr, unsigned int default ) or
unsigned int *ptr )
Define an optional unsigned int, with and without a default.
int optional ( const char *newname, const char *parent, const char *msg,
StringList **ptr=NULL, int many_allowed=FALSE )
An optional option with a StringList return. If TRUE, the second argument allows a StringList with more than one element. There are no defaults for a StringList.
int optional ( const char *newname, const char *parent, const char *msg,
char *ptr )
An optional option with a (char *) return. There are no defaults for a (char *). If the option exists in the ConfigList, it is copied (via strcpy) to ptr.
void range ( const char *name, Range newrange )
Specify that the variable in argument name has the range specified by argument newrange
Range range ( const char *name )
Returns the range for the variable in argument name.
void units ( const char *name, Units newunits )
Specify that the variable in argument name has the units specified by argument newunits
Units units ( const char *name )
Returns the units for the variable in argument name.
Bool scan_float ( DataElement *el, const char *s )
Read in a BigReal. If there are units, do the necessary conversion. Put the final result in el->fdate. Returns error value.
Bool scan_vector ( DataElement *el, const char *s )
Read in a Vector. If there are units, do the necessary conversion. Put the final result in el->fdate. Returns error value.
Bool scan_int ( DataElement *el, const char *s )
Read in an int. If there are units, do the necessary conversion. Put the final result in el->idate. Returns error value.
Bool scan_uint ( DataElement *el, const char *s )
Read in an unsigned int. If there are units, do the necessary conversion. Put the final result in el->uidate. Returns error value.
Bool scan_bool ( DataElement *el, const char *s )
See if the string can be parsed as TRUE or FALSE. If so, set el->idata appropriately. Returns error code.
Bool set_float ( DataElement * )
Make sure the BigReal data value is in range (returns FALSE if not) and sets the (BigReal *), if appropriate.
Bool set_vector ( DataElement * )
If the Vector pointer is defined, set it to the current values.
Bool set_int ( DataElement * )
Make sure the int data value is in range (returns FALSE if not) and sets the (int *), if appropriate.
Bool set_uint ( DataElement * )
Make sure the unsigned int data value is in range (returns FALSE if not) and sets the (unsigned int *), if appropriate.
void set_bool ( DataElement * )
Make sure the BOOLEAN data value is in range (returns FALSE if not) and sets the (BOOLEAN *), if appropriate.
void set_stringlist ( DataElement * )
Sets the (StringList **), if appropriate.
void set_string ( DataElement * )
Copies the first element of the given ConfigList to the (char *), if appropriate.
Bool check_consistancy ( void )
Check that there are no internal loops or other errors in the DataElement array.
Bool set ( const ConfigList& configlist )
Reads each element of the configlist, checks the internal data array, sets the appropriate data pointers, prints all warnings and/or errors, and returns TRUE if it all worked out.
DataElement *internal_find ( const char *name )
Find the element in the internal array conrresponding to the given name. Returns NULL if it doesn't exist.
get ( const char *name, int *val )
Sets the pointer base to the int value associated with the given name, doing type conversion if necessary. If conversion was needed, prints the warning (or error, if it is a Vector) to the screen. Returns FALSE if the name doesn't exist.
get ( const char *name, BigReal *val )
Sets the pointer base to the BigReal value associated with the given name, doing type conversion if necessary. If conversion was needed, prints the warning (or error, if it is a Vector) to the screen. Returns FALSE if the name doesn't exist.
get ( const char *name, Vector *val )
Sets the pointer base to the Vector value associated with the given name. It can only do conversions from STRING and STRINGLIST. Returns FALSE if the conversion is not possible.
get ( const char *name, StringList **val )
Sets (*val) to (configList->find(name)), it name exists, else it returns FALSE.
get ( const char *name, char *val, int n=0 )
Copies the n'th element of val, or returns FALSE if name or the element does not exist.
exists ( const char *name )
Returns TRUE if an element with the specified name exists in the internal DataElement array, else returns FALSE.
defined ( const char *name )
Returns TRUE if an element with the specified name exists and was given either a default or was in the ConfigList.
Internal Class
DataElement
This class is little more than a glorified typedef. It is completely public to ParseOptions and is private to the rest of the code. Its only functions are constructors, which are used to set the correct values and ensure that other values are sane. It stores all the information needed to describe the data elements used by ParseOptions. It knows the name of the datum, its parent's name, the pointer to the parent (if it exists), whether the datum is optional or required, the type of the data (through run-time data typing), the default value (if it exists), and so on. Inside ParseOptions, the DataElement's are stored as an array which grows (during add_element, as needed.
Enumeration
data_types: UNDEF, FLOAT, VECTOR, INT, BOOL,
STRINGLIST, STRING - the types used for run-time typing.
Constructor
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
BigReal *ptr, BigReal default ) or
BigReal default )
Make a FLOAT type with the given default value which can set ptr, or without a default value.
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
Vector *ptr, Vector default ) or
Vector default )
Make a VECTOR type with the given default value which can set ptr, or without a default value.
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
int *ptr, int default ) or
int default )
Make an INT type with the given default value which can set ptr, or without a default value.
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
unsigned int *ptr, unsigned int default ) or
unsigned int default )
Make an UINT type with the given default value which can set ptr, or without a default value.
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
StringList **ptr, int many_allowed=FALSE )
Make an STRINGLIST type which may or may not have multiple elements.
DataElement ( const char *newname,
const char *newparent,
int optional, const char *err,
char *ptr )
Make an STRING type which can strcpy to ptr.

Patch

Purpose
Each Patch object is responsible for maintaining a region of space in the simulation. This includes maintaining the current positions and velocities of all atoms in this region, calculating all the forces acting on these atoms, and integrating the equations of motion for these atoms during each time step.
Files
Patch.[Ch]
Constructor
There are two constructors for this class. The first is used when a Patch object is created from scratch. It creates an empty patch with no atoms. The second constructor is used when the Patch object being created is a patch that has migrated from another processor.
Patch ( int, PatchList * )
Creates a new, empty patch. It is passed its ID and a pointer to the PatchList object it owns.
Patch ( int, PatchList *, Message * )
Constructs a patch from data in the given Message. After construction, the Message is deleted.
Destructor
~Patch ( void )
Method of Use
The Patch object is responsible for managing most of the work done during the simulation. It owns a region of space and is responsible for all of the atoms in that region. This responsibility includes maintaining the current positions and velocities for the atoms, calculating and gathering all of the forces necessary to integrate the equation of motion at each time step, and add or delete atoms that have moved into or out of its region. To accomplish these things, each Patch object contains a number of other objects. These objects include force objects that calculate the various force components for the local atoms, and an Integrate object that is responsible for integrating the equations of motion during each time step. The Patch object's main purpose is to provide a control and data framework which allows each of it's member objects to function. To this end, each time step follows a basic sequence of steps. These steps are:
  1. Send out coordinate messages Local coordinates are sent to neighboring patches via the send_msgs() function. This allows interactions with neighboring atoms to be calculated. A self-message is also sent, telling the patch to actually perform the local calculation. During normal, mid-cycle time steps, this step actually occurs at the end of the previous time step, rather that at the beginning of a new time step. See the Communicate description for more details.
  2. Process incoming messages Messages from other patches may contain all coordinates, only bonded coordinates, or the forces calculated by the other patches. Control messages are sent by each patch to itself to trigger local force computation and integration. During this stage, the number of outstanding messages is also monitored. When all expected messages have been processed, the self-message is sent and received.
  3. Integration and energy reporting This is a specialized case of processing incoming messages, but it represents the last calculation performed during a time step. At this point, all of the forces for the current time step have been evaluated, and the equations of motion are integrated by the Integrate object to obtain new values for the position and velocity of all local atoms. Then the energies from all the force objects are gathered and the kinetic energy is calculated. The resulting values are passed to the local Collect object so that they can be summed across all processors.
The rest of the functionality in the Patch object deals with administrative activities, such as start-up and shut-down, the transfer of atoms from patch to patch, recalibration of force objects at the cycle boundaries, etc.
Private Data Types
These data structures are used only within the Patch object:
BondedWithNeighbor
This data structure is used to track the atoms that need to be sent to each neighbor that we only send bonded coordinates to. Sending coordinates to these neighbors is basically a gathering operation where a specific number and sequence of atom coordinates are gathered and sent during each time step. The structure contains:
num
The number of atoms that are to sent to this neighbor.
atoms
An array of size num that contains the local atom indexes of the atoms that are to be sent to this neighbor.
coords
A Vector array of size num that is used to gather the coordinates to be sent to this neighbor. This provides a buffer to gather the positions in during each time step so that space doesn't need to be allocated and freed during each time step.
Given a BondedWithNeighbor, the act of gathering atoms for a neighbor structure is accomplished as follows:
   BondedWithNeighbor bwn;
   int i;

   for ( i = 0; i < bwn.num; i++ )
      bwn.coords[i] = x[bwn.atoms[i]];
ReturnForceVectors
This structure is used to hold force vectors to be returned to those neighbors that sent us all their atom coordinates. The forces to be returned are accumulated here, and then sent back to that neighbor. The structure contains.
num
The number of force vectors to return to this neighbor.
forces
A Vector array of size num which holds the vectors to be accumulated. The array is set to all 0's at the beginning of each time step. When the coordinate message from this neighbor is processed, these forces are populated and then sent back to the neighbor.
AtomMsgList
This structure is used to form a linked list of atom reassignment Message's that have been received. During atom reassignment, all the atom reassignment messages received from neighbors that actually contain new atoms for this patch are buffered in these lists. Once all the messages have been received, all the messages are processed at once. The structure contains:
num
The number of atoms contained in this message.
msg
A pointer to the Message object.
next
A pointer to the next link in the list.
Private Data
Patchlist *parentList
Pointer to the PatchList object that owns this patch. This is used to access items contained in the PatchList object easily.
int myId
Patch number for this patch. This number is set during construction, and never changes during the life of the patch.
int numAtoms
Number of atoms residing in this patch.
int currentTimestep
The time step that this Patch is currently working on. At present, patches that reside on the same node will always be working on the same time step. Patches that reside on different nodes may be working on a different time step. Thus, at any time, any neighboring patch may be working on a different time step.
int *atoms
Array of size numAtoms that contains the global indexes for the local indexes. Thus atom[i] contains the global index for the i'th local atom.
Vector *x
Array of vectors containing the current positions of all the local atoms.
Vector *v
Array of vectors containing the current velocities of all the local atoms.
Vector *f
Array of vectors containing the current forces acting on all the local atoms. This array is set to all 0's at the beginning of each time step.
BondForce *bondForce
Force object responsible for calculating linear bonds.
AngleForce *angleForce
Force object responsible for calculating bond angle interactions.
ElectForce *electForce
Force object responsible for calculating electrostatic and van der Waals interactions.
ImproperForce *improperForce
Force object responsible for calculating improper dihedral angle interactions.
DihedralForce *dihedralForce
Force object responsible for calculating dihedral angle interactions.
Integrate *integrator
Integration object responsible for integrating the equations of motion to produce new positions and velocities.
int numSend
Number of neighboring patches that we send all coordinates to.
int numRecv
Number of neighboring patches that we receive all coordinates from.
int *sendNeighbors
Array of length numSend that contains the patch ID's of the neighbors that we send all coordinates to.
int *recvNeighbors
Array of length numRecv that contains the patch ID's of the neighbors that we receive all coordinates from.
BondedWithNeighbor *bondedInfo
Array of length numRecv that contains the information about the bonded coordinates that we need to send to each neighbor that we send only bonded coordinates to. The information is placed into this array in the same order as the patch ID's are placed in recvNeighbors. In other words, if patch ID p satisfies p=recvNeighbors[i], then the information about the bonded coordinates to send to patch p is contained in the structure bondedInfo[i].
ReturnForceVectors *returnForces
Array of length numSend that provides a place to accumulate forces that are to be returned to a neighboring patch that sends this patch all of its atoms coordinates. As with bondedInfo, the entries in returnForces correspond to the patch ID of the corresponding element in sendNeighbors.
Bool doneLocal
Flag which indicates whether the local calculations have been performed during the current time step or not.
int tsType
Flag that has the value of either BEGIN_CYCLE or MID_CYCLE, which indicates whether or not this is the first time step in a cycle. This is important, since during the first time step of each clock, the messages received and actions performed are slightly different, as is the initialization done by each force object. The MID_CYCLE steps all perform the same operations.
int coorMsgsOutstanding
Counter which is used to determine how many coordinate messages we are still waiting for during the current time step. At the beginning of each time step, this value is set numSend+numRecv. As each bonded coordinate and all coordinate message is processed, this value is decremented by one. When this value reaches 0, the patch has processed all of the coordinate messages for the current time step.
int forceMsgsOutstanding
Counter which is used to determine how many force messages the patch is still waiting for during the current time step. At the beginning of each time step, this value is set numSend. When this value reaches 0, the patch has processed all of the force messages for the current time step.
int atomMsgsOutstanding
Counter which is used to determine how many atom reassignment messages the patch is still waiting for during the current time step. At the beginning of each time step, this value is set to the number of neighboring patches. When this value reaches 0, the patch has processed all of the atom reassignment messages for the current time step.
int numAtomsRemoved
This value is only valid during atom reassignment, and it contains the number of atoms that have left the spatial region owned by the patch during the current reassignment period.
int numAtomsAdded
This value is only valid during atom reassignment, and it contains the number of atoms that have entered the spatial region owned by the patch during the current reassignment period.
LintList *atomsRemoved
Object that is created for each atom reassignment. It stores the local indexes of atoms that have left the patch.
AtomMsgList *atomsReceived
Linked list that contains messages from neighbors who have sent us atoms that migrated from their region of space. This list is created and destroyed during each atom reassignment period.
AtomMsgList *atomListTail
Pointer to the tail of atomsReceived so that new messages can be added to the list in constant time.
Public Functions
Each Patch object is owned and managed by a PatchList object. Thus, almost all calls to these public functions are done by the PatchList object.
void get_initial_positions ( Message *msg )
Process a message containing the initial positions of atoms belonging to this patch. This is only used at the very beginning of the simulation as atoms are passed out to patches.
void get_initial_velocities ( Message *msg )
Process a message containing the initial velocities of atoms belonging to this patch. This is only used at the very beginning of the simulation as atoms are passed out to patches.
void initialize_timestep ( int timestep )
Prepare the patch to perform a new time step.
void send_msgs ( int time step )
Send out necessary coordinate and self-calculation messages to neighboring patches and ourselves.
void process_msg ( Message *msg, int tag )
Process the message that was received with specified tag. It is in processing these messages that most of the work of the patch is performed.
void end_cycle ( void )
Tear things down at the end of a cycle. This includes things like freeing all the force objects, resetting counters, etc.
void send_atom_reassignments ( void )
Send out messages that contain atoms that have left our region of space. A message is sent to every neighbor, even if the message simply says that there are not atoms to be transferred.
void receive_atom_reassignment ( Message *msg )
Process the message that contains atoms which have entered patch from a neighbor.
void copy_self ( Message *msg )
Place a copy of all the useful data in this patch into the message so that this patch can migrate to another processor. Not that patch redistribution is not yet implemented.
int getNumAtoms ( void )
Returns the number of atoms on this patch.
int *getAtomList ( void )
Returns the list of global indexes for atoms on this patch.
int id ( void )
Returns the patch ID of this patch.
void patch_debug ( void )
Debugging routine that dumps out the current status of the patch to the screen. This function is not normally called anywhere in the code, and exists solely for debugging purposes.
Private Functions
These functions are only called within the Patch object itself, and they perform much of the work of the simulation.
void all_coordinate_init ( Message *msg, int nId, int nIndex )
Initialization routine for messages received from neighbors who send this patch all of their atom coordinates. The forces for the current time step are also calculated. The processing of this message includes passing the coordinates to all of the force objects and building the list of bonded coordinates that must be sent back to this neighbor. msg is the object containing the data, nId is the ID of the neighbor who sent the message, and nIndex is the index of this neighbor into the recvNeighbors and other arrays. This function is only used during the first timestep of each cycle. During mid-cycle steps, the function all_coordinate_force() is used to calculate forces without doing the initialization activities.
void all_coordinate_force ( Message *msg, int nId, int nIndex )
The forces for the current time step are also calculated. msg is the object containing the data, nId is the ID of the neighbor who sent the message, and nIndex is the index of this neighbor into the recvNeighbors and other arrays. This function is used during every mid-cycle time step.
bonded_coordinate_init ( Message *msg, int nId )
Initialization routine for messages received from neighbors who send this patch only atom coordinates needed for bonded calculations. The forces for the current time step are also calculated. The processing of this message includes the passing of the coordinate data to each of the bonded force objects. msg contains the data sent out, and nId is the patch ID of the neighbor it was sent to. This function is only used during the first time step of each cycle. During mid-cycle steps, the function bonded_coordinate_force() is used to calculate the forces without doing the initialization activities.
void bonded_coordinate_force ( Message *msg, int nId )
Calculates forces with a neighbor that sends this patch only bonded coordinates. msg contains the coordinates and nId is the patch ID of the neighbor who sent the message. This function is used during mid-cycle time steps.
void local_init ( void )
Initialize the local force interactions. This prepares all the force objects for calculating local interactions for this cycle, and also calculates local forces for the current time step. This function is used only during the first time step in each cycle. The function local_force() is used to calculate forces during mid-cycle time steps.
void local_force ( void )
Calculates local interactions for the current, mid-cycle, time step.
void add_forces ( Message *msg )
Given a message that contains forces calculated by a neighboring patch that we sent all atom coordinates to, add these forces to the local forces for the current time step.
void prepare_bonded_coords ( BondedWithNeighbors *bwn )
Gather the bonded coordinates that are to be sent to a neighbor. This function performs the loop described above which performs the gather operation necessary to send bonded coordinates to a neighbor. The BondedWithNeighbors structure that describes the coordinates that need to be sent are passed in bwn.
BigReal get_kinetic_energy ( void )
Calculate the kinetic energy contributed by the local atoms for the current time step using the usual equation:
void update_atom_info ( void )
Perform all the actual work for atom reassignment. This function is the one that does all of the actual reassignment of values for atom reassignment. It is called once all the atom reassignment messages have been received from the neighbors of this patch. It is only called if atoms have entered or left this patch. It recreates the arrays atoms, x, v, and f to match the new number of atoms in the patch
int get_list_index ( int value, const int *list, int numvalues )
This function searches for a value in a list of integers and returns the index of the value in the list. It assumes that the value will always be found, and it will terminate the program if a value is not found. It is used during atom reassignment to find the index of a neighbor patch in the list of all neighbors. It is currently implemented as a binary search. value is the integer to be searched for, list is the list of integers to be searched, and numvalues is the number of integers in list.

PatchDistrib

Purpose
The PatchDistrib object is used to determine and report the distribution of patches to processors. For the current implementation, it is responsible for determining what processor every patch on the system belongs to and distributing this information to every other PatchDistrib object on the system. Each object is then also responsible for returning the processor location of any patch. In order to be efficient, the PatchDistrib object allows constant time access to patch information in two ways: by patch ID number, and by grid coordinates. Grid coordinates identify the position of a patch in a set of grid coordinates where the origin is the lowest corner of the model.
Files
PatchDistrib.[Ch]
Constructor
PatchDistrib ( void )
Destructor
~PatchDistrib ( void )
Method of Use
The only part of this class that is currently implemented is the creation of an initial distribution and the sending of this distribution from the client node to tell the client nodes. The creation of the initial patch distribution is done with the function create_initial_distrib(), which is passed a PDB object containing the initial position of all the atoms. This function obtains the maximum and minimum corners of the molecule. It then determines how many patches it will take to cover these dimensions. Then, a layer of empty patches is added around all edges of the system to provide the buffer zone of empty patches that will be used. Patch structures are then created for each of these patches. Coordinates, grid positions, and patch numbers are then assigned to each patch. Also, the number of neighbors, the patch ID's of the neighbors, and which neighbors to send and receive from are also determined. The patches to send and receive from are determined in a very simplistic way at the moment. The gird coordinates are compared in order from x to y to z. If the first coordinate that is not equal is found to be grater, then the patch is sent to. Otherwise, it is received from. Next, these patches are mapped to processors. A recursive coordinate bisection algorithm is used to map patches to processors. The create_initial_distrib() function invokes the RecBisection object to accomplish this. If the recursive bisection algorithm fails for some reason, then a VERY simplistic scheme is used where an equal number of patches is assigned to each processor in sequential patch ID order (the function simple_strip_division() does this). Now this distribution can be sent from the master processor to the client processors. Once it is received on each processor, the PatchList object can use this information to determine how many patches it is responsible for and it can allocate the required Patch objects. Finally, since the PDB information was already parsed to determine the initial distribution, this information can now be used to send the initial coordinates and velocities to each Patch object. This isn't necessarily the most logical place for this to be done, but it turns out to be quite practical.
Functions
void create_initial_distrib ( PDB * )
Create an initial distribution of patches to processors, using the initial positions of all the atoms.
void send_Distrib ( Communicate * )
Send a distribution from the master node to the client nodes.
void receive_Distrib ( Message * )
Receive a distribution from the master node.
void send_initial_positions ( Communicate *, PDB * )
Send out the initial atom coordinates and global atom indexes to each patch. These coordinates are obtained from the PDB object.
void send_initial_velocities ( Communicate *, Vector * )
Send out the initial atom velocities to each patch. The velocities that are to be assigned to each atom are passed in via an array of Vectors.
int patch_node ( int pnum )
Return the node ID that Patch assigned patch pnum to.
int get_patch_id ( int i, int j, int k )
Given the grid coordinates, return the patch number. This is intended to be used to determine a neighboring patch, given a direction.
IntList *patches_for_node ( int )
Give a node number, return an IntList object that contains the patch numbers assigned to that node. This is intended to be used by a give Node object to determine what patches belong to it.
int num_recv_for_patch ( int pnum )
Given a patch number, return the number of neighbors that this patch will receive all coordinates from.
int num_send_for_patch ( int pnum )
Given a patch number, return the number of neighbors that this patch will send all coordinates to.
int get_maxNeighborPatches ( void )
Returns the value of maxNeighborPatches, the maximum number of neighbors any one patch can have.
int get_maxPatchNum ( void )
Returns the value of maxPatchNum, the largest patch index assigned.
int get_recv_patches ( int pnum, int *plist )
The list of patch numbers that the patch pnum will receive all atoms from is returned in the array plist
int get_send_patches ( int pnum, int *plist )
The list of patch numbers that the patch pnum will send all atoms to is returned in the array plist
int simple_strip_division ( int )
Partition the initial volume into strips and assign these strips to processors.
Public Variables
int numPatches
Total number of patches created.

PatchList

Purpose
This class manages and controls the set of Patch objects (see section Patch)which reside on each processor node. The PatchList contains routines to add, move, or delete patches, and contains the logic to complete on individual time step. The Patch objects (see section Patch) then contain particular atoms and have the knowledge of how to calculate forces and integrate the equations of motion.
Files
PatchList.[Ch]
Constructor
PatchList ( void )
Destructor
~PatchList ( void )
Enumerations
TSType: BEGIN_CYCLE, MID_CYCLE
Method of Use
A single PatchList object exists on each processor node; it holds all the individual patches and loops through them to do a time step calculation. It is created during the simulation initialization phase, before any time steps are calculated, and deleted when the simulation is complete. When constructed, it contains no patches; these are added by the PatchConfig object, which calls specific routines within PatchList to add patches that should be on the node. A node-level algorithm is responsible for determining when each time step should be calculated; when a time step is to be done, this algorithm calls do_timestep(int tsType) in the PatchList object. The argument tsType is a flag to indicate the type of time step this is to be. In the current design, there are two types:
  1. BEGIN_CYCLE : The very first time step in a cycle of k steps. For this time step, data may have to be regenerated for the PatchList and each patch due to movement of atoms, and redistribution/creation/deletion of patches.
  2. MID_CYCLE : All other time steps in a cycle other than the first; for these steps, the status of atoms and patches is taken to be static, and local data structures do not have to be generated.
When do_timestep() is called, the PatchList allows each Patch to calculate the forces on its atoms, and to integrate the equations of motion. The algorithm used to do this is:
  1. If BEGIN_CYCLE, regenerate PatchList data structures due to changes in atom and Patch distributions.
  2. Set patchesDone = 0.
  3. For all patches on this node: call patch.send_msgs(tsType)
  4. While patchesDone < "patches in PatchList":
    1. If Message for a Patch available: call patch.process_msg(msg)
    2. If patch.process_msg(msg) returned TRUE, increment patchesDone.
  5. For all patches on this node: call patch.report_data(tsType)
The Patch object is responsible for sending itself messages with commands to do such things as compute local forces, and to integrate the equations of motion once all forces are available. The Communicate object must then return messages of a given tag with the following priority:
  1. From a remote node.
  2. From the local node.
Patches which send messages to another node do so by calling the routine send_to_patch(Message *, patch, id). The argument id is a code used by the patches to distinguish the contents of the Message, it is not the tag. A specific tag is used for all messages that are sent between Patch objects; this tag is defined in common.h.
Functions
void startup ( IntList * )
Initialize the object. It takes an IntList that contains the patch ID's that will be owned by this object, creates all the necessary data structures, and initializes them.
void receive_initial_positions ( void )
This function is used only during initialization. It is just a loop that waits for incoming position messages for each of the patches that it owns and passes the messages off to the appropriate Patch.
void receive_initial_velocities ( void )
This function is used only during initialization. It is just a loop that waits for incoming velocity messages for each of the patches that it owns and passes the messages off to the appropriate Patch.
void reconfig ( void )
Private routine which is called when do_timestep(BEGIN_CYCLE) is called. It regenerates the internal data structures when atoms and/or patches are redistributed.
void send_to_patch ( Message *msg, int patch, int id )
Sends the given Message to the given patch, encoding within the Message which patch the Message is for, the id, and the current time step. The Message sent has the following format:
  • Original data in message.
  • ID.
  • Sending Patch number.
  • Destination Patch number.
  • Time step.
void do_timestep ( int tsType )
Where the action is; this does one complete time step, at the end of which the energies, coordinates, etc. are reported to the master node. The type of time step to do is indicated by the argument.
void add_patch ( Patch * )
Adds the given Patch object to the current set of patches being managed by the PatchList. This function is called by a higher-level algorithm, such as by PatchConfig.
void del_patch ( int patchnum )
Deletes the given Patch object from the current set of patches being managed by the PatchList. This function is called by a higher-level algorithm, such as by PatchConfig.
void move_patch ( int patchnum, int destnode )
Sends a message to destnode with all data required to create a patch identical to Patch patchnum, and then deletes Patch patchnum from the list of local patches. The remote node is then responsible for receiving the message, creating a new patch, and adding it to the PatchList on that node.

PDB

Purpose
This is the class that manages the data in an entire X-PLOR type PDB file. In the most general sense, it should organize the various data types present in the file. However, that generality is not needed. Thus, all this class does is read the ATOM and HETATM records. The generality (and complexity) remains in the code because it was taken from a project to read in and manipulate all PDB records. The atom information is access as an array. There are several ways to search the information in the PDB object. All these search functions are named find_atom_*, where the "*" can be one of many possible search criterion. The result of a search is an IntList pointer which contains the indices to all the atoms found. Memory is allocated for this list, so it must be deleted after it is no longer needed.
Files
PDB.[Ch], IntList.h
Constructor
PDB ( const char *pdbfilename )
The argument is the name of the input X-PLOR type PDB format file to read. The full description of a standard PDB file is available via anonymous FTP from pdb.pdb.bnl:/pub/format.desc.ps. There are two differences between this standard format and the X-PLOR variant, which are explained in PDBAtom (see section PDBAtom, PDBAtomRecord, PDBHetatm). The constructor reads the file and stores the ATOM and HETATM records into one linked list. After all the data is read, the linked list is converted into an array, in order to increase access speed. The following record is a special type recognized by fmd: KEYWRD....BASE64 where the "...." are replaced by spaces. If the constructor encounters this record, it sets a flag indicating that all atom and residue sequence numbers should be written in base-64 notation using the character set "0-9A-Za-z@#". This allows a PDB file to contain over 1 billion atoms and 16 million residues, but is clearly highly non-standard and specific to fmd alone. Such a notation is also used by the PSF file reader.
Destructor
~PDB ( void )
Method of Use
The use of the PDB class is best described by this snippet of code:
   PDB pdbinput ( "pti.pdb" );
   if ( pdbinput.numatoms() == 0 )
      FMD_die ( "There were not atom records in PDB file." );
   IntList *search = pdbinput.find_atom_name ( "CA" );
   cout << "There are" << search->num() << "alpha carbons./n";
   cout << "The fifth is atom number "
        << pdbinput.atom(search[5]->serialnumber() << "./n";
   delete search;
Typedef
PDBAtomList
This structure contains two elements:
PDBAtom *data
Pointer to the atom which is either an ATOM or HETATM record.
PDBAtomList *next
Pointer to the next element in the list.
The list is NUL terminated. This is used internal to the class to maintain the list of all atoms read from the PDB file before it is converted into an array.
Functions
int num_atoms ( void )
Returns the number of atoms read.
IntList *find_atom_serialnumber ( int serialnumber )
Returns indices to atoms whose sequence number match the argument.
IntList *find_atom_name ( const char *name )
Returns indices to atoms whose name match the argument.
IntList *find_atom_alternatelocation ( const char *alternatelocation )
Returns indices to atoms whose alternate location match the argument.
IntList *find_atom_residuename ( const char *residuename )
Returns indices to atoms whose residue matches the argument.
IntList *find_atom_chain ( const char *chain )
Returns indices to atoms whose chain identifier match the argument.
IntList *find_atom_residueseq ( int *residueseq )
Returns indices to atoms whose residue sequence match the argument.
IntList *find_atom_insertioncode ( const char *insertioncode )
Returns indices to atoms whose insertion code match the argument.
IntList *find_atom_segmentname ( const char *segmentname )
Returns indices to atoms whose segment name match the argument.
IntList *find_atom ( const char *name=NULL,
const char *residue=NULL, int residueseq=-1,
const char *segment=NULL )
This provides the ability to search based on several criterion at once. If a field contains its default value of NULL, it will not be used in the search.
PDBAtom *atom ( int place )
Returns the pointer to atom number place. The place numbers are 0 based, hence atom(1) refers to the 2nd atom present.
PDBAtomList *atoms ( void )
Returns the head of the array. Messing with this may cause bad things to happen.
IntList *find_atoms_in_region ( Real x1, Real y1, Real z1,
Real x2, Real y2, Real z2 )
Returns indices to atoms which lie in a certain region of space. Assuming that x1<x2, y1<y2, z1<z2, then an atom at position (x,y,z) is in the region iff x1<=x<x2, y1<=y<y2, z1<=z<z2. The function will reorder the coordinates to that the x1<x2 assumption is true.
void find_extremes ( Vector *, Vector * )
Returns two vectors, one with the minimum (x,y,z) coordinates of the system, and the other with the maximum.

PDBAtom, PDBAtomRecord, PDBHetatm

Derived From
PDBData (see section PDBData, PDBUnknown)
Files
PDBData.[Ch]
Enumerations
Start
Represents the starting column of various data elements in the PDB file. The enumerators include:
STYPE=1     SSERIAL=7    SNAME=13    SALT=17
SCHAIN=22   SRESSEQ=23   SINSERT=27  SSEGNAME=73
SOCC=55     STEMPF=61    SFOOT=68    SRESNAME=18
SX=31       SY=39        SZ=47
Length
Represents the length of each data element in the PDB file. This, combined with Start, specifies the fixed format for the PDB file. The Enumerators include:
LTYPE=6     LSERIAL=5,   LNAME=4     LALT=1
SRESNAME=4  LCHAIN=1,    LRESSEQ=4   LINSERT=1
LOCC=6      LOCCPREC=2   LTEMPF=6    LTEMPFPREC=2
LSEGNAME=4  LCOORPREC=3  LCOOR=8     LFOOT=3
PDBPossibleAtoms
Specifies if the element is to be an ATOM or HETATM record via:
USE_ATOM=ATOM, or USE_HETATM=HETATM.
Constructor
PDBAtom ( char *dataline, PDBPossibleAtoms whichatom )
Given the line as presented in the PDB file, convert the information to either an ATOM or HETATM record.
PDBAtomRecord ( char *dataline )
Given the line from the PDB file, tell the parent class, PDBAtom, to make an ATOM record.
PDBHetatm ( char *dataline )
Given the line from the PDB file, tell the parent class, PDBAtom, to make a HETATM record.
Destructor
~PDBAtom ( void )
~PDBAtomRecord ( void )
~PDBHetatm ( void )
Functions
void parse ( const char *s )
Given a line in PDB format, extract the coordinate information.
sprint ( char *s, PDBFormatStyle usestyle = COLUMNS )
Print the current data in one of the two supported PDB formats.
int serialnumber ( void )
void serialnumber ( int newserialnumber )
Read or change the atom serial number.
const char *name ( void )
void name ( const char *newname )
Read or change the atom name.
const char *alternatelocation ( void )
void alternatelocation ( const char *newalternatelocation )
Read or change the alternate location.
const char*residuename ( void )
void residuename ( const char *newresiduename )
Read or change the residue name.
const char *chain ( void )
void chain ( const char *newchain )
Read or change the chain identifier.
int residueseq ( void )
void residueseq ( int newresidueseq )
Read or change the residue sequence number.
const char *insertioncode ( void )
void insertioncode ( const char *newinsertioncode )
Read or change the insertion code.
Real xcoor ( void )
Real ycoor ( void )
Real zcoor ( void )
void xcoor ( Real newxcoor )
void ycoor ( Real newycoor )
void zcoor ( Real newzcoor )
Read or change one of the x, y, or z coordinates.
const Real *coordinates ( void )
void coordinates ( const Real *newcoordinates )
Read or change all three coordinates.
Real occupancy ( void )
void occupancy ( Real newoccupancy )
Read or change the occupancy.
Real temperaturefactor ( void )
void temperaturefactor ( Real newtemperaturefactor )
Read or change the temperature factor.
int footnote ( void )
void footnote ( int newfootnote )
Read or change the footnote.
const char *segmentname ( void )
void segmentname ( const char *newsegmentname )
Read or change the segment name.

PDBData, PDBUnknown

Purpose
Each line of a PDB file is a data record. There are many different types of records, from TITLE to MATRIX to ATOM. Each record is maintained by a separate class, all of which are derived from PDBData. This class contains an integer which describes which type of PDB data record it is. This allows other pieces of code to recast the base class into the proper subclass. This class also contains some protected functions which can read and write to specific columns in a string, since a PDB file is a fixed format file. The most trivial example of a subclass is PDBUnknown, which is constructed with the string containing the data record. All it does is copy and save the string so that it may be printed later.
Global Functions
PDBData *new_PDBData ( const char *data )
All of the derived classes are constructed with a (char *) containing the line from the PDB file. Since the parent class cannot create the appropriate child (in C++), there must be a helper function which knows which child to create. For the classes derived from PDBData, the appropriate helper function is new_PDBData. It knows how to look at the string to figure out which child to create. It then calls the constructor for that class and returns the pointer.
Files
PDBData.[Ch]
Enumerations
PDBType
Identifiers for the various PDB record types. They include:
HEADER   OBSLTE   COMPDN   SOURCE   EXPDTA
SPRSDE   JRNL     REMARK   SEQRES   FTNOTE
HELIX    SHEET    TURN     SSBOND   SITE
SCALE    MTRIX    TVECT    MODEL    ATOM
ANISOU   SIGUIJ   TER      ENDMDL   CONECT
UNKNOWN  REVDAT   FORMUL   ORIGX    SIGATM
AUTHOR   HET      CRYST1   HETATM   MASTER
END
PDBFormatStyle
This may be either COLUMNS or FIELDS, as there are two ways to print PDB data. The default is the column based format of the PDB file, where a record entry is, for example, the integer between columns 35 and 38. The other separates entries in a record by white space, and unknown entries are represented by a "#" character. This is useful for UNIX text manipulation tools, like awk and perl. fmd only uses the COLUMNS format.
Constructor
PDBData ( PDBType newtype ) - where type is the PDB record type.
Destructor
~PDBData ( void )
Functions
PDBType type ( void )
Returns the type of data which this class contains.
static void scan ( const char *data, int len, int start, int size,
int *ans, int default ) or
Real *ans, Real default ) or
char *ans )
Given a data string of length len, start at position start and read the next size characters. If reading an Int or Real, place the result in ans, using the default value if the field is blank. Otherwise, just return the string of length size in ans.
static void field ( const char *data, int fld, char *result )
Read in the entry from field fld in the data string and return the information in result.
static void sprintcol ( char *s, int start, int len,
const char *val ) or
int val ) or
int prec, Real val )
Print up to len characters from string val into string s starting at position start. If val is Real, use only prec digits of precision.
virtual void sprint ( char *s, PDBFormatStyle uesstyle = COLUMNS )
Print all the data concerning this record into the string s, using the given format style.

RecBisection

Purpose
This object is used to partition the computational domain (patches) into p regions where p is the number of processors. This object is a friend of the PatchDistrib object (see section PatchDistrib) and has direct access to its private data structure which holds the map of patches. The partitioning algorithm has three steps:
  1. The recursive coordinate bisection method is used to determine a temporary partitioning into 3D rectangular prisms where the prisms have approximately equal loads. The load of a prism is simply the sum of loads introduced by each patch in the prism. The compute_patch_load() function determines the load of each patch.
  2. After initial partitioning, the boundaries between regions are modified to improve the communication.
  3. Finally, the force calculation directions are revisited to further improve the computational load of the regions.
At the present time, only step 1 is implemented.
Files
PatchDistrib.[Ch]
Enumerations
directions: ( XDIR=0, YDIR, ZDIR )
Constructor
RecBisection ( void )
Destructor
~RecBisection ( void )
Method of Use
The partitioning is performed by invoking the function partition. This function is called by the PatchDistrib object after the computational domain has been divided into patches. Then, RecBisection accesses the private data of PatchDistrib to gather the patch information, performs partitioning, and assigns partitions to processors.
Functions
int partition ( void )
This is the function invoked from outside to perform partitioning.
void compute_patch_load ( void )
Compute the load introduced by each patch.
void rec_divide ( int n, const Partition& P )
Recursively divide a given partition P into n sub-partitions.
void assignNodes ( void )
Assign the partitions and patches to processors.
int prev_better ( float, float, float )
Returns TRUE if the previous bisection point is better than the current one.
void refine_edges ( void )
void refine_boundaries ( void )
void refine_surface ( void )
Functions not yet implemented.

SimParameters

Purpose
The SimParameters class is one large data structure which holds all of the control parameters for the program. Its member variables are too numerous to document here; refer to SimParameters.h for a list. Nearly all correspond closely to the similarly-named configuration file parameters described in section 4.3. There are also a number of inlined inquiry functions, which should be called instead of having many copies of the code which decodes certain sets of parameters. Currently, there are only inquiry functions to indicate when per-atom data vectors should be sent to be written out, but inquiry functions should probably be used in more places in fmd.
Files
SimParameters.[Ch]
Constructor
SimParameters ( void )
Destructor
~SimParameters ( void )
Functions
void initialize_config_data ( ConfigList *, char *&cwd )
Initialize SimParameters data from the ConfigList object.
void send_SimParameters ( Communicate * )
Used by the master process to send the parameters to the other processors.
void receive_SimParameters ( Message * )
Used by the other processors to receive the data from the master process.
Inquiry Functions
These inquiry functions are to be used instead of the member variables so that (a) the logic can be changed in just one place, if one wishes to change the criteria for when a type of data is to be written out, and (b) to reduce the amount of duplication in source code. The functions whose names begin with is_ return TRUE if that particular type of file is going to be written to at timestep step; if step is negative or absent, they return TRUE if that type of file will be written to at all during the run. The last two such functions are composites, e.g., is_vel_out_step() is just is_velTrj_step() || is_restart_step() || is_last_step(). The functions whose names begin with num_ return the number of data sets of that type that will be written during the run, and are used to provide data for trajectory file headers.
Bool is_coorTrj_step (int step=-1)
Bool is_velTrj_step (int step=-1)
Bool is_electForceTrj_step (int step=-1)
Bool is_allForceTrj_step (int step=-1)
Bool is_restart_step (int step=-1)
Bool is_snapshot_step (int step=-1)
Bool is_last_step (int step=-1)
Bool is_coor_out_step (int step=-1)
Bool is_vel_out_step (int step=-1)
int num_coorTrj_steps ()
int num_velTrj_steps ()
int num_electForceTrj_steps ()
int num_allForceTrj_steps ()
int num_snapshot_steps ()

SphericalBCForce

Purpose
SphericalBCForce implements forces due to spherical boundary condition constraints.
Files
SphericalBCForce.[Ch]
Constructor
SphericalBCForce ( Vector *origin, BigReal size ) This is the constructor for the SphericalBCForce force object. It is responsible for getting all the parameters from the SimParameters object and then determining if this object needs to perform any computation. It only needs to do so if there is some portion of the patch that lays outside of the spherical boundaries.
Destructor
~SphericalBCForce ( void ) The destructor for the SphericalBCForce force object currently does ABSOLUTELY NOTHING!!
Functions
void initialize_timestep ( void )
Set the energy to zero at the start of each time step.
Big_Real get_energy ( void )
Performs the energy calculations for applied spherical boundary condition constraints.
force ( int numAtoms, Vector *x, Vector *forces )
This function calculates the force and energy for the spherical boundary conditions for this patch.

Timer

Purpose
The Timer class is used for timing various aspects of fmd. It is modeled after the CMMD_node_timers implemented on the Thinking Machines Incorporated CM5. Each Timer can be started and stopped multiple times, accumulating the total time from each cycle. A Timer can also be cleared to set the accumulated time to zero. Each Timer tracks clock time, user cpu time, system cpu time, and total cpu time.
Files
Timer.[Ch]
Constructor
Timer ( void )
Destructor
~Timer ( void )
Method of Use
The functions start(), stop(), and clear() are use to start, stop and clear a Timer. The functions clock_time(), cpu_time(), user_time(), and system_time() are used to report the current values of a Timer. For example, to time both the total time to complete a loop and each iteration of the loop, the following code could be used:
   Timer total_time;
   Timer iter_time;

   total_time.start();
   while ( . . . )
     {
       iter_time.start();
       . . .
       iter_time.stop();
       printf ( "ITERATION TOOK %f sec/n",
                iter_time.clock_time() );
       iter_time.clear();
     }
   total_time.stop();
   printf ( "TOTAL TIME = %f secs/n" ,
            total_time.clock_time() );
Functions
void start ( void )
Start a time accumulating time. New time is added to any existing time.
void stop ( void )
Stop a timer from accumulating time.
void clear ( void )
Reset the accumulated time in a timer to zero.
float clock_time ( void )
Get the accumulated clock time from a timer.
float cpu_time ( void )
Get the accumulated CPU time from a timer. This is just user_time() + system_time().
float user_time ( void )
Get the accumulated user CPU time from a timer.
float system_time ( void )
Get the accumulated system CPU time from a timer.

UnitCell

Purpose
The UnitCell object conatins information about the triclinic unit cell which defines the simulation space. The UnitCell is used with any type of periodic boundary condition (for more information on periodic boundaries, see BoundaryMap). The UnitCell can be thought of as the unit cell for a lattice that is replicated in each direction of periodicity. It also contains information about the reciprical lattice, which allows efficient transformation of coordinates between lattice and physical space. The unit cell itself is defined by four vectors identifying the origin, x, y, and z axes of the basis.
Files
UnitCell.[Ch]
Constructor
UnitCell ( void )
Destructor
~UnitCell ( void )
Method of Use
The UnitCell is created by a call to setup(), which is passed the origin and the three lattice vectors (There must always be three lattice vectors even if the simulation uses mixed boundary conditions. Isolated, meaning non-periodic, boundaries will have margin patches added as necessary). setup calculates the reciprocal lattice. The UnitCell can then be used to calculate the overlap which is need for BoundaryMap and NeighborList as well as transform atomic coordinates across the boundary to implement periodic boundary conditions.
Functions
int setup ( Vector O, Vector X, Vector Y, Vector Z );
Initializes the unit cell with the origin and lattice vectors. It calculates and stores the reciprical lattice vectors for later use.
void numberOfCellsForRadius ( BigReal radius, const int xdim,
const int ydim, const int zdim, int *numberOfCells ) Calculates the number of patches needed in each direction to contain a sphere of the given radius. The values are contained in the integer array, which should be of dimension 3 and have been allocated by the calling routine. These values are used by BoundaryMap and NeighborList.
c2i ( Vector in, Vector &out )
Transforms a Vector in Cartesian space into lattice vector space by subtracting off the origin of the UnitCell and multiplying the resulting vector by the reciprocal lattice matrix.
i2c ( Vector in, Vector &out )
Transforms a Vector in lattice vector space into Cartesian space by multiplying the vector by the lattice vector matrix and adding the unit cell offset to the result.
offset ( Vector &v )
Adds the UnitCell offset to a Cartesian vector, transforming a relative vector to one with the UnitCells offset.
removeOffset ( Vector &v )
Subtracts the UnitCell offset from a Cartesian vector. This is used to obtain a relative vector for coordinated translation needed to implement periodic boundary conditions. It is used by PatchDistrib.
warp ( Vector &v )
Takes a vector in lattice coordinates and forces it into the unit cell.

Vector

Purpose
The Vector Class allows us to manipulate vectors as if they were standard data types. A vector contains three BigReal values; x, y, and z. There are two ways to use Vectors. The most natural is through operator overloading, which allows us to say things like: However, this means that multiple copies may occur needlessly, so we provide an alternate means of doing these functions. In essence, these are "two operand functions". So for example, v1.add(v2) will add v1 to v2.
Files
Vector.h, common.h
Constructor
Vector ( void )
By default, creates a null (zero length) vector.
Vector ( const Vector &v2 )
Copy constructor. Copies an existing vector into a new one.
Vector ( BigReal x, BigReal y, BigReal z )
Creates a vector for three explicit elements.
Destructor
~Vector ( void )
Method of Use
Explanation of the use of the Vector class is most easily given by example:
   Vector v1(1.1,2.2,3.3);  // Vector with explicit elements
   Vector v2(-1,55,32.1);
   Vector v3(v1+2*v2);
   Vector v4;

   cout << "v1.x = " << v1.x << "/n";
   cout << v1 << " " << v2 << " " v3 << "/n";
   v4 = v3*5 - v2/4;
   cout << cross(v3,v4) << "/n";
   v3 = (v1 += v2)/-4.25;
   v1.sub(v2);
   v4.mult(3.14);
   cout << v3.length() << " " << v2.dot(v1) << "/n";
   v2 = v4.unit(); // Set v2 to unit vector along v4.
Operators
friend int operator == ( const Vector &v1, const Vector &v2 )
Compares two vectors, returning TRUE if they are the same.
friend int operator != ( const Vector &v1, const Vector &v2 )
Compares two vectors, returning TRUE if they are NOT the same.
friend Vector operator + ( const Vector &v1, const Vector &v2 )
Returns Vector sum of two vectors.
friend Vector operator - ( const Vector &v1, const Vector &v2 )
Returns Vector difference of two vectors.
friend Real operator * ( const Vector &v1, const Vector &v2 )
Returns dot product of two vectors.
Vector operator * ( const Real &v1, const Real &f )
Returns the vector which is v1 * f
Vector operator * ( const Real &f, const Vector &v1 )
Returns the vector which is f * v1
Vector operator / ( const Real &v1, const Real &f )
Returns the vector which is v1 / f
friend Vector cross ( const Vector &v1, const Vector &v2 )
Returns Vector cross product.
friend ostream& operator << ( ostream& strm, const Vector &v1 )
Provides a means to print Vectors using streams. There is no corresponding input function.
Functions
These functions are not as versatile as friend functions above, but the should be faster as they don't need a copy.
Real &operator[](int i)
Let us pretend that v[0] is the X element, v[1], is the Y element, and v[0] is the Z element. All other values cause fmd to exit with an error.
Vector& operator+=(const Vector &v)
Adds two vectors together.
Vector& operator-=(const Vector &v)
Subtracts one vector from another.
void add(const Vector &v)
Adds two vectors, but does not return a value.
add_const(BigReal f)
Adds a scalar to each vector element.
void sub(const Vector &v)
Subtracts one vector from another, but does not return a value.
Real length ( void )
Returns the length (L2-norm) of a vector.
Vector unit ( void )
Returns a unit vector along the original vector.
void cross ( const Vector &v )
Replace this vector with the cross product of this Vector and v.
void mult ( BigReal f )
Multiplies each element of the vector by f.
void div ( BigReal f )
Divide each element of the vector by f.
BigReal dot ( const Vector &v )
Computes the dot product of this vector and v.

WildCard

Purpose
This class adds to its base class, NameTable, the ability to recognize "wild card" names. These are names ending in "*", which match any name which can be formed from the wild card by replacing the "*" with 0 or more appropriately chosen characters (allowing for the reduced character set supported by NameTable.) The user can enter names, some with "*", some without. The user of the class can later ask for all wildcards that match a given (non-wild card) name. This class is derived from NameTable, and primarily adds functionality to its base class. Only the added functions are described here.
Files
NameTable.[Ch]
Constructor
WildCard ( int initial_size = 64 )
Destructor
~WildCard ( void )
Functions
Note that all functions from the NameTable class can be used with a WildCard as well.
long enter_wildcard( const char *name );
Same as NameTable::index, but if "name" ends in "*", it is added to the pattern tree (without the *.)
long *match( const char *name ); long *match( long index )
Returns a 0-terminated string of indices, beginning with the index to the non-wild card form, followed by the wild card matches, from most to least specific. If there are no matches at all, or if name is a null pointer or a blank string, or index is zero, it returns a null pointer. "name", or the name corresponding to "index" should not contain "*". Note: the returned arrays should be deleted with "delete []" when no longer needed.

Miscellaneous Items

This chapter contains descriptions for some of the support functions provided as non-class objects. These include base-64 conversion routines, DCD file support, HDF file support, and string manipulation routines.

Base 64

Purpose
Only two functions make up the support for the base-64 notation used by fmd's special PDB and PSF file format extensions. 5 base-64 digits allow one to compactly count to just over 1 billion. Two functions are provided to convert to and from base-64: ltob64 and b64tol. Prototypes for the functions are provided by base64.h, while the functions and the character set are defined in base64.c. The character set is defined in a static variable in base64.c as
  static char base64_digit[] = "0123456789"
     "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
     "abcdefghijklmnopqrstuvwxyz@#";
Files
base64.[ch]
Functions
long b64tol ( char *s )
Interprets the string specified in *s as a base-64 number and returns it's value as a long. Leading spaces are ignored. Negative signs are allowed, but are not used by fmd's application.
char *ltob64 ( long num, char *result, int n )
Takes the long value given in num and converts it to a base-64 string in *result. n is the size of *result and is checked to make sure the conversion result will fit. It should be at least two greater than the number of base-64 digits expected, to allow for a possible "-" sign, and the trailing null.

DCDlib

Purpose
Provides support function for reading and writing X-PLOR format compatible DCD files. Defines and typedefs provided in dcdlib.h include:
 // DEFINE ERROR CODES THAT MAY BE RETURNED BY DCD ROUTINES

 #define DCD_DNE         -2   //  DCD file does not exist
 #define DCD_OPENFAILED  -3   //  Open of DCD file failed
 #define DCD_BADREAD     -4   //  read call on DCD file failed
 #define DCD_BADEOF      -5   //  premature EOF in DCD file
 #define DCD_BADFORMAT   -6   //  format of DCD file is wrong
 #define DCD_FILEEXISTS  -7   //  output file already exists
 #define DCD_BADMALLOC   -8   //  malloc failed

 //  FUNCTION ALLUSIONS

 typedef int DCDFileDesc;     // File handle type
Files
dcdlib.[ch]
Functions
DCDFileDesc open_dcd_read ( const char *filename )
Given a string in *filename containing the name of the DCD file to be read, this function opens the file and returns a file handle to be used by the other DCD functions when referencing the file. It returns DCD_DNE if the file does not exist, DCD_OPENFAILED if some other failure occured, or a valid DCD file handle if successful.
int read_dcdheader ( DCDFileDesc fd, int *N, int *NSET,
int *ISTART, int *NSAVC, double *DELTA, int *NAMNF,
int **FREEINDEXES )
Given a DCD file handle in fd, it returns data from the DCD file header.
N
Number of atoms.
NSET
Number of time steps saved.
ISTART
Starting timestep.
NSAVC
Time step save frequency.
DELTA
Duration of a time step.
NAMNF
Number of free atoms.
FREEINDEXES
Array indices for free atoms.
int read_dcdstep ( DCDFileDesc fd, int N, float *X, float *Y,
float *Z, int num_fixed, int first, int *indexes )
Function to read DCD data for a specific time step using file handle fd. N is the desired time step number, and coordinates are returned in *X, *Y, and *Z, respectively. Must set first set to 1 the first time the function is called. *indexes are the free atom indices, if any. The function returns 0 upon success, or a DCDlib error code on failure.
DCDFileDesc open_dcd_write ( const char *name )
Function to create a DCD file with the specified name. Returns a valid DCD file handle usable by the other DCDlib functions on success. If the file already exists, the function fails and returns DCD_FILEEXISTS. If the open fails for some other reason, it returns DCD_OPENFAILED.
int write_dcdheader ( DCDFileDesc fd, const char *filename,
int N, int NSET, int ISTART, int NSAVC, double DELTA,
const char *title, const char *title2 )
Function to write DCD file header data.
fd
DCD file handle to write to.
*filename
File name to include in remarks section.
N
Number of atoms.
NSET
Number of time steps to be written.
ISTART
Starting time step.
NSAVC
Number of time steps between saves.
DELTA
Length of a time step.
int write_dcdstep ( DCDFileDesc fd, int N, float *X, float *Y,
float *Z )
Function to write DCD data to file specified by fd for time step N. *X, *Y, and *Z are arrays containing the respective coordinates.
int close_dcd_read ( DCDFileDesc fd, int num_fixed,
int *indexes )
Close a DCD file that had been opened for reading. It also deallocates memory associated with the free atom index list.
int close_dcd_write ( DCDFileDesc fd )
Close a DCD file that had been opened for writing.
void pad ( char *s, int len )
Pads the string given in *s with spaces to reach the length given by len. If the string is longer than len, it is truncated to len.

HDFlib

Purpose
Provides support function for reading and writing NCSA HDF 4.0 format files. The structure of the files includes a set of file attributes to describe the data, and 3 extensible data sets. These characteristics are captured in a set of macros defined in hdflib.h:
HDF2_FORMAT "Version 2"
Defines the file structure version in use.
HDF2_MAX_ALEN 128
Sets the maximum length of attribute strings.
HDF2_MAX_RANK 2
Sets the maximum dimension of the data sets.
HDF2_MAX_FILES 64
Sets the maximum number of simultaneous files.
HDF2_DATASETS 3
Sets the number of data sets per file.
HDF2_READ DFACC_READ
HDF flag used for reading.
HDF2_WRITE DFACC_CREATE
HDF flag used for writing.
HDF2_MAX_ATTRS 11
Sets the maximum number of file attributes defined.
To help access the proper attributes, a character array, is initialized with the attribute names, and macros are defined with the proper indices. These macros are all of the form HDF2_<name>, where <name> is replace with the desired attribute. The attributes are:
0 : title
FMD title string provided by user.
1 : title2
FMD subtitle string provided by user.
2 : program
Name of the program which generated the file.
3 : revision_id
Revision ID of the program which generated the file.
4 : revision_date
Revision date of program that generated the file.
5 : creator
User name of person who created the file.
6 : date
Data the file was created.
7 : type
The type of file (ie. what is original purpose was). This includes output, trajectory, or restart.
8 : class
The type of data contained in the data sets, such as coordinates, velocities, energies, etc.
9 : format
The data structure used in the file. This attribute did not exist for "Version 1" HDF files.
10 : order
If this file is an energy trajectory file, this attribute specifies the energies and the order in which they are written.
A typedef is provided to ease declaration of arrays to hold the file attributes:
   typedef char attrs_t[HDF2_MAX_ATTRS][HDF2_MAX_ALEN];
Files
hdflib.[ch]
Functions
int hdf2_open ( int mode, char *filename, char *dataclass,
attrs_t attrs, int *rank, int ddims[], int *nsets )
Opens an HDF file for reading or writing. It returns a valid HDF file handle on success, or FAIL is something bad happens.
mode
HDF2_WRITE opens the file for writing. The necessary class, elapsed_time, and time_step datasets are created, and the file attribute strings are written. HDF2_READ opens the file and returns the information found.
*filename
The name or path to the desired file.
*dataclass
The data class to be written (ie. coordinates, velocities, etc.). Also used as the name of the name data set.
attrs
Array of strings to be assigned to the file attributes. Index in the array corresponds to the attribute indices above.
*rank
The rank (or dimension) of the main data set. May be any value from 1 up to HDF2_MAX_RANK (currently 2).
ddims
Array of dimension rank specifying the size of each rank dimension.
nsets
The number of time steps contained in each data set.
int hdf2_close ( int fid )
Given an HDF file handle, function closes the file. Function returns SUCCESS or FAIL, as appropriate.
int32 hdf2_dimids ( int fid, char *nm1, char *nm2 )
Given a HDF file handle and two strings, it assigns the strings as the names of the data set dimensions. The function returns SUCCESS or FAIL, as appropriate
int32 hdf2_getdimids ( int fid, char *nm1, char *nm2 )
Given and HDF file handle, the function returns in the strings the names of the data set dimensions. The function returns SUCCESS or FAIL as appropriate.
int32 hdf2_init_read ( int32 sd_fid, char *class, attrs_t attrs,
int32 *rank, int32 ddims[], int32 *nsets )
Open a HDF file for read and extract information from the file. The file attributes are returned in attrs, the rank and dimensions of the main data set are return in *rank and ddims, respectively, and the number of data sets. The function returns SUCCESS or FAIL, as appropriate.
int32 hdf2_init_write ( int32 sd_fid, char *class, attrs_t attrs,
int32 rank, int32 ddims[], int32 *nsets )
Initialize a HDF file opened for write and create the necessary data sets.
sd_fid
HDF file handle.
class
Data class and name of main data set.
attrs
Array of attribute strings, indexed according to the attribute indices.
rank
Rank of the main data set.
ddims
Dimension of the main data set.
nsets
Number of data sets written. It is just initialized to 0.
int hdf2_read ( int fileid, int nset, VOIDP data,
float64 *elapsed_time, int *time_step )
Given a HDF file handle and desired data set number, this functions returns the data and its corresponding elapsed time and time step number. Returns SUCCESS or FAIL as appropriate.
int hdf2_write ( int fileid, int nset, VOIDP data,
float64 *, int * )
Writes the provided data, elapsed time and time step number into the data set specified by nset of the HDF file specified by the file handle. Returns SUCCESS or FAIL as appropriate.
int32 hdf2_rw ( int mode, int fid, int nset, VOIDP data,
float64 *elapsed_time, int *time_step )
Actual function which performs the reads and writes.
int32 hdf2_storeattr ( int32 idx, char *str, attrs_t attrs )
Loads a string into a particular index in the attribute array.

STRlib

Purpose
Provides various string manipulation functions.
Files
strlib.[ch]
Functions
void FMD_truncate ( char *s )
Removes trailing blanks from the string s.
int FMD_read_line ( FILE *fd, char *buf )
Reads in a line of text from a file and returns it left justified in buf. Return 0 on success or -1 failure (usually EOF).
int FMD_find_word ( char *s, char *w )
Determines if the string specified by w is contained in string s. Returns 1 if the word is found, 0 otherwise.
int FMD_blank_string ( char *s )
Checks each character in the string s and returns 1 if isspace() is true for each (ie. all spaces), or 0 otherwise.
void FMD_find_first_word ( char *s, char *w )
This function finds the first word in string s. The first word is defined to be the first set of continuous non-space characters in a string. So in the string " AB14^ FDGFD GFDG" the first word would be "AB14^". The word is returned in the string pointed to by w.
int FMD_read_int ( FILE *fd, char *msg, Bool base64 )
Function used to read in integer lists from a PSF file. It will read the next integer it finds in the file passed to it. The integer may be in normal base-10 representation, or base-64 notation if base64 is TRUE. If an inappropriate alpha character is encountered, the program terminates. If an EOF is encountered, the program terminates. The string msg is used to indicate what we were trying to read in any error messages.
void FMD_pad ( char *s, int n )
Pads the string s out to length n with spaces. If s is already longer than n characters nothing happens. The user MUST insure that memory allocated s is sufficient to hold n characters, or memory overwrites may occur.
void FMD_remove_comment ( char *s )
Removes a comment from the end of a line delineated by an exclamation ("!") mark. The string s is just truncated at the point where the mark is found.
strcasecmp ( const char s[], const char t[] )
strncasecmp ( const char s[], const char t[], int n )
Private versions of the usual system library functions for doing case-sensitive and non-case-sensitive string comparisons. Only compiled if the corresponding system functions can not be found during the auto-configuration process.

Validation Tests

The fmd program can be validated by running known models and comparing results against previous accepted results. There is a subdirectory, Validation, in the FMD source tree which helps accomplish this. This directory provides fmd input files for a variety of sequential and parallel runs, sets of known, or canonical output files used for comparison purposes, and a execution script, runjobs, which allows execution of one or more of the models. The various models are identified with the nomenclature vr_nn, where the vr means "validation run", and nn is the run number. As seen below, the validation system is tightly coupled to these run names.

The basic structure of the Validation subdirectory is as follows:

    ./FMD
    `-----Validation
     |     `-----Canonical
     |      |     `-----P
     |      |      |-----`vr_00
     |      |      |-----`...
     |      |      |-----`vr_nn
     |      |     `-----S
     |      |      |-----`vr_00
     |      |      |-----`...
     |      |      |-----`vr_nn
     |     `-----Data
     |     `-----Jobs
     |      |     `-----P
     |      |     `-----S
     |     `-----Runjobs
     |      |     `-----LAM

The Data subdirectory contains the PDB and PSF files required for each model used. The types of runs are divided into parallel and sequential (single processor), hence the P(arallel) and S(equential) subdirectories under Canonical and Jobs.

A validation run is executed via the runjobs script in the Validation subdirectory.

Usage: runjobs [-h | [-p range,range | no] [-s range,range | no]]

    where -h .. displays a help message
          -p .. selects specific parallel jobs
                Default is all defined.
          -s .. selects specific sequential jobs
                Default is all defined.

    For -p and -s, range lists are specified as comma delimited
    lists of job numbers using the form "j-k,m,..".  This means
    jobs numbered "j" through "k" inclusive, job "m", and so on.
    "no" will deselect all jobs.

Prior to execution, the environment variable "FMD_PARTEST" must be set to YES or NO. This is simply to force awareness that runjobs must be hand configured to run fmd based on the architecture and MPI environment. When runjobs executes, it generates a log file with the name formed from the current date, "yymmdd.log", and records the jobs run and test results.

The actual process of executing a job involves several steps.

  1. Make is executed in the Jobs subdirectories to configure the input files. The Makefiles should be modified to set the correct directories.
  2. The MPI environment is checked. LAMMPI should start a single node virtual machine.
  3. A subdirectory with a name of the form "Runs/P/vr_xx" (for parallel job xx) is created
  4. fmd is executed in the Runs directory, using the input file for the selected job.
  5. The Canonical directory for the job is checked for the presence of a file named "default". If not present, the default test is skipped. If it is found, a standard difference operation is performed against the new and canonical output files. runjobs creates a file call IGNORE which contains patterns for differences which can safely be ignored, such as dates, timing data, machine names, etc. The result of the difference operation is written to a file named "[ps]_vr_xx.diffs". This file is then compared to a NULL file to see if any potentially significant differences were found. If none are found, the difference file is removed, and success is reported. If there are differences, the file is retained. In addition, failure is reported in the log file, with directions to review the appropriate difference file. Changes in spelling and output formatting are routinely spotted, and go away when the Canonical files are updated. Any differences involving state variables should be carefully investigate, as they could be serious.
  6. The Canonical directory for the job is checked for the presence of a shell script named "special". If found, it is executed to perform some special sequence of tests. The script will be executed in the job's Runs subdirectory. It is expected to output any error messages on STDOUT, and exit with a return status of 0 for success or 1 for failure. runjobs will store any output in a file in the Validation directory with the name "[ps]_vr_xx.spec", and report success/failure in its log file. The significance of any failures reported by these tests should be thoroughly investigate.

The main reason runjobs currently requires hand configuration is the plethora of ways MPI environments use to execute parallel jobs. There are several syntaxes associated with the standard mpirun command, and one may or may not have to take special actions to secure the required number of processors (lamboot with LAM-MPI, for instance). Sample runjob scripts, configured for two different LAM-MPI environments, are provided in the Validation/Runjobs/LAM subdirectory.

Note that some jobs depend on output from previous jobs (to test restarts, for instance). Hence not all can be run in isolation. A description of the various tests performed can be found in the "descriptions" file in each of the Jobs subdirectories.

References

B. R. Brooks, R. E. Bruccoleri, B. D. Olafson, D. J. States, S. Swaminathan and M. Karplus, "CHARMm: A Program for Macromolecular Energy, Minimization, and Dynamics Calculations.", J. Comput. Chem., 4(2), pages 187-217, 1983.

Axel T. Br@"unger, "X-PLOR, Version 3.1: A System for X-ray Crystallography and NMR", The Howard Hughes Medical Institute and Department of Molecular Biophysics and Biochemistry, Yale University, 260 Whitney Avenue, P.O. Box 6666, New Haven, CT 06511, 1992.

L. Greengard and V. Rokhlin (a), "A Fast Algorithm for Particle Simulations", J. Comp. Phys., 73, pages 325-348, 1987.

L. Greengard and V. Rokhlin (b), "Rapid evaluation of potential fields in three dimensions." In C. Anderson and Claude Greengard, editors, Vortex Methods, 1360 of Lecture Notes in Mathematics, pages 121-141, Berlin, May 1988. Springer Verlag.

A. McKenny and R. Pachter, "Implementation Issues for Fast Multipole Implementations for Molecular Dynamics Simulations", SIAM Annual Meeting, July, 1996.

M.T. Nelson, W.F. Humphrey, A. Gursoy, A. Dalke, L.V. Kal'e, R.D. Skeel, K. Schulten and R. Kufrin, "NAMD: A Parallel, Object-Oriented Molecular Dynamics Program", International Journal of Supercomputer Applications and High Performance Computing, 10, #4, pages 251-268, 1996.

M. Nelson, W. Humphrey, A. Gursoy, A. Dalke, L. Kale, R. Skeel, K. Schulten and R. Kufrin, "MDScope: A Visual Computing Environment for Structural Biology", Comp. Phys. Comm., 1995 (in press).

Variable/Constant Index

Jump to: 1 - a - b - c - d - e - f - g - i - l - m - n - o - p - r - s - t - u - v - x

1

  • 1-4Scaling
  • a

  • AllForceTrjFile, AllForceTrjFile
  • AllForceTrjFormat
  • AllForceTrjFreq, AllForceTrjFreq
  • angleForce, Patch
  • atomlisttail, Patch
  • AtomMsgList
  • atommsgsoutstanding, Patch
  • atoms, Patch
  • atomsreceived, Patch
  • atomsremoved, Patch
  • b

  • bondedinfo, Patch
  • BondedWithNeighbor
  • bondForce, Patch
  • c

  • Cold
  • ColdRate
  • ColdTemp
  • Collect, maxEnergyCount
  • CommDir
  • CommError
  • COMmotion
  • ConsExp
  • ConsKfile
  • ConsKol
  • ConsRef
  • Constraints
  • Coordinates
  • coormsgsoutstanding, Patch
  • CoorTrjFile
  • CoorTrjFormat
  • CoorTrjFreq
  • currentTimestep, Patch
  • Cutoff
  • CWD
  • d

  • DiceFreq
  • Dielectric
  • Dihedral
  • dihedralforce, Patch
  • donelocal, Patch
  • e

  • EField
  • EFieldOn
  • electforce, Patch
  • ElectForceTrjFreq
  • ElectForceTrjName
  • ElectTrjFormat
  • ElectTrjFreq
  • ElectTrjName
  • EnergyTrjFile
  • EnergyTrjFreq
  • Exclude
  • f

  • f, Patch
  • FirstTimestep
  • FMA
  • FMADegSep
  • FMAlevels
  • FMALevels
  • FMAmp
  • FMAMp
  • FMAOn
  • FMASuperNode
  • forcemsgsoutstanding, Patch
  • g

  • GlobalTest
  • i

  • improperforce, Patch
  • InitCoordsDataset
  • InitCoordsFile
  • InitCoordsFormat
  • integrator, Patch
  • l

  • Langevin
  • LangevinCol
  • LangevinFile
  • LangevinTemp
  • LdbSendStep
  • LdbStepsPerCycle
  • LdbStrategy
  • LintList, LIST_EMPTY
  • LIST_EMPTY, LintList
  • LongSplitting
  • m

  • Margin
  • maxEnergyCount, Collect
  • MaximumMove
  • Minimization
  • MTSAlgorithm
  • myId, Patch
  • n

  • numAngles
  • numAtoms
  • numAtoms, Patch
  • numatomsadded, Patch
  • numatomsremoved, Patch
  • numBonds
  • numConstraints
  • numDihedrals
  • numExclusions
  • numImpropers
  • numMultipleDihedrals
  • numMultipleImpropers
  • numPatches, PatchDistrib
  • numrecv, Patch
  • numsend, Patch
  • NumSteps
  • o

  • OutputEnergies
  • OutputFormat
  • OutputName
  • p

  • PairListDist
  • Parameters
  • parentList, Patch
  • Patch, angleForce
  • Patch, atomlisttail
  • Patch, atommsgsoutstanding
  • Patch, atoms
  • Patch, atomsreceived
  • Patch, atomsremoved
  • Patch, bondedinfo
  • Patch, bondForce
  • Patch, coormsgsoutstanding
  • Patch, currentTimestep
  • Patch, dihedralforce
  • Patch, donelocal
  • Patch, electforce
  • Patch, f
  • Patch, forcemsgsoutstanding
  • Patch, improperforce
  • Patch, integrator
  • Patch, myId
  • Patch, numAtoms
  • Patch, numatomsadded
  • Patch, numatomsremoved
  • Patch, numrecv
  • Patch, numsend
  • Patch, parentList
  • Patch, recvneighbors
  • Patch, returnforces
  • Patch, sendneighbors
  • Patch, tsType
  • Patch, v
  • Patch, x
  • PatchDistrib, numPatches
  • PDB, PDBAtomList
  • PDBAtomList, PDB
  • Periodicity
  • PLMmarginCheck
  • r

  • recvneighbors, Patch
  • RescaleFreq
  • RescaleTemp
  • RestartFormat
  • RestartFreq
  • RestartName
  • returnforces, Patch
  • ReturnForceVectors
  • s

  • Seed
  • SendMethod
  • sendneighbors, Patch
  • SnapshotFile
  • SnapshotFormat
  • SnapshotStart
  • SnapshotStop
  • SpericalBCexp1
  • SphericalBC
  • SphericalBCCenter
  • SphericalBCexp2
  • SphericalBCk1
  • SphericalBCk2
  • SphericalBCr1
  • SphericalBCr2
  • StepsPerCycle, StepsPerCycle
  • StringList
  • Structure
  • SwitchDist
  • Switching
  • t

  • TCouple
  • TCoupleCol
  • TCoupleFile
  • TCoupleTemp
  • Temperature
  • TimeStep
  • Title
  • Title2
  • tsType, Patch
  • u

  • UnitCell
  • UnitOrigin
  • UnitX
  • UnitY
  • UnitZ
  • v

  • v, Patch
  • Velocities
  • VelocitiesDataset
  • VelocitiesFormat
  • VelTrjFile
  • VelTrjFormat
  • VelTrjFreq
  • x

  • x, Patch
  • Function Index

    Jump to: ! - & - * - + - - - / - < - = - [ - a - b - c - d - e - f - g - h - i - l - m - n - o - p - r - s - t - u - v - w - x - y - z

    !

  • !=, Vector
  • &

  • &operator<<, Message
  • *

  • *, Vector, *, Vector, *, Vector
  • +

  • +, Vector
  • -

  • -, Vector
  • /

  • /, Vector
  • <

  • <<, Vector
  • =

  • ==, Vector
  • [

  • [], Vector
  • a

  • add, GenericList
  • add, IntList
  • add, LintList
  • add_atoms, Integrate
  • add_element, ParseOptions
  • add_forces, FullDirect
  • add_forces, Patch
  • add_msg, MessageManager
  • add_msg, MessageQueue
  • add_node, Communicate
  • add_patch, Patchlist
  • add_value, IntTree
  • all_coordinate_force, Patch
  • all_coordinate_init, Patch
  • all_force, Collect
  • all_force, Output
  • alternatelocation, PDBAtom
  • AngleForce, constructor
  • assign_angle_index, Parameters
  • assign_bond_index, Parameters
  • assign_dihedral_index, Parameters
  • assign_improper_index, Parameters
  • assign_vdw_index, Parameters
  • assignNodes, RecBisection
  • atoBool, ParseOptions
  • atom, PDB
  • atom_type_index, Parameters, atom_type_index, Parameters
  • atomcharge, Molecule
  • atomimass, Molecule
  • atommass, Molecule
  • atoms, PDB
  • atomvdwtype, Molecule
  • b

  • b64tol, BASE64
  • back, Message
  • BASE64, b64tol
  • BASE64, ltob64
  • bonded_coordinate_force, Patch
  • bonded_coordinate_init, Patch
  • BondForce, constructor
  • BondForce, destructor
  • BondForce, get_energy
  • BondForce, initialize_timestep
  • BondForce, local_force
  • BondForce, local_init
  • BondForce, neighbor_force
  • BondForce, neighbor_init
  • BondForce, set_recycle
  • BoundaryMap, constructor
  • BoundaryMap, coordIndex
  • BoundaryMap, createBoundaryMap
  • BoundaryMap, destructor
  • BoundaryMap, Image
  • BoundaryMap, middleIndexOfMap
  • BoundaryMap, operator[]
  • BoundaryMap, patchIdIndex
  • BoundaryMap, patchOffset
  • broadcast_all, Communicate
  • broadcast_others, Communicate
  • BufferMPI, constructor
  • BufferMPI, destructor
  • BufferMPI, err_if_busy
  • BufferMPI, error_abort
  • BufferMPI, get_data_size
  • BufferMPI, get_free_buf
  • BufferMPI, get_size
  • BufferMPI, hex_dump
  • BufferMPI, init
  • BufferMPI, is_busy
  • BufferMPI, pack_buffer
  • BufferMPI, print_buffer
  • BufferMPI, recv_buffer
  • BufferMPI, reset_buffer
  • BufferMPI, send_buffer
  • BufferMPI, set_communicator
  • BufferMPI, unpack_buffer
  • BufferMPI, wait
  • build_constraint_params, Molecule
  • build_langevin_params, Molecule
  • c

  • c2i, UnitCell
  • calc_eff_force, LongForce
  • calc_with_node, FullDirect
  • chain, PDBAtom
  • check, Inform
  • check14excl, Molecule
  • check_consistancy, ParseOptions
  • checkexcl, Molecule
  • clear, Message
  • clear, Timer
  • client_startup, Node
  • clock_time, Timer
  • close_dcd_read, DCDlib
  • close_dcd_write, DCDlib
  • Collect, all_force
  • Collect, constructor
  • Collect, coordinate
  • Collect, destructor
  • Collect, energy
  • Collect, init_timestep
  • Collect, long_force
  • Collect, propagate
  • Collect, short_force
  • Collect, velocity
  • Communicate, add_node
  • Communicate, broadcast_all
  • Communicate, broadcast_others
  • Communicate, constructor
  • Communicate, debug
  • Communicate, destructor
  • Communicate, errorno
  • Communicate, nodes
  • Communicate, receive
  • Communicate, send
  • Communicate, send_all
  • Communicate, send_method
  • Communicate, this_node
  • CommunicateMPI
  • CommunicateMPI, constructor
  • CommunicateMPI, destructor
  • CommunicateMPI, do_receive
  • CommunicateMPI, do_send_msg
  • CommunicateMPI, do_send_queue
  • CommunicateMPI, get_sendbuf
  • CommunicateMPI, pack_message
  • CommunicateMPI, unpack_message
  • compute_patch_load, RecBisection
  • ConfigList, constructor
  • ConfigList, destructor
  • ConfigList, find
  • ConfigList, Okay
  • ConstraintForce, constructor
  • ConstraintForce, destructor
  • ConstraintForce, force
  • ConstraintForce, get_energy
  • ConstraintForce, init
  • ConstraintForce, initialize_timestep
  • constructor, AngleForce
  • constructor, BondForce
  • constructor, BoundaryMap
  • constructor, BufferMPI
  • constructor, Collect
  • constructor, Communicate
  • constructor, CommunicateMPI
  • constructor, ConfigList
  • constructor, ConstraintForce
  • constructor, DataElement
  • constructor, DihedralForce
  • constructor, FieldForce
  • constructor, FMAInterface
  • constructor, FullDirect
  • constructor, GenericList
  • constructor, GlobalIntegrate
  • constructor, HashTable
  • constructor, ImproperForce
  • constructor, Inform
  • constructor, Integrate
  • constructor, IntList
  • constructor, IntTree
  • constructor, LintList
  • constructor, LoadBalance
  • constructor, LongForce
  • constructor, Message
  • constructor, MessageManager
  • constructor, MessageQueue
  • constructor, Molecule
  • constructor, MultiBond
  • constructor, NameTable
  • constructor, NeighborList
  • constructor, Node
  • constructor, Output
  • constructor, Parameters
  • constructor, ParseOptions
  • constructor, Patch
  • constructor, Patchdistrib
  • constructor, Patchlist
  • constructor, PDB
  • constructor, PDBAtom
  • constructor, PDBAtomRecord
  • constructor, PDBData
  • constructor, PDBHetatm
  • constructor, RecBisection
  • constructor, SimParameters
  • constructor, SphericalBCForce
  • constructor, Timer
  • constructor, UnitCell
  • constructor, Vectors
  • constructor, WildCard
  • coordinate, Collect
  • coordinate, Output
  • coordinates, PDBAtom
  • coordIndex, BoundaryMap
  • copy_self, Patch
  • cpu_time, Timer
  • create, HashTable
  • create_initial_distrib, PatchDistrib
  • createBoundaryMap, BoundaryMap
  • createNeighborList, NeighborList
  • cross, Vector
  • current, Message
  • current_data, HashTable
  • current_datap, HashTable
  • current_index, HashTable
  • d

  • DataElement, constructor
  • DCDlib, close_dcd_read
  • DCDlib, close_dcd_write
  • DCDlib, open_dcd_read
  • DCDlib, open_dcd_write
  • DCDlib, pad
  • DCDlib, read_dcdheader
  • DCDlib, read_dcdstep
  • DCDlib, write_dcdheader
  • DCDlib, write_dcdstep
  • debug, Communicate
  • defined, ParseOptions
  • del, Message
  • del_patch, Patchlist
  • delete_atoms, Integrate
  • delete_patches, LoadBalance
  • deposit_atoms, GlobalIntegrate
  • deposit_coords, FMAInterface
  • deposit_coords, FullDirect
  • destination, Inform
  • destructor, BondForce
  • destructor, BoundaryMap
  • destructor, BufferMPI
  • destructor, Collect
  • destructor, Communicate
  • destructor, CommunicateMPI
  • destructor, ConfigList
  • destructor, ConstraintForce
  • destructor, FieldForce
  • destructor, FMAInterface
  • destructor, FullDirect
  • destructor, GenericList
  • destructor, GlobalIntegrate
  • destructor, HashTable
  • destructor, Inform
  • destructor, Integrate
  • destructor, IntList
  • destructor, IntTree
  • destructor, LintList
  • destructor, LoadBalance
  • destructor, LongForce
  • destructor, Message
  • destructor, MessageManager
  • destructor, MessageQueue
  • destructor, Molecule
  • destructor, MultiBond
  • destructor, NameTable
  • destructor, NeighborList
  • destructor, Node
  • destructor, Output
  • destructor, Parameters
  • destructor, ParseOptions
  • destructor, Patch
  • destructor, Patchdistrib
  • destructor, Patchlist
  • destructor, PDB
  • destructor, PDBAtom
  • destructor, PDBAtomRecord
  • destructor, PDBData
  • destructor, PDBHetatm
  • destructor, RecBisection
  • destructor, SimParameters
  • destructor, SphericalBCForce
  • destructor, Timer
  • destructor, UnitCell
  • destructor, Vectors
  • destructor, WildCard
  • DihedralForce, constructor
  • div, Vector
  • do_COLD, GlobalIntegration
  • do_integration, GlobalIntegrate
  • do_integration, Integrate
  • do_receive, CommunicateMPI
  • do_send_msg, CommunicateMPI
  • do_send_queue, CommunicateMPI
  • do_timestep, Patchlist
  • do_verlet, GlobalIntegration
  • done_reading_files, Parameters
  • done_reading_structure, Parameters
  • doSimulation, Node
  • dump_data, HashTable
  • e

  • ElectForce, get_energy
  • ElectForce, initialize_timestep
  • ElectForce, local_force
  • ElectForce, local_init
  • ElectForce, neighbor_force
  • ElectForce, neighbor_init
  • end_cycle, LongForce
  • end_cycle, Patch
  • energy, Collect
  • energy, Output
  • enter_wildcard, WildCard
  • err_if_busy, BufferMPI
  • error_abort, BufferMPI
  • errorno, Communicate
  • execute_FMA, FMAInterface
  • exists, HashTable
  • exists, ParseOptions
  • f

  • field, PDBData
  • FieldForce, constructor
  • FieldForce, destructor
  • FieldForce, force
  • FieldForce, get_energy
  • FieldForce, init
  • FieldForce, initialize_timestep
  • find, ConfigList
  • find_atom, PDB
  • find_atom_alternatelocation, PDB
  • find_atom_chain, PDB
  • find_atom_insertioncode, PDB
  • find_atom_name, PDB
  • find_atom_residuename, PDB
  • find_atom_residueseq, PDB
  • find_atom_segmentname, PDB
  • find_atom_serialnumber, PDB
  • find_atoms_in_region, PDB
  • find_extremes, PDB
  • find_msg, MessageManager
  • FMAInterface, constructor
  • FMAInterface, deposit_coords
  • FMAInterface, destructor
  • FMAInterface, execute_FMA
  • FMAInterface, get_patch_forces
  • FMD_blank_string, STRlib
  • FMD_find_first_word, STRlib
  • FMD_find_word, STRlib
  • FMD_pad, STRlib
  • FMD_read_int, STRlib
  • FMD_read_line, STRlib
  • FMD_remove_comment, STRlib
  • FMD_truncate, STRlib
  • footnote, PDBAtom
  • force, ConstraintForce
  • force, FieldForce
  • force, SphericalBCForce
  • FullDirect, add_forces
  • FullDirect, calc_with_node
  • FullDirect, constructor
  • FullDirect, deposit_coords
  • FullDirect, destructor
  • FullDirect, get_patch_forces
  • FullDirect, start_direct ()
  • FullDirect, wait_for_calcs
  • g

  • GenericList, add
  • GenericList, constructor
  • GenericList, destructor
  • GenericList, head
  • GenericList, next
  • GenericList, reset
  • GenericList, size
  • get(BigReal), ParseOptions
  • get(char), ParseOptions
  • get(int), ParseOptions
  • get(StringList), ParseOptions
  • get(Vector), ParseOptions
  • get, Message
  • get_angle, Molecule
  • get_angle_params, Parameters
  • get_angles_for_atom, Molecule
  • get_atomtype, Molecule
  • get_bond, Molecule
  • get_bond_params, Parameters
  • get_bonds_for_atom, Molecule
  • get_cons_params, Molecule
  • get_data_size, BufferMPI
  • get_dihedral, Molecule
  • get_dihedral_params, Parameters
  • get_dihedrals_for_atom, Molecule
  • get_energy, BondForce
  • get_energy, ConstraintForce
  • get_energy, ElectForce
  • get_energy, FieldForce
  • get_energy, MultiBond
  • get_energy, SphericalBCForce
  • get_free_buf, BufferMPI
  • get_head, MessageManager
  • get_head, MessageQueue
  • get_improper, Molecule
  • get_improper_params, Parameters
  • get_impropers_for_atom, Molecule
  • get_initial_positions, Patch
  • get_initial_velocities, Patch
  • get_kinetic_energy, Patch
  • get_list_index, Patch
  • get_long_force, LongForce
  • get_maxNeighborPatches, PatchDistrib
  • get_maxPatchNum, PatchDistrib
  • get_msg_by_node, MessageQueue
  • get_msg_by_tag, MessageQueue
  • get_patch_forces, FMAInterface
  • get_patch_forces, FullDirect
  • get_patch_id, PatchDistrib
  • get_recv_patches, PatchDistrib
  • get_send_patches, PatchDistrib
  • get_sendbuf, CommunicateMPI
  • get_size, BufferMPI
  • get_vdw_pair_parameters, Parameters
  • get_vdw_parameters, Parameters
  • getAtomList, Patch
  • getNumAtoms, Patch
  • GlobalInegration, do_integration
  • GlobalIntegrate, constructor
  • GlobalIntegrate, deposit_atoms
  • GlobalIntegrate, destructor
  • GlobalIntegrate, process_msg
  • GlobalIntegrate, return_atoms
  • GlobalIntegration, do_COLD
  • GlobalIntegration, do_verlet
  • h

  • HashTable, constructor
  • HashTable, create
  • HashTable, current_data
  • HashTable, current_datap
  • HashTable, current_index
  • HashTable, destructor
  • HashTable, dump_data
  • HashTable, exists
  • HashTable, nentries
  • HashTable, next
  • HashTable, operator []
  • HashTable, remove
  • HashTable, reset_iterator
  • hdf2_close, HDFlib
  • hdf2_dimids, HDFlib
  • hdf2_getdimids, HDFlib
  • hdf2_init_read, HDFlib
  • hdf2_init_write, HDFlib
  • hdf2_open, HDFlib
  • hdf2_read, HDFlib
  • hdf2_rw, HDFlib
  • hdf2_storeattr, HDFlib
  • hdf2_write, HDFlib
  • HDFlib hdf2_init_read
  • HDFlib, hdf2_close
  • HDFlib, hdf2_dimids
  • HDFlib, hdf2_getdimids
  • HDFlib, hdf2_init_write
  • HDFlib, hdf2_open
  • HDFlib, hdf2_read
  • HDFlib, hdf2_rw
  • HDFlib, hdf2_storeattr
  • HDFlib, hdf2_write
  • head, GenericList
  • head, LintList
  • hex_dump, BufferMPI
  • i

  • i2c, UnitCell
  • id, Patch
  • Image, BoundaryMap
  • ImproperForce, constructor
  • index, NameTable
  • Inform, check
  • Inform, constructor
  • Inform, destination
  • Inform, destructor
  • Inform, on
  • Inform, send
  • Inform, use_comm
  • init, BufferMPI
  • init, ConstraintForce
  • init, FieldForce
  • init, Integrate
  • init_patches, LoadBalance
  • init_timestep, Collect
  • initialize_config_data, SimParameters
  • initialize_first_timestep, LongForce
  • initialize_timestep, BondForce
  • initialize_timestep, ConstraintForce
  • initialize_timestep, ElectForce
  • initialize_timestep, FieldForce
  • initialize_timestep, LongForce
  • initialize_timestep, MultiBond
  • initialize_timestep, Patch
  • initialize_timestep, SphericalBCForce
  • insertioncode, PDBAtom
  • Integrate, add_atoms
  • Integrate, constructor
  • Integrate, delete_atoms
  • Integrate, destructor
  • Integrate, do_integration
  • Integrate, init
  • internal_find, ParseOptions
  • IntList, add
  • IntList, constructor
  • IntList, destructor
  • IntList, num
  • IntList, unique
  • IntTree, add_value
  • IntTree, constructor
  • IntTree, destructor
  • IntTree, make_array
  • IntTree, size
  • is_allForceTrj_step, SimParameters
  • is_atom_constrained, Molecule
  • is_busy, BufferMPI
  • is_coor_out_step, SimParameters
  • is_coorTrj_step, SimParameters
  • is_electForceTrj_step, SimParameters
  • is_last_step, SimParameters
  • is_parent_node, ParseOptions
  • is_restart_step, SimParameters
  • is_snapshot_step, SimParameters
  • is_vel_out_step, SimParameters
  • is_velTrj_step, SimParameters
  • item, Message
  • items, Message
  • l

  • langevin_force_val, Molecule
  • langevin_param, Molecule
  • ldb_method1, LoadBalance
  • Length, NeighborList
  • length, Vector
  • LintList, add
  • LintList, constructor
  • LintList, destructor
  • LintList, head
  • LintList, next
  • LoadBalance, constructor
  • LoadBalance, delete_patches
  • LoadBalance, destructor
  • LoadBalance, init_patches
  • LoadBalance, ldb_method1
  • local_force, BondForce
  • local_force, ElectForce
  • local_force, MultiBond
  • local_force, Patch
  • local_init, BondForce
  • local_init, ElectForce
  • local_init, MultiBond
  • local_init, Patch
  • long_force, Collect
  • long_force, Output
  • LongForce, calc_eff_force
  • LongForce, constructor
  • LongForce, destructor
  • LongForce, end_cycle
  • LongForce, get_long_force
  • LongForce, initialize_first_timestep
  • LongForce, initialize_timestep
  • LongForce, prepare_to_receive_atoms
  • LongForce, receive_atom_info
  • LongForce, save_state
  • LongForce, send_atom_info
  • LongForce, send_forces
  • ltob64, BASE64
  • m

  • make_array, IntTree
  • make_dependencies, ParseOptions
  • master_startup, Node
  • match, WildCard
  • Message, &operator<<
  • Message, back
  • Message, clear
  • Message, constructor
  • Message, current
  • Message, del
  • Message, destructor
  • Message, get
  • Message, item
  • Message, items
  • Message, put
  • Message, reset
  • Message, size
  • Message, skip
  • Message, type
  • MessageManager, add_msg
  • MessageManager, constructor
  • MessageManager, destructor
  • MessageManager, find_msg
  • MessageManager, get_head
  • MessageManager, num
  • MessageQueue, add_msg
  • MessageQueue, constructor
  • MessageQueue, destructor
  • MessageQueue, get_head
  • MessageQueue, get_msg_by_node
  • MessageQueue, get_msg_by_tag
  • MessageQueue, num
  • middleIndexOfMap, BoundaryMap
  • Molecule, atomcharge
  • Molecule, atomimass
  • Molecule, atommass
  • Molecule, atomvdwtype
  • Molecule, build_constraint_params
  • Molecule, build_langevin_params
  • Molecule, check14excl
  • Molecule, checkexcl
  • Molecule, constructor
  • Molecule, destructor
  • Molecule, get_angle
  • Molecule, get_angles_for_atom
  • Molecule, get_atomtype
  • Molecule, get_bond
  • Molecule, get_bonds_for_atom
  • Molecule, get_cons_params
  • Molecule, get_dihedral
  • Molecule, get_dihedrals_for_atom
  • Molecule, get_improper
  • Molecule, get_impropers_for_atom
  • Molecule, is_atom_constrained
  • Molecule, langevin_force_val
  • Molecule, langevin_param
  • Molecule, print_angles
  • Molecule, print_atoms
  • Molecule, print_bonds
  • Molecule, print_dihedrals
  • Molecule, print_exclusions
  • Molecule, print_impropers
  • Molecule, read_psf_file
  • Molecule, receive_Molecule
  • Molecule, send_Molecule
  • move_patch, PatchList
  • mult, Vector
  • MultiBond, initialize_timestep
  • MultiBond, constructor
  • MultiBond, destructor
  • MultiBond, get_energy
  • MultiBond, local_force
  • MultiBond, local_init
  • MultiBond, neighbor_force
  • MultiBond, neighbor_init
  • n

  • name, NameTable
  • name, PDBAtom
  • NameTable, constructor
  • NameTable, destructor
  • NameTable, index
  • NameTable, name
  • NameTable, size
  • neighbor_force, BondForce
  • neighbor_force, ElectForce
  • neighbor_force, MultiBond
  • neighbor_init, BondForce
  • neighbor_init, ElectForce
  • neighbor_init, MultiBond
  • NeighborList, constructor
  • NeighborList, createNeighborList
  • NeighborList, destructor
  • NeighborList, Length
  • NeighborList, operator[]
  • nentries, HashTable
  • next, GenericList
  • next, HashTable
  • next, LintList
  • Node, client_startup
  • Node, constructor
  • Node, destructor
  • Node, doSimulation
  • Node, master_startup
  • Node, velocities_from_PDB
  • nodes, Communicate
  • num, IntList
  • num, MessageManager
  • num, MessageQueue
  • num_allForceTrj_steps, SimParameters
  • num_atoms, PDB
  • num_coorTrj_steps, SimParameters
  • num_electForceTrj_steps, SimParameters
  • num_recv_for_patch, PatchDistrib
  • num_send_for_patch, PatchDistrib
  • num_snapshot_steps, SimParameters
  • num_velTrj_steps, SimParameters
  • numberOfCellsForRadius, UnitCell
  • o

  • occupancy, PDBAtom
  • offset, UnitCell
  • okay, ConfigList
  • on, Inform
  • open_dcd_read, DCDlib
  • open_dcd_write, DCDlib
  • operator [], HashTable
  • operator[], BoundaryMap
  • operator[], NeighborList
  • optional(BigReal), ParseOptions
  • optional(char), ParseOptions
  • optional(int), ParseOptions
  • optional(StringList), ParseOptions
  • optional(u_int), ParseOptions
  • optional(Vector), ParseOptions
  • optionalB(int), ParseOptions
  • Output, all_force
  • Output, constructor
  • Output, coordinate
  • Output, destructor
  • Output, energy
  • Output, long_force
  • Output, short_force
  • Output, velocity
  • p

  • pack_buffer, BufferMPI
  • pack_message, CommunicateMPI
  • pad, DCDlib
  • Parameters, assign_angle_index
  • Parameters, assign_bond_index
  • Parameters, assign_dihedral_index
  • Parameters, assign_improper_index
  • Parameters, assign_vdw_index
  • Parameters, atom_type_index, Parameters, atom_type_index
  • Parameters, constructor
  • Parameters, destructor
  • Parameters, done_reading_files
  • Parameters, done_reading_structure
  • Parameters, get_angle_params
  • Parameters, get_bond_params
  • Parameters, get_dihedral_params
  • Parameters, get_improper_params
  • Parameters, get_vdw_pair_parameters
  • Parameters, get_vdw_parameters
  • Parameters, print_angle_summary
  • Parameters, print_bond_summary
  • Parameters, print_dihedral_summary
  • Parameters, print_improper_summary
  • Parameters, print_param_summary
  • Parameters, print_vdw_pair_summary
  • Parameters, print_vdw_summary
  • Parameters, read_parameter_file
  • Parameters, receive_Parameters
  • Parameters, send_Parameters
  • parse, PDBAtom
  • PARSE_ANYTHING, ParseOptions
  • PARSE_BIGREAL, ParseOptions
  • PARSE_BOOL, ParseOptions
  • PARSE_FLOAT, ParseOptions
  • PARSE_INT, ParseOptions
  • PARSE_MULTIPLES, ParseOptions
  • PARSE_STRING, ParseOptions
  • PARSE_UINT, ParseOptions
  • PARSE_VECTOR, ParseOptions
  • ParseOptions, add_element
  • ParseOptions, atoBool
  • ParseOptions, check_consistancy
  • ParseOptions, constructor
  • ParseOptions, defined
  • ParseOptions, destructor
  • ParseOptions, exists
  • ParseOptions, get(BigReal)
  • ParseOptions, get(char)
  • ParseOptions, get(int)
  • ParseOptions, get(StringList)
  • ParseOptions, get(Vector)
  • ParseOptions, internal_find
  • ParseOptions, is_parent_node
  • ParseOptions, make_dependencies
  • ParseOptions, optional(BigReal)
  • ParseOptions, optional(char)
  • ParseOptions, optional(int)
  • ParseOptions, optional(StringList)
  • ParseOptions, optional(u_int)
  • ParseOptions, optional(Vector)
  • ParseOptions, optionalB(int)
  • ParseOptions, PARSE_ANYTHING
  • ParseOptions, PARSE_BIGREAL
  • ParseOptions, PARSE_BOOL
  • ParseOptions, PARSE_FLOAT
  • ParseOptions, PARSE_INT
  • ParseOptions, PARSE_MULTIPLES
  • ParseOptions, PARSE_STRING
  • ParseOptions, PARSE_UINT
  • ParseOptions, PARSE_VECTOR
  • ParseOptions, Range
  • ParseOptions, range(get)
  • ParseOptions, range(set)
  • ParseOptions, require(BigReal)
  • ParseOptions, require(char)
  • ParseOptions, require(int)
  • ParseOptions, require(StringList)
  • ParseOptions, require(u_int)
  • ParseOptions, require(Vector)
  • ParseOptions, requireB(int)
  • ParseOptions, scan_bool
  • ParseOptions, scan_float
  • ParseOptions, scan_int
  • ParseOptions, scan_uint
  • ParseOptions, scan_vector
  • ParseOptions, set
  • ParseOptions, set_bool
  • ParseOptions, set_float
  • ParseOptions, set_int
  • ParseOptions, set_string
  • ParseOptions, set_stringlist
  • ParseOptions, set_uint
  • ParseOptions, set_vector
  • ParseOptions, Units
  • ParseOptions, units(get)
  • ParseOptions, units(set)
  • partition, RecBisection
  • Patch, add_forces
  • Patch, all_coordinate_force
  • Patch, all_coordinate_init
  • Patch, bonded_coordinate_force
  • Patch, bonded_coordinate_init
  • Patch, constructor
  • Patch, copy_self
  • Patch, destructor
  • Patch, end_cycle
  • Patch, get_initial_positions
  • Patch, get_initial_velocities
  • Patch, get_kinetic_energy
  • Patch, get_list_index
  • Patch, getAtomList
  • Patch, getNumAtoms
  • Patch, id
  • Patch, initialize_timestep
  • Patch, local_force
  • Patch, local_init
  • Patch, patch_debug
  • Patch, prepare_bonded_coords
  • Patch, process_msg
  • Patch, receive_atom_reassignment
  • Patch, send_atom_reassignments
  • Patch, send_msgs
  • Patch, update_atom_info
  • patch_debug, Patch
  • patch_node, PatchDistrib
  • PatchDistrib, constructor
  • PatchDistrib, create_initial_distrib
  • PatchDistrib, destructor
  • PatchDistrib, get_maxNeighborPatches
  • PatchDistrib, get_maxPatchNum
  • PatchDistrib, get_patch_id
  • PatchDistrib, get_recv_patches
  • PatchDistrib, get_send_patches
  • PatchDistrib, num_recv_for_patch
  • PatchDistrib, num_send_for_patch
  • PatchDistrib, patch_node
  • PatchDistrib, patches_for_node
  • PatchDistrib, receive_Distrib
  • PatchDistrib, send_Distrib
  • PatchDistrib, send_initial_positions
  • PatchDistrib, send_initial_velocities
  • PatchDistrib, simple_strip_division
  • patches_for_node, PatchDistrib
  • patchIdIndex, BoundaryMap
  • PatchList, add_patch
  • PatchList, constructor
  • PatchList, del_patch
  • PatchList, destructor
  • PatchList, do_timestep
  • PatchList, move_patch
  • PatchList, receive_initial_positions
  • PatchList, receive_initial_velocities
  • PatchList, reconfig
  • PatchList, send_to_patch
  • PatchList, startup
  • patchOffset, BoundaryMap
  • PDB, atom
  • PDB, atoms
  • PDB, constructor
  • PDB, destructor
  • PDB, find_atom
  • PDB, find_atom_alternatelocation
  • PDB, find_atom_chain
  • PDB, find_atom_insertioncode
  • PDB, find_atom_name
  • PDB, find_atom_residuename
  • PDB, find_atom_residueseq
  • PDB, find_atom_segmentname
  • PDB, find_atom_serialnumber
  • PDB, find_atoms_in_region
  • PDB, find_extremes
  • PDB, num_atoms
  • PDBAtom, alternatelocation
  • PDBAtom, chain
  • PDBAtom, constructor
  • PDBAtom, coordinates
  • PDBAtom, destructor
  • PDBAtom, footnote
  • PDBAtom, insertioncode
  • PDBAtom, name
  • PDBAtom, occupancy
  • PDBAtom, parse
  • PDBAtom, residuename
  • PDBAtom, residueseq
  • PDBAtom, segmentname
  • PDBAtom, serialnumber
  • PDBAtom, temperaturefactor
  • PDBAtom, xcoor
  • PDBAtom, ycoor
  • PDBAtom, zcoor
  • PDBAtomRecord, constructor
  • PDBAtomRecord, destructor
  • PDBData, constructor
  • PDBData, destructor
  • PDBData, field
  • PDBData, scan
  • PDBData, sprint
  • PDBData, sprintcol
  • PDBData, type
  • PDBHetatm, constructor
  • PDBHetatm, destructor
  • prepare_bonded_coords, Patch
  • prepare_to_receive_atoms, LongForce
  • print_angle_summary, Parameters
  • print_angles, Molecule
  • print_atoms, Molecule
  • print_bond_summary, Parameters
  • print_bonds, Molecule
  • print_buffer, BufferMPI
  • print_dihedral_summary, Parameters
  • print_dihedrals, Molecule
  • print_exclusions, Molecule
  • print_improper_summary, Parameters
  • print_impropers, Molecule
  • print_param_summary, Parameters
  • print_vdw_pair_summary, Parameters
  • print_vdw_summary, Parameters
  • process_msg, GlobalIntegrate
  • process_msg, Patch
  • propagate, Collect
  • put, Message
  • r

  • range(get), ParseOptions
  • range(set), ParseOptions
  • Range, ParseOptions
  • read_dcdheader, DCDlib
  • read_dcdstep, DCDlib
  • read_parameter_file, Parameters
  • read_psf_file, Molecule
  • rec_divide, RecBisection
  • RecBisection, assignNodes
  • RecBisection, compute_patch_load
  • RecBisection, constructor
  • RecBisection, destructor
  • RecBisection, partition
  • RecBisection, rec_divide
  • RecBisection, refine_boundaries
  • RecBisection, refine_edges
  • RecBisection, refine_surface
  • receive, Communicate
  • receive_atom_info, LongForce
  • receive_atom_reassignment, Patch
  • receive_Distrib, PatchDistrib
  • receive_initial_positions, PatchList
  • receive_initial_velocities, PatchList
  • receive_Molecule, Molecule
  • receive_Parameters, Parameters
  • receive_SimParameters, SimParameters
  • reconfig, PatchList
  • recv_buffer, BufferMPI
  • refine_boundaries, RecBisection
  • refine_edges, RecBisection
  • refine_surface, RecBisection
  • remove, HashTable
  • removeOffset, UnitCell
  • require(BigReal), ParseOptions
  • require(char), ParseOptions
  • require(int), ParseOptions
  • require(StringList), ParseOptions
  • require(u_int), ParseOptions
  • require(Vector), ParseOptions
  • requireB(int), ParseOptions
  • reset, GenericList
  • reset, Message
  • reset_buffer, BufferMPI
  • reset_iterator, HashTable
  • residuename, PDBAtom
  • residueseq, PDBAtom
  • return_atoms, GlobalIntegrate
  • s

  • save_state, LongForce
  • scan, PDBData
  • scan_bool, ParseOptions
  • scan_float, ParseOptions
  • scan_int, ParseOptions
  • scan_uint, ParseOptions
  • scan_vector, ParseOptions
  • segmentname, PDBAtom
  • send, Communicate
  • send, Inform
  • send_all, Communicate
  • send_atom_info, LongForce
  • send_atom_reassignments, Patch
  • send_buffer, BufferMPI
  • send_Distrib, PatchDistrib
  • send_forces, LongForce
  • send_initial_positions, PatchDistrib
  • send_initial_velocities, PatchDistrib
  • send_method, Communicate
  • send_Molecule, Molecule
  • send_msgs, Patch
  • send_Parameters, Parameters
  • send_SimParameters, SimParameters
  • send_to_patch, PatchList
  • serialnumber, PDBAtom
  • set, ParseOptions
  • set_bool, ParseOptions
  • set_communicator, BufferMPI
  • set_float, ParseOptions
  • set_int, ParseOptions
  • set_recycle, BondForce
  • set_string, ParseOptions
  • set_stringlist, ParseOptions
  • set_uint, ParseOptions
  • set_vector, ParseOptions
  • setup, UnitCell
  • short_force, Collect
  • short_force, Output
  • SimParameters, constructor
  • SimParameters, destructor
  • SimParameters, initialize_config_data
  • SimParameters, is_allForceTrj_step
  • SimParameters, is_coor_out_step
  • SimParameters, is_coorTrj_step
  • SimParameters, is_electForceTrj_step
  • SimParameters, is_last_step
  • SimParameters, is_restart_step
  • SimParameters, is_snapshot_step
  • SimParameters, is_vel_out_step
  • SimParameters, is_velTrj_step
  • SimParameters, num_allForceTrj_steps
  • SimParameters, num_coorTrj_steps
  • SimParameters, num_electForceTrj_steps
  • SimParameters, num_snapshot_steps
  • SimParameters, num_velTrj_steps
  • SimParameters, receive_SimParameters
  • SimParameters, send_SimParameters
  • simple_strip_division, PatchDistrib
  • size, GenericList
  • size, IntTree
  • size, Message
  • size, NameTable
  • skip, Message
  • SphericalBCForce, constructor
  • SphericalBCForce, destructor
  • SphericalBCForce, force
  • SphericalBCForce, get_energy
  • SphericalBCForce, initialize_timestep
  • sprint, PDBData
  • sprintcol, PDBData
  • start, Timer
  • start_direct (), FullDirect
  • startup, PatchList
  • stop, Timer
  • strcasecmp, STRlib
  • STRlib FMD_find_first_word
  • STRlib, FMD_blank_string
  • STRlib, FMD_find_word
  • STRlib, FMD_pad
  • STRlib, FMD_read_int
  • STRlib, FMD_read_line
  • STRlib, FMD_remove_comment
  • STRlib, FMD_truncate
  • STRlib, strcasecmp
  • STRlib, strncasecmp, STRlib, strncasecmp
  • system_time, Timer
  • t

  • temperaturefactor, PDBAtom
  • this_node, Communicate
  • Timer, clear
  • Timer, clock_time
  • Timer, constructor
  • Timer, cpu_time
  • Timer, destructor
  • Timer, start
  • Timer, stop
  • Timer, system_time
  • Timer, user_time
  • type, Message
  • type, PDBData
  • u

  • unique, IntList
  • UnitCell, c2i
  • UnitCell, constructor
  • UnitCell, destructor
  • UnitCell, i2c
  • UnitCell, numberOfCellsForRadius
  • UnitCell, offset
  • UnitCell, removeOffset
  • UnitCell, setup
  • UnitCell, warp
  • units(get), ParseOptions
  • units(set), ParseOptions
  • Units, ParseOptions
  • unpack_buffer, BufferMPI
  • unpack_message, CommunicateMPI
  • update_atom_info, Patch
  • use_comm, Inform
  • user_time, Timer
  • v

  • Vector, !=
  • Vector, *, Vector, *, Vector, *
  • Vector, +
  • Vector, -
  • Vector, /
  • Vector, <<
  • Vector, ==
  • Vector, []
  • Vector, cross
  • Vector, div
  • Vector, length
  • Vector, mult
  • Vectors, constructor
  • Vectors, destructor
  • velocities_from_PDB, Node
  • velocity, Collect
  • velocity, Output
  • w

  • wait, BufferMPI
  • wait_for_calcs, FullDirect
  • warp, UnitCell
  • WildCard, constructor
  • WildCard, destructor
  • WildCard, enter_wildcard
  • WildCard, match
  • write_dcdheader, DCDlib
  • write_dcdstep, DCDlib
  • x

  • xcoor, PDBAtom
  • y

  • ycoor, PDBAtom
  • z

  • zcoor, PDBAtom
  • Concept Index

    Jump to: 1 - [ - a - b - c - d - e - f - g - h - i - l - m - n - o - p - r - s - t - u - v - w - x

    1

  • 1-4 interaction scaling factor
  • [

  • [], IntList
  • a

  • all-force trajectory write frequency, all-force trajectory write frequency
  • Anderson degree of separation
  • Anderson super node
  • AngleForce
  • AngleForce, constructor
  • AngleForce, files
  • AngleForce, purpose
  • attributes, HDF file
  • b

  • BASE64 keyword, BASE64 keyword
  • BASE64 support
  • BASE64, files
  • BASE64, functions
  • BASE64, purpose
  • basic user parameters
  • bath coupling constant column
  • bath temperature
  • bath temperature file
  • BondForce
  • BondForce, constructor
  • BondForce, destructor
  • BondForce, files
  • BondForce, functions
  • BondForce, method
  • BondForce, purpose
  • boundary condition constant, first
  • boundary condition constant, second
  • boundary condition exponent, first
  • boundary condition exponent, second
  • boundary condition radius, first
  • boundary condition radius, second
  • BoundaryMap, class
  • BoundaryMap, constructor
  • BoundaryMap, destructor
  • BoundaryMap, files
  • BoundaryMap, functions
  • BoundaryMap, method
  • BoundaryMap, purpose
  • BufferMPI, class
  • BufferMPI, constructor
  • BufferMPI, destructor
  • BufferMPI, files
  • BufferMPI, functions
  • BufferMPI, private enumerations
  • BufferMPI, private functions
  • BufferMPI, purpose
  • c

  • center of mass motion
  • class, AngleForce
  • class, BondForce
  • class, BoundaryMap
  • class, BufferMPI
  • class, Collect
  • class, Communicate
  • class, CommunicateMPI
  • class, ConfigList
  • class, ConstraintForce
  • class, DihedralForce
  • class, ElectForce
  • class, FieldForce
  • class, FMAInterface
  • class, FullDirect
  • class, GenericList
  • class, GlobalIntegrate
  • class, HashTable
  • class, ImproperForce
  • class, Inform
  • class, Integrate
  • class, IntList
  • class, IntTree
  • class, LintList
  • class, LoadBalance
  • class, LongForce
  • class, Message
  • class, MessageManager
  • class, MessageQueue
  • class, Molecule
  • class, MultiBond
  • class, NameTable
  • class, NeighborList
  • class, Node
  • class, Output
  • class, Parameters
  • class, ParseOptions
  • class, Patch
  • class, PatchDistrib
  • class, PatchList
  • class, PDB
  • class, PDBAtom
  • class, PDBAtomRecord
  • class, PDBData
  • class, PDBHetatm
  • class, PDBUnknown
  • class, RecBisection
  • class, SimParameters
  • class, SphericalBCForce
  • class, Timer
  • class, UnitCell
  • class, Vector
  • class, WildCard
  • classes, classes
  • Collect, class
  • Collect, constants
  • Collect, constructor
  • Collect, destructor
  • Collect, files
  • Collect, functions
  • Collect, method
  • Collect, purpose
  • column, batch coupling constant
  • Communicate, class
  • Communicate, constructor
  • Communicate, derived classes
  • Communicate, destructor
  • Communicate, enumerations
  • Communicate, files
  • Communicate, functions
  • Communicate, method
  • Communicate, purpose
  • CommunicateMPI, class
  • CommunicateMPI, constructor
  • CommunicateMPI, destructor
  • CommunicateMPI, files
  • CommunicateMPI, private functions
  • CommunicateMPI, protected functions
  • CommunicateMPI, purpose
  • ConfigList, class
  • ConfigList, constructor
  • ConfigList, destructor
  • ConfigList, files
  • ConfigList, Functions
  • ConfigList, method
  • ConfigList, purpose
  • ConfigList, typedef
  • constants
  • constants, Collect
  • constants, LintList
  • ConstraintForce
  • ConstraintForce, constructor
  • ConstraintForce, destructor
  • ConstraintForce, files
  • ConstraintForce, functions
  • ConstraintForce, method
  • ConstraintForce, purpose
  • constructor, AngleForce
  • constructor, BondForce
  • constructor, BoundaryMap
  • constructor, BufferMPI
  • constructor, Collect
  • constructor, Communicate
  • constructor, CommunicateMPI
  • constructor, ConfigList
  • constructor, ConstraintForce
  • constructor, DataElement
  • constructor, DihedralForce
  • constructor, ElecForce, constructor, ElecForce
  • constructor, FieldForce
  • constructor, FMAInterface
  • constructor, FullDirect
  • constructor, GenericList
  • constructor, GlobalIntegrate
  • constructor, HashTable
  • constructor, ImproperForce
  • constructor, Inform
  • constructor, Integrate
  • constructor, IntList
  • constructor, IntTree
  • constructor, LintList
  • constructor, LoadBalance
  • constructor, LongForce
  • constructor, Message
  • constructor, MessageManager
  • constructor, MessageQueue
  • constructor, Molecule
  • constructor, MultiBond
  • constructor, NameTable
  • constructor, NeighborList
  • constructor, Node
  • constructor, Output
  • constructor, Parameters
  • constructor, ParseOptions
  • constructor, Patch
  • constructor, Patchdistrib
  • constructor, Patchlist
  • constructor, PDB
  • constructor, PDBAtom
  • constructor, PDBAtomRecord
  • constructor, PDBData
  • constructor, PDBHetatm
  • constructor, RecBisection
  • constructor, SimParameters
  • constructor, SphericalBCForce
  • constructor, Timer
  • constructor, UnitCell
  • constructor, Vectors
  • constructor, WildCard
  • conventions, file names
  • coordinate trajectory write frequency
  • couple to temperature bath
  • CTOFNB (xplor)
  • CTONNB (xplor)
  • CUTNb (xplor)
  • d

  • damping rate, dihedral Langevin dynamics
  • data types, Patch
  • DataElement, constructor
  • DataElement, enumeration
  • DataElement, ParseOptions
  • DCD file support
  • DCDlib, files
  • DCDlib, functions
  • DCDlib, purpose
  • defines, ParseOptions
  • degree of separation
  • derived classes, Communicate
  • destructor, BondForce
  • destructor, BoundaryMap
  • destructor, BufferMPI
  • destructor, Collect
  • destructor, Communicate
  • destructor, CommunicateMPI
  • destructor, ConfigList
  • destructor, ConstraintForce
  • destructor, ElecForce
  • destructor, ElectForce
  • destructor, FieldForce
  • destructor, FMAInterface
  • destructor, FullDirect
  • destructor, GenericList
  • destructor, GlobalIntegrate
  • destructor, HashTable
  • destructor, Inform
  • destructor, Integrate
  • destructor, IntList
  • destructor, IntTree
  • destructor, LintList
  • destructor, LoadBalance
  • destructor, LongForce
  • destructor, Message
  • destructor, MessageManager
  • destructor, MessageQueue
  • destructor, Molecule
  • destructor, MultiBond
  • destructor, NameTable
  • destructor, NeighborList
  • destructor, Node
  • destructor, Output
  • destructor, Parameters
  • destructor, ParseOptions
  • destructor, Patch
  • destructor, Patchdistrib
  • destructor, Patchlist
  • destructor, PDB
  • destructor, PDBAtom
  • destructor, PDBAtomRecord
  • destructor, PDBData
  • destructor, PDBHetatm
  • destructor, RecBisection
  • destructor, SimParameters
  • destructor, SphericalBCForce
  • destructor, Timer
  • destructor, UnitCell
  • destructor, Vectors
  • destructor, WildCard
  • dielectric constant
  • dihedral dynamics
  • dihedral dynamics, with Langevin dynamics
  • dihedral Langevin damping rate
  • dihedral Langevin temperature
  • DihedralForce
  • DihedralForce, constructor
  • DihedralForce, files
  • DihedralForce, purpose
  • e

  • E14Fac (xplor)
  • ElectForce, class
  • ElectForce, constructor, ElectForce, constructor
  • ElectForce, destructor, ElectForce, destructor
  • ElectForce, files
  • ElectForce, functions
  • ElectForce, method
  • ElectForce, purpose
  • electric field parameters
  • electric field settings
  • electric field strength
  • electrostatic force trajectory write frequency
  • electrostatic switching
  • electrostatic trajectory write frequency
  • enable, unit cell
  • energy audit frequency
  • energy minimization
  • energy minimization parameters
  • energy trajectory write frequency
  • enumeration, DataElement
  • enumerations, Communicate
  • enumerations, Message
  • enumerations, ParseOptions
  • enumerations, PatchList
  • enumerations, PDBData
  • enumerations, RecBisection
  • EPS (xplor)
  • equilibration temperature, equilibration temperature
  • exclusion policies
  • f

  • FieldForce
  • FieldForce, constructor
  • FieldForce, destructor
  • FieldForce, files
  • FieldForce, functions
  • FieldForce, method
  • FieldForce, purpose
  • file name conventions
  • file, molecular structure
  • files, all-force force trajectory
  • files, all-force trajectory
  • files, AngleForce
  • files, BASE64
  • files, BondForce
  • files, BoundaryMap
  • files, BufferMPI
  • files, Collect
  • files, Communicate
  • files, CommunicateMPI
  • files, ConfigList
  • files, ConstraintForce
  • files, coordinate trajectory
  • files, coordinates
  • files, DCDlib
  • files, DihedralForce
  • files, ElectForce
  • files, electrostatic force trajectory, files, electrostatic force trajectory
  • files, energy trajectory
  • files, FieldForce
  • files, FMAInterface
  • files, FullDirect
  • files, GenericList
  • files, GlobalIntegrate
  • files, harmonic constraints column
  • files, harmonic constraints file
  • files, HashTable
  • files, HDFlib
  • files, ImproperForce
  • files, Inform
  • files, Integrate
  • files, IntList
  • files, IntTree
  • files, Langevin parameter
  • files, LintList
  • files, LoadBalance
  • files, LongForce
  • files, Message
  • files, MessageManager
  • files, MessageQueue
  • files, Molecules
  • files, MultiBond
  • files, NameTable
  • files, NeighborList
  • files, Node
  • files, output
  • files, Output
  • files, parameter
  • files, Parameters
  • files, ParseOptions
  • files, Patch
  • files, PatchDistrib
  • files, Patchlist
  • files, PDB
  • files, PDBAtom
  • files, PDBData
  • files, RecBisection
  • files, restart
  • files, SimParameters
  • files, snapshot
  • files, SphericalBCForce
  • files, STRlib
  • files, Timer
  • files, UnitCell
  • files, user input syntax
  • files, Vectors
  • files, velocities
  • files, velocity trajectory
  • files, WildCard
  • FINAltemp (xplor)
  • first time step value
  • FIRSttemp (xplor)
  • FMAInterface, class
  • FMAInterface, constructor
  • FMAInterface, destructor
  • FMAInterface, files
  • FMAInterface, functions
  • FMAInterface, method
  • FMAInterface, purpose
  • FMM3D mode
  • FMM3D user parameters
  • force test
  • format, all-force trajectory file
  • format, coordinate trajectory file
  • format, electrostatic trajectory file
  • format, initCoordsDataset
  • format, initCoordsFile
  • format, initCoordsFormat
  • format, output files
  • format, restart file
  • format, snapshot file
  • format, velocities
  • format, velocitiesDataset
  • format, velocity trajectory file
  • frequency, DICE updates
  • FullDirect, class
  • FullDirect, constructor
  • FullDirect, destructor
  • FullDirect, files
  • FullDirect, functions
  • FullDirect, purpose
  • functions, BASE64
  • functions, BondForce
  • functions, BoundaryMap
  • functions, BufferMPI
  • functions, Collect
  • functions, Communicate
  • Functions, ConfigList
  • functions, ConstraintForce
  • functions, DCDlib
  • functions, Electrostatic
  • functions, FieldForce
  • functions, FMAInterface
  • functions, FullDirect
  • functions, GenericList
  • functions, global, PDBData
  • functions, GlobalIntegrate
  • functions, HashTable
  • functions, HDFlib
  • functions, Inform
  • functions, Integrate
  • functions, IntList
  • functions, IntTree
  • functions, LintList
  • functions, LoadBalance
  • functions, LongForce
  • functions, message
  • functions, MessageManager
  • functions, MessageQueue
  • functions, Molecule, functions, Molecule
  • functions, MultiBond
  • functions, NameTable
  • functions, NeighborList
  • functions, Node
  • functions, Output
  • functions, Parameters, functions, Parameters, functions, Parameters, functions, Parameters, functions, Parameters
  • functions, ParseOptions
  • functions, Patch
  • functions, PatchDistrib
  • functions, PatchList
  • functions, PDB
  • functions, PDBAtom
  • functions, PDBAtomRecord
  • functions, PDBData
  • functions, PDBHetatm
  • functions, private, Patch
  • functions, RecBisection
  • functions, SimParameters
  • functions, SphericalBCForce
  • functions, STRlib
  • functions, Timer
  • functions, UnitCell
  • functions, Vectors
  • functions, WildCard
  • g

  • GenericList, class
  • GenericList, constructor
  • GenericList, destructor
  • GenericList, files
  • GenericList, functions
  • GenericList, method
  • GenericList, purpose
  • global force test switch
  • global functions, ParseOptions
  • global test
  • GlobalIntegrate, class
  • GlobalIntegrate, constructor
  • GlobalIntegrate, destructor
  • GlobalIntegrate, files
  • GlobalIntegrate, functions
  • GlobalIntegrate, purpose
  • globals
  • h

  • harmonic constraint function
  • harmonic constraint parameters
  • harmonic constraints
  • harmonic constraints data column
  • harmonic constraints file
  • harmonic reference points
  • HashTable, class
  • HashTable, constructor
  • HashTable, destructor
  • HashTable, files
  • HashTable, functions
  • HashTable, method
  • HashTable, purpose
  • HDF file attributes
  • HDF file support
  • HDF format
  • HDFlib, files
  • HDFlib, functions
  • HDFlib, purpose
  • i

  • IEQFrq (xplor)
  • ImproperForce
  • ImproperForce, constructor
  • ImproperForce, files
  • ImproperForce, purpose
  • Inform, class
  • Inform, constructor
  • Inform, destructor
  • Inform, files
  • Inform, functions
  • Inform, method
  • Inform, purpose
  • initial coordinates file
  • initial temperature
  • initializing random number generator
  • inquiry functions, SimParameters
  • Integrate, class
  • Integrate, constructor
  • Integrate, destructor
  • Integrate, files
  • Integrate, functions
  • Integrate, method
  • Integrate, purpose
  • internal class, ParseOption
  • IntList, []
  • IntList, class
  • IntList, constructor
  • IntList, destructor
  • IntList, files
  • IntList, functions
  • IntList, operators
  • IntList, purpose
  • Introduction to fmd
  • IntTree, class
  • IntTree, constructor
  • IntTree, destructor
  • IntTree, files
  • IntTree, functions
  • IntTree, purpose
  • ISVFrq (xplor)
  • l

  • Langevin data column
  • Langevin dynamics flag
  • Langevin dynamics parameters
  • Langevin parameter file
  • Langevin temperature
  • LintList, class
  • LintList, constants
  • LintList, constructor
  • LintList, destructor
  • LintList, files
  • LintList, functions
  • LintList, method
  • LintList, purpose
  • load balance send stats
  • load balancing cycle
  • load balancing strategy
  • LoadBalance, class
  • LoadBalance, constructor
  • LoadBalance, destructor
  • LoadBalance, files
  • LoadBalance, functions
  • LoadBalance, purpose
  • long range force splitting
  • LongForce
  • LongForce, constructor
  • LongForce, destructor
  • LongForce, files
  • LongForce, functions
  • LongForce, method
  • LongForce, purpose
  • m

  • margins, patch
  • Message, class
  • Message, constructor
  • Message, destructor
  • Message, enumerations
  • Message, files
  • Message, functions
  • Message, method
  • Message, purpose
  • MessageManager, class
  • MessageManager, constructor
  • MessageManager, destructor
  • MessageManager, files
  • MessageManager, functions
  • MessageQueue, class
  • MessageQueue, constructor
  • MessageQueue, destructor
  • MessageQueue, files
  • MessageQueue, functions
  • MessageQueue, purpose
  • method, BondForce
  • method, BoundaryMap
  • method, Collect
  • method, Communicate
  • method, ConfigList
  • method, ConstraintForce
  • method, ElectForce
  • method, FieldForce
  • method, FMAInterface
  • method, GenericList
  • method, HashTable
  • method, Inform
  • method, Integrate
  • method, LintList
  • method, LongForce
  • method, Message
  • method, Molecule
  • method, MultiBond
  • method, NeighborList
  • method, Node
  • method, Output
  • method, Parameters
  • method, ParseOptions
  • method, Patch
  • method, PatchDistrib
  • method, PatchList
  • method, PDB
  • method, Timer
  • method, UnitCell
  • method, Vectors
  • minimization movement
  • Molecule, class
  • Molecule, constructor
  • Molecule, destructor
  • Molecule, files
  • Molecule, functions, Molecule, functions
  • Molecule, method
  • Molecule, purpose
  • Molecule, variables
  • MultiBond
  • MultiBond, constructor
  • MultiBond, destructor
  • MultiBond, files
  • MultiBond, functions
  • MultiBond, method
  • MultiBond, purpose
  • multiple time step algorithm
  • multipole expansion levels
  • multipole expansion terms
  • n

  • NameTable, class
  • NameTable, constructor
  • NameTable, destructor
  • NameTable, files
  • NameTable, functions
  • NameTable, purpose
  • NBXMod (xplor)
  • NeighborList, class
  • NeighborList, constructor
  • NeighborList, destructor
  • NeighborList, files
  • NeighborList, functions
  • NeighborList, method
  • NeighborList, purpose
  • Node, class
  • Node, constructor
  • Node, destructor
  • Node, files
  • Node, functions
  • Node, method
  • Node, objects
  • NSAVC (xplor)
  • NSAVV (xplor)
  • NSTEp (xplor)
  • number of time steps
  • o

  • objects, Node
  • operators, IntList
  • operators, Vectors
  • Output, class
  • Output, constructor
  • Output, destructor
  • Output, files
  • output, format
  • Output, functions
  • Output, method
  • Output, purpose
  • p

  • pair exclusion
  • pair list distance
  • pair list margin test
  • Parameters, class
  • Parameters, constructor
  • Parameters, destructor
  • Parameters, files
  • Parameters, functions, Parameters, functions, Parameters, functions, Parameters, functions, Parameters, functions
  • Parameters, method
  • Parameters, purpose
  • ParseOptions, class
  • ParseOptions, constructor
  • ParseOptions, DataElement
  • ParseOptions, defines
  • ParseOptions, destructor
  • ParseOptions, enumerations
  • ParseOptions, files
  • ParseOptions, functions
  • ParseOptions, global functions
  • ParseOptions, internal class
  • ParseOptions, method
  • ParseOptions, purpose
  • patch margins
  • Patch, class
  • Patch, constructor
  • Patch, data types
  • Patch, destructor
  • Patch, files
  • Patch, functions
  • Patch, functions, private
  • Patch, method
  • Patch, private data
  • Patch, purpose
  • PatchDistrib, class
  • PatchDistrib, constructor
  • PatchDistrib, destructor
  • PatchDistrib, files
  • PatchDistrib, functions
  • PatchDistrib, method
  • PatchDistrib, purpose
  • PatchList, class
  • PatchList, constructor
  • PatchList, destructor
  • PatchList, enumerations
  • PatchList, files
  • PatchList, functions
  • PatchList, method
  • PatchList, purpose
  • PDB, class
  • PDB, constructor
  • PDB, destructor
  • PDB, files
  • PDB, functions
  • PDB, method
  • PDB, purpose
  • PDB, typedef
  • PDBAtom, class
  • PDBAtom, constructor
  • PDBAtom, destructor
  • PDBAtom, files
  • PDBAtom, functions
  • PDBAtomRecord, class
  • PDBAtomRecord, constructor
  • PDBAtomRecord, destructor
  • PDBAtomRecord, functions
  • PDBData, class
  • PDBData, constructor
  • PDBData, destructor
  • PDBData, enumerations
  • PDBData, files
  • PDBData, functions
  • PDBData, functions, global
  • PDBData, purpose
  • PDBHetatm, class
  • PDBHetatm, constructor
  • PDBHetatm, destructor
  • PDBHetatm, functions
  • PDBUnknown, class
  • periodic boundary condition parameters
  • private data, Patch
  • private enumerations, BufferMPI
  • private functions, BufferMPI
  • private functions, CommunicateMPI
  • program structure
  • protected functions, CommunicateMPI
  • purpose, AngleForce
  • purpose, BASE64
  • purpose, BondForce
  • purpose, BoundaryMap
  • purpose, BufferMPI
  • purpose, Collect
  • purpose, Communicate
  • purpose, CommunicateMPI
  • purpose, ConfigList
  • purpose, ConstraintForce
  • purpose, DCDlib
  • purpose, DihedralForce
  • purpose, ElectForce
  • purpose, FieldForce
  • purpose, FMAInterface
  • purpose, FullDirect
  • purpose, GenericList
  • purpose, GlobalIntegrate
  • purpose, HashTable
  • purpose, HDFlib
  • purpose, ImproperForce
  • purpose, Inform
  • purpose, Integrate
  • purpose, IntList
  • purpose, IntTree
  • purpose, LintList
  • purpose, LoadBalance
  • purpose, LongForce
  • purpose, Message
  • purpose, MessageQueue
  • purpose, Molecule
  • purpose, MultiBond
  • purpose, NameTable
  • purpose, NeighborList
  • purpose, Output
  • purpose, Parameters
  • purpose, ParseOptions
  • purpose, Patch
  • purpose, PatchDistrib
  • purpose, PatchList
  • purpose, PDB
  • purpose, PDBData
  • purpose, RecBisection
  • purpose, SimParameters
  • purpose, SphericalBCForce
  • purpose, STRlib
  • purpose, Timer
  • purpose, UnitCell
  • purpose, Vector
  • purpose, WildCard
  • r

  • random number seed
  • RecBisection, class
  • RecBisection, constructor
  • RecBisection, destructor
  • RecBisection, enumerations
  • RecBisection, files
  • RecBisection, functions
  • RecBisection, purpose
  • References and additional readings
  • required user parameters
  • rescaling temperature
  • restart frequency
  • restart, files
  • restart, format
  • runjobs
  • s

  • SAVE (xplor)
  • setting all-force trajectory file
  • setting all-force trajectory file format
  • setting all-force trajectory file name
  • setting all-force trajectory write frequency, setting all-force trajectory write frequency
  • setting applied electric field on
  • setting center of spherical BC's
  • setting coordinate trajectory file format
  • setting coordinate trajectory file name
  • setting coordinate trajectory write frequency
  • setting cut-off distance
  • setting DICE update frequency
  • setting electric field strength
  • setting electrostatic force trajectory file
  • setting electrostatic force trajectory write frequency
  • setting electrostatic trajectory file format
  • setting electrostatic trajectory file name
  • setting electrostatic trajectory write frequency
  • Setting energy audit frequency
  • setting energy minimization
  • setting energy trajectory file name
  • setting energy trajectory write frequency
  • setting exclusion policy
  • setting first boundary condition radius
  • setting first force constant
  • setting first force exponent
  • setting first time step value
  • setting FMM3D usage
  • setting harmonic constraints
  • setting harmonic constraints file
  • setting harmonic data column
  • setting harmonic energy function
  • setting harmonic reference points
  • setting initial coordinates dataset, setting initial coordinates dataset
  • setting initial coordinates file format
  • setting initial velocity file
  • setting job subtitle
  • setting job title
  • setting Langevin data column
  • setting Langevin dynamics
  • setting Langevin parameter file
  • setting Langevin temperature
  • setting maximum movement during minimization
  • setting multipole expansion levels
  • setting multipole expansion terms
  • setting output file
  • setting output file format
  • setting pair list distance
  • setting parameter files
  • setting patch margins
  • setting PDB coordinates file
  • setting rescaling temperature
  • setting restart file format
  • setting second boundary condition radius
  • setting second force constant
  • setting second force exponent
  • setting snapshot file format
  • setting snapshot file name
  • setting snapshot interval, setting snapshot interval
  • setting spherical boundary conditions
  • setting steps per cycle
  • setting structure files
  • setting switching distance
  • setting switching mode
  • setting temperature
  • setting temperature rescaling frequency
  • setting time step
  • setting time steps
  • setting velocities file format
  • setting velocity trajectory file
  • setting velocity trajectory file format
  • setting velocity trajectory write frequency
  • setting working directory
  • SHIFt (xplor)
  • SimParameters, class
  • SimParameters, constructor
  • SimParameters, destructor
  • SimParameters, files
  • SimParameters, functions
  • SimParameters, inquiry functions
  • SimParameters, purpose
  • snapshot start
  • snapshot stop
  • snapshot, file name
  • spherical boundary condition constant, first
  • spherical boundary condition constant, second
  • spherical boundary condition exponent, first
  • spherical boundary condition exponent, second
  • spherical boundary condition parameters
  • spherical boundary condition radius, first
  • spherical boundary condition radius, second
  • spherical boundary conditions flag
  • spherical boundary conditions, center
  • SphericalBCForce, class
  • SphericalBCForce, constructor
  • SphericalBCForce, destructor
  • SphericalBCForce, files
  • SphericalBCForce, functions
  • SphericalBCForce, purpose
  • splitting, long range forces
  • steps per cycle
  • string support
  • STRlib, files
  • STRlib, functions
  • STRlib, purpose
  • subtitle specification
  • super node
  • switch distance
  • switching mode
  • t

  • temperature bath
  • temperature rescaling frequency
  • temperature rescaling parameters
  • temperature, dihedral Langevin dynamics
  • test pair list margin
  • time step specification
  • time step value, first
  • Timer, class
  • Timer, constructor
  • Timer, destructor
  • Timer, files
  • Timer, functions
  • Timer, method
  • Timer, purpose
  • title specification
  • TRAJectory (xplor)
  • trajectory, all-force
  • trajectory, all-force force
  • trajectory, all-force write frequency, trajectory, all-force write frequency
  • trajectory, coordinate
  • trajectory, coordinate write frequency
  • trajectory, electrostatic
  • trajectory, electrostatic force
  • trajectory, electrostatic write frequency, trajectory, electrostatic write frequency
  • trajectory, energy
  • trajectory, energy write frequency
  • trajectory, velocity
  • trajectory, velocity write frequency
  • TRUNcation (xplor)
  • typedef, ConfigList
  • typedef, PDB
  • u

  • unit cell, enable
  • unit cell, origin
  • unit cell, periodicity
  • unit cell, X axis
  • unit cell, Y axis
  • unit cell, Z axis
  • UnitCell, class
  • UnitCell, constructor
  • UnitCell, destructor
  • UnitCell, files
  • UnitCell, functions
  • UnitCell, method
  • UnitCell, purpose
  • units
  • user input file syntax
  • v

  • validation
  • variables, Molecule
  • Vector, class
  • Vector, purpose
  • Vectors, constructor
  • Vectors, destructor
  • Vectors, files
  • Vectors, functions
  • Vectors, method
  • Vectors, operators
  • velocities file
  • velocities file format
  • VELOcity (xplor)
  • velocity trajectory write frequency
  • VSWItch (xplor)
  • w

  • WildCard, class
  • WildCard, constructor
  • WildCard, destructor
  • WildCard, files
  • WildCard, functions
  • WildCard, purpose
  • working directory
  • x

  • xplor equivalent parameters, xplor equivalent parameters

  • This document was generated on 20 March 2000 using the texi2html translator version 1.52.