Re: [OpenBabel-Devel] forcefield classes

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

The problem with the derivative of the torsional term is solved. Because I
was using the CalcTorsionAngle I overlooked the fact that the sign of the
gradient is also changed by dot(cross(ab,bc),cross(bc,cd))...

On 2/15/07, Tim Vandermeersch <tim...@gm...> wrote:
>
> Yesterday I commited some code to update the force field classes, this
> mail contains some details about the changes.
>
> LineSearch(OBAtom *atom, vector3 &direction),
> SteepestDescent(int steps, int method),
> ConjugateGradients(int steps, int method):
>
> The algorithm for LineSearch is explained in forcefield.cpp
> The method argument for SteepestDescent and ConjugateGradients can be
> OBFF_ANALYTICAL_GRADIENT or OBFF_NUMERICAL_GRADIENT.
> There are still some problems with the analytical gradients. The gradient
> for the torsional term is not always correct, but I'm not really sure why.
> The analytical gradients were calculated using mathematica and almost
> copy/pasted to the source code. With the use of ValidateGradients() I hope
> to solve this problem soon, but if you should see the problem please point
> it out. (At the moment I think it has something to do with the derivative of
> cos(n*tor) wich is zero where it should be zero, but also exactly between
> these points. Need to look into this...)
>
> More advenced optimization methods (Newton-Raphson) will be added later...
>
>
> 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.)
>
>
>
> 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.
>
> The first 45% of the test suite works (excluding some molecules) producing
> good results. The errors are in the range 0.00-1.00% and due differences
> in calulated bond lengths etc.
>
> 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.?
>
> Structure generation:
> 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. Suggestions are
> welcome...
> These matrix operations would alse be usefull in other parts such as
> newton-raphson optimization (determinant of 3Nx3N hessian needed, N = #
> atoms)
>
> Regards,
>  Tim
>