Open Babel forcefield integration

As some of you know, v 1.98.x added a new forcefield framework, but required Python scripts to use Open Babel forcefields (UFF, MMFF94, GAFF).

I have a new test build that should solve that (finally) but I need testers.

Please let me know if you’re willing to test. (At the moment, it leaves the previous Open Babel integration intact in the UI.) It means that everyone should have UFF, MMFF94, etc. methods for use.

Basically … just draw / import molecules and try the Calculate ⇒ Optimize command:

  • Does it optimize?
  • Does it stop before optimization is complete (e.g., weird bond lengths remain)
  • etc.

@matterhorn103 - the next commit will be to move the “Optimize Geometry” command out of the Calculate menu and give it the keyboard shortcut.

I think for 1.99, I’ll probably still keep the Open Babel menu around until this gets a lot of testing.

Just quickly tried out the AppImage. Note that I do have other compiled versions of Avo on the same machine, but Open Babel is not installed globally and is not in the path. So I guess there’s not too much clash.

The first optimization I run after launch works, but subsequent ones fail. The first optimization on a fresh launch also fails if I open the Configure... dialog before running the optimization. Example console output:

Open Babel formats ready:  146
Setting default format to cjson.
Error, Open Babel plugins directory not found.
 initial  159.528  gradNorm:  805.93
 maxSteps 250  steps  50
 optimize  0 3.10181  gradNorm:  15.0911
 optimize  1 2.66116  gradNorm:  4.88384
 optimize  2 2.62537  gradNorm:  2.11039
 optimize  3 2.60655  gradNorm:  3.51632
 optimize  4 2.59021  gradNorm:  1.93709
 optimize  5 2.57574  gradNorm:  2.93823
 optimize  6 2.56297  gradNorm:  1.77809
 optimize  7 2.55131  gradNorm:  2.57765
 optimize  8 2.54112  gradNorm:  1.50013
 optimize  9 2.53167  gradNorm:  2.30302
 optimize  10 2.52324  gradNorm:  1.34274
 optimize  11 2.51528  gradNorm:  2.11752
 optimize  12 2.50806  gradNorm:  1.16759
 optimize  13 2.50085  gradNorm:  2.15151
 optimize  14 2.49412  gradNorm:  1.04989
 optimize  15 2.48736  gradNorm:  2.16115
 optimize  16 2.48076  gradNorm:  1.056
 optimize  17 2.47402  gradNorm:  2.18241
 optimize  18 2.46718  gradNorm:  1.11468
 optimize  19 2.46006  gradNorm:  2.2347
 optimize  20 2.45247  gradNorm:  1.38986
 optimize  21 2.44424  gradNorm:  2.45789
 optimize  22 2.43544  gradNorm:  1.47542
 optimize  23 2.42605  gradNorm:  2.55618
 optimize  24 2.4151  gradNorm:  2.22582
 optimize  25 2.40336  gradNorm:  2.65815
 optimize  26 2.3842  gradNorm:  5.05043
 optimize  27 2.36446  gradNorm:  1.97601
 optimize  28 2.34878  gradNorm:  3.22556
 optimize  29 2.33182  gradNorm:  2.23285
 optimize  30 2.31435  gradNorm:  3.14027
 optimize  31 2.29544  gradNorm:  2.4342
 optimize  32 2.27615  gradNorm:  3.083
 optimize  33 2.25545  gradNorm:  2.60645
 optimize  34 2.23451  gradNorm:  3.05378
 optimize  35 2.21205  gradNorm:  2.90294
 optimize  36 2.18968  gradNorm:  2.98587
 optimize  37 2.16635  gradNorm:  3.01319
 optimize  38 2.14268  gradNorm:  3.25684
 optimize  39 2.11861  gradNorm:  2.89181
 optimize  40 2.09439  gradNorm:  3.53646
 optimize  41 2.06927  gradNorm:  2.85001
 optimize  42 2.04546  gradNorm:  3.27179
 optimize  43 2.02187  gradNorm:  2.55763
 optimize  44 1.9997  gradNorm:  3.09032
 optimize  45 1.97748  gradNorm:  2.49531
 optimize  46 1.9563  gradNorm:  3.17558
 optimize  47 1.93557  gradNorm:  2.28899
 optimize  48 1.91632  gradNorm:  3.02942
 optimize  49 1.89758  gradNorm:  2.16244
QProcess: Destroyed while process ("/tmp/.mount_AvogadsdYPZ8/usr/bin/obmm") is still running.
 initial  0  gradNorm:  0
 maxSteps 250  steps  50
 optimize  0 0  gradNorm:  0
QProcess: Destroyed while process ("/tmp/.mount_AvogadsdYPZ8/usr/bin/obmm") is still running.
 initial  0  gradNorm:  0
 maxSteps 250  steps  50
 optimize  0 0  gradNorm:  0

The optimization also seems quite slow, taking 14 s for 49 MMFF94 cycles with acetone. Don’t know how that compares to your machine. LJ on the other hand (I know the difference is that it’s hard-coded) is practically instantaneous.

At launch I also see:

"Checking for energy scripts in path /tmp/.mount_AvogadR1M9s6/usr/bin/../lib/avogadro2/scripts/energy"
"Cannot load script /tmp/.mount_AvogadR1M9s6/usr/lib/avogadro2/scripts/energy/"
 register  GAFF
Could not register model GAFF due to name conflict.
 register  GFN-FF
 register  GFN1
 register  GFN2
 register  MMFF94
Could not register model MMFF94 due to name conflict.
 register  UFF
Could not register model UFF due to name conflict.

and the name conflict messages don’t get printed by my compiled version.

Yes. Unfortunately, obmm which is used for energy / gradient analysis has some sort of weird synchronization issue with writing to standard output. I’ve been tinkering for a while to decrease latency, but :person_shrugging:

I will probably re-implement UFF directly in Avogadro, which will be near-instantaneous, but will also take a bit of time.

You’re seeing “name conflict” messages because right now, this code takes over and any installed scripts will be ignored. Once testing is solid, this implementation will be the fallback. (Surprisingly, the Python scripts are faster than obmm because of this synchronization issue.)

I’ll check on the multiple optimization piece. Seemed to work for me, but sync bugs are always the worst to debug.

Okay, I’m adding an optional build that uses Open Babel directly. For now, I think I’d recommend this for 1.99 builds (e.g. -DBUILD_GPL_PLUGINS=ON)

I thought I would resurrect this thread, rather than start a new one, as I’m having trouble with the OB forcefields. Platform is macOS 13.6.3 on an M2 Pro, with Avogadro 2 v 1.99.0

Launching from a terminal I spotted the following warning:

OBEnergy: method: MMFF94
OBEnergy: method not found: MMFF94
*** Open Babel Error in LoadAllPlugins
Unable to find OpenBabel plugins. Try setting the BABEL_LIBDIR environment variable.
forcefields is not a recognized plugin type. Those with instances of sub-types loaded are:

I took a bit of a guess and set BABEL_LIBDIR to /Applications/ and while that seemed to fix the warnings on startup, if I try to use UFF to optimise a geometry I get the following messages to terminal:

OBEnergy: method: UFF
*** Open Babel Error in ParseParamFile
Cannot open UFF.prm
*** Open Babel Error in SetTypes
Cannot open UFF.prm

Any suggestions of what I should try next?

Huh. It should be setting both BABEL_LIBDIR and BABEL_DATADIR but both are needed.

If I point BABEL_DATADIR to /Applications/ then the optimisation does indeed work.

Okay, I’ll go make sure there’s code to ensure those environment variables are set. (Weird, since they should be set by the startup code.) I set them for Windows anyway.

Glad it’s working in the meantime.

I tried the build downloaded from the commit on macOS, and it doesn’t optimize. Nothing happens if I click optimize, if I click calculate energy or force norm, both show me 0.

I see the same behavior for the nightly build downloaded today from the website and for the 1.99.0 arm64 build from github.

The optimization through Open Babel → Optimize Geometry does work

Can you do me a favor? If you run from the Terminal / command-line, e.g.

export AVO_PATH=/Applications/
export BABEL_LIBDIR=$AVO_PATH/lib/openbabel 
export BABEL_DATADIR=$AVO_PATH/share/openbabel/3.1.1/

Does that help? I’m still not sure why they’re not being set by the rest of the code, but for @JGrantHill it seemed to help.

I have a week of spring break coming up and I can certainly get an updated build assuming that works for you.

1 Like

yes, this works