Compute orientorder/atom command prints some weird values

Hello LAMMPS users,
I am having some problems while calculating Q6 using compute orientorder/atom command. Let’s say I have three types of particles in the system (type 1, type 2 ,type 3). I created a group with particle type 1. Then I used that group-ID to compute Q6 within some cutoff distance. When I dump computed Q6 in the .lammpstrj file, it is giving some values for particle type 1. But the surprising fact is that it also prints some random value for particle type 2 and 3. Lammps manual for compute orientorder/atom command says that “The value of Ql is set to zero for atoms not in the specified compute group”. But that is not the case I see, it is printing some weird values, sometimes -47.0, 20.0 etc. If anyone in this list has experienced this issue, kindly let me know.

The lines in the input script which are related to this calculation are mentioned below.

group Tpart type 1

compute Q6 Tpart orientorder/atom nnn NULL degrees 1 6 cutoff 3.5

dump 1 all custom 500 q6.lammpstrj id type xs ys zs c_Q6[*]

It would be nice if someone can point out any mistakes I am making or if there is any bug reported regarding this problem. I am using the LAMMPS version 2018.

Thanks in advance.

Debdas

Hello LAMMPS users,
I am having some problems while calculating Q6 using compute orientorder/atom command. Let’s say I have three types of particles in the system (type 1, type 2 ,type 3). I created a group with particle type 1. Then I used that group-ID to compute Q6 within some cutoff distance. When I dump computed Q6 in the .lammpstrj file, it is giving some values for particle type 1. But the surprising fact is that it also prints some random value for particle type 2 and 3. Lammps manual for compute orientorder/atom command says that “The value of Ql is set to zero for atoms not in the specified compute group”. But that is not the case I see, it is printing some weird values, sometimes -47.0, 20.0 etc. If anyone in this list has experienced this issue, kindly let me know.

as far as i can tell from checking the current source code, the statement in the manual is not correct. certain computed values are set to zero, but not the ones outside the selected group.
this will be remedied in an upcoming patch release.

The lines in the input script which are related to this calculation are mentioned below.

group Tpart type 1

compute Q6 Tpart orientorder/atom nnn NULL degrees 1 6 cutoff 3.5

dump 1 all custom 500 q6.lammpstrj id type xs ys zs c_Q6[*]

It would be nice if someone can point out any mistakes I am making or if there is any bug reported regarding this problem. I am using the LAMMPS version 2018.

this is useless information. there were 24 LAMMPS releases in 2018. LAMMPS prints the exact version date at the very beginning of each run.

axel.

Hello Axel,
Thanks for your comments. Sorry that I did not mention the proper LAMMPS release, even the release year was not correct. The version I am using is LAMMPS (3 Mar 2020).

As for the other groups it is printing some random values, I hope that would not cause any error in the calculation of Q6 for the group I am considering. Should one be worried about this or just ignore the values for outside the selected groups. It would be nice if you could kindly shed light on this.

Thank you very much.
With regards
Debdas

Hello Axel,
Thanks for your comments. Sorry that I did not mention the proper LAMMPS release, even the release year was not correct. The version I am using is LAMMPS (3 Mar 2020).

As for the other groups it is printing some random values, I hope that would not cause any error in the calculation of Q6 for the group I am considering. Should one be worried about this or just ignore the values for outside the selected groups. It would be nice if you could kindly shed light on this.

just ignore them. those are stale values from atoms that have been migrating between subdomains or reordered. every time LAMMPS recomputes the neighbor lists, atoms may be exchanged between subdomains and/or their local order is changed. the computed parameters are still computed from scratch, but the currently published implementation does not zero out all values. it is quite unusual to only compute those parameters for a subset of atoms and that is the reason why it hasn’t been noticed. if it bothers you, you can try to assign each of the individual per-atom vectors to an atom style variable where you multiply it with a group function (which is 1.0 or atoms in the group and 0.0 for atoms outside).

axel.

OK, I see. Thanks for the nice clarification. I will try to do the things you mentioned in the last portion of your email.

Thanks and regards
Debdas