Why does Optimize Geometry doesnt work?

I believe this to be a bug with Avogadro

Environment Information

Avogadro version: 1.100 Appimage
Operating system and version: Fedora 41

Expected Behavior

Optimizing Geometry

Actual Behavior

Nothing.

Steps to Reproduce

Draw or import any molecule, and try to optimize with the 1.100 Avogadro Appimage version.

==============================
*** Open Babel Error  in ParseParamFile
  Cannot open parameter file
 initial  0  gradNorm:  0
 maxSteps 250  steps  125

I seem to be getting this error when I try to optimize any kind of molecule, heres the full log if needed.

Avogadroapp version:  1.100.0
Avogadrolibs version:  1.100.0
Qt version:  6.8.1
qt.core.qobject.connect: QObject::connect(QObject, Unknown): invalid nullptr parameter
qt.tlsbackend.ossl: Failed to load libssl/libcrypto.
SSL version:  ""
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
Using locale:  "en_US"
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
 registering GPL plugins
OBEnergy: method:  MMFF94
OBEnergy: method:  UFF
OBEnergy: method:  GAFF
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslSocket
qt.network.ssl: The backend named "cert-only" does not support TLS
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed
"/tmp/.mount_AvogadeP1Bio/usr/bin/obabel"  found:  "/tmp/.mount_AvogadeP1Bio/usr/bin/obabel: Open Babel 3.1.1 -- Jan 21 2025 -- 17:50:29"
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslSocket
qt.network.ssl: The backend named "cert-only" does not support TLS
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed
OBEnergy: method:  MMFF94
Open Babel formats ready:  145
Setting default format to cjson.
==============================
*** Open Babel Error  in ParseParamFile
  Cannot open parameter file
 initial  0  gradNorm:  0
 maxSteps 250  steps  125

Yeah, if Open Babel can’t open the force field parameters, there’s not much that you can do. We can check out the AppImage, but my suggestion in the meantime is to use the Flatpak which I think @matterhorn103 has been testing more routinely.

I don’t test every update to the beta exhaustively, I’m afraid, I tend to just have a quick look at the things that have been directly affected by the merged changes.

Having said that, the beta Flatpak is the version I use myself day-to-day, so I often notice if things are off.

When it comes to this issue specifically, I can attest that the Open Babel geometry optimization works fine in the Flatpak. :slight_smile:

In general I can also say that, now that the quirks of the sandbox and Flatpak packaging have been worked out, the Flatpak is generally more reliable than the AppImage on account of its increased independence from the system. So anyone who reads this and is having some issue with the AppImage, give the Flatpak a spin and see if it solves it. :smiley:

And to be clear, I’d like to figure out why the AppImage doesn’t find the Open Babel parameter files. But the Flatpak is a good workaround.

(For some reason, the Windows release binary didn’t have any Open Babel files either :man_shrugging: )

1 Like

Of course :slight_smile:

I feel like I remember having the same issue with the Flatpak at one point? Can’t remember for sure though, or how I fixed it.

Here’s the trees of each:

appimagetree.txt (434.8 KB)
flatpaktree.txt (204.8 KB)

I can’t easily see that there are any key files missing, but maybe something will jump out at you.

Incidentally, while I can reproduce the bug my error is ever so slightly different:

==============================
*** Open Babel Error  in ParseParamFile
  Cannot open UFF.prm
==============================
*** Open Babel Error  in SetTypes
  Cannot open UFF.prm
 initial  0  gradNorm:  0
 maxSteps 250  steps  125

It looks like Open Babel can’t find those data files.

If you use the “Color by Partial Charge” command in the View menu and pick “EEM” do you get any sort of error message? I want to figure out if it’s limited to the forcefield code or not. Thanks.

That works ok, yeah.

Though while it does run and doesn’t complain about missing/being unable to read any files, I’m not sure it works exactly like it’s meant to as

  1. for a start EEM gives a bizarrely negative charge for the alpha-carbon in acetic acid (but that could just be the nature of the model, which is not one I’ve heard of before)

  2. after colouring by MMFF94 charges only the COOH group is coloured and the rest is white

  3. the Atom Properties dialog only seems to be able to display one flavour of partial charge at a time, and which one it chooses to display is somewhat unpredictable

It certainly works in the Flatpack and not in the Appimage.