AutoOpt Tool & ForceField Extention

Geoffrey Hutchison wrote:

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
(AutoOpt).

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.

Although the OpenBabel plugin classes, formats, forcefields, etc., were
not designed for a multithreaded environment, generally having a single
global instance, this does not have to be so. OBFormat has a virtual
function MakeNewInstance() which was intended to get round the single
instance problem, although there are currently no implementations. I
already had in mind to move it to OBPlugin and to give it a default
implementation which returns a new object of the derived class(e.g.
OBForcefield) that was a copy of the calling instance. Multithreaded
application programs could routinely call this after FindForcefield etc.
to work with a new instance which they would delete at the end. I don’t
know enough about multithreaded programming to know whether this is a
complete solution, but at least it gives you multiple sets of the
class’s member variables to work with. Having it copy rather than return
an empty instance allows it to be useful in the middle of what you are
doing to branch the process.

I’ll look into implementing this, unless somebody can point out any
fatal flaws.

On SetIgnoredAtom etc., I agree with Geoff: they would be better in
another class, not in OBMol.

Chris