misprint of energy after minimization

Hi all,

I think there is an issue in the energy printed after several minimizations. I think this problem was reported before and I thought it was solved but I am still getting it. I am using LAMMPS 20 Nov 2015 version and when I run the input attached some times I get the following results:

10000 0 -76497.515 0 -76497.515 0.0027235404 152161.17
10100 0 -76497.515 0 -76497.515 0.00030810088 152161.17
10200 0 -76497.515 0 -76497.515 -0.097640545 152161.18
10300 0 -76497.515 0 -76497.515 -0.016365993 152161.17
10400 0 -76497.515 0 -76497.515 -0.0001410428 152161.17
10500 0 -76497.515 0 -76497.515 -0.04172869 152161.17
10600 0 -76497.515 0 -76497.515 0.023740253 152161.17
10700 0 -76497.515 0 -76497.515 -0.00042210994 152161.17
10800 0 -76497.515 0 -76497.515 -0.052015823 152161.17
10862 0 -76460.842 0 -76460.842 -333.15531 152161.17
Loop time of 123.104 on 32 procs for 8433 steps with 8640 atoms

80.8% CPU use with 32 MPI tasks x 1 OpenMP threads

Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-76497.3279363 -76497.5147972 -76460.8424556

From a pretty well converged value of the energy the output jumps to a higher value in the last step.

I am using gcc version 4.4.5 and openmpi. I am trying to find out if that is just when fix box/relax is used.

Thanks,

Enrique

in.gamma-surf (2.68 KB)

out (6.8 MB)

S9-110-W-SMALL-MIN.data (308 KB)

WHe_Acklandmod_Juslin_fixed.eam (418 KB)

enrique,

this input deck requires a very long time to run. this makes debugging
near impossible.
do you think you could manufacture some input that runs faster? it
doesn't have to produce meaningful results, just reproduce the issue.

also, you might want to try running a test with the latest patch.
we've been systematically auditing different parts of LAMMPS with
static code analysis tools and incrementally added changes to address
the issues reported. this is a bit of a long shot, but it may just be
that one of them solves the problem you are seeing.

thanks,
axel.

Yeah,

I know it will be hard to track with the run I sent. I’ll try to find something easier but it seems like the issue is subtle and does not show up that often.
I just pull the latest version and I’ll try with it to see if I can reproduce the error.

Thanks,
Enrique

Hi Enrique,

This rings a bell alright. I suspect it has something to do with how fix box/relax works. I looked at your output file and observed that the increases in energy on the last step only occur when fix box/relax is used. Also, it only happens 29 times out of 230 runs. Finally, there seem to be to distinct non-zero values of the pressure occurring: ~-400 (13 times) and ~-335 (16 times) e.g.

41700 0 -76498.327 0 -76498.327 0.020841973 152163.74
41747 0 -76455.626 0 -76455.626 -400.20929 152163.74

8000 0 -76497.016 0 -76497.016 0.01963703 152165.9
8071 0 -76460.332 0 -76460.332 -335.14861 152165.92

I suspect that the final geometry is unchanged, but the energy and pressure calculation is somehow incorrect. You could verify this by reading back in the dump file. I bet you will see energy and pressure very close to the previous step. If you are going to be running this type of simulation again, you could also follow the final minimize with a ‘run 0’ command, to get the true energy. That way, I predict you will always get a good value for ${ener}. As Axel said, in order to fully track this down, we would need a smaller example.

Aidan

Hi Aidan,

I agree, the problem seems to be in box/relax. I have used the last pulled version and the results are the same. You are right in your diagnostics so I’ll try the run 0, that should work. And I’ll try to find something more tractable so it is easier to debug.

Thanks guys,
Enrique