moltemplate issue in identifying # of bond, angle, and torsion types (dioxane example)

I got a reply from Jason Lambert who wrote the
conversion script ([email protected]...).

I suspect that the script generates bond, angle,
dihedral, and improper interaction types for combinations of atoms for
which are defined somewhere in the "oplsaa.txt" file. It does this
even if some of those interactions are not present in the molecules in
your particular system.
I will forward this to Jason Lambert:

Like the file, the file generated encompasses all
available combinations of 2,3,and 4 body interactions between the
given atoms so your answer was spot on Andrew.

If that is the case, then the additional bond, angle, dihedral, and
improper types (and coefficients) are harmless. Since they are not
used, they should not effect the physics of your simulation.

(At some point I was thinking of writing a script to strip out
unnecessary information from the data files created by moltemplate,
but I got lazy.)

I hope this allays this one particular concern.
I am still worried about how improper interactions are generated by moltemplate.
Moltemplate currently examines the network of bonds in your files and
generates impropers with the atom order I,J,K,L assuming that the
first atom in the list ("I") is the central atom. (This might change
soon.) For example:

------ (from moltemplate) -------

# 4-body "improper" interaction subgraph:
# L
# * 1st bond connects atoms I and J
# | => 2nd bond connects atoms I and K
# _.*._ 3rd bond connects atoms I and L
# *' I `*
# J K

Now I THINK THAT also assumes that the improper
interaction parameters stored in the oplsaa.txt/oplsaa.prm files list
the atom types in the same order:

------ oplsaa.prm --------

imptors 0 0 3 4 21.000 180.0 2
imptors 0 0 3 52 21.000 180.0 2
imptors 0 0 24 0 5.000 180.0 2
imptors 0 0 47 0 30.000 180.0 2
imptors 0 0 48 0 5.000 180.0 2

Since "0" is a wildcard character I'm guessing the central atom is
stored in the 3rd column (what I am calling "K". It's hard to tell,
but some of these numbers "3", "47", "48" appear to be carbons).

I don't expect you to know the answer, but I'm curious: is the central
atom in this file stored in the 3rd column?

(In that case, we might need to patch the code.)

I will forward this question to Jason too.

I spent this weekend looking at the OPLSAA and GAFF code distributed
with moltemplate, and I -think- the dihedral and improper interactions
for OPLSAA are correct. (There was, however, a serious bug in GAFF
which I just fixed.)

More specifically, the "" and ""
programs together appear to be creating improper interactions between
the correct 4 atoms and in the correct order (at least, according to
the documentation I have access to). Simulated molecules which are
supposed to be planar remain planar.

This code also appears to be looking up the force-field parameters for
impropers and dihedrals correctly. (Even though extra parameters are
frequently included, they are never used).

Whether there are missing factors of 2 in the force-field, is another issue.

But there is no substitute for testing the actual output against the
output of other programs, as Axel suggested. If you do this, please
do post any discrepancies you find!