Syntax:

Definitions of intramolecular angle terms are given in 'angles' blocks. Multiple 'angles' blocks may exist, each defining a subset of terms, and each possessing a different functional form.

The 'angle' keyword begins a block of intermolecular parameter definitions, and the single argument form should specify the functional form of the interactions.

The format of lines within the 'angles' block is as follows:

typename_i  typename_j  typename_k  data1 [data2...]

The three ''typenames'' identify the particular angle to which the parameters are relevant. Note that typenames given for an angle ''i''-''j''-''k'' will also match an angle ''k''-''j''-''i''. Data parameters should be provided in the required order for the specified form.

For example:

angles harmonic
HT  CT  HT   80.0   109.4
end

provides parameters for an H-C-H angle using the harmonic potential.

Syntax:

Definitions of intramolecular bond terms are given in 'bonds' blocks. Multiple 'bonds' blocks may exist, each defining a subset of terms, and each possessing a different functional form.

The 'bond' keyword begins a block of intermolecular parameter definitions, and the single argument form should specify the functional form of the interactions.

The format of lines within the 'bonds' block is as follows:

typename_i  typename_j  data1 [data2...]

The two ''typenames'' identify the particular bond to which the parameters are relevant. Note that typenames given for a bond ''i''-''j'' will also match a bond ''j''-''i''. Data parameters should be provided in the required order for the specified form.

For example:

bonds constraint
HT  CT  4000.0  1.06
end

provides parameters for an H-C bond using the constraint potential.

Syntax:

The 'data' block defines additional generic data for each atom type. The additional data can be accessed through the 'datad', 'datai', and 'datas' members of the ffatom type.

The quoted argument supplied to the block defines the data types and names to be expected for each specified atom type, and furthermore stricly defines the order in which they must be given. Any of the standard simple variable types int, double, and string may be used.

The format of individual lines within the block is as follows:

typeid  typename  data1  [data2 ...]

Following the identifying typeid and typename data items are given one after the other and in the order they are declared in the block keyword argument.

For example:

data "string dogtype, int bridge, int likespasta, double numtoes"
1	OW	"redsetter"	1	0	9
2	HW	"dalmation"	1	1	64
end

This defines a quartet of extra data (random, odd data...) for each of the specified atom types.

Syntax:

The 'defines' block makes it possible to state commonly-used or lengthy chunks of NETA that do not belong to any specific atom type, and which can then be reused multiple times in many different atom type descriptions. Each definition in the block is given an identifying unique name which allows it to be referenced with the '$' symbol.

The format of lines within the 'defines' block is as follows:

name  "NETA"

The NETA descriptions provided for each definition must be valid, or the forcefield will not be loaded. In subsequent NETA definitions for atom types the definitions may be inserted by stating '$name'. For example:

defines
water_oxygen	"-O(nh=2,nbonds=2)"
end

...

types
1       HW2     H       "nbonds=1,$water_oxygen"              "Water hydrogen"
end

Syntax:

In forcefields, the most detailed information provided is typically the short-range intermolecular and charge parameters, with different values (or at least different charges) given to each individual atom type. Usually, intramolecular terms are more general and don't depend so much on the exact atom type. For example, given a tetrahedral carbon CT and three different aliphatic hydrogens H1, H2, and H3, the bond between the carbon and any of the three hydrogen types will likely be the same with respect to the force constant, equilibrium distance etc.

So, the forcefield will have to contain three intramolecular bond definitions covering CT-H1, CT-H2, and CT-H3, each having the same parameters, right? Not necessarily. While this is perfectly acceptable, for large forcefields the number of redundant terms may become quite large, and even for small forcefields with only a handful of terms, adding in duplicate data might irk the more obsessive amongst us. On these occasions, atomtype 'equivalents' can be defined, which effectively link a set of atomtypes to a single identifying name that can then be used in any intramolecular parameter definitions.

The format of individual lines in 'equivalents' block is:

alias  typename  [typename ...]

In the waffle above, aliasing the three hydrogens H1, H2, and H3 to a single typename 'H1' can be done as follows:

equivalents
H1   H1  H2  H3
end

Note that the aliased name does not have to be an atomtype name already defined in the types section.

Syntax:

The 'function' block contains one or more function definitions relevant to rule-based forcefields. The function(s) should be written in the standard command language style.

For example:

function
end

defines the function to be used when generation of a bond term is required. See the functions section in rule-based forcefields for more information and a list of valid function declarations that may be used.

Syntax:

The 'generator' block defines additional data for each atom type, for use in forcefields which employ functions to generate all (or additional) terms. For example, the GAFF forcefield is able to generate extra intramolecular terms if the relevant definitions are not already defined in the forcefield, and the UFF and DREIDING forcefields contain no pre-defined intramolecular terms whatsoever.

The quoted argument supplied to the block defines the data types and names to be expected for each atom type, and furthermore stricly defines the order in which they must be given. Any of the standard simple variable types int, double, and string may be used.

The format of individual lines within the block is as follows:

typeid  typename  data1  [data2 ...]

Following the identifying typeid and typename data items are given one after the other and in the order they are declared in the block keyword argument.

For example:

generator "string altname, double radius, double p, int i"
1	OW	"watero"	3.16	1.0	16
2	HW	"waterh"	0.0	0.0	1
end

Syntax:

Intermolecular van der Waals parameters and the charge associated with each atom type belong in the 'inter' section. There may be multiple 'inter' sections within the same forcefield file, but parameters for an individual atomtype may be defined only once.

The 'inter' keyword begins a block of intermolecular parameter definitions, and the single argument form should specify the functional form of the intermolecular interactions.

The format of individual lines within the block is as follows:

typeid  typename  q  data1 [data2 ...]

The ''form'' parameter specified the form of short-range interaction potential to use for each of the following atomtypes. ''typeid'' and ''typename'' refer to a single type defined in the 'types' section, ''q'' is the atomic charge of this atomtype, and then follows the data describing the interaction. The order of the values given should correspond to the order of parameters expected for the specified functional form.

For example, the Lennard-Jones potential takes two data ''epsilon'' and ''sigma'' in that order. For a chloride atomtype with ID 24, if ''epsilon'' = 0.5, ''sigma'' equals 3.0, and the charge on the atomtype is -1 ''e'', the corresponding entry in the 'inter' block will be:

24   Cl    -1.0   0.5   3.0

Some functional forms have default values for some parameters used in the functional form, and need not be specified (if there are any, these will be detailed in the functional form chapter). For this reason, it is important not to add any unnecessary extra data to the entries in the 'inter' block, since this may overwrite a default parameter that results in literal chaos.

Syntax:

Definitions of intramolecular torsion terms are given in 'torsions' blocks. Multiple 'torsions' blocks may exist, each defining a subset of terms, and each possessing a different functional form.

The 'torsion' keyword begins a block of intermolecular parameter definitions, and the first (mandatory) argument form should specify the functional form of the interactions. For torsions the electrostatic and VDW 1-4 interactions (i.e. those between atoms 1 [i] and 4 [l]) are scaled by some factor between 0.0 and 1.0. The optional escale and vscale arguments specify these scaling factors - if they are not provided, they both default to 0.5.

The format of lines within the 'torsions' block is as follows:

typename_i  typename_j  typename_k  typename_l  data1 [data2...]

The four ''typenames'' identify the particular torsion to which the parameters are relevant. Note that typenames given for a torsion ''i''-''j''-''k''-''l'' will also match a torsion ''l''-''k''-''j''-''i''. Data parameters should be provided in the required order for the specified form.

For example:

torsions cos
HT  CT  OC  HO   3.0   5.0   0.0
end

provides parameters for an H-C-O-H torsion using the cosine potential.

torsions cos3 0.8333333 0.25
CT  CT  CT  O1   1.0  -2.0   0.0
CT  CT  CT  O2   0.5  -1.4   1.0
end

defines two C-C-C-O torsions of the triple cosine form, and with custom scale factors.

Syntax:

The core of the forcefield file is the types section, listing the ids, names, and elements of the different atom types present in the forcefield, as well as a description telling Aten how to recognise them.

The format of each line in the 'types' block is as follows:

typeid  typename  element  NETA  [description]

The ''id'' is an integer number used to identify the type. It should be positive, and must be unique amongst all those defined in a single forcefield. ''typename'' is the actual name of the atom type ('OW', 'C1', 'N_ar' etc.), and is referred to in the other sections of the forcefield file, and ''element'' is the type's element symbol as found in the periodic table ('O', 'C', 'N', etc.). The ''type description'' defining how Aten should recognise this particular type follows (in quotes if necessary), and then optionally a short text describing the type (which appears in lists within the program to help identify particular types). Atom types may be defined over multiple 'types' blocks within the same file if necessary, i.e. more than one 'types' block may exist, but all type IDs must be unique over all such blocks.

For example:

types
35  CT  C  "nbonds=4"  "Simple tetrahedral carbon"
end

describes a bog-standard tetrahedral carbon called 'CT', and assigns it an ID of 35.

	See also:
	Atom typing for an overview of atom typing The NETA reference for a description of the atom typing language

Syntax:

The 'uatypes' section contains exactly the same information as the 'types' block except that a mass must also be provided. In the 'types' block it is assumed that the character element of the type also implicitly defines the mass (as would be expected). In the case of united-atom forcefields, this is not necessarily the case. Thus, the 'uatypes' block allows a mass to be associated in order to account for the light atoms subsumed into the heavy atom's mass. This information can be accesses through the 'mass' member of the ffatom variable type.

The format of each line in the 'uatypes' block is as follows:

typeid  typename  element  mass  NETA  [description]

The ''id'' is an integer number used to identify the type. It should be positive, and must be unique amongst all those defined in a single forcefield. ''typename'' is the actual name of the atom type ('OW', 'C1', 'N_ar' etc.), and is referred to in the other sections of the forcefield file, and ''element'' is the type's element symbol as found in the periodic table ('O', 'C', 'N', etc.). The ''type description'' defining how Aten should recognise this particular type follows in quotes, and then optionally a short text describing the type (which appears in lists within the program to help identify particular types). The ''mass'' is the united atom mass of the type (i.e. the sum of heavy and light atom masses). Atom types may be defined over multiple 'types' blocks within the same file if necessary, i.e. more than one 'types' block may exist, but all type IDs must be unique over all such blocks.

For example:

uatypes
10  CH2  C  14.0265  "nbonds=2,nh=0"  "United atom methylene carbon"
end

describes a united-atom methylene carbon, with mass of 14.0265 (C+2H).

	See also:
	Atom typing for an overview of atom typing The NETA reference for a description of the atom typing language The ffatom type for how to access the 'mass' parameter