WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 11

Dear LAMMPS users,
The setting of the potential function in the IN file is like this:

pair_style reax/c lmp_control
pair_coeff * * ffield.reax.ca Ca O C

But there will be an Error during debugging. what is the problem? Is the error of ‘error’ caused by ‘Warning’? How can this problem be avoided?

WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 0 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 0 (src/REAXFF/fix_qeq_reaxff.cpp:775)
Per MPI rank memory allocation (min/avg/max) = 1175 | 1175 | 1175 Mbytes
** Step Temp E_pair E_mol TotEng Press**
** 0 0 -403366.21 0 -403366.21 -401632.87**
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 1 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 1 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 2 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 2 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 3 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 3 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 4 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 4 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 5 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 5 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 6 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 6 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 7 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 7 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 8 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 8 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 11 (src/REAXFF/fix_qeq_reaxff.cpp:775)
WARNING: Fix qeq/reaxff CG convergence failed after 200 iterations at step 11 (src/REAXFF/fix_qeq_reaxff.cpp:775)
ERROR: Lost atoms: original 23336 current 2665 (src/thermo.cpp:488)
Last command: run 3000

It’s impossible to give a precise comment with so little information on your system, but it seems that your system is exploding. You lost 90% of your atoms in only 11 steps:

My guess, is that either your initial topology is very far from equilibrium, or that you have some of the parameters that are really wrong, like the timestep.

Simon

This in file is small and is mainly used to debug whether the force field is correct. As follows:

units real
atom_style full
read_data final0902.data
pair_style reax/c lmp_control
pair_coeff * * ffield.reax.ca Ca O C
neighbor 1 bin
neigh_modify every 10 delay 0 check no
fix 1 all nve
fix 2 all qeq/reax 1 0.0 10.0 1e-6 param.qeq
fix 3 all temp/berendsen 300.0 300.0 100.0
timestep 0.25
dump 1 all atom 1 dump.reax.ca
run 10

I created the data file section of the model as follows:

23336 atoms
13682 bonds
13433 angles
0 dihedrals
4423 impropers

3 atom types
1 bond types
1 angle types
1 improper types

-2.211811668   103.110394311 xlo xhi
-2.259833408   176.146549777 ylo yhi
-2.504449461    16.745641068 zlo zhi

Masses

1 40.080000 # ca+2
2 15.999000 #O-2
3 12.011150 # c2=

Atoms # full

  1      1   1  2.000000     1.722613404     0.479112386     5.714694108   0   0   0 # ca+2
  2      1   1  2.000000    -1.391004984     5.338925427     5.580628321   0   0   0 # ca+2
  3      1   2  0.000000     5.041775455     1.210429713     1.184184362   0   0   0 # o-2
  4      1   2  0.000000     2.484881561     5.706118924     1.335187048   0   0   0 # o-2
  5      1   2  0.000000     1.269198914     2.868826903     7.127021073   0   0   0 # o-2
  6      1   2  0.000000     4.987362301     7.264688849     7.175430581   0   0   0 # o-2
  7      1   3  0.000000     5.050001425     2.912604632     7.209503032   0   0   0 # c2=
  8      1   3  0.000000     2.511021481     7.284632856     7.206358190   0   0   0 # c2=
  9      1   2  0.000000     3.427098467     1.975927129    13.217339045   0   0   0 # o-2
 10      1   2  0.000000     1.121882964     6.329277458    13.285760850   0   0   0 # o-2
 11      1   2  0.000000     2.604843814     2.939939167    15.870709298   0   0   0 # o-2
 12      1   2  0.000000     0.085757160     7.321588701    15.874393494   0   0   0 # o-2
 13      1   3  0.000000     5.041953005     2.910793981    15.879219648   0   0   0 # c2=
 14      1   3  0.000000    -1.145128012     0.000046061    12.977895033   0   0   0 # c2=
 15      1   2  0.000000     3.753658915     3.574392392    10.095673325   0   0   0 # o-2
 16      1   3  0.000000     2.499622878     7.284921401    15.881075819   0   0   0 # c2=
 17      1   2  0.000000     1.081062262     8.071205192    10.080851967   0   0   0 # o-2
 18      1   3  0.000000     2.507349088     4.363712075    12.994439579   0   0   0 # c2=
 19      1   2  0.000000     1.305843476    -0.666122767     1.458193340   0   0   0 # o-2
 20      1   1  2.000000     4.625979141     2.118423396    12.057287116   0   0   0 # ca+2
 21      1   2  0.000000     3.794321578     3.763014311     1.404524031   0   0   0 # o-2
 22      1   2  0.000000     0.587212561     1.831970843    15.899941347   0   0   0 # o-2
 23      1   2  0.000000     3.422542093     5.016166812    16.146184837   0   0   0 # o-2
 24      1   1  2.000000     1.495692187     7.073579385    11.878757956   0   0   0 # ca+2
 25      1   2  0.000000     3.799560807     5.015196595     7.286819104   0   0   0 # o-2
 26      1   2  0.000000     1.277097810     9.368268576     7.293699491   0   0   0 # o-2
 27      1   2  0.000000     3.828253236     0.794371133     7.210470613   0   0   0 # o-2
 28      1   2  0.000000     1.292760889     5.185787237     7.192854309   0   0   0 # o-2
 29      1   2  0.000000     1.298434062     2.262122036    12.961769510   0   0   0 # o-2
 30      1   2  0.000000     0.081416351     1.469829134    10.101225054   0   0   0 # o-2
 31      1   2  0.000000     0.653844241     4.038396321    15.867346683   0   0   0 # o-2
 32      1   2  0.000000     3.741505139     2.254236179     4.344090136   0   0   0 # o-2

bonds

angles

That data file is bogus. With ReaxFF there should be no bonds, angles, dihedrals, or impropers. …and having only one type of each with 3 atom types is also no plausible. You have to review the process of creating the data file.

Yes. And the charge values are also strange: a lot of 0.0, and some +2.0 q. It’s easier for fix qeq to equilibrate if the initial charge values are reasonable.

Some quick notes:

The LAMMPS code issues a “warning” in situations which usually should not occur in simulations, but where the developers trust users to sort things out themselves – as opposed to “errors” where a simulation is almost certain to be incorrect moving forward.

As two simple examples: LAMMPS will give a “warning” when long-range electrostatics are used but the total box charge is non-zero, because such simulations are occasionally used (for benchmarking or for unusual systems) even though it’s almost always a mistake. But LAMMPS will give an “error” if a particle “flies out of the box” in such a simulation – there’s just no valid way to continue.

In your case: REAXFF depends on “charge equilibration” which assigns dynamic atom charges to minimise electrochemical potential (so for example more electronegative particles will have more negative partial charges). The conjugate gradient algorithm is used to determine what those charges will be. But the algorithm depends on having a reasonable first guess (convergence from any initial condition is only guaranteed for fully linear problems and after an infinite number of steps). As others have pointed out, your initial data file contains extremely implausible charge values, so the conjugate gradient algorithm can’t converge on anything sensible. After which the simulation naturally explodes.

2 Likes