Re: [OpenBabel-Devel] forcefield classes

[Tim V. <tim...@gm...>]

On 2/16/07, Geoffrey Hutchison <ge...@ge...> wrote:
>
>
> On Feb 15, 2007, at 3:42 PM, Tim Vandermeersch wrote:
>
> > Yesterday I commited some code to update the force field classes,
> > this mail contains some details about the changes.
>
> Thanks! I've been working on breaking out some of the wiki
> documentation into separate pages and will try to link some of this
> into the code in the SVN trunk too (i.e., for the API documentation).
> The example graphs and equations are really helpful.


The ghemical  forcefield is now completely implemented. The
ValidateGradients gives small errors but occasional larger errors in the
torional term, when these molecules are minimized nothing "wrong" can be
observed  (before benzene rings weren't planar etc.). I also made some
changes to ghemical to output information about individual interactions. At
the moment the first results look good, but a way to get ghemical to run in
batch mode would be usefull for validation.
All the energy expressions and graphs on the wiki for the ghemical
forceifeld are also finished.

Structure generation:
The new SystematicRotorSearch() is now used by obgen. Currently it starts
from the same structure as GenerateCoordinates and then starts to rotate
around rotateble bonds. A better solution (working on it) would be to use
bond lengths and angles from the forcefield parameters. Because the ghemica=
l
forcefield does not make a difference between a CCCC or CCCH torsion angle,
molecules like diethylether were not staight after minimizing a structure
from GenerateCoordinates(). This problem is now solved. (note: not all bond=
s
are rotated in the current svn version, but I'm only testing straight chain
molecules at the moment...)
A remaining problem are rings. Ring bonds are (currently? torlib.txt?) not
considered rotatable. A possible solution would be to construct all rings i=
n
one plane in a knowledge based manner. This could possibly be a start/part
of a 0D->2D conversion. Suggestions are welcome.


> ValidateLineSearch(), ValidateSteepestDescent(),
> > ValidateConjugateGradients():
> > Used to validate the implementation of these optimization functions
> > using a simple example function x^2 + 2*y^2. The minimum of this
> > function is (0,0) as you can see directly. The
> > ValidateSteepestDescent functions finds this minimum (by
> > approximation) in 3 steps as expected. The
> > ValidateConjugateGradients functions finds this minimum (by
> > approximation) in 2 steps as would be expected since this is a
> > function of 2 variables.  (This example is taken from "Molecular
> > Modelling, Principles and Applications, Andrew R. Leach, 2nd ed.)
>
> Great, I'll try to split these out into separate unit tests in the
> test/ directory, so they're also part of "make check".


The result has to be visually inspected at the moment. Criteria to check a
correct minimization and return some value could be added.

> MMFF atom typing:
> > This is done using SMARTS rules in mmffsymb.prm. In the future this
> > may change since the rules become rather complex. There are alot of
> > atom types in mmff and atoms in a ring that OB perceives as
> > 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
> typer and OBTypeTable, since some molecules will come in with pre-
> typed atoms.
>
> As far as aromaticity, there's no good solution right now (i.e., for
> a 2.1 release or 2.x in general). The valence model needs some work,
> intended for the 3.0 version. That will naturally require having
> several different aromaticity / Kekulization classes.
>
> > While doing this I noticed that I sometimes got errors from
> > openbabel's atom type translation. In types.txt there are entries
> > wich are case sensitive such as Cl, Br, ... The mol2 files use CL,
> > 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
> 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
> > some complex matrix operations (eigenvalues, eigenvectors, ...) OB
> > currently doesn't support. What would be the best way to solve this
> > problem? Linking against a library may be might be unwanted for
> > users only interested in conversion. Making a new implementation is
> > possible, but time consuming. Integrating GPL parts from libraries
> > is an option.
>
> Several other people have been pushing for eigenvalue / matrix
> inversion code. Some of the updated matrix/vector code in the SVN
> trunk was contributed by Beno=EEt Jacob, who wrote the Eigen linear
> algebra library recently. Unfortunately, Eigen doesn't yet have
> support for this, so I'll try to write a new implementation to be
> shared between Eigen and OB.


That would be great.

2.1 release:
Should there be parts of the forcefield code in the 2.1 release? If yes, I
would suggest a stripped down version of the current SVN version. This coul=
d
be ghemical with the SteepestDescent, ConjugateGradients for obgen and smal=
l
programs like obenergy, obminimize, ... could quickly be written. Altough I
have some more time the next 6 weeks, MMFF94 will not be ready/validated I
think (know). Code profiling might also be preferable before release. Pleas=
e
let me know what you think about this so I can focus on  things that
possibly need to be included in the 2.1 release.

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

Tim