Hello
Don’t know if this is the proper forum for this question/feature request, but here goes anyway.
I wonder if it is possible to print some information about which atom(s) are out of range together with the error statement, as this could simplify the debugging process quite a lot.
Looking forward to any reply.
Kind regards,
Øystein
This check is done in a time critical code path, so we have avoided to collect more details about what is triggering this situation. However, most of the time you should be able to collect some information anyway by reducing the timestep and making frequent output of the trajectory and then monitoring the trajectory. Most of the time this condition is triggered by either forces/velocities becoming NaN due to close contacts or atoms moving too fast within a single timestep.
A good way to check for overlaps/close contacts is to insert a line like:
delete_atoms overlap 0.1 all all
to your input and checking the output for a nonzero number of atoms deleted and then comparing before/after dump files for the identities of the deleted atoms.
A good way to check for fast atoms is to dump velocities along with the coordinates (or just vx, vy, vz directly) in a dump file and then import it into a visualization tool that can color atoms by velocity.
Ok, that makes sense.
Those are all very good tips - thanks a lot!
Perhaps one (e.g. the delete_atoms one) or several of them might even be included in the docs (11.4. Error messages)?
Øystein
I wouldn’t put it in the list of Error messages. My suggestions are more generic and apply to other situations as well (lost atoms, bond atom missing, unstable cell, etc.).
That part of the manual still needs a lot of work to be more aligned with current needs and the changes in how we manage the code and what the LAMMPS user base has changed into over the years. There is already a “Common problems” section that could be expanded into a “Common problems and how to address them” section where there would be multiple descriptive subsections with a small table of contents at the top.
Right now there is just a big blob of text that doesn’t look that it contains helpful advice. Owing to the growing number of (new) LAMMPS users unfamiliar with best practices of MD simulations it could also suggest “safe” simulation protocols (minimization before MD unless restarting, running with fixed volume and potentially just adjusting the volume manually to the desired density with change_box instead of starting with fix npt) and other best practices, and also recommend built-in introspection tools like the “info” command or how to detect issues from visualization or analysis (e.g. using time averaged properties).
If you feel like this is something you would be willing to invest some time into (and help out other LAMMPS users in the same situation), we always welcome pull requests with such kinds of changes. 
P.S.: A vast source of recommendations is the mailing list archive. A long time ago when I was teaching myself using and programming the CPMD Car-Parrinello MD code, I have spent some time and “harvested” the CPMD mailing list for such questions and answer that were of more general interest and then tried to build simple test cases and tried out suggested solutions and wrote a “questions and answers” section for their manual. It helped me personally a lot to gain a lot of insight into the code and how to deal with problematic setups and not just other users that later could look up things in the manual.
Thanks for more great advice!
I can’t promise anything, but I might be interested in contributing to the manual if possible. What would be the logical first steps if I wanted to do so?
Øystein
make spelling for spellchecking. You may need to install some additional software for that.doc/src/Errors_common.rst file and/or add a new file next to it with your contributions of frequent problems and solutionsVery good! Will have a look at this 
Hello Lammps users
I am also facing this problem when simulating a hydrated kaolinite model. I have tried according to some recommendations to decrease the timestep and increase the box parameters, but the problem is not solved. I would be glad if someone could help me.
I would remind you that I have not had this problem with the kaolinite system alone and with kaolinite with a water molecule. The problem occurs when I do the full hydrated.
Honestly, which help can you expect if you don’t share any meaningful information?
I bet your problem is a bad starting geometry. Changing the box dimensions when you have a solid interface seems a bad idea, unless by that you mean the cell vector perpendicular to the surface. You see, I cannot read your mind and frankly don’t be surprised if people ignore your plea for help.
Hello everyone
I am sorry , if my preoccupation is not clear
So that is my input file
I would remind you that I have not had this problem with the kaolinite system alone and with kaolinite with a water molecule. The problem occurs when I do the full hydrated.
control.in (1.7 KB)
data.lj (40.8 KB)
These files are full of outdated commands and errors.
This means, they can only work with a very, VERY old version of LAMMPS.
Too old to be recommended for use due to the number of known (and now fixed) bugs in them.
After correcting the issues in the data file (there is still one problem remaining in that all atoms have the same molecule ID 1 that has no impact on the physics but could result in practical issues during analysis or for mode complex computations) and inserting a delete_atoms overlap 0.001 all all there are 6 atoms found that are closer than 0.001 angstrom distance from each other, so are likely right on top of each other and thus leading to problems. In fact, running the corrected data file leads to diverging coulomb energy:
Step Time Temp Atoms TotEng E_vdwl E_coul PotEng
0 0 0 588 -nan -nan -nan -nan
This is a clear case of the GI-GO principle.