There are some confusions when use “compute stress/atom” at Windows version

Dear all,

we have try many times the last 2 columns of thermo output are not the same. The “v_prerss” may be thousands of times larger than the “perss”, the results in Linux and windows versions are inconsistent, and the gap is close to three orders. For example the press is about -3970.1197, but it will be 287559.69 which calculated by windows versions.

log.lammps_LAMMPS (8 Feb 2019) for windows.txt (26.5 KB)

log.lammps_LAMMPS (12 Dec 2018)for linux.txt (4 KB) (248 KB)

it is highly unlikely, that it is a Windows vs. Linux issue.

you are not really comparing the same thing here, since you are comparing output of a run with the omp suffix and OpenMP enabled against a compilation without any OpenMP support. those will execute different code paths. what happens on windows, if you do not use the omp suffix and the -pk omp command line flag?


thank you very much.
There have a detail describe, we found the main reason is the use of OpenMP multi-threading. But don’t know how to do with it.

neither do i, and i wrote most of the USER-OMP package code. but not reax/c/omp code and that uses the threadsafe functions in the USER-OMP package in unusual ways. this is not easy to untangle. global energy and stress are working as does per-atom energy, but the per-atom stress will either leave out some contributions or double count others for a variety of options and workarounds that i have tried.

also, there is not much of a point in repeating information from github here, since i am “@akohlmey” on github and well aware of what is going on there, since i am largely taking care of overseeing the LAMMPS project on github.

i simply responded here on the mailing list, to point out that your evidence did not support your conclusion (that the windows version is broken and linux is not).
for now, the only solution is to stop with an error when per-atom stress is requested for pair style reax/c/omp. i will implement the corresponding code and it will be included in the next patch release.



the temporary solution is to avoid using OpenMP and use either the serial version of LAMMPS or the MPI version, but not the omp suffix or the omp package.