Fix issues exposed by running pair style unit tests with pair_modify nofdotr

[akohlmey]

Summary

Pair styles frequently use F dot r to determine the (global) virial and thus compute pressure. However, for computing per-atom stress this is accumulated for each pair. In addition there is the command pair_modify nofdotr to enforce that code path, even when no per-atom stress is requested. Of course those two code paths are supposed to produce the same results within the level possible by floating-point math. This pull request attempts to fix or flag situations where there is currently a discrepancy.
Also a corresponding check was added to the unit test tool for pair styles.

Related Issue(s)

This was detected while working on PR #2708

Author(s)

Aidan Thompson, SNL and Axel Kohlmeyer, Temple U

Licensing

By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under either the GNU General Public License version 2 (GPL v2) or the GNU Lesser General Public License version 2.1 (LGPL v2.1).

Backward Compatibility

Some setups that would previously run and produce erroneous results may abort now.

Implementation Notes

The basic fix to correct the behavior is that tallying of the virial needs to be done for either vflag_global or vflag_atom, i.e. the test should be for vflag_either and corresponding the the v_tally*() or ev_tally*() functions need to compute the virial contribution for either case and then tally it to either the global or per-atom accumulators. For the OPENMP versions this requires changing the API so that the pointer to the "pair" class is passed along so that the various flags set by Pair::ev_init() are accessible.

Beyond that, some pair styles had typos, were missing a call to a matching tally function or had a sign error on the arguments to the tally function. For the MEAM package the tallying had to be done manually and thus API for meam_force() changed accordingly.

Pair styles affected (checked items have a fix in this PR):

• buck/intel
• buck/coul/long/intel
• lj/charmm/coul/chamm/intel
• lj/charmm/coul/long/intel
• eam/intel (and variants)
• edip/omp
• meam
• polymorphic
• reax/c (will be corrected in PR Refactoring and improving REAXFF and QEQ packages #2708)
• reax/c/omp (will be corrected in PR Refactoring and improving REAXFF and QEQ packages #2708)
• airebo (and variants)
• airebo/omp (and variants)
• bop
• comb
• comb/omp
• comb3
• extep
• gw (and variants)
• lcbop
• tersoff (and variants)
• tersoff/omp (and variants)
• tersoff/table/omp
• rann

This also include several peripheral fixes:

• USER-INTEL pair styles did not use nighbor->find_request(this) to look up existing neighbor list requests.
• detect the new LLVM based Intel compilers alongside the old Intel compilers in CMake scripts
• an uninitialized data access fix in a unit test tool

Post Submission Checklist

• The feature or features in this pull request is complete
• Licensing information is complete
• Corresponding author information is complete
• The source code follows the LAMMPS formatting guidelines
• Suitable new documentation files and/or updates to the existing docs are included
• The added/updated documentation is integrated and tested with the documentation build system
• The feature has been verified to work with the conventional build system
• The feature has been verified to work with the CMake based build system
• Suitable tests have been added to the unittest tree.

[sjplimp]

@akohlmey @athomps These are all INTEL package pair styles? Should Mike Brown be a reviewer on this?

[akohlmey]

@akohlmey @athomps These are all INTEL package pair styles? Should Mike Brown be a reviewer on this?

Not "all", only the first few. But it is pointless to try and fix them in USER-INTEL when the core code doesn't address the problem consistently for all non-accelerated pair styles. Also, for USER-INTEL the fix is often to check and error out, since many of them do not tally per-atom stress at all (for performance reasons).

[akohlmey]

@athomps this is now almost complete. The only pending issue are the INTEL package specific failures, which are likely due to a limitation caused by the optimizations therein. Those pair styles don't support per-atom stress, for example. So I may have to address those in the tester tool rather than in the pair styles themselves.

[athomps]

Great work. I approve.