ERROR: Out of range atoms - cannot compute PPPM


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,

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.

1 Like

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)?


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. :smiley:

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?


  • get familiar with git, if you are not already
  • get an account on GitHub, if you don’t already have one
  • create a fork of the LAMMPS repository on GitHub to your account, if you don’t have one already
  • make a clone of your fork and also set up the original LAMMPS repository as an “upstream” remote (so you can easily merge/update/rebase from upstream to follow the development
  • create a feature branch based off of the current master
  • go to the doc folder and see if you can build the manual (in HTML format is sufficient at the beginning) and run make spelling for spellchecking. You may need to install some additional software for that.
  • get familiar with ReStructuredText (RST) syntax for typesetting the manual
  • look for some simple things to edit (typos, bad formatting, bad grammar)
  • try to submit a pull request for that (there is a Howto section in the manual for that)
  • start working on improving the doc/src/Errors_common.rst file and/or add a new file next to it with your contributions of frequent problems and solutions

Very good! Will have a look at this :slight_smile: