Error Handling

Hi Lammps Developers,

Has error or exception handling ever been considered to be added, like a try-catch or some type of mechanism that would not cause the simulations to complete shut down if certain error codes were thrown? For example, you’re trying to quickly reduce the volume and this causes a bond, angle, dihedral or something to get lost because maybe the skin distance was too short, with error handling, you could have Lammps throw an error code, then within the input file you could deal with it. This may be a silly idea but what got me thinking about this is that I had a simulation running that seemed to be stable (15 million timesteps, timestep 10fs, NPT with stable volume and temp.) and all of a sudden it says a dihedral got lost, quite frustrating.

Cheers

Hi Lammps Developers,

Has error or exception handling ever been considered to be added, like a
try-catch or some type of mechanism that would not cause the simulations to
complete shut down if certain error codes were thrown? For example, you're

c++ exceptions are a bad idea, because they make the common case (no
error) expensive by adding overhead.

trying to quickly reduce the volume and this causes a bond, angle, dihedral
or something to get lost because maybe the skin distance was too short, with
error handling, you could have Lammps throw an error code, then within the
input file you could deal with it. This may be a silly idea but what got me

thinking about this is that I had a simulation running that seemed to be
stable (15 million timesteps, timestep 10fs, NPT with stable volume and
temp.) and all of a sudden it says a dihedral got lost, quite frustrating.

again, adding this kind of overhead would not be desirable. what you
could do is a "paranoid" version of the verlet integrator, but for the
most part the way LAMMPS (and MD) works is that you can only detect
that something went wrong after it is too late and you cannot recover
(specifically MPI cannot easily be reset). that is where writing
restart/checkpoint files frequently at the beginning of a simulation
comes into play, which actually *is* some kind of exception handling.
if you just add a little script wrapper around running LAMMPS
repeatedly from the last valid checkpoint/restart you have a good
approximation of what you are looking for without having to add
anything to LAMMPS and also having the maximum performance (RTTI and
exception support can cost between 5% and 20% performance).

axel.