Hello all,
I have minimization question that I am having a bit of trouble answering on my own. I have noticed that while running multiple successive minimizations with identical stopping conditions, I reach different minimum energies with each successive call to the minimize command (each lower than the last). The per/atom energy change is small, but the delta E from step to step is a few eV (which pretty big). After maybe 5 or 6 calls to minimize it does eventually arrive at a constant minimum potential energy. I would have assumed (wrongly apparently) that calling back to back minimizations with the same stopping criterion would result in the same energy. Is there anything I can do to ensure I get to the lowest energy on the first try? Or do I need to do multiple minimization iterations. I am stumped.
Here is some sample output from the first two back to back minimizations that shows a 2.2 eV drop from the first to the second minimization step.
minimize 1.0e-12 1.0e-12 10000 10000
Loop time of 80.2622 on 8 procs for 94 steps with 80285 atoms
Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-561634.185465 -565727.752697 -565727.752697
Force two-norm initial, final = 751.81 11.3901
Force max component initial, final = 6.17553 4.49151
Final line search alpha, max atom move = 1.13488e-10 5.09731e-10
Iterations, force evaluations = 94 305
minimize 1.0e-12 1.0e-12 10000 10000
Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-565727.752697 -565729.982136 -565729.982136
Force two-norm initial, final = 11.3697 3.47224
Force max component initial, final = 4.49151 0.896667
Final line search alpha, max atom move = 7.08149e-10 6.34974e-10
Iterations, force evaluations = 24 136
Thanks,
Dave
Are you using fix box/relax? If so, its doc page
explains why successive minimize commands can
minimize further:
IMPORTANT NOTE: Performing a minimization with this fix is not a mathematically well-defined minimization problem. This is because the objective function being minimized changes if the box size/shape changes. In practice this means the minimizer can get “stuck” before you have reached the desired tolerance. The solution to this is to restart the minmizer from the new adjusted box size/shape, since that creates a new objective function valid for the new box size/shape. Repeat as necessary until the box size/shape has reached its new equilibrium.
Steve
No, I am using straight minimization with constant periodic boundary size, no box min.
Setting min_style to hftn seems to fix the problem.
I changed the min_style from the cg default to hftn and it now seems to behave more like I expect and am getting much higher precision between successive minimization steps. There is something about the cg algorithm that my system doesn’t like. With min_style set to hftn it still runs a few iterations with successive minimizations before stopping. But now setting etol is 1e-12 the changes in potential energy between minimizations are around 1e-6 eV which is more than fine with me. I can probably back off the etol to 1e-9 and be OK.
In case you are wondering, the reason I am doing successive minimization in the first place is because I am calculating interaction energies between two separated objects starting at a distance of r = infinity (aka r > the potential cut-off) and then slowingly decreasing r. I noticed the potential energy was changing even though my two objects were still beyond the cut-off distance.
FIRE should be another good candidate to try when the box geo is kept constant.
Carlos
Maybe Aidan (CCd) has some ideas …
Steve
For my case, it seems like running min_style fire to a very tight etol at the start, and then running fire a slightly looser etol for successive iterations as I bring my objects together gives me a very stable energy vs. separation curve. I am using a many-body potential that has a fairly short cut-off so I think I am running into issues with getting metastable states. Adding temperature with fire seems to help it find a better minimum to start with. This probably due to some surface reconstruction that just wasn’t happening at 0K.
Thanks to Carlos for suggesting I play with fire. Good call.
Good to know that playing with FIRE doesn’t always gets one burn 
However, note that in the snapshots you sent of your minimization output your stopping criterion was displaying “linesearch alpha is zero” thus the CG algorithm was not converging.
If you look int the archives you’ll find old emails from Aidan passing on some good tips on how to play with the minimizer params. On the personal side I however can empirically say that CG is not always the best choice for dealing with certain many-body potentials. Maybe because the initial assumptions
needed for the minimization problem to be defined are loose or violated by such types?
Carlos