[gmx-users] force field parameters/B state dihedrals

[Berk Hess]

>From: "David Mobley" <dmobley at gmail.com>
>Reply-To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>To: "Discussion list for GROMACS users" <gmx-users at gromacs.org>
>Subject: [gmx-users] force field parameters/B state dihedrals
>Date: Thu, 20 Jul 2006 15:07:35 -0700
>
>Dear all,
>
>I'm setting up some relative free energy calculations involving
>changing atom types, and I have a related question about topologies.
>
>In the dihedrals section, if my force field  contains parameters for
>the dihedral states organized by bond type, these are automatically
>filled in when no parameters are specified in the topology.
>
>On the other hand, if I specify parameters in the topology file for A
>and B states, these are use instead of those specified for the force
>field.
>
>What happens if I specify parameters in the topology file for only the
>A state? Does the B state:
>(a) automatically use the parameters specified by the A state, or
>(b) first check the force field for parameters, only using those
>specified by the A state if it finds none?
>
>I know that in cases where I specify parameters for only the A state,
>and none are found in the force field, the B state uses the same A
>state parameters. My question is what happens when B state parameters
>could be specified by the force field, as this seems somewhat
>ambiguous...

We have had a discussion about this some time ago
and we have changed the behavior for Gromacs 3.3.
In 3.3, when you give A state parameters only, they are
always copied to the B state. If you did not specify B state
parameters a warning is issued, as this is indeed somewhat ambiguous.
Unfortunately it seems that we forgot to describe this situation
in the manual.
So the B state parameters are only searched for using the B state
atom types when also no A state parameters have been supplied.

Note that there is still ambiguity when one specifies
A and B state parameters in the bonded types sections.
This issue has not been resolved yet.

Berk.