compute gyration/chunk of molecules

Hello lammps developers,

I have a problem, when I use the compute gyration/chunk for molecules
individually some values are non sense. This a script test:

# water/dodecane interface at 300 K and 1 atm

units real
atom_style full
boundary p p p

pair_style lj/charmm/coul/long 8.5 10.0

bond_style harmonic
angle_style charmm
dihedral_style charmm

pair_modify tail yes
pair_modify mix arithmetic

read_data equil_interface_nvt.data

kspace_style pppm 0.0001
neighbor 2 bin
neigh_modify every 2 delay 10 check yes
timestep 0.5

velocity all create 300.0 69 rot yes dist gaussian

reset_timestep 0

#fix run_npt all npt temp 300 300 50 iso 1.0 1.0 500
#run 1000000
#unfix run_npt

thermo 100
thermo_style custom step temp etotal press vol lx ly lz

write_data equil_npt.data

group water molecule <> 1 7757
group dodecane molecule <> 7758 8372

#compute ccs all chunk/atom bin/1d y center 1.0
compute mol all chunk/atom molecule
compute molwater water chunk/atom molecule
compute moldodecane dodecane chunk/atom molecule compress yes

#compute cmwater water com/chunk molwater
#compute cmdodecane dodecane com/chunk moldodecane

compute rgwater water gyration/chunk molwater
compute rgdodecane dodecane gyration/chunk moldodecane
compute rg all gyration/chunk mol

reset_timestep 0
fix run_nvt all nvt temp 300 300 50
fix 1 water ave/time 1 1 100 c_rgwater file rgwater.dat mode vector
fix 2 dodecane ave/time 1 1 100 c_rgdodecane file rgdodecane.dat mode vector
fix 3 all ave/time 1 1 100 c_rg file rg.dat mode vector
run 100

for example in the file rgwater.dat the gyration radius for water is the
following (line 60 to 73)
56 0.327781
57 0.337399
58 0.329807
59 0.335523
60 0.32193
61 0.324811
62 11.6983 <- this no sense
63 0.332929
64 0.335569
65 0.336309
66 0.3383
67 0.337413
68 0.336956
69 0.335276
..
..
(line 220 to 229)
216 0.336661
217 0.32669
218 13.7159 <-
219 0.333946
220 0.324528
221 0.337303
222 11.5517 <-
223 11.6212 <-
224 0.335237
225 0.328516

for dodecane is the same behavior rgdodecane.dat in the first line

0 615
1 3.74373
2 3.38038
3 26.9056 <-
4 20.6336 <-
5 3.20623
6 3.24774
7 3.60914
8 25.4639 <-
9 3.49589
10 3.3417
11 25.4778 <-
12 3.30506
13 3.91393
14 3.41182
15 18.4701 <-
16 3.15704
17 2.95738

this happed even I consider the all molecules is only see the rg.dat
So how is possible fix the problem, I thing must be use the minimum_image
function in the compute_gyration_chunk command.
Thank for you help me. (if necessary a topological file if only send me a
message)

Best
Samuel

in.interfacial_tension (1.46 KB)

log.lammps (3.81 KB)

rg.dat (223 KB)

rgdodecane.dat (14.2 KB)

rgwater.dat (208 KB)

From he compute gyration/chunk doc page:

NOTE: The coordinates of an atom contribute to Rg in “unwrapped” form,
by using the image flags associated with each atom. See the “dump
custom”_dump.html command for a discussion of “unwrapped” coordinates.
See the Atoms section of the “read_data”_read_data.html command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
using the “set image”_set.html command.

Is it possible you have a molecule that straddles a periodic boundary

and the image flags are not initialized correctly (e.g. in the data file).

If this is the case, then you would get a large Rg for that molecule, b/c when LAMMPS

performs the unwrap, the atoms in a molecule will end up

being very far from each other.

Steve

Hello lammps developers,

in this case how should be the set image command, to obtain the correctly
gyration radius.
Thanks for help me.

Samuel

Hello lammps developers,

in this case how should be the set image command, to obtain the correctly
gyration radius.

you don't seem to fully understand the issue. there is no single magic
"just do this and it will work"-command for the kind of problem, steve
is describing.

the first step, that you have to do, is to check your data file to see
whether it contains image flags and whether applying those would make
all your molecules "whole".

at this point, however, this is all speculation, since none of us has
seen your data file.
another issue may be, that you are running into a problem that has
already been corrected in a newer version of LAMMPS.

axel.