Dear all,
I have a query regarding dynamic groups determined by an atom-style variable. We’re using the orientorder/atom and coord_number computes to define such an atom-style variable via a common solidity criterion;
in.test (2.38 KB)
David,
this is indeed a surprising behavior.
I have dug a little deeper into what is happening and I think I have found an explanation, but I am not certain what would be the proper solution. Thus I am copying Steve so he can chime in.
Essentially what seems to happen is that compute coord/atom (and through it compute orientorder/atom) is called twice in every timestep, once by a fix that updates the dynamic groups and a second time by the compute reduce command. This happens at different “phases” of a timestep. The group update is rather early, while the output is rather late.
The problem now seems to be that by the time the group is updated, properties of ghost atoms including coordinates have not been updated, but when the thermo output triggers compute reduce, they have. The different data for ghost atoms then leads to different results for compute coord/atom (directly or indirectly) and thus you can get a different number of atoms when you compare the members of the group and then number of atoms where the atom style variable is true during the second check.
Now it looks like the fix to update the groups sets a flag to indicate to computes when they are called early and that they need to update information on ghost atoms, but I see this only been looked for with compute cluster/atom, but not in compute coord/atom or orientorder/atom, so my interpretation is that these computes have not been updated for the case that they would be called to define a dynamic group.
Axel.
Thanks for this Axel – very helpful.
With this information we’ve been able to produce the expected behaviour by updating orientorder/atom in a similar fashion to cluster/atom.
I will try to construct a coherent pull request in case the changes are helpful to others.
David