Compute hexorder/atom - troubles

LAMMPS LAMMPS Mailing List Mirror
1

Dear all,
I’m using lammps-22Aug18 to perform an MD simulation of interacting octagones each one composed by nine particles (a central particles of type 1 and eight corners of type 2); to do so I’m using the atom_style hybrid molecular sphere.
Since I wanted to calculate the hexatic order parameter for the ocatgones, I created a group that include all the octagone centers and then calculate the hexatic order with the lammps command compute hexorder/atom only for this group.
The strange thing I noticed is that if at the beginning of the simulation when I dump the values c_hexatic[1] and c_hexatic[2] I have a value for type 1 particles and zero for type 2 particles as I expected, going on with subsequent timesteps I noticed that also particles of type 2 at some point start to have non zero values of the hexatic order parameter. I cannot explain this behavior, since I asked lammps to calculate those values only for type 1 particles and at the beginning (meaning non only timestep 0, but also later) everything worked as I expected. In the following I add the code I used:

clear

units micro
dimension 3
newton on
boundary p p f #
atom_style hybrid molecular sphere
atom_modify sort 100000 2

comm_modify mode single cutoff 0.1 vel yes

bond_style harmonic
angle_style harmonic
improper_style harmonic
pair_style lj/cut 0.05

read_data ${inputFile}

print “read input”

#bond_style harmonic
bond_coeff 1 1.0 0.0675
bond_coeff 2 1.0 0.0517

#angle_style harmonic
angle_coeff 1 1.0 45.0

#improper_style harmonic
improper_coeff 1 1.0 180.0

#pair_style lj/cut 0.05
pair_coeff 1 1 {centreLJ} 0.120 0.135* *pair_coeff 1 2 {centreLJ} 0.07 0.0785
pair_coeff 2 2 ${cornerLJ} 0.0172 0.043

print “pairs set”

group octagones_center type 1

# — set thermo output —

thermo 10000
thermo_style custom step temp fmax ke etotal

compute cbond1 all property/local batom1 batom2 btype

compute hexatic octagones_center hexorder/atom nnn NULL cutoff 0.135

# — dump rules —

dump particle_dump all custom 100000 {dumpDir}/particles*.dat id mol type mass x y z vx vy vz fx fy fz c_hexatic[1] c_hexatic[2]</i> *dump_modify particle_dump sort id* <i>dump bond_dump all local 100000 {dumpDir}/bonds*.dat index c_cbond1[1] c_cbond1[2] c_cbond1[3]

timestep 1e-5

variable zspring atom -0.1*z
fix tether2d all addforce 0.0 0.0 v_zspring

fix thermostatting all nve

fix finiteT all langevin 300.0 300.0 0.001 1234

run 2000000

unfix finiteT
unfix thermostatting
unfix tether2d

I have to say that I’ve also tried to chose the options nnn=NULL and cutoff=0.135 but I noticed the same problem, except from the fact that instead of numerical values I got inf values. I will appreciate any help in understanding why this is happening. Thanks in advance.

Best,
Linda Ravazzano

2

Linda,

I don’t see how this could be possible from looking at the (current) source code. Are you sure that you are correctly interpreting the trajectory dump data?
Also, please update to the most recent (stable) version of LAMMPS to make certain that you are not affected by a bug that has already been fixed.

Axel.

3

Dear Professor Kohlmeyer,
I’ve updated my lammps version to the last stable release (3Mar2020) an rerun the code. But I still have the same problem as before. Here some of the output with non zero values of the hexatic/order parameters for type 2 particles:

ITEM: TIMESTEP
200000
ITEM: NUMBER OF ATOMS
10125
ITEM: BOX BOUNDS pp pp ff
-2.5000000000000000e+00 2.5000000000000000e+00
-2.5000000000000000e+00 2.5000000000000000e+00
-1.0000000000000000e+00 1.0000000000000000e+00
ITEM: ATOMS id mol type mass x y z vx vy vz fx fy fz c_hexatic[1] c_hexatic[2]
1 1 1 2.61799e-05 -0.949649 -1.8 -0.000661903 -0.303815 -0.0256191 -0.65186 -0.0278452 0.170022 -0.102482 -0.0580069 -0.25599
2 1 2 2.61799e-05 -1.01437 -1.79163 0.00224891 0.0831883 -0.630208 -0.0350834 -0.19706 0.117946 -0.00779863 0 0
3 1 2 2.61799e-05 -1.00697 -1.84409 0.000363407 0.607105 -0.0457628 -0.122335 0.165474 -0.228777 -0.0599993 0 0
4 1 2 2.61799e-05 -0.957687 -1.86213 -0.0022715 0.469021 0.033987 -0.0162833 -0.153947 0.00195416 0.215048 0 0
5 1 2 2.61799e-05 -0.907261 -1.85497 -0.00409378 -0.197383 0.0854277 -0.250912 0.167956 -0.231876 -0.380953 0 0
6 1 2 2.61799e-05 -0.883642 -1.80851 -0.00366095 0.296311 0.409524 0.0428266 0.260049 0.194199 0.124892 -0.107892 -0.200177
7 1 2 2.61799e-05 -0.90177 -1.76311 -0.00146339 -0.202791 0.025406 -0.151227 0.135847 0.0223299 0.00497552 0 0
8 1 2 2.61799e-05 -0.940332 -1.72646 0.00123316 0.0494682 0.139885 -0.100143 0.0700483 0.00673109 -0.0786883 0 0
9 1 2 2.61799e-05 -0.990105 -1.74766 0.00264548 -0.375105 0.20581 -0.23516 -0.135723 -0.0152821 -0.112692 0 0
10 2 1 2.61799e-05 1.21422 0.945414 -0.000460638 0.285836 -0.749029 -0.539065 -0.0613366 0.178787 -0.021356 0.0892571 -0.253491
11 2 2 2.61799e-05 1.24654 1.00642 -0.00129849 -0.334843 0.31171 0.138889 -0.0223496 0.223458 0.185849 0 0
12 2 2 2.61799e-05 1.19054 1.02275 0.00101076 -0.165045 -0.256483 -0.102759 -0.278007 0.0682216 -0.205397 0 0
13 2 2 2.61799e-05 1.14511 0.982174 0.00255265 0.053355 0.118105 -0.178415 0.0601526 -0.116543 -0.251298 0.0395835 0.244363
14 2 2 2.61799e-05 1.15066 0.925974 0.00196992 -0.473788 0.307933 -0.206581 -0.157957 0.0715032 -0.117775 0 0
15 2 2 2.61799e-05 1.18317 0.886844 0.000444482 0.305226 0.454672 -0.0415064 -0.184175 0.171254 0.109823 0 0
16 2 2 2.61799e-05 1.23426 0.88065 -0.00166208 0.324062 0.566307 -0.426762 -0.415293 -0.174438 0.105527 0 0
17 2 2 2.61799e-05 1.2763 0.912366 -0.00313443 -0.0251381 -0.0631756 0.543895 -0.152972 -0.0374146 0.0625611 0 0
18 2 2 2.61799e-05 1.27648 0.964606 -0.00278354 -0.172054 1.10073 -0.284863 0.141179 0.0389351 0.119038 -0.0326908 0.0717899
19 3 1 2.61799e-05 1.07111 1.49639 0.000645532 -0.277422 0.401307 0.220335 -0.125664 -0.172978 -0.040956 0.395841 0.178044
20 3 2 2.61799e-05 1.12312 1.4515 0.00682973 -0.125381 -0.418943 0.397249 -0.123468 0.276135 0.181093 0 0
21 3 2 2.61799e-05 1.13617 1.50085 0.0014622 0.190283 -0.312648 -0.609275 -0.145845 0.280557 0.254903 0.424644 0.417281
22 3 2 2.61799e-05 1.11604 1.54761 -0.00423325 -0.518569 0.183679 0.234663 -0.125463 -0.147885 0.0370447 0 0
23 3 2 2.61799e-05 1.06654 1.56176 -0.00685332 -0.0928527 -0.38853 -0.121324 -0.107794 0.259722 0.143908 0 0
24 3 2 2.61799e-05 1.02273 1.53806 -0.00507283 0.303969 0.454208 0.548067 0.087257 0.0993037 -0.0256024 0 0
25 3 2 2.61799e-05 1.00155 1.49142 -0.000121579 0.477852 -0.121845 0.561508 0.180366 0.0707122 -0.0733283 0 0
26 3 2 2.61799e-05 1.02746 1.44605 0.00556992 0.231282 0.36206 0.607763 -0.295801 0.313135 0.0616424 0 0
27 3 2 2.61799e-05 1.07597 1.43006 0.00835928 -0.0708726 0.593564 -0.168318 -0.309734 -0.130757 -0.0406714 0 0

This time I also tried to add an atom_modify map array at the beginning of the code, thinking that maybe something could go wrong in assigning the particles to different processors using mpi, but nothing changed.

Best,
Linda

4

what happens, if you remove the following line?

dump_modify particle_dump sort id

5

here is another idea.
can you try the following one-line change to the source code, recompile and run again?

$ git diff
diff --git a/src/compute_hexorder_atom.cpp b/src/compute_hexorder_atom.cpp
index 96d4c4767…b4ffd91b4 100644
— a/src/compute_hexorder_atom.cpp
+++ b/src/compute_hexorder_atom.cpp
@@ -239,7 +239,7 @@ void ComputeHexOrderAtom::compute_peratom()
}
qn[0] = usum/nnn;
qn[1] = vsum/nnn;

  • }
  • } else qn[0] = qn[1] = 0.0;
    }
    }
6

Dear Professor Kohlmeyer,
Thanks for the support. I’ve tried the first option of removing the dump_modify particle_dump sort id. Those strange behavior was less common but still I had some type 2 particles with non zero values of the hexatic order parameters.
Another thing that I have to notice is that if I switch on the option nnn NULL for the compute hexorder/atom, I obtain inf values.

Now I’m going to try the second way you suggested and let you know what happens.

Best,
Linda Ravazzano

7

Dear Professor Kohlmeyer,
With the change you suggested to the compute_hexorder_atom.cpp file, the problem is now solved and I correctly see only zero values for type 2 particles.
Many thanks for your advices.

Best,
Linda

8

Thanks for the feedback, Linda, the change will be included in the next LAMMPS patch. Axel.