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.
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)?
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?
Very good! Will have a look at this