Relaxation satisfying both energy and force tolerance

Hi everyone,

When using the minimize command, LAMMPS stops when either the energy tolerance (etol) or the force tolerance (ftol) is reached.

min_style cg
minimize 1.0e-12 1.0e-12 500000 500000

Is there a way to make it stop only when both the energy and force tolerances are satisfied?

Thanks
Dominic

No, but if you know whether if is the energy or the force that converges first, then you can set the other to 0.0.

Please keep in mind that with tolerances as low as you already are using (1.0e-12) you are close to the floating point epsilon and if you use any pair style that has some kind of tabulation with spline functions or similar included (instead of a fully analytical one), then you are probably beyond the noise created by the potential and then final iterations to convergence are just random moves anyway.

I wanted to fix the lattice along x and y direction, and relax along z direction (biaxial strain relaxation).

This is how I tried to execute it.

fix 1 all box/relax z 1e-8 vmax 0.001

print “— Performing structural relaxation on the strained cell —”
thermo 100
thermo_style custom step pe press pxx pyy pzz lx ly lz
min_style cg
minimize 0.0 1.0e-8 10000 10000
unfix 1

From the log file, the output was as follows:

Reading data file …
triclinic box = (0 0 0) to (7.9807283 6.9115135 6.388468) with tilt (3.9903642 3.9121217 2.2586645)
WARNING: Triclinic box skew is large. LAMMPS will run inefficiently. (src/domain.cpp:221)
1 by 1 by 1 MPI processor grid
reading atoms …
16 atoms
read_data CPU = 0.001 seconds
NequIP/Allegro is using input precision d and output precision d
NequIP/Allegro: Loading model from …/bao_fine_tuned.nequip.pth
NequIP/Allegro: Freezing TorchScript model…
Type mapping:
NequIP/Allegro type | NequIP/Allegro name | LAMMPS type | LAMMPS name
7 | O | 2 | O
55 | Ba | 1 | Ba
Neighbor list info …
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8
ghost atom cutoff = 8
binsize = 4, bins = 4 3 2
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair nequip, perpetual
attributes: full, newton off, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
Setting up cg style minimization …
Unit style : metal
Current step : 0
WARNING: Energy due to 3 extra global DOFs will be included in minimizer energies
(src/min.cpp:222)
Per MPI rank memory allocation (min/avg/max) = 4.213 | 4.213 | 4.213 Mbytes
Step PotEng Press Pxx Pyy Pzz Lx Ly Lz
0 -99.026282 -28760.921 -35126.938 -35752.377 -15403.447 7.9807283 6.9115135 6.388468
6 -99.031873 -26468.834 -33800.82 -34491.012 -11114.669 7.9807283 6.9115135 6.3692897
Loop time of 52.0938 on 1 procs for 6 steps with 16 atoms

98.9% CPU use with 1 MPI tasks x 1 OpenMP threads

Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-99.026281505009 -99.0318733081501 -99.0318733081501
Force two-norm initial, final = 3.3878172 2.4445482
Force max component initial, final = 3.3878172 2.4445482
Final line search alpha, max atom move = 1.5604917e-09 3.8146973e-09
Iterations, force evaluations = 6 47

Since I am fixing x and y, I get why the Pxx and Pyy values are high, but from this current input prompt, shouldnt Pzz be lowered to 0?
Is there any mistake i am making in this input?
Is it because the data file is not orthogonal as mentioned from the warning?

Not necessarily. The minimizer stops when the required conditions are reached. When the pressure fluctuates by large amounts it may not hit exactly zero.
Please note that for atomic systems, the pressure is computed from the virial and that has very large fluctuations even for tiny changes is the system is small and your system is extremely small with just 16 atoms.

No, but using an orthogonal supercell would reduce the noise that LAMMPS is picking up from having to convert between cartesian and fractional coordinates serveral times per iteration when the cell is not orthogonal.

Since you mentioned VASP before, please keep in mind that for classical MD codes, the main concern is for efficiently simulating large numbers of particles. A quantum level “precise” minimization is not part of that. If you want to get this, you may need to use a different tool and use LAMMPS just as a “force engine”. There is the MDI package which allows coupling different atomic and molecular simulation codes, although the more common situation is that some quantum package serves as the force engine for LAMMPS as integrator.