Problems with relaxation using ReaxFF

if you start from an ideal fcc crystal,
there should be no significant forces
due to symmetry. why would you expect
anything different?

axel.

Hello Axel,

Thanks for the comment. Because when I change the lattice constant the same happens. For Al experimental lattice constant is 4.05 Angstroms, I tried the range 4.0 - 5.0 but in all cases it stops at step 2 with no change in energy. To my understanding it seems that convergence is not progressing for some reason.

Hello Axel,

Thanks for the comment. Because when I change the lattice constant the same
happens. For Al experimental lattice constant is 4.05 Angstroms, I tried the
range 4.0 - 5.0 but in all cases it stops at step 2 with no change in
energy. To my understanding it seems that convergence is not progressing for
some reason.

of course! and exactly for the reason that i was
mentioning. due to symmetries all forces cancel,
thus no atoms will move, thus no change in energy,
thus the stop after two steps.

axel.

now to comment on your second issue.

there is indeed a problem with using
box/relax in combination with reax/c.

despite the latest bugfixes in the memory management,
the code can result in memory corruption with a
variable cell. i would speculate that the handling
of neighbor lists inside the reax/c code itself is
no perfect, since there are no problems, if you
relax from too small a lattice constant (and thus
the number of neighbors within the cutoffs decreases).
but you get segfault or complaints from glibc
about corrupted memory, when you start from
too large a box (and then the number of neighbors
will increase and require reallocation of storage for it)
possibly the tests for that are not catching all
cases completely.

cheers,
    axel.

p.s.: with box/relax you *do* get more than two steps
during minimization, of course.