[MMTK] force field modules

[Konrad Hinsen]

On Jun 10, 2004, at 23:56, Eric Zollars wrote:

> 1.  An energy() call to an InfiniteUniverse with an AmberLJForceField 
> instance will fail with AttributeError: ForceFieldData instance has no 
> attribute 'atom_type'.  As far as I

AmberLJForceField is a term inside Amber94ForceField and is not meant 
to be used on its own. The class AmberLJForceField exists only for 
testing purposes. If you want a pure Lennard-Jones force field, use 
LennardJonesForceField.

>  can tell this is because 
> NonBondedInteractions.LJForceField.evaluatorTerms has never set this 
> attribute of "global_data".  With the 
> MMForceField.MMNonbondedForceField.evaluatorTerms method, this 
> attribute is set by the collectAtomTypesAndIndices method.  But 
> LJForceField never calls a similar method.  What has to be done to 
> make this work?

The two cases you are studying treat their parameters differently 
because of their different needs. And you are free to use yet some 
other method to feed parameters to your force field. This aspect of 
force fields is not part of the interface. All that your code has to 
make sure is that your force field object has a methods evaluatorTerms 
that returns a list of C evaluator objects. How the C objects obtain 
their parameters is left to the implementor.

LennardJonesForceField uses a rather straightforward way to obtain the 
parameters directly from the chemical database. Amber94ForceField is 
more complicated because Lennard-Jones parameters come from the Amber94 
parameter file, which is read once and then supplies data to several 
force field terms. The database contains only the Amber atom type.

For yet another example, see SPCEFF.py, which uses hard-coded 
Lennard-Jones parameters.

> 2.  Why is the NonBondedForceField.ready() method in the 
> NonBondedInteractions module set to return 'bonded'?  If this class is 
> to be used without a bonded force field should this be set to return 
> '1'?

In that case, the method must be overridden, as done by 
LennardJonesForceField. The default implementation of 
NonBondedForceField is for a term in a complex force field that 
includes bonded terms. The reason for this choice is the principle of 
least surprise: as it is, if you forget to overrride ready(), you get 
an error message and go hunting for its origin. If the default had been 
to return 1, then using NonBondedForceField together with 
BondedForceField would yield wrong results without even a warning 
message.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Laboratoire Léon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: hinsen at llb.saclay.cea.fr
---------------------------------------------------------------------