Hello all,
I am facing a problem with reax/c/species command. When I use it to group my atoms with their molecular id, i.e. the per-atom vector of the reax/c/species command, I am getting some wrong values. Printing this information for one processor one can see that at multiples of 1000 timestep the values are wrong. For more processors this phenomenon is evident at earlier and more timesteps. I attach my input file which contains CH4 and O2 molecules. Also on the attached results.pdf one can see what I mean. I sorted the atoms based on their id and on the highlighted ones it is obvious that only for one timestep the values change abruptly and without a cause; and then they take again their previous values. I would really appreciate if someone could tell me what am I doing wrong. The LAMMPS version I use is: version 7 Aug 2019.
Thank you very much in advance,
Stratos
data.input (8.14 KB)
ffield_CHO_2008 (5.7 KB)
in.sim (1.16 KB)
results.pdf (183 KB)
1 Like
Please try rerunning your input with the command:
atom_modify sort 0
added.
By default, LAMMPS will sort all local atom arrays every 1000 steps to improve cache locality and it looks like reaxc does not update the internal information so that there is an inconsistency with the output.
axel.
Dear Axel,
Thank you very much for once again solving my problem!
Stratos
Dear Axel,
Unfortunately I replied too quickly. That did solve the problem when running on one processor, but applying the command atom_modify sort 0 2.0 for multiple processors the problem remains at intermediate timestep, such as 107, 740, 1240, 1542 etc. for 4 procs. Is there anything else that could cause this issue?
Stratos
Dear Axel,
Unfortunately I replied too quickly. That did solve the problem when running on one processor, but applying the command atom_modify sort 0 2.0 for multiple processors the problem remains at intermediate timestep, such as 107, 740, 1240, 1542 etc. for 4 procs. Is there anything else that could cause this issue?
no idea. at least not right now. the event happening every 1000 steps with neighborlist rebuilds in every step were a strong hint at atom sorting.
i’ve been looking through the source code since to find an indication which property associated with the order of atoms that gets out of sync and then again back in sync and how, but so far without luck.
The USER-REAXC package is not easy to read, since it was originally written as a standalone C code by somebody following very different conventions what the LAMMPS code has and then it was retrofitted into the LAMMPS framework. most of the resulting kinks have been worked out and corrected over time, but some corner cases still occasionally pop up.
Axel.
Ray, Oleg,
any suggestion where to look for a cure for this unexpected behavior?
Thanks,
Axel.