Issue regarding peratom compute quantities in 28Jun14 Lammps on Linux CentOS6

Please post to the list, not to me,
as others may have ideas.

I don’t think the centrosym should ever be > 100
for an atom. Can you verify if you get the same

(bad) answer if you re-run that timestep snapshot from a restart
or dump file (e.g. via read_dump). Also do you
get the same answer when you run that snapshot
for 0 steps on any number of procs? DItto for

compute coord/atom - i.e. are the values it produces

Again I’m skeptical that the results have anything to do with
previous runs. Can you

you post a (simple, small if possible) example that shows
the opposite of anything I am suggesting?


Hi Steve,

Thanks for the reply. I've tried out a couple of things as you suggested and the behaviour is somewhat strange.

- I can confirm that changing the number of processors does not change the outcome. I've attached some images of this system run on 64 and 32 processors. In the images it is as if you can see the domain decomposition by looking at the centrosymmetry parameter (64 rectangles visible for 64 processors)
- Restarting the system from a restart file after completing one of the run steps seems to fix this issue, however, sometimes it does not, it seems to be random.
- Sometimes centrosymmetry and coordination is not reported properly in the first few steps of the run and then it "corrects" and is OK by the end
- Using the read_dump command seems to fix the issue although I do not know if this is just random
- This issue seems to affect the 28Jun14 version... I've run the same code (making superficial syntax changes as required) on 20Sep12 Lammps without a problem
- Anything that occurrence where the centrosymmetry corrects itself, the coordination calculations also appear correct
- I've also confirmed that the error is an improper centrosymmetry/coordination calculation... when I crunch the numbers using a post-processing program, the values come out properly

So in short, it seems that there is some issue with how LAMMPS is internally calculating these values, but I have no clue what triggers this behaviour





This issue seems to affect the 28Jun14 version… I’ve run the same code (making superficial syntax changes as >required) on 20Sep12 Lammps without a problem

So can you verify that the current (Jan 15) version still has the problem?

If so, can you post the needed files for a simple, small problem that gives a bad centro/atom

result, e.g. values over 100, and another script for the older 20Sep12 version where
the answer for the same problem is correct? Then I can look for the issue.


Hi Steve,

I've compiled the latest stable version (9Dec14) and this issue does not crop up.