Dipole moment calculation problems

LAMMPS LAMMPS General Discussion
,
1

Dear users,

I am calculating the dipole moment M and M^2 values for MOFs (please find the data file below).

For M, there are two ways to calculate (p.s. here I only calculate the values along x direction):

  1. using the “compute dipole” command (see attached file “in.computedipole”, the result is 0);

  2. using the equation of M = Sum_n q_i* r_i - Sum_n q_i * (Sum_n m_i*r_i)/Sum_n m_i based on the center of mass (see attached file “in.equation”, the result is around -108) according to the previous discussion:

(https://matsci.org/t/lammps-users-problem-with-compute-dipole-chunk/34733)

does anyone know why these two results are different, and the obtained negative values (-108) from the second way confused me, what does it mean?

For M^2 (which I will use to further calculate <M^2>), I am confused about whether the equation I used is correct or not, the one I used is: M^2= sum_n (q_ir_i)^2-[Sum_n q_i * (Sum_n m_ir_i)/Sum_n m_i]^2
(see commands used in the attached file “in.equation”)

please correct me if I made any mistake, thank you.
data.HKUST-1 (331.8 KB)
in.computedipole (3.3 KB)
in.equation (3.8 KB)

wang

2

This may be a bug, because the whole issue comes from the fact that your molecule ID is equal to 444, instead of 1. If you change variable Mx equal c_M[1][1] to variable Mx equal c_M[444][1], you will get the same output for both cases.

According to the manual for compute dipole/chunk:

These computes calculate a global array where the number of rows = the number of chunks

so, in theory, you should have only a single row, because you have one molecule, but because its ID is 444, the actual values are at this index instead of 1.

3

Please note that under periodic boundary conditions the dipole moment of a simulation box is not quite well-defined: Polarization density - Wikipedia (see the “Polarisation ambiguity” section). Furthermore, while polarisation changes are well-defined, only the “itinerant polarisation” is meaningful (that is, using unwrapped instead of wrapped coordinates).