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)
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:
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/ani2x.py"
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
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.
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:
ops
I took a bit of a guess and set BABEL_LIBDIR to /Applications/Avogadro2.app/Contents/lib/openbabel 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
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.
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
