Repository: lammps/lammps
Pull request #4594: Collected small changes
Author: login: akohlmey
Labels: name: enhancement
name: documentation
name: library_interface
name: examples
Created: 2025-05-13T10:45:48Z | Merged: 2025-05-20T02:13:37Z

**Summary**

This pull request combines multiple small changes and fixes that don't justify a pull request on their own.

**Related Issue(s)**

Closes #4592
Closes #4595 

**Author(s)**

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**

The sign of *dx*, *dy*, and *dz* in `compute bond/local` and `compute pair/local` is no longer determined by their atom IDs but by their order in the bond-list or neighbor-list.
This is for consistency with *fx*, *fy*, *fz*. The respective atom IDs can by obtained
with `compute property/local`.

**Implementation Notes**

The following individual changes are included:
- make `eflag_global`, `eflag_atom`, `vflag_global`, and `vflag_atom` of the `Update` class accessible through the C-library interface
- enable the PotentialFileReader class to adjust the line buffer size of the internal TextFileReader class instance
- documentation updates
- add section about OPC water model (used by the latest Amber force field revision) to TIP4P howto
- add generic section about conventional force field to BioFF Howto section
- update outdated fix imd examples with GPU acceleration (after being unchanged for 15 years)
- delete a couple assignments to self in KOKKOS
- avoid type clash with constant string argument for some MPI implementations in LATBOLTZ package
- correct check for 32-bit integer overflow in `compute podd/atom`
- includes PR #4595
- remove directionCorrection from `compute bond/local` and `compute pair/local` according to discussion below

**Post Submission Checklist**

- [ ] The feature or features in this pull request is complete
- [x] Licensing information is complete
- [x] Corresponding author information is complete
- [x] The source code follows the LAMMPS formatting guidelines
- [x] Suitable new documentation files and/or updates to the existing docs are included
- [x] The added/updated documentation is integrated and tested with the documentation build system
- [x] The feature has been verified to work with the conventional build system
- [x] The feature has been verified to work with the CMake based build system
- [x] Suitable tests have been added to the unittest tree.


Linked issue #4592: [Feature Request] expose `eflag` and `vflag` to C-API for fix external
**Summary**

Currently its not possible to know wheter the virial or energy contributions of a fix external are required for the current timestep, as `eflag` and `vflag` are not exposed through the C-API. Exposing these flags would make it possible to only calculate the energies and virials in the callback in fix external for the timesteps where they are actually needed.

**Detailed Description**

One possible way to do this would be to make `vflag` and `eflag` available through `lammps_extract_setting` or `lammps_extract_global`, if these flags are indeed a global value (which I'm not sure is the case).

Another approach would be to extend the api with functions that may look like this:
```C
double *lammps_fix_external_get_virial_global(void *handle, const char *id, int *vflag_global)
double **lammps_fix_external_get_virial_atom(void *handle, const char *id, int *vflag_atom)
double *lammps_fix_external_get_energy_global(void *handle, const char *id, int *eflag_global)
double *lammps_fix_external_get_energy_atom(void *handle, const char *id, int *eflag_atom)
```
These would then return pointers to `user_virial`, `vatom`, `user_energy`, and `eatom`, respectively, and also set the corresponding flag. This would also eliminate a few unecessary copy operations.
Linked issue comments: user: login: akohlmey
created_at: 2025-05-12T15:57:01Z
body: Both `eflag` and `vflag` are bitmasks. Exporting them would also require to export the corresponding constants for the bits, and that is not something desirable.

What can be exported rather easily are `eflag_global`, `eflag_atom`, `vflag_global`, and `vflag_atom` from the `Update` class, which are set to the timestep where these properties are requested. See `update.h`.

> Another approach would be to extend the api with functions that may look like this

I would like to avoid adding 4 more special purpose APIs for a single niche functionality.

> and also set the corresponding flag

What do you mean by that? It would be a bad choice to have a "getter" function set something.
author_association: MEMBER
user: login: Joroks
created_at: 2025-05-13T06:11:20Z
body: Thanks! Exposing these flags through `lammps_extract_setting` or `lammps_extract_global` is a solution I'm perfectly happy with!

> I would like to avoid adding 4 more special purpose APIs for a single niche functionality.

The reason that I've suggested adding these new functions is that  currently, the following functions are used to set the peratom virial and energy:
```C
lammps_fix_external_set_energy_peratom()
lammps_fix_external_set_virial_peratom()
```
Which from my perspective is a bit unfortunate, as I have to allocate my own temporary memory and zero it out, which at the end just gets copied anyways. Directly having access to `vatom` and `eatom` would reduce these minor inefficiencies.
However, I fully understand, why you would not want to introduce more API functions that, apart from these minor inconveniences, duplicate the behavoir of already existing API functions.

> What do you mean by that? It would be a bad choice to have a "getter" function set something.

Yes, I agree with that. In that case the signature *would* just be something like this:
```C
double **lammps_fix_external_extract_virial_atom(void *handle, const char *id)
double *lammps_fix_external_extract_energy_atom(void *handle, const char *id)
```
Again, I'm not expecting you to actually implement this (although it would be nice).
author_association: NONE

Diff:
diff --git a/doc/src/Howto.rst b/doc/src/Howto.rst
index ec90472c274..cdc4efd7373 100644
--- a/doc/src/Howto.rst
+++ b/doc/src/Howto.rst
@@ -66,6 +66,7 @@ Force fields howto
    :name: force_howto
    :maxdepth: 1
 
+   Howto_FFgeneral
    Howto_bioFF
    Howto_amoeba
    Howto_tip3p
diff --git a/doc/src/Howto_FFgeneral.rst b/doc/src/Howto_FFgeneral.rst
new file mode 100644
index 00000000000..1b96ae11197
--- /dev/null
+++ b/doc/src/Howto_FFgeneral.rst
@@ -0,0 +1,55 @@
+Some general force field considerations
+=======================================
+
+A compact summary of the concepts, definitions, and properties of force
+fields with explicit bonded interactions (like the ones discussed in
+this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
+
+A force field has 2 parts: the formulas that define its potential
+functions and the coefficients used for a particular system.  To assign
+parameters it is first required to assign atom types.  Those are not
+only based on the elements, but also on the chemical environment due to
+the atoms bound to them.  This often follows the chemical concept of
+*functional groups*.  Example: a carbon atom bound with a single bond to
+a single OH-group (alcohol) would be a different atom type than a carbon
+atom bound to a methyl CH3 group (aliphatic carbon).  The atom types
+usually then determine the non-bonded Lennard-Jones parameters and the
+parameters for bonds, angles, dihedrals, and impropers.  On top of that,
+partial charges have to be applied.  Those are usually independent of
+the atom types and are determined either for groups of atoms called
+residues with some fitting procedure based on quantum mechanical
+calculations, or based on some increment system that add or subtract
+increments from the partial charge of an atom based on the types of
+the neighboring atoms.
+
+Force fields differ in the strategies they employ to determine the
+parameters and charge distribution in how generic or specific they are
+which in turn has an impact on the accuracy (compare for example
+CGenFF to CHARMM and GAFF to Amber).  Because of the different
+strategies, it is not a good idea to use a mix of parameters from
+different force field *families* (like CHARMM, Amber, or GROMOS)
+and that extends to the parameters for the solvent, especially
+water.  The publication describing the parameterization of a force
+field will describe which water model to use.  Changing the water
+model usually leads to overall worse results (even if it may improve
+on the water itself).
+
+In addition, one has to consider that *families* of force fields like
+CHARMM, Amber, OPLS, or GROMOS have evolved over time and thus provide
+different *revisions* of the force field parameters.  These often
+corresponds to changes in the functional form or the parameterization
+strategies.  This may also result in changes required for simulation
+settings like the preferred cutoff or how Coulomb interactions are
+computed (cutoff, smoothed/shifted cutoff, or long-range with Ewald
+summation or equivalent).  Unless explicitly stated in the publication
+describing the force field, the Coulomb interaction cannot be chosen at
+will but must match the revision of the force field.  That said,
+liberties may be taken during the initial equilibration of a system to
+speed up the process, but not for production simulations.
+
+----------
+
+.. _Typelabel2:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
+
diff --git a/doc/src/Howto_bioFF.rst b/doc/src/Howto_bioFF.rst
index 92dd45b9b63..cf8e4ab13e6 100644
--- a/doc/src/Howto_bioFF.rst
+++ b/doc/src/Howto_bioFF.rst
@@ -1,22 +1,16 @@
 CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
 =======================================================
 
-A compact summary of the concepts, definitions, and properties of
-force fields with explicit bonded interactions (like the ones discussed
-in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
-
-A force field has 2 parts: the formulas that define it and the
-coefficients used for a particular system.  Here we only discuss
-formulas implemented in LAMMPS that correspond to formulas commonly used
-in the CHARMM, AMBER, COMPASS, and DREIDING force fields.  Setting
-coefficients is done either from special sections in an input data file
-via the :doc:`read_data <read_data>` command or in the input script with
-commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
-<bond_coeff>` and so on.  See the :doc:`Tools <Tools>` doc page for
-additional tools that can use CHARMM, AMBER, or Materials Studio
-generated files to assign force field coefficients and convert their
-output into LAMMPS input. LAMMPS input scripts can also be generated by
-`charmm-gui.org <https://charmm-gui.org/>`_.
+Here we only discuss formulas implemented in LAMMPS that correspond to
+formulas commonly used in the CHARMM, AMBER, COMPASS, and DREIDING force
+fields.  Setting coefficients is done either from special sections in an
+input data file via the :doc:`read_data <read_data>` command or in the
+input script with commands like :doc:`pair_coeff <pair_coeff>` or
+:doc:`bond_coeff <bond_coeff>` and so on.  See the :doc:`Tools <Tools>`
+doc page for additional tools that can use CHARMM, AMBER, or Materials
+Studio generated files to assign force field coefficients and convert
+their output into LAMMPS input. LAMMPS input scripts can also be
+generated by `charmm-gui.org <https://charmm-gui.org/>`_.
 
 CHARMM and AMBER
 ----------------
@@ -203,9 +197,11 @@ rather than individual force constants and geometric parameters that
 depend on the particular combinations of atoms involved in the bond,
 angle, or torsion terms.  DREIDING has an :doc:`explicit hydrogen bond
 term <pair_hbond_dreiding>` to describe interactions involving a
-hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM
-or AMBER, the DREIDING force field has not been parameterized for
-considering solvents (like water).
+hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM or
+AMBER, the DREIDING force field has not been parameterized for
+considering solvents (like water) and has no rules for assigning
+(partial) charges.  That will seriously limit its accuracy when used for
+simulating systems where those matter.
 
 See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
 
@@ -272,10 +268,6 @@ compatible with a subset of OPLS interactions.
 
 ----------
 
-.. _Typelabel2:
-
-**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
-
 .. _howto-MacKerell:
 
 **(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998).  J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f
diff --git a/doc/src/Howto_spc.rst b/doc/src/Howto_spc.rst
index 00bd8a1b10d..f84d7797d2f 100644
--- a/doc/src/Howto_spc.rst
+++ b/doc/src/Howto_spc.rst
@@ -1,5 +1,5 @@
-SPC water model
-===============
+SPC and SPC/E water model
+=========================
 
 The SPC water model specifies a 3-site rigid water molecule with
 charges and Lennard-Jones parameters assigned to each of the three atoms.
diff --git a/doc/src/Howto_tip4p.rst b/doc/src/Howto_tip4p.rst
index 47a1b9b5787..76c470d6159 100644
--- a/doc/src/Howto_tip4p.rst
+++ b/doc/src/Howto_tip4p.rst
@@ -1,5 +1,5 @@
-TIP4P water model
-=================
+TIP4P and OPC water models
+==========================
 
 The four-point TIP4P rigid water model extends the traditional
 :doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
@@ -9,9 +9,11 @@ the oxygen along the bisector of the HOH bond angle.  A bond style of
 :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
 <angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
 In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
-style :doc:`zero <angle_zero>` can be used.
+style :doc:`zero <angle_zero>` can be used.  Very similar to the TIP4P
+model is the OPC water model.  It can be realized the same way as TIP4P
+but has different geometry and force field parameters.
 
-There are two ways to implement TIP4P water in LAMMPS:
+There are two ways to implement TIP4P-like water in LAMMPS:
 
 #. Use a specially written pair style that uses the :ref:`TIP3P geometry
    <tip3p_molecule>` without the point M. The point M location is then
@@ -21,7 +23,10 @@ There are two ways to implement TIP4P water in LAMMPS:
    computationally very efficient, but the charge distribution in space
    is only correct within the tip4p labeled styles.  So all other
    computations using charges will "see" the negative charge incorrectly
-   on the oxygen atom.
+   located on the oxygen atom unless they are specially written for using
+   the TIP4P geometry internally as well, e.g. :doc:`compute dipole/tip4p
+   <compute_dipole>`, :doc:`fix efield/tip4p <fix_efield>`, or
+   :doc:`kspace_style pppm/tip4p <kspace_style>`.
 
    This can be done with the following pair styles for Coulomb with a cutoff:
 
@@ -68,77 +73,90 @@ TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
 parameters adjusted for use with a long-range Coulombic solver
 (e.g. Ewald or PPPM in LAMMPS).  Note that for implicit TIP4P models the
 OM distance is specified in the :doc:`pair_style <pair_style>` command,
-not as part of the pair coefficients.
+not as part of the pair coefficients. Also parameters for the OPC
+model (:ref:`Izadi <Izadi>`) are provided.
 
 .. list-table::
       :header-rows: 1
-      :widths: 36 19 13 15 17
+      :widths: 40 12 12 14 11 11
 
       * - Parameter
         - TIP4P (original)
         - TIP4P/Ice
         - TIP4P/2005
         - TIP4P (Ewald)
+        - OPC
       * - O mass (amu)
         - 15.9994
         - 15.9994
         - 15.9994
         - 15.9994
+        - 15.9994
       * - H mass (amu)
         - 1.008
         - 1.008
         - 1.008
         - 1.008
+        - 1.008
       * - O or M charge (:math:`e`)
         - -1.040
         - -1.1794
         - -1.1128
         - -1.04844
+        - -1.3582
       * - H charge (:math:`e`)
         - 0.520
         - 0.5897
         - 0.5564
         - 0.52422
+        - 0.6791
       * - LJ :math:`\epsilon` of OO (kcal/mole)
         - 0.1550
         - 0.21084
         - 0.1852
         - 0.16275
+        - 0.21280
       * - LJ :math:`\sigma` of OO (:math:`\AA`)
         - 3.1536
         - 3.1668
         - 3.1589
         - 3.16435
+        - 3.1660
       * - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
         - 0.0
         - 0.0
         - 0.0
         - 0.0
+        - 0.0
       * - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
         - 1.0
         - 1.0
         - 1.0
         - 1.0
+        - 1.0
       * - :math:`r_0` of OH bond (:math:`\AA`)
         - 0.9572
         - 0.9572
         - 0.9572
         - 0.9572
+        - 0.8724
       * - :math:`\theta_0` of HOH angle
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
+        - 103.60\ :math:`^{\circ}`
       * - OM distance (:math:`\AA`)
         - 0.15
         - 0.1577
         - 0.1546
         - 0.1250
+        - 0.1594
 
-Note that the when using the TIP4P pair style, the neighbor list cutoff
+Note that the when using a TIP4P pair style, the neighbor list cutoff
 for Coulomb interactions is effectively extended by a distance 2 \* (OM
 distance), to account for the offset distance of the fictitious charges
-on O atoms in water molecules.  Thus it is typically best in an
+on O atoms in water molecules.  Thus, it is typically best in an
 efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
 distance), to shrink the size of the neighbor list.  This leads to
 slightly larger cost for the long-range calculation, so you can test the
@@ -192,6 +210,94 @@ file changed):
     run 20000
     write_data tip4p-implicit.data nocoeff
 
+When constructing an OPC model, we cannot use the ``tip3p.mol`` file due
+to the different geometry.  Below is a molecule file providing the 3
+sites of an implicit OPC geometry for use with TIP4P styles.  Note, that
+the "Shake" and "Special" sections are missing here.  Those will be
+auto-generated by LAMMPS when the molecule file is loaded *after* the
+simulation box has been created.  These sections are required only when
+the molecule file is loaded *before*.
+
+.. _opc3p_molecule:
+.. code-block::
+
+   # Water molecule. 3 point geometry for OPC model
+
+   3 atoms
+   2 bonds
+   1 angles
+
+   Coords
+
+   1    0.00000  -0.06037   0.00000
+   2    0.68558   0.50250   0.00000
+   3   -0.68558   0.50250   0.00000
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+
+   Charges
+
+   1       -1.3582
+   2        0.6791
+   3        0.6791
+
+   Bonds
+
+   1   1      1      2
+   2   1      1      3
+
+   Angles
+
+   1   1      2      1      3
+
+Below is a LAMMPS input file using the implicit method to implement
+the OPC model using the molecule file from above and including the
+PPPM long-range Coulomb solver.
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style full
+    region box block -5 5 -5 5 -5 5
+    create_box 2 box bond/types 1 angle/types 1 &
+                extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
+
+    mass 1 15.9994
+    mass 2 1.008
+
+    pair_style lj/cut/tip4p/long 1 2 1 1 0.1594 12.0
+    pair_coeff 1 1 0.2128 3.166
+    pair_coeff 2 2 0.0    1.0
+
+    bond_style zero
+    bond_coeff 1 0.8724
+
+    angle_style zero
+    angle_coeff 1 103.6
+
+    kspace_style pppm/tip4p 1.0e-5
+
+    molecule water opc3p.mol  # this file has the OPC geometry but is without M
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+    fix rigid all shake 0.001 10 10000 b 1 a 1
+    minimize 0.0 0.0 1000 10000
+
+    reset_timestep 0
+    timestep 1.0
+    velocity all create 300.0 5463576
+    fix integrate all nvt temp 300 300 100.0
+
+    thermo_style custom step temp press etotal pe
+
+    thermo 1000
+    run 20000
+    write_data opc-implicit.data nocoeff
+
 Below is the code for a LAMMPS input file using the explicit method and
 a TIP4P molecule file.  Because of using :doc:`fix rigid/small
 <fix_rigid>` no bonds need to be defined and thus no extra storage needs
@@ -279,3 +385,8 @@ Phys, 79, 926 (1983).
 
 **(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
    https://doi.org/10.1063/1.2121687
+
+.. _Izadi:
+
+**(Izadi)** Izadi, Anandakrishnan, Onufriev, J. Phys. Chem. Lett., 5, 21, 3863 (2014)
+   https://doi.org/10.1021/jz501780a
diff --git a/doc/src/Intro_authors.rst b/doc/src/Intro_authors.rst
index 38f1102595d..730cd2e336d 100644
--- a/doc/src/Intro_authors.rst
+++ b/doc/src/Intro_authors.rst
@@ -84,8 +84,9 @@ lammps.org".  General questions about LAMMPS should be posted in the
 
    \normalsize
 
-Past developers include Paul Crozier and Mark Stevens, both at SNL,
-and Ray Shan, now at Materials Design.
+Past core developers include Paul Crozier and Mark Stevens, both at SNL,
+and Ray Shan while at SNL and later at Materials Design, now at Thermo
+Fisher Scientific.
 
 ----------
 
diff --git a/doc/src/Intro_portability.rst b/doc/src/Intro_portability.rst
index 63ae147b8c1..564cdc47f4a 100644
--- a/doc/src/Intro_portability.rst
+++ b/doc/src/Intro_portability.rst
@@ -28,8 +28,9 @@ Build systems
 LAMMPS can be compiled from source code using a (traditional) build
 system based on shell scripts, a few shell utilities (grep, sed, cat,
 tr) and the GNU make program. This requires running within a Bourne
-shell (``/bin/sh``).  Alternatively, a build system with different back
-ends can be created using CMake.  CMake must be at least version 3.16.
+shell (``/bin/sh`` or ``/bin/bash``).  Alternatively, a build system
+with different back ends can be created using CMake.  CMake must be
+at least version 3.16.
 
 Operating systems
 ^^^^^^^^^^^^^^^^^
@@ -40,11 +41,18 @@ Also, compilation and correct execution on macOS and Windows (using
 Microsoft Visual C++) is checked automatically for the largest part of
 the source code.  Some (optional) features are not compatible with all
 operating systems, either through limitations of the corresponding
-LAMMPS source code or through incompatibilities of source code or
-build system of required external libraries or packages.
+LAMMPS source code or through incompatibilities or build system
+limitations of required external libraries or packages.
 
-Executables for Windows may be created natively using either Cygwin or
-Visual Studio or with a Linux to Windows MinGW cross-compiler.
+Executables for Windows may be created either natively using Cygwin,
+MinGW, Intel, Clang, or Microsoft Visual C++ compilers, or with a Linux
+to Windows MinGW cross-compiler.  Native compilation is supported using
+Microsoft Visual Studio or a terminal window (using the CMake build
+system).
+
+Executables for macOS may be created either using Xcode or GNU compilers
+installed with Homebrew.  In the latter case, building of LAMMPS through
+Homebrew instead of a manual compile is also possible.
 
 Additionally, FreeBSD and Solaris have been tested successfully to
 run LAMMPS and produce results consistent with those on Linux.
@@ -61,8 +69,9 @@ CPU architectures
 ^^^^^^^^^^^^^^^^^
 
 The primary CPU architecture for running LAMMPS is 64-bit x86, but also
-32-bit x86, and 64-bit ARM and PowerPC (64-bit, Little Endian) are
-regularly tested.
+64-bit ARM and PowerPC (64-bit, Little Endian) are currently regularly
+tested.  Further architectures are tested by Linux distributions that
+bundle LAMMPS.
 
 Portability compliance
 ^^^^^^^^^^^^^^^^^^^^^^
diff --git a/doc/src/compute_bond_local.rst b/doc/src/compute_bond_local.rst
index e070d507b10..7ce6f9b15a9 100644
--- a/doc/src/compute_bond_local.rst
+++ b/doc/src/compute_bond_local.rst
@@ -64,20 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
+the force on the first atom *i* in the bond due to the second atom *j*.
+Mathematically, they are obtained by multiplying the value of *force*
+from above with a unit vector created from the *dx*, *dy*, and *dz*
+components of the distance vector also described above.  For bond styles
+that apply non-central forces, such as :doc:`bond_style bpm/rotational
 <bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
 components of the normal force component.
 
diff --git a/doc/src/compute_pair_local.rst b/doc/src/compute_pair_local.rst
index 31209f63f49..605bfc8e9ea 100644
--- a/doc/src/compute_pair_local.rst
+++ b/doc/src/compute_pair_local.rst
@@ -56,19 +56,33 @@ force cutoff distance for that interaction, as defined by the
 :doc:`pair_style <pair_style>` and :doc:`pair_coeff <pair_coeff>`
 commands.
 
-The value *dist* is the distance between the pair of atoms.
-The values *dx*, *dy*, and *dz* are the :math:`(x,y,z)` components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of higher to the one with the lower atom ID.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the value of
+   their atom-IDs but by their order in the neighbor list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the distance between the pair of atoms.  The values
+*dx*, *dy*, and *dz* are the :math:`(x,y,z)` components of the distance
+vector :math:`\vec{x_i} - \vec{x_j}` between the pair of atoms.  The
+order of the atoms is determined by the neighbor list and the respective
+atom-IDs can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *eng* is the interaction energy for the pair of atoms.
 
 The value *force* is the force acting between the pair of atoms, which
 is positive for a repulsive force and negative for an attractive
-force.  The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
-*force* on atom I. For pair styles that apply non-central forces,
-such as :doc:`granular pair styles <pair_gran>`, these values only include
-the :math:`(x,y,z)` components of the normal force component.
+force.
+
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
+the force vector on the first atom *i* of a pair in the neighbor list
+due to the second atom *j*.  Mathematically, they are obtained by
+multiplying the value of *force* from above with a unit vector created
+from the *dx*, *dy*, and *dz* components of the distance vector also
+described above.  For pair styles that apply non-central forces, such as
+:doc:`granular pair styles <pair_gran>`, these values only include the
+:math:`(x,y,z)` components of the normal force component.
 
 A pair style may define additional pairwise quantities which can be
 accessed as *p1* to *pN*, where :math:`N` is defined by the pair style.
diff --git a/doc/utils/sphinx-config/false_positives.txt b/doc/utils/sphinx-config/false_positives.txt
index c81be91cbeb..c87637a26e5 100644
--- a/doc/utils/sphinx-config/false_positives.txt
+++ b/doc/utils/sphinx-config/false_positives.txt
@@ -103,6 +103,7 @@ Amit
 amsmath
 amu
 Amzallag
+Anandakrishnan
 analytical
 Anders
 Andric
@@ -397,6 +398,7 @@ Broglie
 brownian
 brownw
 Broyden
+Bruenger
 Bruskin
 Brusselle
 Bryantsev
@@ -1731,6 +1733,7 @@ Iyz
 iz
 izcm
 ized
+Izadi
 Izrailev
 Izumi
 Izvekov
@@ -2807,6 +2810,7 @@ oneMKL
 oneway
 onlysalt
 ons
+Onufriev
 OO
 Oord
 opencl
diff --git a/examples/PACKAGES/imd/in.bucky-plus-cnt b/examples/PACKAGES/imd/in.bucky-plus-cnt
index b3eeff3cc1a..af511fe11f9 100644
--- a/examples/PACKAGES/imd/in.bucky-plus-cnt
+++ b/examples/PACKAGES/imd/in.bucky-plus-cnt
@@ -46,8 +46,8 @@ fix     integrate   mobile nve
 fix     thermostat  mobile langevin 300.0 300.0 2000.0 234624
 
 # IMD setup.
-fix  comm       all imd 6789 unwrap on trate 10
-#fix  comm       all imd 6789 unwrap on trate 10 nowait on
+#fix  comm       all imd 6789 unwrap on trate 10
+fix  comm       all imd 6789 unwrap on trate 10 nowait on
 
 # temperature is based on mobile atoms only
 compute mobtemp mobile temp
diff --git a/examples/PACKAGES/imd/in.bucky-plus-cnt-gpu b/examples/PACKAGES/imd/in.bucky-plus-cnt-gpu
index 5762ec68c8f..f3e4b32cdc9 100644
--- a/examples/PACKAGES/imd/in.bucky-plus-cnt-gpu
+++ b/examples/PACKAGES/imd/in.bucky-plus-cnt-gpu
@@ -1,16 +1,20 @@
 # stick a buckyball into a nanotube
+
+# enable GPU package from within the input:
+package gpu 0 pair/only on
+suffix gpu
+
 units           real
 dimension       3
 boundary       f f f
 atom_style      molecular
-newton          off
 
 processors * * 1
 
 # read topology 
 read_data       data.bucky-plus-cnt
 
-pair_style  lj/cut/gpu  10.0
+pair_style  lj/cut  10.0
 bond_style  harmonic
 angle_style charmm
 dihedral_style charmm
@@ -29,9 +33,6 @@ neigh_modify    delay 0 every 1 check yes
 
 timestep        2.0
 
-# required for GPU acceleration
-fix   gpu  all      gpu  force 0 0 1.0
-
 # we only move some atoms.
 group mobile type 1
 
@@ -49,8 +50,8 @@ fix     integrate   mobile nve
 fix     thermostat  mobile langevin 300.0 300.0 2000.0 234624
 
 # IMD setup.
-fix  comm       all imd 6789 unwrap on trate 10
-#fix  comm       all imd 6789 unwrap on trate 10 nowait on
+#fix  comm       all imd 6789 unwrap on trate 10
+fix  comm       all imd 6789 unwrap on trate 10 nowait on
 
 # temperature is based on mobile atoms only
 compute mobtemp mobile temp
diff --git a/examples/PACKAGES/imd/in.deca-ala_imd-gpu b/examples/PACKAGES/imd/in.deca-ala_imd-gpu
index 72c3f4aae9a..9470f7c213f 100644
--- a/examples/PACKAGES/imd/in.deca-ala_imd-gpu
+++ b/examples/PACKAGES/imd/in.deca-ala_imd-gpu
@@ -1,8 +1,12 @@
-# 
+#
+
+# enable GPU package from within the input:
+package gpu 0 pair/only on
+suffix gpu
+
 units           real
 neighbor        2.5 bin
 neigh_modify    delay 1 every 1 
-newton          off
 
 atom_style      full
 bond_style      harmonic
@@ -10,20 +14,18 @@ angle_style     charmm
 dihedral_style  charmm
 improper_style  harmonic
 
-pair_style      lj/charmm/coul/long/gpu 8 10
+pair_style      lj/charmm/coul/long 8 10
 pair_modify     mix arithmetic
 special_bonds   charmm
 read_data       data.deca-ala-solv
 
-fix             0 all gpu force/neigh 0 0 1.0    
-
 group peptide   id <= 103
 fix             rigidh all shake 1e-6 100 1000 t 1 2 3 4 5 a 23
 
 thermo          100
 thermo_style    multi
 timestep        2.0
-kspace_style    pppm/gpu 1e-5
+kspace_style    pppm 1e-5
 
 fix             ensemble all npt temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0 drag 0.2
 
diff --git a/examples/PACKAGES/imd/in.melt_imd-gpu b/examples/PACKAGES/imd/in.melt_imd-gpu
index 24904eb832e..f1406befa63 100644
--- a/examples/PACKAGES/imd/in.melt_imd-gpu
+++ b/examples/PACKAGES/imd/in.melt_imd-gpu
@@ -1,30 +1,32 @@
-# 3d Lennard-Jones melt
+# 3d Lennard-Jones melt with GPU package acceleration
 
-units		lj
-atom_style	atomic
-newton      off
+# enable GPU package from within the input:
+package gpu 0
+suffix gpu
 
-lattice		fcc 0.8442
-region		box block 0 10 0 10 0 10
-create_box	1 box
-create_atoms	1 box
-mass		1 1.0
+units           lj
+atom_style      atomic
 
-velocity	all create 3.0 87287
+lattice         fcc 0.8442
+region          box block 0 10 0 10 0 10
+create_box      1 box
+create_atoms    1 box
+mass            1 1.0
 
-pair_style	lj/cut/gpu 2.5
-pair_coeff	1 1 1.0 1.0 2.5
+velocity        all create 3.0 87287
 
-neighbor	0.3 bin
-neigh_modify	every 5 delay 10 check yes
+pair_style      lj/cut 2.5
+pair_coeff      1 1 1.0 1.0 2.5
+
+neighbor        0.3 bin
+neigh_modify    every 5 delay 10 check yes
 
 thermo_style    custom step pe ke spcpu
 
-fix     0 all gpu force/neigh 0 0 1.0
-fix		1 all nve
+fix             1 all nve
 
 # IMD setup.
 fix  comm       all imd 5678 unwrap off fscale 20.0 trate 20 nowait on
 
-thermo		500
-run		5000000
+thermo          500
+run             5000000
diff --git a/src/KOKKOS/meam_dens_init_kokkos.h b/src/KOKKOS/meam_dens_init_kokkos.h
index dd63be96bdb..23985c70825 100644
--- a/src/KOKKOS/meam_dens_init_kokkos.h
+++ b/src/KOKKOS/meam_dens_init_kokkos.h
@@ -236,7 +236,6 @@ MEAMKokkos<DeviceType>::meam_dens_init(int inum_half, int ntype, typename AT::t_
   this->d_neighbors_half = d_neighbors_half;
   this->d_neighbors_full = d_neighbors_full;
   this->d_offset = d_offset;
-  this->nlocal = nlocal;
 
   if (need_dup) {
     dup_rho0 = Kokkos::Experimental::create_scatter_view<Kokkos::Experimental::ScatterSum, Kokkos::Experimental::ScatterDuplicated>(d_rho0);
diff --git a/src/KOKKOS/meam_force_kokkos.h b/src/KOKKOS/meam_force_kokkos.h
index 1875e22dcfe..703bee23d7e 100644
--- a/src/KOKKOS/meam_force_kokkos.h
+++ b/src/KOKKOS/meam_force_kokkos.h
@@ -17,7 +17,6 @@ void MEAMKokkos<DeviceType>::meam_force(
 {
   EV_FLOAT ev;
 
-  this->eflag_either = eflag_either;
   this->eflag_global = eflag_global;
   this->eflag_atom = eflag_atom;
   this->vflag_global = vflag_global;
diff --git a/src/KOKKOS/pair_kokkos.h b/src/KOKKOS/pair_kokkos.h
index 399142dfafc..63e637c108d 100644
--- a/src/KOKKOS/pair_kokkos.h
+++ b/src/KOKKOS/pair_kokkos.h
@@ -961,7 +961,7 @@ EV_FLOAT pair_compute_neighlist (PairStyle* fpair, std::enable_if_t<(NEIGHFLAG&P
       lastcall = fpair->lmp->update->ntimestep;
       vectorsize = GetMaxNeighs(list);
       if (vectorsize == 0) vectorsize = 1;
-      vectorsize = MathSpecial::powint(2,(int(log2(vectorsize) + 0.5))); // round to nearest power of 2
+      vectorsize = MathSpecial::powint(2.0,(int(log2(double(vectorsize)) + 0.5))); // round to nearest power of 2
 
   #if defined(KOKKOS_ENABLE_HIP)
       int max_vectorsize = 64;
diff --git a/src/LATBOLTZ/fix_lb_fluid.cpp b/src/LATBOLTZ/fix_lb_fluid.cpp
index 286b56cab51..d5161bba427 100644
--- a/src/LATBOLTZ/fix_lb_fluid.cpp
+++ b/src/LATBOLTZ/fix_lb_fluid.cpp
@@ -2344,7 +2344,7 @@ void FixLbFluid::SetupBuffers()
                   MPI_MODE_CREATE | MPI_MODE_WRONLY, MPI_INFO_NULL, &dump_file_handle_raw);
 
     MPI_File_set_size(dump_file_handle_raw, 0);
-    MPI_File_set_view(dump_file_handle_raw, 0, MPI_DOUBLE, dump_file_mpitype, "native",
+    MPI_File_set_view(dump_file_handle_raw, 0, MPI_DOUBLE, dump_file_mpitype, (char *)"native",
                       MPI_INFO_NULL);
   }
 }
diff --git a/src/ML-POD/compute_podd_atom.cpp b/src/ML-POD/compute_podd_atom.cpp
index 4ab6e233931..364bfb54acf 100644
--- a/src/ML-POD/compute_podd_atom.cpp
+++ b/src/ML-POD/compute_podd_atom.cpp
@@ -58,8 +58,8 @@ ComputePODDAtom::ComputePODDAtom(LAMMPS *lmp, int narg, char **arg) :
   pod = nullptr;
   elements = nullptr;
 
-  if (((((MAXBIGINT*3.0)*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
-    error->all(FLERR, "Per-atom data too large");
+  if ((((3.0*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
+      error->all(FLERR, "Too many atoms ({}) for compute {}", atom->natoms, style);
   size_peratom_cols = 3 * atom->natoms * podptr->Mdesc * podptr->nClusters;
   peratom_flag = 1;
 }
@@ -110,8 +110,8 @@ void ComputePODDAtom::compute_peratom()
   if (atom->natoms > nmax) {
     memory->destroy(pod);
     nmax = atom->natoms;
-    if (((((MAXBIGINT*3.0)*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
-      error->all(FLERR, "Per-atom data too large");
+    if ((((3.0*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
+      error->all(FLERR, "Too many atoms ({}) for compute {}", atom->natoms, style);
     int numdesc = 3 * atom->natoms * podptr->Mdesc * podptr->nClusters;
     memory->create(pod, nmax, numdesc,"podd/atom:pod");
     array_atom = pod;
diff --git a/src/compute_bond_local.cpp b/src/compute_bond_local.cpp
index e9632d254fa..6354c67638e 100644
--- a/src/compute_bond_local.cpp
+++ b/src/compute_bond_local.cpp
@@ -428,22 +428,19 @@ int ComputeBondLocal::compute_bonds(int flag)
           if (dstr) input->variable->internal_set(dvar, sqrt(rsq));
         }
 
-        // to make sure dx, dy and dz are always from the lower to the higher id
-        double directionCorrection = tag[atom1] > tag[atom2] ? -1.0 : 1.0;
-
         for (int n = 0; n < nvalues; n++) {
           switch (bstyle[n]) {
             case DIST:
               ptr[n] = sqrt(rsq);
               break;
             case DX:
-              ptr[n] = dx * directionCorrection;
+              ptr[n] = dx;
               break;
             case DY:
-              ptr[n] = dy * directionCorrection;
+              ptr[n] = dy;
               break;
             case DZ:
-              ptr[n] = dz * directionCorrection;
+              ptr[n] = dz;
               break;
             case ENGPOT:
               ptr[n] = engpot;
diff --git a/src/compute_pair_local.cpp b/src/compute_pair_local.cpp
index 57f15264f02..fa5d1648449 100644
--- a/src/compute_pair_local.cpp
+++ b/src/compute_pair_local.cpp
@@ -277,22 +277,19 @@ int ComputePairLocal::compute_pairs(int flag)
         else
           ptr = alocal[m];
 
-        // to make sure dx, dy and dz are always from the lower to the higher id
-        double directionCorrection = itag > jtag ? -1.0 : 1.0;
-
         for (n = 0; n < nvalues; n++) {
           switch (pstyle[n]) {
             case DIST:
               ptr[n] = sqrt(rsq);
               break;
             case DX:
-              ptr[n] = delx * directionCorrection;
+              ptr[n] = delx;
               break;
             case DY:
-              ptr[n] = dely * directionCorrection;
+              ptr[n] = dely;
               break;
             case DZ:
-              ptr[n] = delz * directionCorrection;
+              ptr[n] = delz;
               break;
             case ENG:
               ptr[n] = eng;
diff --git a/src/library.cpp b/src/library.cpp
index e6b14dafd3f..a8acbade524 100644
--- a/src/library.cpp
+++ b/src/library.cpp
@@ -1622,6 +1622,11 @@ int lammps_extract_global_datatype(void * /*handle*/, const char *name)
   if (strcmp(name,"neigh_dihedrallist") == 0) return LAMMPS_INT_2D;
   if (strcmp(name,"neigh_improperlist") == 0) return LAMMPS_INT_2D;
 
+  if (strcmp(name,"eflag_global") == 0) return LAMMPS_BIGINT;
+  if (strcmp(name,"eflag_atom") == 0) return LAMMPS_BIGINT;
+  if (strcmp(name,"vflag_global") == 0) return LAMMPS_BIGINT;
+  if (strcmp(name,"vflag_atom") == 0) return LAMMPS_BIGINT;
+
   if (strcmp(name,"map_style") == 0) return LAMMPS_INT;
 #if defined(LAMMPS_BIGBIG)
   if (strcmp(name,"map_tag_max") == 0) return LAMMPS_BIGINT;
@@ -1707,6 +1712,7 @@ report the "native" data type.  The following tables are provided:
 * :ref:`Simulation box settings <extract_box_settings>`
 * :ref:`System property settings <extract_system_settings>`
 * :ref:`Neighbor topology data <extract_neighbor_lists>`
+* :ref:`Energy and virial tally settings <extract_tally_settings>`
 * :ref:`Git revision and version settings <extract_git_settings>`
 * :ref:`Unit settings <extract_unit_settings>`
 
@@ -1984,6 +1990,35 @@ Get length of lists with :ref:`lammps_extract_setting() <extract_neighbor_settin
      - nimproperlist
      - list of impropers (atom1, atom2, atom3, atom4, type)
 
+.. _extract_tally_settings:
+
+**Energy and virial tally settings**
+
+.. list-table::
+   :header-rows: 1
+   :widths: 20 12 16 52
+
+   * - Name
+     - Type
+     - Length
+     - Description
+   * - eflag_global
+     - bigint
+     - 1
+     - timestep global energy is tallied on
+   * - eflag_atom
+     - bigint
+     - 1
+     - timestep per-atom energy is tallied on
+   * - vflag_global
+     - bigint
+     - 1
+     - timestep global virial is tallied on
+   * - vflag_atom
+     - bigint
+     - 1
+     - timestep per-atom virial is tallied on
+
 .. _extract_git_settings:
 
 **Git revision and version settings**
@@ -2194,10 +2229,15 @@ void *lammps_extract_global(void *handle, const char *name)
 
   if (strcmp(name,"q_flag") == 0) return (void *) &lmp->atom->q_flag;
 
-  if (strcmp(name,"neigh_bondlist") == 0) return lmp->neighbor->bondlist;
-  if (strcmp(name,"neigh_anglelist") == 0) return lmp->neighbor->anglelist;
-  if (strcmp(name,"neigh_dihedrallist") == 0) return lmp->neighbor->dihedrallist;
-  if (strcmp(name,"neigh_improperlist") == 0) return lmp->neighbor->improperlist;
+  if (strcmp(name,"neigh_bondlist") == 0) return (void *) lmp->neighbor->bondlist;
+  if (strcmp(name,"neigh_anglelist") == 0) return (void *) lmp->neighbor->anglelist;
+  if (strcmp(name,"neigh_dihedrallist") == 0) return (void *) lmp->neighbor->dihedrallist;
+  if (strcmp(name,"neigh_improperlist") == 0) return (void *) lmp->neighbor->improperlist;
+
+  if (strcmp(name,"eflag_global") == 0) return (void *) &lmp->update->eflag_global;
+  if (strcmp(name,"eflag_atom") == 0) return (void *) &lmp->update->eflag_atom;
+  if (strcmp(name,"vflag_global") == 0) return (void *) &lmp->update->vflag_global;
+  if (strcmp(name,"vflag_atom") == 0) return (void *) &lmp->update->vflag_atom;
 
   if (strcmp(name,"map_style") == 0) return (void *) &lmp->atom->map_style;
   if (strcmp(name,"map_tag_max") == 0) return (void *) &lmp->atom->map_tag_max;
diff --git a/src/potential_file_reader.cpp b/src/potential_file_reader.cpp
index 2a93a4a5242..7bac388ba00 100644
--- a/src/potential_file_reader.cpp
+++ b/src/potential_file_reader.cpp
@@ -86,11 +86,21 @@ PotentialFileReader::~PotentialFileReader()
 /** Set comment (= text after '#') handling preference for the file to be read
  *
  * \param   value   Comment text is ignored if true, or not if false */
+
 void PotentialFileReader::ignore_comments(bool value)
 {
   reader->ignore_comments = value;
 }
 
+/** Set line buffer size of the internal TextFileReader class instance.
+ *
+ * \param   bufsize   New size of the line buffer */
+
+void PotentialFileReader::set_bufsize(int bufsize)
+{
+  reader->set_bufsize(bufsize);
+}
+
 /** Reset file to the beginning */
 
 void PotentialFileReader::rewind()
diff --git a/src/potential_file_reader.h b/src/potential_file_reader.h
index c07b4b83f6d..534457a2f83 100644
--- a/src/potential_file_reader.h
+++ b/src/potential_file_reader.h
@@ -41,6 +41,7 @@ class PotentialFileReader : protected Pointers {
                       const int auto_convert = 0);
   ~PotentialFileReader() override;
 
+  void set_bufsize(int bufsize);
   void ignore_comments(bool value);
 
   void rewind();
diff --git a/src/read_data.cpp b/src/read_data.cpp
index 79d88148c57..cf7b224db22 100644
--- a/src/read_data.cpp
+++ b/src/read_data.cpp
@@ -174,13 +174,13 @@ void ReadData::command(int narg, char **arg)
         addflag = VALUE;
         bigint offset = utils::bnumeric(FLERR, arg[iarg + 1], false, lmp);
         if (offset > MAXTAGINT)
-          error->all(FLERR, "Read data add atomID offset {} is too big", offset);
+          error->all(FLERR, "Read data add IDoffset {} is too big", offset);
         id_offset = offset;
 
         if (atom->molecule_flag) {
           offset = utils::bnumeric(FLERR, arg[iarg + 2], false, lmp);
           if (offset > MAXTAGINT)
-            error->all(FLERR, "Read data add molID offset {} is too big", offset);
+            error->all(FLERR, "Read data add MOLoffset {} is too big", offset);
           mol_offset = offset;
           iarg++;
         }
diff --git a/src/reset_atoms_mol.cpp b/src/reset_atoms_mol.cpp
index 54d3bbcc763..363e2f08eb9 100644
--- a/src/reset_atoms_mol.cpp
+++ b/src/reset_atoms_mol.cpp
@@ -211,7 +211,7 @@ void ResetAtomsMol::reset()
 
     // if offset < 0 (default), reset it
     // if group = all, offset = 0
-    // else offset = largest molID of non-group atoms
+    // else offset = largest molecule ID of non-group atoms
 
     if (offset < 0) {
       if (groupbit != 1) {
diff --git a/src/text_file_reader.cpp b/src/text_file_reader.cpp
index 715e82ab325..d598c274f08 100644
--- a/src/text_file_reader.cpp
+++ b/src/text_file_reader.cpp
@@ -93,7 +93,9 @@ TextFileReader::~TextFileReader()
   delete[] line;
 }
 
-/** adjust line buffer size */
+/** adjust line buffer size
+ *
+ * \param  newsize  New size of the internal line buffer */
 
 void TextFileReader::set_bufsize(int newsize)
 {
diff --git a/unittest/c-library/test_library_properties.cpp b/unittest/c-library/test_library_properties.cpp
index e2149d98e60..39b31e82179 100644
--- a/unittest/c-library/test_library_properties.cpp
+++ b/unittest/c-library/test_library_properties.cpp
@@ -383,10 +383,48 @@ TEST_F(LibraryProperties, global)
     char *c_ptr = (char *)lammps_extract_global(lmp, "units");
     EXPECT_THAT(c_ptr, StrEq("real"));
 
-    EXPECT_EQ(lammps_extract_global_datatype(lmp, "ntimestep"), LAMMPS_INT64);
-    auto *b_ptr = (int64_t *)lammps_extract_global(lmp, "ntimestep");
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "ntimestep"), LAMMPS_BIGINT);
+    auto *b_ptr = (bigint *)lammps_extract_global(lmp, "ntimestep");
     EXPECT_EQ((*b_ptr), 2);
 
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "natoms"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "natoms");
+    EXPECT_EQ((*b_ptr), 29);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "nbonds"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "nbonds");
+    EXPECT_EQ((*b_ptr), 24);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "nangles"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "nangles");
+    EXPECT_EQ((*b_ptr), 30);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "ndihedrals"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "ndihedrals");
+    EXPECT_EQ((*b_ptr), 31);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "nimpropers"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "nimpropers");
+    EXPECT_EQ((*b_ptr), 2);
+
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "neigh_bondlist"), LAMMPS_INT_2D);
+    EXPECT_NE(lammps_extract_global(lmp, "neigh_bondlist"), nullptr);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "neigh_anglelist"), LAMMPS_INT_2D);
+    EXPECT_NE(lammps_extract_global(lmp, "neigh_anglelist"), nullptr);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "neigh_dihedrallist"), LAMMPS_INT_2D);
+    EXPECT_NE(lammps_extract_global(lmp, "neigh_dihedrallist"), nullptr);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "neigh_improperlist"), LAMMPS_INT_2D);
+    EXPECT_NE(lammps_extract_global(lmp, "neigh_improperlist"), nullptr);
+
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "eflag_global"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "eflag_global");
+    EXPECT_EQ((*b_ptr), 2);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "eflag_atom"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "eflag_atom");
+    EXPECT_EQ((*b_ptr), 0);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "vflag_global"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "vflag_global");
+    EXPECT_EQ((*b_ptr), 2);
+    EXPECT_EQ(lammps_extract_global_datatype(lmp, "vflag_atom"), LAMMPS_BIGINT);
+    b_ptr = (bigint *)lammps_extract_global(lmp, "vflag_atom");
+    EXPECT_EQ((*b_ptr), 0);
+
     EXPECT_EQ(lammps_extract_global_datatype(lmp, "dt"), LAMMPS_DOUBLE);
     auto *d_ptr = (double *)lammps_extract_global(lmp, "dt");
     EXPECT_DOUBLE_EQ((*d_ptr), 0.1);
diff --git a/unittest/python/python-numpy.py b/unittest/python/python-numpy.py
index 4930527a611..be9109b9a31 100644
--- a/unittest/python/python-numpy.py
+++ b/unittest/python/python-numpy.py
@@ -153,7 +153,7 @@ def testExtractComputeLocalArray(self):
         self.assertEqual(values[0,0], 0.5)
         self.assertEqual(values[0,3], -0.5)
         self.assertEqual(values[1,0], 1.5)
-        self.assertEqual(values[1,3], 1.5)
+        self.assertEqual(values[1,3], -1.5)
 
     def testExtractAtom(self):
         self.lmp.command("units lj")


Reviews:
user: login: sjplimp
body: Code looks perfect - just one comment on the 2 doc pages for pair/local and bond/local
state: CHANGES_REQUESTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T20:07:14Z
user: login: sjplimp
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T20:12:02Z
user: login: sjplimp
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T20:14:26Z
user: login: sjplimp
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T20:15:44Z
user: login: akohlmey
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-18T01:05:52Z
user: login: sjplimp
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-19T14:20:47Z
user: login: sjplimp
body: approved after making the one change you caught
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-19T14:21:30Z
user: login: akohlmey
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T14:25:07Z
user: login: copilot-pull-request-reviewer[bot]
body: ## Pull Request Overview

This PR combines multiple small changes and fixes that improve consistency in data interfaces, remove deprecated directional corrections, update error message formatting, and refresh documentation and examples.  
- Exposes new energy/virial flag members via the C interface in library.cpp.  
- Removes unused directionCorrection multiplications in compute_pair_local.cpp and compute_bond_local.cpp.  
- Updates error message formatting in compute_podd_atom.cpp and adjusts example inputs and documentation for current best practices.

### Reviewed Changes

Copilot reviewed 27 out of 27 changed files in this pull request and generated 2 comments.

<details>
<summary>Show a summary per file</summary>

| File                                           | Description                                                                              |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| src/library.cpp                                | Exposes eflag/vflag via the C interface and updates tally documentation.                 |
| src/compute_pair_local.cpp                     | Removes the directionCorrection multiplication from dx, dy, dz values.                     |
| src/compute_bond_local.cpp                     | Removes the directionCorrection multiplication from bond dx, dy, dz values.                |
| src/ML-POD/compute_podd_atom.cpp               | Adjusts the integer overflow check and updates the error message formatting.               |
| src/LATBOLTZ/fix_lb_fluid.cpp                   | Updates the MPI_File_set_view call by casting the view string to (char *).                  |
| src/KOKKOS/pair_kokkos.h                       | Adds explicit casts to double in the logarithmic calculation for vectorsize rounding.      |
| src/KOKKOS/meam_force_kokkos.h                 | Removes a redundant assignment to eflag_either.                                            |
| src/KOKKOS/meam_dens_init_kokkos.h             | Removes an unused assignment to nlocal.                                                    |
| examples/PACKAGES/imd/*                        | Updates GPU-related example inputs to use non-GPU pair styles and adjusted fix commands.     |
| doc/*                                          | Refreshes documentation content for water models and force field guidelines.               |
</details>





state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-19T15:24:57Z

Review comments:
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: sjplimp
body: Here is what I suggest, and similar for pair local doc page:

The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
the force on the first atom I in the bond due to the second atom J.  Mathematically, this is obtained by multiplying the components dx, dy, dz of the distance vector described above by *force*.  For bond styles that apply non-central forces ...
created_at: 2025-05-16T20:12:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: sjplimp
body: Here and in the pair local doc, I would say it this way:
The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of the force on the first atom I in the bond due to the second atom J in the bond.  Mathematically, they are obtained by multiplying the dx, dy, dz components of the distance vector described above by *force*.  For bond styles that apply non-central ...

created_at: 2025-05-16T20:14:26Z
author_association: CONTRIBUTOR
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: sjplimp
body: sorry, it seemed to require my comment twice ...
created_at: 2025-05-16T20:15:44Z
author_association: CONTRIBUTOR
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: akohlmey
body: > they are obtained by multiplying the dx, dy, dz components of the distance vector described above by _force_.

That would not be correct. The value of force is the internally computed force multiplied by *r*.
One could say, that it is a vector obtained from multiplying with a unit vector created from dx, dy, dz.
created_at: 2025-05-18T01:05:52Z
author_association: MEMBER
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: sjplimp
body: yes - good catch - how about "obtained by converting the (dx,dy,dz) distance vector (above) to a unit vector and multiplying by the *force* quantity (above)"
created_at: 2025-05-19T14:20:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -64,22 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: TBD
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
-<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
-components of the normal force component.
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
path: doc/src/compute_bond_local.rst
user: login: akohlmey
body: I had already made a change that says the same.
created_at: 2025-05-19T14:25:07Z
author_association: MEMBER
diff_hunk: @@ -58,8 +58,8 @@ ComputePODDAtom::ComputePODDAtom(LAMMPS *lmp, int narg, char **arg) :
   pod = nullptr;
   elements = nullptr;
 
-  if (((((MAXBIGINT*3.0)*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
-    error->all(FLERR, "Per-atom data too large");
+  if ((((3.0*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
+      error->all(FLERR, "Too many atoms ({}_ for compute {}", atom->natoms, style);
path: src/ML-POD/compute_podd_atom.cpp
user: login: Copilot
body: The error message formatting on the subsequent line appears to be missing a closing parenthesis and proper placeholder completions. Consider revising the message to something like "Too many atoms ({} for compute {})" to ensure clear communication.
```suggestion
      error->all(FLERR, "Too many atoms ({} for compute {})", atom->natoms, style);
```
created_at: 2025-05-19T15:24:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -110,8 +110,8 @@ void ComputePODDAtom::compute_peratom()
   if (atom->natoms > nmax) {
     memory->destroy(pod);
     nmax = atom->natoms;
-    if (((((MAXBIGINT*3.0)*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
-      error->all(FLERR, "Per-atom data too large");
+    if ((((3.0*atom->natoms)*podptr->nClusters)*podptr->Mdesc) > (MAXSMALLINT*1.0))
+      error->all(FLERR, "Too many atoms ({}) for compute {}", atom->natoms, style);
path: src/ML-POD/compute_podd_atom.cpp
user: login: Copilot
body: The error message on this check also uses an incomplete format string. Update it to include the missing characters so that it reads clearly, for example: "Too many atoms ({} for compute {})".
```suggestion
      error->all(FLERR, "Too many atoms ({} for compute {})", atom->natoms, style);
```
created_at: 2025-05-19T15:24:57Z
author_association: CONTRIBUTOR

PR comments:
user: login: akohlmey
created_at: 2025-05-15T15:08:38Z
body: @sjplimp do you think that the patch suggested in https://matsci.org/t/outputs-from-pair-local-command/63507/2 to get a force sign consistent with the distances makes sense to include?
author_association: MEMBER
user: login: sjplimp
created_at: 2025-05-15T18:15:39Z
body: @akohlmey I see the inconsistency mentioned on MatSci.  But I think it would be better to change dx,dy,dz to be wrt atom I (i,e. distance of atom J from atom I), just like fx,fy,fz are the force on atom I due to atom J.  I don't recall what the motivation was to have dx,dy,dz be the distance from the higher ID to the lower ID.  I.e. remove the "directionCorrection" logic from the current version.  The user can also get the IDs of the I and J atoms in the dump file via compute property/local
author_association: CONTRIBUTOR
user: login: akohlmey
created_at: 2025-05-15T18:23:08Z
body: > @akohlmey I see the inconsistency mentioned on MatSci. But I think it would be better to change dx,dy,dz to be wrt atom I (i,e. distance of atom J from atom I), just like fx,fy,fz are the force on atom I due to atom J. I don't recall what the motivation was to have dx,dy,dz be the distance from the higher ID to the lower ID. I.e. remove the "directionCorrection" logic from the current version. The user can also get the IDs of the I and J atoms in the dump file via compute property/local

@sjplimp It looks like you approved it here: https://github.com/lammps/lammps/pull/3032

I guess we need to ask @GenieTim for clarification.
author_association: MEMBER
user: login: sjplimp
created_at: 2025-05-15T18:24:05Z
body: A better way to say it (e.g. in the doc page) would be that (dx,dy,dz) is the vector displacement = Xi - Xj
force is the magnitude of the force with a sign = positive for repulsion, negative for attraction
(fx,fy,fz) is force*(dx,dy,dz) or effectively the force of atom J on atom I
compute pair/local is coded the same way as all the pair styles (e.g. pair lj/cut), if the directionCorrection is removed

author_association: CONTRIBUTOR
user: login: sjplimp
created_at: 2025-05-15T18:33:19Z
body: Looked at the older PR - @GenieTim added (dx,dy,dz) to be like compute bond/local.  But bonds are ID of I < ID of J by construction, not like pair interactions, which come from neigh lists.  So I think making dx,dy,dz and fx,fy,fz be consistent with pair styles is the way to do it.  Also compute pair/local can possibly have the IDs of I,J be the same. which directionCorrection cannot account for consistently.  E.g. if you wanted to compute a virial from the sum of compute pair/local outputs.
author_association: CONTRIBUTOR
user: login: sjplimp
created_at: 2025-05-15T18:49:25Z
body: PR #3032 also added dx,dy,dz to compute bond/local and the doc page sentences about lower ID and higher ID to both
pair/local and bond/local. I think that doc page info as well as directionCorrection should be removed from both commands.
Dx,dy,dz and fx,fy,fz will be consistent in both local commands if they are just done the way pair and bond styles do the calculations.  I think the logic to skip duplicate pairs or bonds in both local styles when newton is off, is what confused the issue.
author_association: CONTRIBUTOR
user: login: akohlmey
created_at: 2025-05-16T03:30:51Z
body: @sjplimp I've tried to implement your suggestions. Please have another look and suggest corrections where needed.
author_association: MEMBER