Dear all,
restarting the following calculation:
units lj
atom_style charge
boundary p p p
read_data initpos.dat
mass 1 1.0
mass 2 1.0
group anions type 2
group cations type 1
velocity all create 0.85 87287
pair_style lj/cut/coul/long 2.5 8.0
pair_coeff 1 1 1.0 1.0
pair_coeff 1 2 1.0 1.0
pair_coeff 2 2 1.0 1.0
dielectric 2.0
kspace_style pppm 1.0e-10
neighbor 0.3 bin
neigh_modify every 1 delay 0 check no
variable valoremeno equal ramp(0.000001,-1.0)
variable valorepiu equal ramp(0.000001,1.0)
fix trucco1 anions adapt 1 atom charge v_valoremeno
fix trucco2 cations adapt 1 atom charge v_valorepiu
fix evoluzione all nve
compute corr all temp/com
fix termostato all langevin 0.85 0.85 100.0 699483
fix_modify termostato temp corr
fix barostato all press/berendsen iso 0.005 0.005 100.0
dump 1 all xyz 500 test.xyz
thermo 100
thermo_style custom step temp press etotal lx ly lz
restart 100000 liquido
run 400000
with an initial cell:
1200 atoms
2 atom types
0.0 11.22 xlo xhi
0.0 9.717 ylo yhi
-100.0 109.717 zlo zhi
I found that LAMMPS becomes 10 times slower. Comparing the output files of the first calculation:
LAMMPS (12 Apr 2013)
Reading data file …
orthogonal box = (0 0 -100) to (11.22 9.717 109.717)
2 by 2 by 24 MPI processor grid
1200 atoms
600 atoms in group anions
600 atoms in group cations
PPPM initialization …
WARNING: For better accuracy use ‘pair_modify table 0’ (…/kspace.cpp:239)
G vector (1/distance)= 0.532191
grid = 8 6 128
stencil order = 5
estimated absolute RMS force accuracy = 7.4631e-13
estimated relative force accuracy = 7.4631e-13
using double precision FFTs
3d grid and FFT values/proc = 792 96
Setting up run …
Memory usage per processor = 0.511139 Mbytes
Step Temp Press TotEng Lx Ly Lz
…
With the one of the restart calculation:
LAMMPS (12 Apr 2013)
Reading data file …
orthogonal box = (-0.0195522 -0.016933 -100.365) to (11.2396 9.73393 110.082)
2 by 2 by 24 MPI processor grid
1200 atoms
1200 velocities
600 atoms in group anions
600 atoms in group cations
PPPM initialization …
WARNING: For better accuracy use ‘pair_modify table 0’ (…/kspace.cpp:239)
G vector (1/distance)= 0.557791
grid = 180 162 1440
stencil order = 5
estimated absolute RMS force accuracy = 3.54532e-08
estimated relative force accuracy = 3.54532e-08
using double precision FFTs
3d grid and FFT values/proc = 596970 437400
Setting up run …
Memory usage per processor = 61.778 Mbytes
Step Temp Press TotEng Lx Ly Lz
…
it seems that the k vectors grid as been enlarged by a factor 10 in all directions!
Now you might argue that, being the simulation at constant pressure, the size of the simulation cell is growing more and more and, in the restart, the recalculated mesh gets bigger and bigger. But recovering the cell information from the restart file (with binary2data) the cell results:
-1.9552155318933728e-02 1.1239552155318632e+01 xlo xhi
-1.6933002961971866e-02 9.7339330029621713e+00 ylo yhi
-1.0036545627067763e+02 1.1008245627067761e+02 zlo zhi
basically unchanged during the whole first simulation.
This is the input file of the restart calculation where I simply used the command read_restart and commented the read_data line and the setting of initial velocities:
units lj
atom_style charge
boundary p p p
#read_data initpos.dat
read_restart liquido.400000
mass 1 1.0
mass 2 1.0
group anions type 2
group cations type 1
#velocity all create 0.85 87287
pair_style lj/cut/coul/long 2.5 8.0
pair_coeff 1 1 1.0 1.0
pair_coeff 1 2 1.0 1.0
pair_coeff 2 2 1.0 1.0
dielectric 2.0
kspace_style pppm 1.0e-10
neighbor 0.3 bin
neigh_modify every 1 delay 0 check no
variable valoremeno equal ramp(-1.0,-1.0)
variable valorepiu equal ramp(1.0,1.0)
fix trucco1 anions adapt 1 atom charge v_valoremeno
fix trucco2 cations adapt 1 atom charge v_valorepiu
fix evoluzione all nve
compute corr all temp/com
fix termostato all langevin 0.85 0.85 100.0 699483
fix_modify termostato temp corr
fix barostato all press/berendsen iso 0.005 0.005 100.0
dump 1 all xyz 500 test.xyz
thermo 100
thermo_style custom step temp press etotal lx ly lz
restart 100000 liquido
run 400000
As a last check I forced LAMMPS to use the smaller mesh of the first calculation using the command
kspace_modify mesh 8 6 128
and of course the velocity of the calculation goes back to original one.
Did I messed up something or did I discovered my first LAMMPS bug?
Cheers and thanks for your work.
Andrea