Particle order redistributed periodically in output?

Submitted by barolfe on Thu, 03/31/2011 - 09:54

I am running LIGGGHTS with approximately 34,000 particles in a confined STL geometry with mixing paddles rotating to agitate the particles. I've noticed in my output (as .vtk files) that the order in which the particle positions are written change every 1000 time steps (regardless of how often I dump data). The "Lookup Table" for atom types at the end of the .vtk file changes correspondingly. Thus, if I have two atom types, visually the simulation runs smoothly. However, because I have no way of knowing how the particle order has changed, I have no way of tracking or identifying an individual particle. One solution would be to give every single atom its own type, which then would elucidate the remapping, but this is an unrealistic option.

As a clarifying example: I've labeled all the particles near the wall at the start of the simulation as "type 3". The labeling is done by giving each row of my data a unique identifier and ASSUMING this order will be retained throughout the simulation. As the simulation progresses, the labeled particles move slightly as the mixing paddles rotate, but generally are confined to the wall within 1000 steps. As soon as 1,000 steps has been reached, the labeled particles suddenly become randomly distributed and continue normally for another 1000 steps until, again, they become randomly distributed (or so it seems based on the histograms). Therefore, if the labeling order is being held constant, the order of the x,y,z data must be changing.

Is this normal behavior? Is it LIGGGHTS issue or is it a pizza.py issue? Any help would be much appreciated.

- Bryan

Forums:

JF's picture

JF | Thu, 03/31/2011 - 10:20

Hello Bryan,

The order in which the particle positions are written change every 1000 time steps, because the neighbor list has been rebuilt before.

LIGGGHTS and also LAMMMPS (I think) sorted the atoms according to their coordinates in order to find quickly the neighbor particles.

I think, you can track one particle with its atom id, no ???

Regards
JF

barolfe | Thu, 03/31/2011 - 10:33

Thanks for the reply JF.

This was my suspicion.

pizza.py seems to ignore the atom-id when writing .vtk and .xyz files because, I believe, both of these file types use order as a unique identifier.

I can reconfigure my post-processing scripts to handle the raw dump files instead of .vtk or .xyz.

EDIT: I was unaware of the d.sort() option, which seems will solve all my problems.

Thanks again,

- Bryan

JF's picture

JF | Thu, 03/31/2011 - 10:44

Sorry, I have never paid attention to know if pizza.py respects the atom-id.

You need to wait for the reply from Christoph, but I think that the vtk files created from these following pizza functions respect the atom-id :

d=dump("dump.mySimulation")

v=vtk(d)

v.manyGran()

Regards
JF

ckloss's picture

ckloss | Thu, 03/31/2011 - 10:49

JF is correct: if you use v.manyGran() with the pizza.py from this site, the ID is written to VTK
the output order cannot be guaranteed, especially in parallel, so identifying via ID is the best idea
there is also a sorting that is done for memory coalescence, but you can turn it off with atom_modify sort 0 0 if you want

Christoph

barolfe | Thu, 03/31/2011 - 12:11

Thank you both! This has been tremendously helpful and I really should have looked into the pizza documentation further before posting my question.

- Bryan