Skip to content

ENH: Force-consistent optimizers

The original intention of this merge request was to make BFGSLinesearch again use force-consistent energies as part of the optimization algorithm. Note this was the original behavior many years ago; it was removed a couple of years ago as a bugfix that isn't necessary any more.

I discovered that it really makes a difference to use the force-consistent energy when training to a tight force tolerance, in my case 0.01 eV/A. I ran a batch of 65 optimizations and found that the force-consistent method typically saved a few steps and always performed as well or better than the non force-consistent method. In one run, it would not converge unless I used force-consistent energies.

After discussions below, it was decided to do this for all optimizers that use the energy. It is now implemented more centrally in the base class Optimize, and all dependent optimizers can decide to use the force_consistent keyword upon initialization. Also, a note is made in the log file that force-consistent energies are being used (which will hopefully prevent anyone who scrapes the logfile for their final converged energy from using the wrong values). I have implemented this on all local optimizers with two exceptions: GoodOldQuasiNewton (which seems to be intended to be archival) and the preconditioned ones in the precon directory (for some reason, I got errors trying to use these as-is with GPAW, so didn't touch them).

For optimizers that use the energy in addition to forces, the new default behavior is to use force-consistent energies if they are available, but to fall back to regular energies if not. The user can override this by supplying True or False to the force_consistent keyword in the initialization of the optimizers.

Merge request reports