Reducing user confusion around LJ potential

Development
1

Currently, a fresh installation of Avogadro will only have a single forcefield available: the Lennard-Jones potential. There have already been several posts (e.g. here, though I remember at least one other) where users are confused because the structures they are obtaining from optimizations are “wrong”, because they were optimized using the LJ potential (i.e. they are correct but not the expected result).

Having the forcefield framework available/optimization possible, but only with LJ and no other options unless extra tools are installed, seems to be counterproductive. Users will click Optimize and immediately get a “bad” geometry, and think that Avogadro is broken.

It is not even necessary to open the Configure... menu before running an optimization, so users probably won’t realize they are using LJ. Besides which, the Lennard-Jones is rarely thought of as a forcefield per se, and “Lennard-Jones” is not written anywhere, only LJ, so it just looks like another acronym and I suspect most chemists wouldn’t make the connection between “LJ” and the basic bonding model they studied back in first-year chemistry…

Moreover, very few users will actually want the results of a LJ potential, except very occasionally for educational purposes. It is no good for reasonable geometries of most molecules, so it seems like a bad default option.

I’m aware that making another forcefield the default option would be tricky. So how do you feel about perhaps instead simply disabling the LJ potential until the other forcefields have been “unlocked” by setting up Python and installing openbabel? This way UFF could be the default option, with LJ only as fall back, and the user would have to deliberately choose LJ to use it.

If the user attempts to run a calculation through the forcefield framework without having done those steps, a simple message could be displayed instructing the user how to enable forcefields or sending them to the relevant docs.

If the current Open Babel functionality under Extensions > Open Babel remains in the program, it’s not like we would be disabling optimizations altogether.

2

So rather than continue to work debugging the Open Babel integration (which solves all of this) … I should put work in to only allow the new framework when scripts are installed?

I understand the confusion and concern, but this is a temporary issue.

While that might be true for molecules, it’s not really true for materials. If you have a unit cell, LJ isn’t such a bad thing because there’s already packing…

3

Sorry, please don’t take me the wrong way here. I was not trying to suggest more work but rather trying to save it, by heading off a deluge of support requests after 1.99 is released.

What have you got planned re Open Babel integration? To integrate the bundled Open Babel functionality into the Forcefield Framework? Obviously that would be very nice…

Sorry if I missed you detailing it in the past. When I suggest things that are in reality already in progress or are planned, or are in contradiction to a decided on direction, believe me when I say it’s due to ignorance, not a misguided overestimation of the importance of my own opinions!

I’ll be more patient.

I assumed that the status quo is to some extent the only option due to the way the licensing works i.e. that even though Avogadro is packaged with the Open Babel binary, because it is GPL licensed it can only be used via system calls and the Python bindings can thus not be included in the base install. Whereas if the user installs the Python bindings themselves it’s ok.

And I understood from your previous posts related to xtb that any script for use with the framework couldn’t rely on system calls as they would be too slow for the live optimization functionality. Meaning only hard-coded (LJ) forcefields or ones using Python libraries (openbabel, xtb-python) are really fit-for-purpose.

4

Yes, that’s the idea.

Open Babel has a program obmm which is little used, but provides direct access to the MM force fields:

  • load file
  • set force field
  • calculate energy
  • calculate gradients
  • update coordinates
  • repeat

In principal, this is exactly what the various Python scripts do in the new framework. The challenge has been synchronizing the “write command, get response” communication with obmm … debugging synchronized communication is the pain point.

I feel confident I can get that fixed up.

Failing that, there are a few approaches for the near term for 1.99 to make sure it all gets merged together. (I’ll probably still keep the Open Babel menu, since its “Perceive Bond Orders” code is still better tested.)

5

BTW, please excuse delays / low communication. January has been incredibly busy for me with the start of the semester, etc.