Dear Lammps community,
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.
When adding ‘components 6’ to this command, the output contains values for c_orient, c_orient,…,c_orient. 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 has a distribution similar to what I would expect for q6 when it should be q4, and c_orient 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?
Thanks for your help!
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[*], c_orient[*], … , c_orient[*], corresponding to q4, q6, … , q12, in addition to 26 columns for the components of q6. Here, c_orient[*] 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. In this case, atomic values for c_orient are the same as c_orient[*] 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.
@athomps can you have a look at this?
I am not certain, if this is a bug, an oversight in the documentation, or an incorrect use issue.
So it sounds like this issue only arises with the wildcard usage
c_orient..c_orient gives correct results, is that right?
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 .. c_orient for example) results in the correct values. I believe I tried it and still had issues, but I will follow-up.