I am having an issue with the output for the compute orientorder/atom per-atom array. In my current implementation, I am using the 23 Jun 2022 - Update 4 version of LAMMPS and the lines pertaining to this compute are:
compute orient all orientorder/atom
dump 1 all custom/gz 1 mcmd.sroq6.dmp.gz id type x y z c_pe c_orient[*]
In this case, I would expect a vector of 5 values corresponding to q4, q6, q8, q10, and q12. However, this output results in a single per-atom value for c_orient[5].
When adding ‘components 6’ to this command, the output contains values for c_orient[5], c_orient[6],…,c_orient[31]. This would make sense for 2*(2*l+1) values plus the default q4 through q12 values. However, the range of values for the fcc crystal do not align if the first 5 values are the order parameters; for example, c_orient[5] has a distribution similar to what I would expect for q6 when it should be q4, and c_orient[6] goes from approx. -0.04 to 0.04 which does not correspond to the expected range. I would also expect these values to be 0<q(x)<1 for each order parameter.
I have had success previously implementing this in a bcc system, however with a different version of LAMMPS. Is this a potential bug or am I missing something else here?
I have an update after further investigation. Using LAMMPS (29 Oct 2020), I alter the compute and dump output to the following:
compute orient all orientorder/atom nnn 12 components 6
dump 1 all custom/gz 1 mcmd.sroq6.dmp.gz id type x y z c_pe c_orient[*][*]
This results in 31 output columns labelled c_orient[1][*], c_orient[2][*], … , c_orient[31][*], corresponding to q4, q6, … , q12, in addition to 26 columns for the components of q6. Here, c_orient[2][*] matches the expected the distribution for q6.
However, when reducing c_orient[*][*] to c_orient[*], the output then becomes truncated again resulting in an output that begins at c_orient[5]. In this case, atomic values for c_orient[5] are the same as c_orient[9][*] in the previous c_orient[*][*] implementation.
When trying c_orient[*][*] in newer (and the most recent) version of LAMMPS, this is not an accepted command.
Thanks for reading, if nothing else, have care in your use of orientorder/atom.
I will need to double-check when our cluster comes back online tonight/tomorrow and give some more detail about that question for the more recent LAMMPS versions I tested. There was definitely an issue with the output when using the wildcard, but I am not sure if specifying each individual output (c_orient[2] .. c_orient[28] for example) results in the correct values. I believe I tried it and still had issues, but I will follow-up.