Re: [OpenBabel-Devel] forcefield classes

[Geoffrey H. <ge...@ge...>]

On Feb 15, 2007, at 3:42 PM, Tim Vandermeersch wrote:

> Yesterday I commited some code to update the force field classes, =20
> this mail contains some details about the changes.

Thanks! I've been working on breaking out some of the wiki =20
documentation into separate pages and will try to link some of this =20
into the code in the SVN trunk too (i.e., for the API documentation). =20=

The example graphs and equations are really helpful.

> ValidateLineSearch(), ValidateSteepestDescent(), =20
> ValidateConjugateGradients():
> Used to validate the implementation of these optimization functions =20=

> using a simple example function x^2 + 2*y^2. The minimum of this =20
> function is (0,0) as you can see directly. The =20
> ValidateSteepestDescent functions finds this minimum (by =20
> approximation) in 3 steps as expected. The =20
> ValidateConjugateGradients functions finds this minimum (by =20
> approximation) in 2 steps as would be expected since this is a =20
> function of 2 variables.  (This example is taken from "Molecular =20
> Modelling, Principles and Applications, Andrew R. Leach, 2nd ed.)

Great, I'll try to split these out into separate unit tests in the =20
test/ directory, so they're also part of "make check".

> MMFF atom typing:
> This is done using SMARTS rules in mmffsymb.prm. In the future this =20=

> may change since the rules become rather complex. There are alot of =20=

> atom types in mmff and atoms in a ring that OB perceives as =20
> aromatic isn't always aromatic in mmff. Suggestions are welcome here.

In the future, it may be better to tap into the existing SMARTS atom =20
typer and OBTypeTable, since some molecules will come in with pre-=20
typed atoms.

As far as aromaticity, there's no good solution right now (i.e., for =20
a 2.1 release or 2.x in general). The valence model needs some work, =20
intended for the 3.0 version. That will naturally require having =20
several different aromaticity / Kekulization classes.

> While doing this I noticed that I sometimes got errors from =20
> openbabel's atom type translation. In types.txt there are entries =20
> wich are case sensitive such as Cl, Br, ... The mol2 files use CL, =20
> BR, ... Is this a bug, or should the mol files use Cl, Br.?

It's a bug in the MMFF94 files, but please file it as a bug in the OB =20=

tracker, since the mol2format code should be able to handle it somehow.
Here are the mol2 atom types:
http://www.tripos.com/mol2/atom_types.html

> I started implementing a distance geometry algorithm. This requires =20=

> some complex matrix operations (eigenvalues, eigenvectors, ...) OB =20
> currently doesn't support. What would be the best way to solve this =20=

> problem? Linking against a library may be might be unwanted for =20
> users only interested in conversion. Making a new implementation is =20=

> possible, but time consuming. Integrating GPL parts from libraries =20
> is an option.

Several other people have been pushing for eigenvalue / matrix =20
inversion code. Some of the updated matrix/vector code in the SVN =20
trunk was contributed by Beno=EEt Jacob, who wrote the Eigen linear =20
algebra library recently. Unfortunately, Eigen doesn't yet have =20
support for this, so I'll try to write a new implementation to be =20
shared between Eigen and OB.

Thanks again for all your hard work! Let me (or us) know what we can =20
do to help on the force field bits.
-Geoff=