bondchk failed with reax/c

Dear Lammps users,

I am having some trouble with the pair_style reax/c. I keep running into “-bondchk failed”. I am trying to simulate a rather non-uniform system, my unit cell is part graphite, part dense gas. From previous questions on the list I’ve noted the common advice is to increase the values of safezone and mincap. I’ve tried that without any effect. For a given simulation, the error occurs at the same timestep, independent of the values of safezone and mincap. Visualizing the trajectory doesn’t show any bad structures or strange behavior.

I was wondering about the “units” of safezone and mincap. What do the numbers represent and how high can you go within reason? I am using version 30jul16. Any other advice?

Sincerely,

Eirik Hjertenæs

Dear Lammps users,

I am having some trouble with the pair_style reax/c. I keep running into
“-bondchk failed”. I am trying to simulate a rather non-uniform system, my
unit cell is part graphite, part dense gas. From previous questions on the
list I’ve noted the common advice is to increase the values of safezone and
mincap. I’ve tried that without any effect. For a given simulation, the
error occurs at the same timestep, independent of the values of safezone and
mincap. Visualizing the trajectory doesn’t show any bad structures or
strange behavior.

what happens, if you write out a restart file just briefly before the
"bondchk" error would happen
and then restart from that restart with a new input file. would it
still happen at the exact same timestep.
there must be something singular happen at this very step.

have you done checks running each subsystem of your system separately
and found that all your settings and parameters are suitable for a
stable and correct simulation reproducing some reference material
properties as expected?

I was wondering about the “units” of safezone and mincap. What do the
numbers represent and how high can you go within reason? I am using version
30jul16. Any other advice?

you could try updating LAMMPS to the very latest patchlevel version
and compile/run with the KOKKOS variant of reax (with thread/openmp
support). this uses a more robust memory management approach, that
will trigger automatic reallocation of buffers, if needed. then LAMMPS
should get past that problematic step or crash with a different issue
and you should see from the simulation trajectory better, if is
something is amiss.

i would recommend to do the more basics and simpler tests first. what
you describes "smells" as if there is some more fundamental issue,
that you haven't noticed or didn't report.

axel.

For the Kokkos version of ReaxFF, you can even turn off OpenMP threading and associated overhead by building with "Makefile.kokkos_mpi_only" in /src/MAKE/OPTIONS/.

Stan

Thanks, Stan and Axel, for your feedback.

One of my simulations failed at step 45,001 so I did a restart from step 45,000. This new simulation also ran for 45,001 steps before running into "bondchk failed" again. The indices that appear in the "bondchk failed"-lines were different than from the first run. The fact that both simulations could run for exactly 45,001 steps feels significant.

I have optimized the force field myself so there could certainly be something wrong with it, although it does work for very simple systems.

From the other posts I've read concerning this error, it can be related to dramatic reactivity and a large number of neighbors. In my simulations there can be quite a bit of relative movement of adjacent graphene layers, also across periodic boundaries. Could this be the cause of the problem?

A question before I try the Kokkos version, does it support GCMC simulations?

Thanks once again!

Sincerely,

Eirik Hjertenæs

A question before I try the Kokkos version, does it support GCMC simulations?

It should work, especially if you are not running on a GPU. We actually regularly test a simple example of GCMC + Kokkos in our regression test suite using OpenMP. There is no Kokkos threaded version of GCMC so GCMC runs in non-threaded mode. Admittedly if you are doing something very complex with GCMC it may not be included in this simple regression test. If you try it out and run into issues let us know.

Thanks,

Stan

This could definitely be a source of the problem. What part of the forcefield did you modify? Can you run part of the system with your modified force field parameters, I.e., run graphite in one test and run the gas in another?

Thanks,
Ray

Thanks your input, Ray.

I have made changes to the Li-C force field by Raju et al. (http://pubs.acs.org/doi/abs/10.1021/ct501027v)
I have added an element by including a new set of atom parameters and its pair parameters with carbon. The general parameters and the carbon pair, angle and 4-body parameters are unchanged. The parameters work fine for pure gas and pure graphite. I don't include any of the other elements from the force field by Raju.

Sincerely,

Eirik Hjertenæs

Then it seems to me the pair parameters and the lack of angle, dihedral and possibly improper interactions between your new element and Carbon is the source of problem.

Optimizing (or fitting/training) a force field is a very complicated and delicate work, and this is especially true for such a complicated force field like ReaxFF. You developing a ReaxFF potential with an additional element is itself a publication, which is certainly not advisable via the mailing list.

I would suggest you the following:
1. Find a collaborator with experience in optimizing a ReaxFF potential, or
2. Contact Prof. Adri van Duin and collaborate with him.

Hope this helps.

Ray

Eirik,

FYI I tried the Kokkos version of ReaxFF on another input scrip that uses GCMC today, running on a CPU. With the original pair_style reax/c, it crashed with an "hbondchk failed” error, but with the new Kokkos version of ReaxFF the script seemed to run fine. The thermo output (before pair_style reax/c crashed) was very close for many timesteps. So trying out the Kokkos version is definitely worth a shot. Of course Kokkos won't fix issues with a new parameterization of the forcefield but it could help you see what is going on without crashing. For reference, here is how I built/ran with Kokkos:

Use the latest development version of LAMMPS and a c++11 compiler
make yes-kokkos
make -j4 kokkos_mpi_only

and run with:

./lmp_kokkos_mpi_only -in in.lmp -k on -sf kk -pk kokkos neigh half newton on comm no

Stan