AutoOpt Tool & ForceField Extention


While using the AutoOpt Tool and the ForceField Extention in the same
session, soc, me and probably many more have noticed that avogadro
craches. There is probably a conflict somewhere because they are not
aware of each others actions. Each forcefield has a global definition
to which you get a reference when you call FindForceField(). So when
two or more Tools/Extentions, are changing things in this global
forcefield class without knowing what the other is doing, crashes can
be expected. I’m I right so far?

I’m currently working on a way to specify which atoms you want to
include in your calculations and which atoms you want to fix in 3D
space while minimizing. This would allow us to load a pdb file with
bound ligand, ignore all the atoms more then 5A from the ligand and
fix all the atoms which are not part of the ligand. Then you could
minimize the ligand in a rigid binding pocket, are use the AutoOpt
tool on it, make changes to the ligand, and AutoOpt again, …
I allready commited the following functions to handle this:
SetIgnoreAtom(), GetIgnoreAtom(), ClearIgnoreAtom() and SetFixAtom(),
GetFixAtom(), ClearFixAtom()
The SetIgnoreAtom() functions are called before Setup(), then in
SetupCalculations() the force field code checks if it needs to ignore
the term by calling GetIgnoreAtom(). The same goes for the
minimization code, it will need to check if it actually needs to move
the atom…

To solve the first problem and to implement the second part, I propose
that we let one force field extention handle all things that have to
do with force fields. Other tools/extentions which need to use force
field code as well, should do it by using this extention. Is this
possible? Can a tool/extention use or depend on another
tool/extention? Or we could move AutoOpt to the forcefield

I would like to hear from you all what you think of this.

Thanks in advance,

I solved the first problem, the LogFile was still ste from “Optimize
Geometry”, this caused a crash in the other treath… Simply setting
the log file to NULL before calling setup in autoopttool.cpp fixes
this issue.


I’m not sure this thread fits will with the openbabel-devel list,
since it’s largely related to Avogadro.

Here’s some background to the Open Babel folks. Avogadro has two ways
to run geometry optimizations using the OBForceField framework. One is
a command (extension) which runs an optimization. The other is a tool
which can run in the background while the molecule is being edited

I think the key point is that global objects like the force fields
need to be returned to constant state.

It may also be helpful to “lock” the force field objects. What if
someone runs the extension in one thread while AutoOpt runs in another
thread. The answer: a crash.

This is a little different than other plugins in Open Babel, which are
comparatively short-lived.

I’m glad you fixed the first bug, but I think you’ve uncovered a
slightly deeper issue with force fields.