Thermo output changed unexpectedly

Dear LAMMPS users,

This is a testing run. I first used “minimize” with “box/deform” to reduce pxx, pyy, pxy and fmax to almost zero. Then I ran nve. I found that the pxx, pyy, pxy and fmax in the last line of the thermo output for “minimize” is slightly different from those in the first line of the thermo output for “run”. Though the difference is very small, I was wondering why that was happening. I expected them to be identical.

In addition, the thermo output is still changing slightly during “run” even when I set all force components and velocities to zero.

The in file and log file are as follows. Thank you very much!

Dan

In file:

units metal
dimension 2
atom_style atomic
boundary p p p

read_data initial.txt

pair_style lj96/cut 6.0
pair_coeff 1 1 0.452510307537823 2.324933918540124 5.112
pair_coeff 1 2 0.599150487713543 2.601363907981857 5.6
pair_coeff 2 2 0.752500878127781 2.870475237138771 6.0
pair_modify shift yes

neighbor 0.3 bin
neigh_modify delay 0 every 1 check yes

velocity all create 0.0 1 units box

fix 1 all enforce2d

thermo_style custom step pe xy xlo xhi ylo yhi pxx pyy pxy fmax
thermo 50
fix 5 all box/relax x 0.0 y 0.0 xy 0.0 vmax 1.0e-4 nreset 50
min_modify line quadratic
minimize 0.0 1.0e-6 1000000 10000000
unfix 5

Dear LAMMPS users,

This is a testing run. I first used "minimize" with "box/deform" to reduce
pxx, pyy, pxy and fmax to almost zero. Then I ran nve. I found that the pxx,
pyy, pxy and fmax in the last line of the thermo output for "minimize" is
slightly different from those in the first line of the thermo output for
"run". Though the difference is very small, I was wondering why that was
happening. I expected them to be identical.

have you ever heard some stories about the limitations of
floating-point math? and what happens, if you compute numbers, that
depend on summing up values of equal magnitude but opposite sign.

In addition, the thermo output is still changing slightly during "run" even
when I set all force components and velocities to zero.

unless you do a run with "pre no", you have a reneighboring happen
during setup and that can result in a reordering of the atoms and thus
affect your numbers. without knowing the exact system setup and how
large your individual force contributions are (before they get summed
up), it is difficult to say, whether you have a genuine problem or are
just overinterpreting your data. the fact that you provide epsilon and
sigma with excessive precision and yet use an extremely short cutoff
hints at the latter.

axel.

Thank you, Axel. I understand why the thermo at the beginning of run differs from the thermo at the end of minimize. But I do not understand very well why the thermo still changes during the first run step, i.e.from Step 456 to Step 457 since the setup and reneighboring have finished before the first run step. When the system evolves during the step, no interatomic forces exist, so the atoms should stay right at the same positions. Also, no reneighboring/reordering is taking place. So I would expect that the thermos remain unchanged. I was wondering if you could explain a little more about this and point out which part of my reasoning is wrong.

Dan

Thank you, Axel. I understand why the thermo at the beginning of run differs
from the thermo at the end of minimize. But I do not understand very well
why the thermo still changes during the first run step, i.e.from Step 456
to Step 457 since the setup and reneighboring have finished before the first
run step. When the system evolves during the step, no interatomic forces
exist, so the atoms should stay right at the same positions. Also, no
reneighboring/reordering is taking place. So I would expect that the thermos
remain unchanged. I was wondering if you could explain a little more about
this and point out which part of my reasoning is wrong.

i will try provide some more explanations, if you answer *my* question
first and request for the missing data to reproduce your test. it is a
waste of time to discuss in this hypothetical way without being able
to reproduce what you are seeing and making additional checks and
tests to support my assessments.

if you believe there is a bug in LAMMPS, it is your task to prove it
is there, not my task to prove it isn't.

thanks,
     axel.