NAMD Wiki: AddingComputeBonds
These notes provide a guide for adding a new "ComputeBonds" into NAMD. Setting up a "ComputeBonds" is appropriate for calculating force, potential energy, and virial for interactions that:
- involve fixed atom tuples that can be predetermined from the initial structure,
- depend only on atom positions and fixed force field parameters,
- depend primarily on atoms within the same patch and secondarily on atoms that cross a patch boundary to adjacent neighbor patches, and
- have O(N) tuples and O(1) computational work per tuple.
Generally, these atom tuples will be connected by covalent bonds to guarantee that they remain close throughout a simulation.
There is already machinery within NAMD for automatically organizing the "ComputeBonds" and their "BondElem" arrays after every atom patch migration, but several files must be edited and data structures must be provided to Molecule.h/C and Parameters.h/C. The following discussion is based on adding a fictitious "Foobar" interaction.
Adding a Foobar interaction will generally require adding files:
- ComputeFoobars.C - contains code for the actual calculation,
- ComputeFoobars.h - contains definitions for FoobarElem and defines compute classes ComputeFoobars inherited from template class ComputeHomeTuples and ComputeSelfFoobars inherited from ComputeSelfTuples,
- ComputeFoobars.inl - a secondary include file that defines some constructors and operators for FoobarElem.
Mostly small modifications will generally be needed in the following files (from the src/ directory):
and build files from the main directory:
- Make.depends - regenerate this using "make depends" in one of the architecture build directories (this should work if Gnu make is being used); check it into CVS so that others can correctly build Foobar evaluation into NAMD,
- Makefile - add "$(DISTDIR)/ComputeFoobars.o \" dependency to OBJS (listed in alphabetical order).
Since a "Foobar" involves tuples of four atoms, it is easiest to modify the ComputeDihedrals.C/h/inl files. Copy these files, changing "DIHEDRALS", "Dihedrals", and "dihedrals" to "FOOBARS", "Foobars", and "foobars", respectively. There will be two different compute classes generated to evaluate Foobars: ComputeSelfFoobars formed by atoms in the same patch, and ComputeFoobars formed by atoms from two to four adjacent patches. Both of these classes are generated by templates that require classes FoobarElem, Foobar, and FoobarValue. The FoobarElem class is defined in files ComputeFoobars.C/h/inl and is explicitly accessed by the ComputeHomeTuples and ComputeSelfTuples templates, so the data members and methods copied from the ComputeDihedrals.C/h/inl files are all necessary. For the time being, ignore the data structures used by the memory efficient version of NAMD (e.g., AtomSignature, TupleSignature). These parts can be commented out and safeguarded against using something like a NAMD_die("Foobar interactions not supported in memory efficient version of NAMD") statement. The Foobar class is likely defined in structures.h and then used to define members of the Molecule class:
- foobars - the array of Foobars to be evaluated,
- numFoobars - the length of the foobars array,
- foobarsByAtom - a jagged array of arrays of int, that for each atom index provide an array of indexes into the foobars array; each array is terminated by -1, and each element of the foobars array is indexed exactly once.
The internals of the Foobar class are not accessed directly by ComputeHomeTuples, so the naming and data content can be adjusted to suit the calculation of Foobar, but it seems necessary to at least store the AtomIDs of the atoms participating in a Foobar interaction and probably also an index for obtaining its FoobarValue force field parameters. The FoobarValue class is most likely to be defined in Parameters.h, with the Parameters class having a foobar_array member.