Priority of minimization convergence parameters, etol and ftol.

Hello LAMMPS users/developers,

I have a question regarding the priority of convergence parameters provided to the minimize routine. We are currently working on a simulation for which we want forces to be the deciding criterion in stopping our minimization run. I checked the file min_cg.cpp (starting line 85) and found that etol is evaluated first and so I wanted to know if there would be any unwanted consequences for rearranging the order of the etol and ftol checks? I realize that energy minimization is usually the most desired form, but for our highly defective (purposefully defective) structures, seemingly small forces are causing havoc on our results and so we want better control over them.
Also found in the manual, it states that either etol and ftol can be set to 0.0, which allows some other criterion to kill the minimization. What other parameters will do this, or is it referring to which of etol and ftol are not set to 0.0? I have tried the following lines, all yielding the exact same results:

minimize 1.0e-12 1.0e-12 20000 600000

minimize 1.0e-6 1.0e-12 20000 600000

minimize 0.0 1.0e-12 20000 600000

Thanks in advance for your help.

Hello LAMMPS users/developers,

      I have a question regarding the priority of convergence parameters
provided to the minimize routine. We are currently working on a simulation
for which we want forces to be the deciding criterion in stopping our
minimization run. I checked the file min_cg.cpp (starting line 85) and
found that etol is evaluated first and so I wanted to know if there would be
any unwanted consequences for rearranging the order of the etol and ftol
checks? I realize that energy minimization is usually the most desired

changing the order wouldn't change the fact that the code would return
when either of the two criteria are reached.

form, but for our highly defective (purposefully defective) structures,
seemingly small forces are causing havoc on our results and so we want
better control over them.

well, only with very bad minimization algorithms you can get a
condition where the energy doesn't decrease, while you are not in the
(energy) minimum.

     Also found in the manual, it states that either etol and ftol can be
set to 0.0, which allows some other criterion to kill the minimization.
What other parameters will do this, or is it referring to which of etol and
ftol are not set to 0.0? I have tried the following lines, all yielding the
exact same results:

you have 4 parameters:

1) energy
2) forces
3) max. number of iterations
4) max. number of steps

you have to check which condition is actually triggered. but there is
more to be considered:
- by default, minimization moves all atoms, so even "irrelevant"
relaxations far away from a defect can have a significant impact. that
can trick the minimization algorithm to pay more attention to parts of
your system that you don't care about. cure for that would be to set
those forces to zero after a sufficient initial relaxation.
- you have to carefully check how "rugged" your potential hypersurface
is. e.g. if you have a splined/interpolated potential, or the number
of atoms within the cutoff keeps changing near the minimum or you
simply reach the limit of numerical precision of double precision
floating point math, or if there are residual symmetries that result
in symmetric forces which may prohibit finding the desired minimum.
this can be addressed by checking the details and stability tests,
where you apply a small randomization of positions and then
re-minimize to see, if you hit the same minimum.

minimize 1.0e-12 1.0e-12 20000 600000
minimize 1.0e-6 1.0e-12 20000 600000
minimize 0.0 1.0e-12 20000 600000

Thanks in advance for your help.

minimization in general can be a tricky business. there are far too
many degrees of freedom to do an exhaustive search for all but the
most trivial cases. sometimes it help to switch minimizers or make
sure that your initial configuration is suitable. sometimes it takes
some trickery to "guide" the minimizer. sometimes there is nothing you
can do.

axel