Run stops without error - Reax/c

Hi,
I am running a simulation using reax/c. The run stops at the step 0 without any error. The log file is as follows. btw the output file says this:

Hi,
I am running a simulation using reax/c. The run stops at the step 0
without any error. The log file is as follows. btw the output file says
this:

​there *has* to be some kind of error message, it just may not be recorded
in the log file or regular output. you should try running the same input
interactively​.

your input seems to have *extremely* aggressive settings for time step (1
fs is *far* too large for a system containing hydrogens without
constraining bonds containing the hydrogens.) similarly, your choice of
neighbor list rebuilds is similarly aggressive considering the choice of
time step (updating neighbor lists only every 10 steps with only 1 angstrom
skin distance). i doubt that you can get reliable time integration with
these settings.

i suggest you build a smaller system with only a few 100 atoms and make
some interactive test runs and determine reliable settings. please also
check the examples bundled with LAMMPS. you should enable neighbor list
checking and do multiple shorter runs consecutively, so you can see, if you
get dangerous builds, which is an indication of too aggressive neighbor
list settings without jobs crashing. please keep in mind that a
successfully completed run does not automatically a physically meaningful
run.

axel.

There are a number of possible things wrong with this simulation (timestep too large, neighboring too infrequent, minimized but not equilibrated, initial pressure too far from target pressure). But the biggest problem is you are not receiving the error message that was probably generated, either by LAMMPS or the runtime system. Before you do anything else, verify that you can find LAMMPS error messages. It is easy to generate a message of type error->all() using a bogus input command such as ‘foo’. To get a message of type error->one() requires a little more effort. The following 2-line script seems to do the trick:

region box block 0 0 0 0 0 0
create_box 1 box

I don’t know how to make LAMMPS reliably generate a runtime system error message. I bet Axel knows. Finally, a feature of ReaxFF is that it can make a process write an error message directly to standard error output, when for example, an array size exceeds its allocated size. You should make sure that you are redirecting standard output and standard error to the same output file e.g.

mpiexec --n 512 ./lmp_mpi -in in.lmp >& lmp.out

Aidan

There are a number of possible things wrong with this simulation (timestep
too large, neighboring too infrequent, minimized but not equilibrated,
initial pressure too far from target pressure). But the biggest problem is
you are not receiving the error message that was probably generated, either
by LAMMPS or the runtime system. Before you do anything else, verify that
you can find LAMMPS error messages. It is easy to generate a message of
type error->all() using a bogus input command such as 'foo'. To get a
message of type error->one() requires a little more effort. The following
2-line script seems to do the trick:

region box block 0 0 0 0 0 0
create_box 1 box

I don't know how to make LAMMPS reliably generate a runtime system error
message. I bet Axel knows. Finally, a feature of ReaxFF is that it can make
a process write an error message directly to standard error output, when
for example, an array size exceeds its allocated size. You should make
sure that you are redirecting standard output and standard error to the
same output file e.g.

mpiexec --n 512 ./lmp_mpi -in in.lmp >& lmp.out

there is an additional wrinkle here. when running in parallel, you are at
the mercy of the MPI library to deliver error messages from remote nodes.
redirecting stdin and stdout

MPICH and its many derivatives are famous for swallowing them and only
causing a generic segmentation fault on the frontend. with OpenMPI the MPI
library tries harder, but one has to check carefully where to errors are
redirected, when running under a batch system.

axel.
​​

Bottom line: if you can’t tell us the non-generic error message, we can’t tell you what went wrong.