Plugin for energy/gradient calculation with Gromacs

Development Plugins
1

I have implemented an energy/gradient plugin that calls GROMACS to compute energies and gradients (can be found here). I did it mainly as a proof of concept to understand the interface, and eventually to validate newly parameterized force fields. At the moment, the implementation relies on file-based I/O, which introduces significant overhead and makes the workflow quite slow.

The plugin works for both energy minimization and MD. However, I observe a different behavior compared to the bundled force fields in optimization:

  • With the built-in force fields, geometry optimization is interactive (the structure updates step by step)
  • With my plugin, only the final optimized geometry is shown (no intermediate updates)

Is this the expected behavior for external energy/gradient plugins, or is there a mechanism to report intermediate geometries back to Avogadro during optimization? If this is the expected behavior, maybe it’d be better to stop the optimization once it is completed, as the application can otherwise become somewhat unresponsive.

Finally, while following the documentation (which was very helpful), I found a few points that could perhaps be clarified:

  • A complete minimal example of an energy/gradient script would be useful
  • the --file argument does not seem to be used; instead, -f is expected.
  • An example showing how run(filename) should be called would help

If useful, I would be happy to contribute a pull request with suggested improvements to the documentation.

1 Like
2

This looks great, thank you! I just added a binary-based mechanism (i.e., just sending coordinates and gradients as arrays of floats) and I’m currently working to update to a new framework which would avoid file IO as well.

Is there a way to run GROMACS as a “server” like i-PI - The Atomistic Cookbook

The idea of the energy models is that Avogadro handles the geometry optimization or MD (including constraints) and the external program supplies energy and gradients of that particular set of coordinates.

Your script seems like it would be very handy for a “Run GROMACS” command (e.g. optimize or do a short MD run).

I’m not super familiar with GROMACS, but maybe the gmxapi Python package - GROMACS 2026.0 documentation would be useful?

Yep. I have several in the process of migration to the new plugin framework. I’ll be sharing them in the next week or two, along with updates to the docs.

3

And to clarify, the basic idea of the energy plugins is to say:

  • here’s the starting topology
  • Avogadro will send you some coordinates, please give us energies and forces (gradients) for each one
  • (eventually possibly other properties for each coordinate set)
4

You’ll be pleased to know that I am also (as well as Geoff) planning to contribute to a complete overhaul of the plugins documentation to go with the new API/framework :slight_smile:

5

Great! That sounds really useful. I’ll be waiting for the new API (and docs). If I can help in any way, please, let me know.

Regarding the topology, while the automatic atom typing of generalized FFs as GAFF or UFF is very handy, engines like Gromacs actually benefit from having explicit topology files. Would the new API include the possibility to add additional into, such as the path to the topology file? In my implementation, I am assuming a fixed name “topology.top” file in the current folder.

Many thanks for the impressive work in the new features of the program!

6

I’ll see what I can get done for v2.0. My goal all along has been to allow models to offer an options dialog, e.g for setting topology or selecting solvent model, other parameters, etc.

Certainly it’s on the roadmap.

1 Like