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
bogus?
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?
Steve
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
Thanks!
Matt
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.
Steve
Hi Steve,
I've compiled the latest stable version (9Dec14) and this issue does not crop up.
Matt