Merge branch 'master' into atc-doc-to-rst

# Conflicts:
#	doc/src/fix_atc.rst

doc/src/Build_basics.rst

@@ -40,14 +40,14 @@ is below.
    -D LAMMPS_MACHINE=name    # name = mpi, serial, mybox, titan, laptop, etc
                              # no default value
 
-The executable created by CMake (after running make) is named *lmp* unless
+The executable created by CMake (after running make) is named ``lmp`` unless
-the LAMMPS\_MACHINE option is set.  When setting `LAMMPS_MACHINE=name`
+the LAMMPS_MACHINE option is set.  When setting ``LAMMPS_MACHINE=name``
-the executable will be named *lmp\_name*\.  Using `BUILD\_MPI=no` will
+the executable will be called ``lmp_name``.  Using ``BUILD_MPI=no`` will
 enforce building a serial executable using the MPI STUBS library.
 
 **Traditional make**\ :
 
-The build with traditional makefiles has to be done inside the source folder `src`.
+The build with traditional makefiles has to be done inside the source folder ``src``.
 
 .. code-block:: bash
 
@@ -56,17 +56,17 @@ The build with traditional makefiles has to be done inside the source folder `sr
    make mybox              # uses Makefile.mybox to produce lmp_mybox
 
 Any "make machine" command will look up the make settings from a file
-Makefile.machine, create a folder Obj\_machine with all objects and
+Makefile.machine, create a folder Obj_machine with all objects and
-generated files and an executable called *lmp\_machine*\ .  The standard
+generated files and an executable called ``lmp_machine``\ .  The standard
-parallel build with `make mpi` assumes a standard MPI installation with
+parallel build with ``make mpi`` assumes a standard MPI installation with
 MPI compiler wrappers where all necessary compiler and linker flags to
 get access and link with the suitable MPI headers and libraries are set
 by the wrapper programs.  For other cases or the serial build, you have
-to adjust the make file variables MPI\_INC, MPI\_PATH, MPI\_LIB as well
+to adjust the make file variables ``MPI_INC``, ``MPI_PATH``, ``MPI_LIB``
-as CC and LINK.  To enable OpenMP threading usually a compiler specific
+as well as ``CC`` and ``LINK``\ .  To enable OpenMP threading usually
-flag needs to be added to the compile and link commands.  For the GNU
+a compiler specific flag needs to be added to the compile and link
-compilers, this is *-fopenmp*\ , which can be added to the CC and LINK
+commands.  For the GNU compilers, this is ``-fopenmp``\ , which can be
-makefile variables.
+added to the ``CC`` and ``LINK`` makefile variables.
 
 For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
 
@@ -79,8 +79,8 @@ For the serial build the following make variables are set (see src/MAKE/Makefile
    MPI_LIB =       -lmpi_stubs
 
 You also need to build the STUBS library for your platform before making
-LAMMPS itself.  A "make serial" build does this for you automatically,
+LAMMPS itself.  A ``make serial`` build does this for you automatically,
-otherwise, type "make mpi-stubs" from the src directory, or "make" from
+otherwise, type ``make mpi-stubs`` from the src directory, or ``make`` from
 the src/STUBS dir.  If the build fails, you will need to edit the
 STUBS/Makefile for your platform.  The stubs library does not provide
 MPI/IO functions required by some LAMMPS packages, e.g. MPIIO or USER-LB,
@@ -88,8 +88,8 @@ and thus is not compatible with those packages.
 
 .. note::
 
-   The file STUBS/mpi.c provides a CPU timer function called
+   The file ``src/STUBS/mpi.c`` provides a CPU timer function called
-   MPI\_Wtime() that calls gettimeofday() .  If your operating system
+   MPI_Wtime() that calls gettimeofday() .  If your operating system
    does not support gettimeofday() , you will need to insert code to
    call another timer.  Note that the ANSI-standard function clock()
    rolls over after an hour or so, and is therefore insufficient for
@@ -126,29 +126,29 @@ to: e.g. LATTE and USER-COLVARS.  See the :doc:`Packages details
 <Packages_details>` doc page for more info on these packages and the doc
 pages for their respective commands for OpenMP threading info.
 
-For CMake, if you use BUILD\_OMP=yes, you can use these packages and
+For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
-turn on their native OpenMP support and turn on their native OpenMP
+and turn on their native OpenMP support and turn on their native OpenMP
-support at run time, by setting the OMP\_NUM\_THREADS environment
+support at run time, by setting the ``OMP_NUM_THREADS`` environment
 variable before you launch LAMMPS.
 
-For building via conventional make, the CCFLAGS and LINKFLAGS
+For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
 variables in Makefile.machine need to include the compiler flag that
-enables OpenMP. For GNU compilers it is -fopenmp.  For (recent) Intel
+enables OpenMP. For GNU compilers it is ``-fopenmp``\ .  For (recent) Intel
-compilers it is -qopenmp.  If you are using a different compiler,
+compilers it is ``-qopenmp``\ .  If you are using a different compiler,
 please refer to its documentation.
 
 .. _default-none-issues:
 
 **OpenMP Compiler compatibility info**\ :
 
-Some compilers do not fully support the 'default(none)' directive
+Some compilers do not fully support the ``default(none)`` directive
 and others (e.g. GCC version 9 and beyond) may implement OpenMP 4.0
-semantics, which are incompatible with the OpenMP 3.1 directives used
+semantics, which are incompatible with the OpenMP 3.1 semantics used
 in LAMMPS (for maximal compatibility with compiler versions in use).
-In those case, all 'default(none)' directives (which aid in detecting
+In those case, all ``default(none)`` directives (which aid in detecting
-incorrect and unwanted sharing) can be replaced with 'default(shared)'
+incorrect and unwanted sharing) can be replaced with ``default(shared)``
-while dropping all 'shared()' directives. The script
+while dropping all ``shared()`` directives. The script
-'src/USER-OMP/hack\_openmp\_for\_pgi\_gcc9.sh' can be used to automate
+'src/USER-OMP/hack_openmp_for_pgi_gcc9.sh' can be used to automate
 this conversion.
 
 ----------
@@ -183,11 +183,11 @@ optimization flags appropriate to that compiler and any
 build.
 
 You can tell CMake to look for a specific compiler with these variable
-settings.  Likewise you can specify the FLAGS variables if you want to
+settings.  Likewise you can specify the corresponding ``CMAKE_*_FLAGS``
-experiment with alternate optimization flags.  You should specify all
+variables if you want to experiment with alternate optimization flags.
-3 compilers, so that the small number of LAMMPS source files written
+You should specify all 3 compilers, so that the small number of LAMMPS
-in C or Fortran are built with a compiler consistent with the one used
+source files written in C or Fortran are built with a compiler consistent
-for all the C++ files:
+with the one used for all the C++ files:
 
 .. code-block:: bash
 
@@ -300,19 +300,18 @@ are set, defaults are applied.
    -D LAMMPS_LIB_SUFFIX=name    # name = mpi, serial, mybox, titan, laptop, etc
                                 # no default value
 
-Setting BUILD\_EXE=no will not produce an executable.  Setting
+Setting ``BUILD_EXE=no`` will not produce an executable.  Setting
-BUILD\_LIB=yes will produce a static library named *liblammps.a*\ .
+``BUILD_LIB=yes`` will produce a static library named ``liblammps.a``\ .
-Setting both BUILD\_LIB=yes and BUILD\_SHARED\_LIBS=yes will produce a
+Setting both ``BUILD_LIB=yes`` and ``BUILD_SHARED_LIBS=yes`` will produce a
-shared library named *liblammps.so* instead. If LAMMPS\_LIB\_SUFFIX is
+shared library named ``liblammps.so`` instead. If ``LAMMPS_LIB_SUFFIX=name``
-set to *name* in addition, the name of the generated libraries will be
+is set in addition, the name of the generated libraries will be changed to
-changed to either *liblammps\_name.a* or *liblammps\_name.so*\ ,
+either ``liblammps_name.a`` or ``liblammps_name.so``\ , respectively.
-respectively.
 
 **Traditional make**\ :
 
 With the traditional makefile based build process, the choice of
 the generated executable or library depends on the "mode" setting.
-Several options are available and "mode=exe" is the default.
+Several options are available and ``mode=exe`` is the default.
 
 .. code-block:: bash
 
@@ -322,11 +321,11 @@ Several options are available and "mode=exe" is the default.
    make mode=shlib machine    # build LAMMPS shared lib liblammps_machine.so
    make mode=shexe machine    # same as "mode=exe" but uses objects from "mode=shlib"
 
-The two "exe" builds will generate and executable *lmp\_machine*\ ,
+The two "exe" builds will generate and executable ``lmp_machine``\ ,
-while the two library builds will create a file *liblammps\_machine.a*
+while the two library builds will create a file ``liblammps_machine.a``
-or *liblammps\_machine.so*\ . They will also create generic soft links,
+or ``liblammps_machine.so``\ . They will also create generic soft links,
-named *liblammps.a* and *liblammps.so*\ , which point to the specific
+named ``liblammps.a`` and ``liblammps.so``\ , which point to the specific
-*liblammps\_machine.a/so* files.
+``liblammps_machine.a/so`` files.
 
 **CMake and make info**\ :
 
@@ -335,7 +334,7 @@ the auxiliary libraries it depends on must also exist as shared
 libraries.  This will be the case for libraries included with LAMMPS,
 such as the dummy MPI library in src/STUBS or any package libraries in
 the lib/packages directory, since they are always built in a shared
-library compatible way using the -fPIC switch.  However, if a library
+library compatible way using the ``-fPIC`` switch.  However, if a library
 like MPI or FFTW does not exist as a shared library, the shared library
 build may generate an error.  This means you will need to install a
 shared library version of the auxiliary library.  The build instructions
@@ -353,10 +352,10 @@ in the default /usr/local/lib location:
    make
    make install
 
-You may need to use "sudo make install" in place of the last line if you
+You may need to use ``sudo make install`` in place of the last line if you
-do not have write privileges for /usr/local/lib.  The end result should
+do not have write privileges for ``/usr/local/lib``.  The end result should
-be the file /usr/local/lib/libmpich.so.  On many Linux installations the
+be the file ``/usr/local/lib/libmpich.so``.  On many Linux installations the
-folder "${HOME}/.local" is an alternative to using /usr/local and does
+folder ``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
 not require superuser or sudo access.  In that case the configuration
 step becomes:
 
@@ -420,7 +419,7 @@ It is also possible to create the HTML version of the manual within
 the :doc:`CMake build directory <Build_cmake>`.  The reason for this
 option is to include the installation of the HTML manual pages into
 the "install" step when installing LAMMPS after the CMake build via
-"make install".
+``make install``.
 
 .. code-block:: bash
 
@@ -479,6 +478,6 @@ you want to copy files to is protected.
 
 **Traditional make**\ :
 
-There is no "install" option in the src/Makefile for LAMMPS.  If you
+There is no "install" option in the ``src/Makefile`` for LAMMPS.  If
-wish to do this you will need to first build LAMMPS, then manually
+you wish to do this you will need to first build LAMMPS, then manually
 copy the desired LAMMPS files to the appropriate system directories.

doc/src/Build_cmake.rst

@@ -13,8 +13,8 @@ good place to start.
 
 Building LAMMPS with CMake is a two-step process.  First you use CMake
 to create a build environment in a new directory.  On Linux systems,
-this will be based on makefiles for use with make.  Then you use the
+this will be by default based on Unix-style makefiles for use with make.
-make command to build LAMMPS, which uses the created
+Then you use the *make* command to build LAMMPS, which uses the created
 Makefile(s). Example:
 
 .. code-block:: bash
@@ -28,8 +28,8 @@ The cmake command will detect available features, enable selected
 packages and options, and will generate the build environment.  By default
 this build environment will be created for "Unix Makefiles" on most
 platforms and particularly on Linux.  However, alternate build tools
-(e.g. Ninja) and support files for Integrated Development Environments
+(e.g. Ninja) and project files for Integrated Development Environments
-(IDE) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
+(IDEs) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
 selected via the "-G" command line flag. For the rest of the documentation
 we will assume that the build environment is generated for makefiles
 and thus the make command will be used to compile and link LAMMPS as
@@ -55,16 +55,17 @@ your system with:
 This will install the lammps executable and library (if requested), some
 tools (if configured) and additional files like library API headers,
 manpages, potential and force field files. The location of the installation
-tree is set by the CMake variable "CMAKE\_INSTALL\_PREFIX" which defaults
+tree is set by the CMake variable "CMAKE_INSTALL_PREFIX" which defaults
 to ${HOME}/.local
 
 ----------
 
-There are 3 variants of CMake: a command-line version (cmake), a text mode
+There are 3 variants of the CMake command itself: a command-line version
-UI version (ccmake), and a graphical GUI version (cmake-GUI).  You can use
+(*cmake* or *cmake3*), a text mode UI version (*ccmake* or *ccmake3*),
-any of them interchangeably to configure and create the LAMMPS build
+and a graphical GUI version (*cmake-gui*).  You can use any of them
-environment.  On Linux all the versions produce a Makefile as their
+interchangeably to configure and create the LAMMPS build environment.
-output.  See more details on each below.
+On Linux all the versions produce a Makefile as their output by default.
+See more details on each below.
 
 You can specify a variety of options with any of the 3 versions, which
 affect how the build is performed and what is included in the LAMMPS
@@ -82,12 +83,13 @@ this directory or sub-directories within it that CMake creates.
 
 .. note::
 
-   To perform a CMake build, no packages can be installed or a
+   To perform a CMake build, no packages can be installed or a build
-   build been previously attempted in the LAMMPS src directory by using
+   been previously attempted in the LAMMPS src directory by using "make"
-   "make" commands to :doc:`perform a conventional LAMMPS build <Build_make>`.  CMake detects if this is the case and
+   commands to :doc:`perform a conventional LAMMPS build <Build_make>`.
-   generates an error, telling you to type "make no-all purge" in the src
+   CMake detects if this is the case and generates an error, telling you
-   directory to un-install all packages.  The purge removes all the \*.h
+   to type "make no-all purge" in the src directory to un-install all
-   files auto-generated by make.
+   packages.  The purge removes all the \*.h files auto-generated by
+   make.
 
 You must have CMake version 3.10 or later on your system to build
 LAMMPS.  Installation instructions for CMake are below.
@@ -106,8 +108,9 @@ folder, recreate the directory and start over.
 
 .. code-block:: bash
 
-   cmake [options ...] /path/to/lammps/cmake  # build from any dir
+   cmake  [options ...] /path/to/lammps/cmake  # build from any dir
-   cmake [options ...] ../cmake               # build from lammps/build
+   cmake  [options ...] ../cmake               # build from lammps/build
+   cmake3 [options ...] ../cmake               # build from lammps/build
 
 The cmake command takes one required argument, which is the LAMMPS
 cmake directory which contains the CMakeLists.txt file.
@@ -119,7 +122,8 @@ command-line options.  Several useful ones are:
 
    -D CMAKE_INSTALL_PREFIX=path  # where to install LAMMPS executable/lib if desired
    -D CMAKE_BUILD_TYPE=type      # type = RelWithDebInfo (default), Release, MinSizeRel, or Debug
-   -G output                     # style of output CMake generates
+   -G output                     # style of output CMake generates (e.g. "Unix Makefiles" or "Ninja")
+   -D CMAKE_MAKE_PROGRAM=builder # name of the builder executable (e.g. set to "gmake" instead of "make")
    -DVARIABLE=value              # setting for a LAMMPS feature to enable
    -D VARIABLE=value             # ditto, but cannot come after CMakeLists.txt dir
    -C path/to/preset/file        # load some CMake settings before configuring
@@ -127,7 +131,7 @@ command-line options.  Several useful ones are:
 All the LAMMPS-specific -D variables that a LAMMPS build supports are
 described on the pages linked to from the :doc:`Build <Build>` doc page.
 All of these variable names are upper-case and their values are
-lower-case, e.g. -D LAMMPS\_SIZES=smallbig.  For boolean values, any of
+lower-case, e.g. -D LAMMPS_SIZES=smallbig.  For boolean values, any of
 these forms can be used: yes/no, on/off, 1/0.
 
 On Unix/Linux machines, CMake generates a Makefile by default to

doc/src/Build_extras.rst

@@ -14,7 +14,7 @@ or
 
    $ make yes-name
 
-as described on the :doc:`Build\_package <Build_package>` doc page.
+as described on the :doc:`Build_package <Build_package>` doc page.
 
 For a CMake build there may be additional optional or required
 variables to set.  For a build with make, a provided library under the
@@ -107,37 +107,37 @@ which GPU hardware to build for.
    -D CUDA_MPS_SUPPORT=value # enables some tweaks required to run with active nvidia-cuda-mps daemon
                              # value = yes or no (default)
 
-GPU\_ARCH settings for different GPU hardware is as follows:
+GPU_ARCH settings for different GPU hardware is as follows:
 
-* sm\_12 or sm\_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
+* sm_12 or sm_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
-* sm\_20 or sm\_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
+* sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
-* sm\_30 or sm\_35 or sm\_37 for Kepler (supported since CUDA 5)
+* sm_30 or sm_35 or sm_37 for Kepler (supported since CUDA 5)
-* sm\_50 or sm\_52 for Maxwell (supported since CUDA 6)
+* sm_50 or sm_52 for Maxwell (supported since CUDA 6)
-* sm\_60 or sm\_61 for Pascal (supported since CUDA 8)
+* sm_60 or sm_61 for Pascal (supported since CUDA 8)
-* sm\_70 for Volta (supported since CUDA 9)
+* sm_70 for Volta (supported since CUDA 9)
-* sm\_75 for Turing (supported since CUDA 10)
+* sm_75 for Turing (supported since CUDA 10)
 
 A more detailed list can be found, for example,
 at `Wikipedia's CUDA article <https://en.wikipedia.org/wiki/CUDA#GPUs_supported>`_
 
 CMake can detect which version of the CUDA toolkit is used and thus can
 include support for **all** major GPU architectures supported by this toolkit.
-Thus the GPU\_ARCH setting is merely an optimization, to have code for
+Thus the GPU_ARCH setting is merely an optimization, to have code for
 the preferred GPU architecture directly included rather than having to wait
 for the JIT compiler of the CUDA driver to translate it.
 
 **Traditional make**\ :
 
-Before building LAMMPS, you must build the GPU library in lib/gpu.
+Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
 You can do this manually if you prefer; follow the instructions in
-lib/gpu/README.  Note that the GPU library uses MPI calls, so you must
+``lib/gpu/README``.  Note that the GPU library uses MPI calls, so you must
 use the same MPI library (or the STUBS library) settings as the main
-LAMMPS code.  This also applies to the -DLAMMPS\_BIGBIG,
+LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG``\ ,
--DLAMMPS\_SMALLBIG, or -DLAMMPS\_SMALLSMALL settings in whichever
+``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
 Makefile you use.
 
-You can also build the library in one step from the lammps/src dir,
+You can also build the library in one step from the ``lammps/src`` dir,
-using a command like these, which simply invoke the lib/gpu/Install.py
+using a command like these, which simply invoke the ``lib/gpu/Install.py``
 script with the specified args:
 
 .. code-block:: bash
@@ -156,22 +156,22 @@ Makefile.machine you start from via the corresponding -c, -a, -p, -e
 switches (as in the examples above), and also save a copy of the new
 Makefile if desired:
 
-* CUDA\_HOME = where NVIDIA CUDA software is installed on your system
+* ``CUDA_HOME`` = where NVIDIA CUDA software is installed on your system
-* CUDA\_ARCH = sm\_XX, what GPU hardware you have, same as CMake GPU\_ARCH above
+* ``CUDA_ARCH`` = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
-* CUDA\_PRECISION = precision (double, mixed, single)
+* ``CUDA_PRECISION`` = precision (double, mixed, single)
-* EXTRAMAKE = which Makefile.lammps.\* file to copy to Makefile.lammps
+* ``EXTRAMAKE`` = which Makefile.lammps.\* file to copy to Makefile.lammps
 
-The file Makefile.linux\_multi is set up to include support for multiple
+The file Makefile.linux_multi is set up to include support for multiple
 GPU architectures as supported by the CUDA toolkit in use. This is done
 through using the "--gencode " flag, which can be used multiple times and
 thus support all GPU architectures supported by your CUDA compiler.
 
 If the library build is successful, 3 files should be created:
-lib/gpu/libgpu.a, lib/gpu/nvc\_get\_devices, and
+``lib/gpu/libgpu.a``\ , ``lib/gpu/nvc_get_devices``\ , and
-lib/gpu/Makefile.lammps.  The latter has settings that enable LAMMPS
+``lib/gpu/Makefile.lammps``\ .  The latter has settings that enable LAMMPS
-to link with CUDA libraries.  If the settings in Makefile.lammps for
+to link with CUDA libraries.  If the settings in ``Makefile.lammps`` for
 your machine are not correct, the LAMMPS build will fail, and
-lib/gpu/Makefile.lammps may need to be edited.
+``lib/gpu/Makefile.lammps`` may need to be edited.
 
 .. note::
 
@@ -211,35 +211,36 @@ minutes to hours) to build.  Of course you only need to do that once.)
    -D LMP_DEBUG_CURL=value         # set libcurl verbose mode on/off, value = off (default) or on
    -D LMP_NO_SSL_CHECK=value       # tell libcurl to not verify the peer, value = no (default) or yes
 
-If DOWNLOAD\_KIM is set, the KIM library will be downloaded and built
+If ``DOWNLOAD_KIM`` is set, the KIM library will be downloaded and built
 inside the CMake build directory.  If the KIM library is already on
-your system (in a location CMake cannot find it), set the PKG\_CONFIG\_PATH
+your system (in a location CMake cannot find it), set the ``PKG_CONFIG_PATH``
 environment variable so that libkim-api can be found.
 
 *For using OpenKIM web queries in LAMMPS*\ :
 
-If LMP\_DEBUG\_CURL is set, the libcurl verbose mode will be on, and any
+If the ``LMP_DEBUG_CURL`` environment variable is set, the libcurl verbose
-libcurl calls within the KIM web query display a lot of information about
+mode will be on, and any libcurl calls within the KIM web query display a
-libcurl operations. You hardly ever want this set in production use, you will
+lot of information about libcurl operations.  You hardly ever want this
-almost always want this when you debug/report problems.
+set in production use, you will almost always want this when you debug or
+report problems.
 
 The libcurl performs peer SSL certificate verification by default. This
 verification is done using a CA certificate store that the SSL library can
 use to make sure the peer's server certificate is valid. If SSL reports an
 error ("certificate verify failed") during the handshake and thus refuses
-further communication with that server, you can set LMP\_NO\_SSL\_CHECK.
+further communication with that server, you can set ``LMP_NO_SSL_CHECK``\ .
-If LMP\_NO\_SSL\_CHECK is set, libcurl does not verify the peer and connection
+If ``LMP_NO_SSL_CHECK`` is set, libcurl does not verify the peer and connection
 succeeds regardless of the names in the certificate. This option is insecure.
 As an alternative, you can specify your own CA cert path by setting the
-environment variable CURL\_CA\_BUNDLE to the path of your choice. A call to the
+environment variable ``CURL_CA_BUNDLE`` to the path of your choice. A call
-KIM web query would get this value from the environmental variable.
+to the KIM web query would get this value from the environmental variable.
 
 **Traditional make**\ :
 
 You can download and build the KIM library manually if you prefer;
-follow the instructions in lib/kim/README.  You can also do it in one
+follow the instructions in ``lib/kim/README``\ .  You can also do it in one
 step from the lammps/src dir, using a command like these, which simply
-invoke the lib/kim/Install.py script with the specified args.
+invoke the ``lib/kim/Install.py`` script with the specified args.
 
 .. code-block:: bash
 
@@ -252,7 +253,7 @@ invoke the lib/kim/Install.py script with the specified args.
   $ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
 
 Settings for OpenKIM web queries discussed above need to be applied by adding
-them to the LMP\_INC variable through editing the Makefile.machine you are
+them to the ``LMP_INC`` variable through editing the Makefile.machine you are
 using.  For example:
 
 .. code-block:: make
@@ -271,7 +272,7 @@ build for, either CPUs (multi-threading via OpenMP) or KNLs (OpenMP)
 or GPUs (NVIDIA Cuda).
 
 For a CMake or make build, these are the possible choices for the
-KOKKOS\_ARCH settings described below.  Note that for CMake, these are
+``KOKKOS_ARCH`` settings described below.  Note that for CMake, these are
 really Kokkos variables, not LAMMPS variables.  Hence you must use
 case-sensitive values, e.g. BDW, not bdw.
 
@@ -334,7 +335,7 @@ For NVIDIA GPUs using CUDA, set these 4 variables:
    -D CMAKE_CXX_COMPILER=wrapper      # wrapper = full path to Cuda nvcc wrapper
 
 The wrapper value is the Cuda nvcc compiler wrapper provided in the
-Kokkos library: lib/kokkos/bin/nvcc\_wrapper.  The setting should
+Kokkos library: ``lib/kokkos/bin/nvcc_wrapper``\ .  The setting should
 include the full path name to the wrapper, e.g.
 
 .. code-block:: bash
@@ -343,9 +344,9 @@ include the full path name to the wrapper, e.g.
 
 **Traditional make**\ :
 
-Choose which hardware to support in Makefile.machine via
+Choose which hardware to support in ``Makefile.machine`` via
-KOKKOS\_DEVICES and KOKKOS\_ARCH settings.  See the
+``KOKKOS_DEVICES`` and ``KOKKOS_ARCH`` settings.  See the
-src/MAKE/OPTIONS/Makefile.kokkos\* files for examples.
+``src/MAKE/OPTIONS/Makefile.kokkos\*`` files for examples.
 
 For multicore CPUs using OpenMP:
 
@@ -400,18 +401,18 @@ library.
    -D DOWNLOAD_LATTE=value    # download LATTE for build, value = no (default) or yes
    -D LATTE_LIBRARY=path      # LATTE library file (only needed if a custom location)
 
-If DOWNLOAD\_LATTE is set, the LATTE library will be downloaded and
+If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded and
 built inside the CMake build directory.  If the LATTE library is
 already on your system (in a location CMake cannot find it),
-LATTE\_LIBRARY is the filename (plus path) of the LATTE library file,
+``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library file,
 not the directory the library file is in.
 
 **Traditional make**\ :
 
 You can download and build the LATTE library manually if you prefer;
-follow the instructions in lib/latte/README.  You can also do it in
+follow the instructions in ``lib/latte/README``\ .  You can also do it in
-one step from the lammps/src dir, using a command like these, which
+one step from the ``lammps/src`` dir, using a command like these, which
-simply invokes the lib/latte/Install.py script with the specified
+simply invokes the ``lib/latte/Install.py`` script with the specified
 args:
 
 .. code-block:: bash
@@ -450,10 +451,10 @@ be installed on your system.
 **Traditional make**\ :
 
 Before building LAMMPS, you must build the CSlib library in
-lib/message.  You can build the CSlib library manually if you prefer;
+``lib/message``\ .  You can build the CSlib library manually if you prefer;
-follow the instructions in lib/message/README.  You can also do it in
+follow the instructions in ``lib/message/README``\ .  You can also do it in
-one step from the lammps/src dir, using a command like these, which
+one step from the ``lammps/src`` dir, using a command like these, which
-simply invoke the lib/message/Install.py script with the specified args:
+simply invoke the ``lib/message/Install.py`` script with the specified args:
 
 .. code-block:: bash
 
@@ -461,9 +462,9 @@ simply invoke the lib/message/Install.py script with the specified args:
   $ make lib-message args="-m -z"  # build with MPI and socket (ZMQ) support
   $ make lib-message args="-s"     # build as serial lib with no ZMQ support
 
-The build should produce two files: lib/message/cslib/src/libmessage.a
+The build should produce two files: ``lib/message/cslib/src/libmessage.a``
-and lib/message/Makefile.lammps.  The latter is copied from an
+and ``lib/message/Makefile.lammps``\ .  The latter is copied from an
-existing Makefile.lammps.\* and has settings to link with the ZeroMQ
+existing ``Makefile.lammps.\*`` and has settings to link with the ZeroMQ
 library if requested in the build.
 
 ----------
@@ -474,10 +475,10 @@ MSCG package
 -----------------------
 
 To build with this package, you must download and build the MS-CG
-library.  Building the MS-CG library and using it from LAMMPS requires
+library.  Building the MS-CG library requires that the GSL
-a C++11 compatible compiler and that the GSL (GNU Scientific Library)
+(GNU Scientific Library) headers and libraries are installed on your
-headers and libraries are installed on your machine.  See the
+machine.  See the ``lib/mscg/README`` and ``MSCG/Install`` files for
-lib/mscg/README and MSCG/Install files for more details.
+more details.
 
 **CMake build**\ :
 
@@ -487,19 +488,19 @@ lib/mscg/README and MSCG/Install files for more details.
    -D MSCG_LIBRARY=path      # MSCG library file (only needed if a custom location)
    -D MSCG_INCLUDE_DIR=path  # MSCG include directory (only needed if a custom location)
 
-If DOWNLOAD\_MSCG is set, the MSCG library will be downloaded and built
+If ``DOWNLOAD_MSCG`` is set, the MSCG library will be downloaded and built
 inside the CMake build directory.  If the MSCG library is already on
-your system (in a location CMake cannot find it), MSCG\_LIBRARY is the
+your system (in a location CMake cannot find it), ``MSCG_LIBRARY`` is the
 filename (plus path) of the MSCG library file, not the directory the
-library file is in.  MSCG\_INCLUDE\_DIR is the directory the MSCG
+library file is in.  ``MSCG_INCLUDE_DIR`` is the directory the MSCG
 include file is in.
 
 **Traditional make**\ :
 
 You can download and build the MS-CG library manually if you prefer;
-follow the instructions in lib/mscg/README.  You can also do it in one
+follow the instructions in ``lib/mscg/README``\ .  You can also do it in one
-step from the lammps/src dir, using a command like these, which simply
+step from the ``lammps/src`` dir, using a command like these, which simply
-invoke the lib/mscg/Install.py script with the specified args:
+invoke the ``lib/mscg/Install.py`` script with the specified args:
 
 .. code-block:: bash
 
@@ -511,9 +512,9 @@ invoke the lib/mscg/Install.py script with the specified args:
   $ make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release
 
 Note that 2 symbolic (soft) links, "includelink" and "liblink", will
-be created in lib/mscg to point to the MS-CG src/installation dir.
+be created in ``lib/mscg`` to point to the MS-CG ``src/installation``
-When LAMMPS is built in src it will use these links.  You should not
+dir.  When LAMMPS is built in src it will use these links.  You should
-need to edit the lib/mscg/Makefile.lammps file.
+not need to edit the ``lib/mscg/Makefile.lammps`` file.
 
 ----------
 
@@ -524,7 +525,7 @@ OPT package
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_OPT=yes".
+No additional settings are needed besides ``-D PKG_OPT=yes``
 
 **Traditional make**\ :
 
@@ -542,15 +543,15 @@ POEMS package
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_OPT=yes".
+No additional settings are needed besides ``-D PKG_OPT=yes``
 
 **Traditional make**\ :
 
-Before building LAMMPS, you must build the POEMS library in lib/poems.
+Before building LAMMPS, you must build the POEMS library in ``lib/poems``\ .
 You can do this manually if you prefer; follow the instructions in
-lib/poems/README.  You can also do it in one step from the lammps/src
+``lib/poems/README``\ .  You can also do it in one step from the ``lammps/src``
 dir, using a command like these, which simply invoke the
-lib/poems/Install.py script with the specified args:
+``lib/poems/Install.py`` script with the specified args:
 
 .. code-block:: bash
 
@@ -559,13 +560,13 @@ lib/poems/Install.py script with the specified args:
   $ make lib-poems args="-m mpi"     # build with default MPI C++ compiler (settings as with "make mpi")
   $ make lib-poems args="-m icc"     # build with Intel icc compiler
 
-The build should produce two files: lib/poems/libpoems.a and
+The build should produce two files: ``lib/poems/libpoems.a`` and
-lib/poems/Makefile.lammps.  The latter is copied from an existing
+``lib/poems/Makefile.lammps``\ .  The latter is copied from an existing
-Makefile.lammps.\* and has settings needed to build LAMMPS with the
+``Makefile.lammps.\*`` and has settings needed to build LAMMPS with the
 POEMS library (though typically the settings are just blank).  If
-necessary, you can edit/create a new lib/poems/Makefile.machine file
+necessary, you can edit/create a new ``lib/poems/Makefile.machine`` file
-for your system, which should define an EXTRAMAKE variable to specify
+for your system, which should define an ``EXTRAMAKE`` variable to specify
-a corresponding Makefile.lammps.machine file.
+a corresponding ``Makefile.lammps.machine`` file.
 
 ----------
 
@@ -575,9 +576,9 @@ PYTHON package
 ---------------------------
 
 Building with the PYTHON package requires you have a Python shared
-library available on your system, which needs to be a Python 2
+library available on your system, which needs to be a Python 2.7
-version, 2.6 or later.  Python 3 is not yet supported.  See
+version or a Python 3.x version.  See ``lib/python/README`` for more
-lib/python/README for more details.
+details.
 
 **CMake build**\ :
 
@@ -588,16 +589,16 @@ lib/python/README for more details.
 Without this setting, CMake will guess the default Python on your
 system.  To use a different Python version, you can either create a
 virtualenv, activate it and then run cmake.  Or you can set the
-PYTHON\_EXECUTABLE variable to specify which Python interpreter should
+PYTHON_EXECUTABLE variable to specify which Python interpreter should
 be used.  Note note that you will also need to have the development
 headers installed for this version, e.g. python2-devel.
 
 **Traditional make**\ :
 
-The build uses the lib/python/Makefile.lammps file in the compile/link
+The build uses the ``lib/python/Makefile.lammps`` file in the compile/link
 process to find Python.  You should only need to create a new
-Makefile.lammps.\* file (and copy it to Makefile.lammps) if the LAMMPS
+``Makefile.lammps.\*`` file (and copy it to ``Makefile.lammps``\ ) if
-build fails.
+the LAMMPS build fails.
 
 ----------
 
@@ -618,11 +619,11 @@ To build with this package, you must download and build the `Voro++ library <vor
    -D VORO_LIBRARY=path      # Voro++ library file (only needed if at custom location)
    -D VORO_INCLUDE_DIR=path  # Voro++ include directory (only needed if at custom location)
 
-If DOWNLOAD\_VORO is set, the Voro++ library will be downloaded and
+If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
 built inside the CMake build directory.  If the Voro++ library is
 already on your system (in a location CMake cannot find it),
-VORO\_LIBRARY is the filename (plus path) of the Voro++ library file,
+VORO_LIBRARY is the filename (plus path) of the Voro++ library file,
-not the directory the library file is in.  VORO\_INCLUDE\_DIR is the
+not the directory the library file is in.  VORO_INCLUDE_DIR is the
 directory the Voro++ include file is in.
 
 **Traditional make**\ :
@@ -656,7 +657,7 @@ The USER-ADIOS package requires the `ADIOS I/O library <https://github.com/ornla
 version 2.3.1 or newer. Make sure that you have ADIOS built either with or
 without MPI to match if you build LAMMPS with or without MPI.
 ADIOS compilation settings for LAMMPS are automatically detected, if the PATH
-and LD\_LIBRARY\_PATH environment variables have been updated for the local ADIOS
+and LD_LIBRARY_PATH environment variables have been updated for the local ADIOS
 installation and the instructions below are followed for the respective build systems.
 
 **CMake build**\ :
@@ -674,7 +675,7 @@ Turn on the USER-ADIOS package before building LAMMPS. If the ADIOS 2.x software
 
   $ make yes-user-adios
 
-otherwise, set ADIOS2\_DIR environment variable when turning on the package:
+otherwise, set ADIOS2_DIR environment variable when turning on the package:
 
 .. code-block:: bash
 
@@ -691,8 +692,8 @@ The USER-ATC package requires the MANYBODY package also be installed.
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_USER-ATC=yes"
+No additional settings are needed besides "-D PKG_USER-ATC=yes"
-and "-D PKG\_MANYBODY=yes".
+and "-D PKG_MANYBODY=yes".
 
 **Traditional make**\ :
 
@@ -739,7 +740,7 @@ USER-AWPMD package
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_USER-AQPMD=yes".
+No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
 
 **Traditional make**\ :
 
@@ -800,12 +801,12 @@ C++11-only features.
 **CMake build**\ :
 
 This is the recommended build recipe: no additional settings are normally
-needed besides "-D PKG\_USER-COLVARS=yes".
+needed besides "-D PKG_USER-COLVARS=yes".
 
 Building and linking of Lepton (or other C++11-only features) is enabled
 automatically when compilation is carried out with C++11 support, and disabled
 otherwise.  Optionally, Lepton build may be manually controlled with the flag
-"-D COLVARS\_LEPTON=yes\|no".
+"-D COLVARS_LEPTON=yes\|no".
 
 **Traditional make**\ :
 
@@ -850,7 +851,7 @@ not need to be edited.
 USER-PLUMED package
 -------------------------------------
 
-.. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/\_installation.html
+.. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/_installation.html
 
 Before building LAMMPS with this package, you must first build PLUMED.
 PLUMED can be built as part of the LAMMPS build or installed separately
@@ -872,7 +873,7 @@ LAMMPS uses can be updated without the need for a recompile of LAMMPS
 for as long as the shared PLUMED library is ABI-compatible.
 
 The third linkage mode is "runtime" which allows the user to specify
-which PLUMED kernel should be used at runtime by using the PLUMED\_KERNEL
+which PLUMED kernel should be used at runtime by using the PLUMED_KERNEL
 environment variable. This variable should point to the location of the
 libplumedKernel.so dynamical shared object, which is then loaded at
 runtime. This mode of linking is particularly convenient for doing
@@ -889,7 +890,7 @@ LAMMPS build.
 
 **CMake build**\ :
 
-When the "-D PKG\_USER-PLUMED" flag is included in the cmake command you
+When the "-D PKG_USER-PLUMED" flag is included in the cmake command you
 must ensure that GSL is installed in locations that are specified in
 your environment.  There are then two additional commands that control
 the manner in which PLUMED is obtained and linked into LAMMPS.
@@ -899,21 +900,21 @@ the manner in which PLUMED is obtained and linked into LAMMPS.
    -D DOWNLOAD_PLUMED=value   # download PLUMED for build, value = no (default) or yes
    -D PLUMED_MODE=value       # Linkage mode for PLUMED, value = static (default), shared, or runtime
 
-If DOWNLOAD\_PLUMED is set to "yes", the PLUMED library will be
+If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
 downloaded (the version of PLUMED that will be downloaded is hard-coded
 to a vetted version of PLUMED, usually a recent stable release version)
-and built inside the CMake build directory.  If DOWNLOAD\_PLUMED is set
+and built inside the CMake build directory.  If DOWNLOAD_PLUMED is set
 to "no" (the default), CMake will try to detect and link to an installed
 version of PLUMED.  For this to work, the PLUMED library has to be
 installed into a location where the pkg-config tool can find it or the
-PKG\_CONFIG\_PATH environment variable has to be set up accordingly.
+PKG_CONFIG_PATH environment variable has to be set up accordingly.
 PLUMED should be installed in such a location if you compile it using
 the default make; make install commands.
 
-The PLUMED\_MODE setting determines the linkage mode for the PLUMED
+The PLUMED_MODE setting determines the linkage mode for the PLUMED
 library.  The allowed values for this flag are "static" (default),
 "shared", or "runtime".  For a discussion of PLUMED linkage modes,
-please see above.  When DOWNLOAD\_PLUMED is enabled the static linkage
+please see above.  When DOWNLOAD_PLUMED is enabled the static linkage
 mode is recommended.
 
 **Traditional make**\ :
@@ -952,7 +953,7 @@ package and compile LAMMPS in the usual manner:
 Once this compilation completes you should be able to run LAMMPS in the
 usual way.  For shared linkage mode, libplumed.so must be found by the
 LAMMPS executable, which on many operating systems means, you have to
-set the LD\_LIBRARY\_PATH environment variable accordingly.
+set the LD_LIBRARY_PATH environment variable accordingly.
 
 Support for the different linkage modes in LAMMPS varies for different
 operating systems, using the static linkage is expected to be the most
@@ -976,7 +977,7 @@ the HDF5 library.
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_USER-H5MD=yes".
+No additional settings are needed besides "-D PKG_USER-H5MD=yes".
 
 This should auto-detect the H5MD library on your system.  Several
 advanced CMake H5MD options exist if you need to specify where it is
@@ -1040,7 +1041,7 @@ runs with other compilers and without TBB and MKL.
 **Traditional make**\ :
 
 Choose which hardware to compile for in Makefile.machine via the
-following settings.  See src/MAKE/OPTIONS/Makefile.intel\_cpu\* and
+following settings.  See src/MAKE/OPTIONS/Makefile.intel_cpu\* and
 Makefile.knl files for examples. and src/USER-INTEL/README for
 additional information.
 
@@ -1076,8 +1077,8 @@ USER-MOLFILE package
    -D MOLFILE_INCLUDE_DIRS=path   # (optional) path where VMD molfile plugin headers are installed
    -D PKG_USER-MOLFILE=yes
 
-Using "-D PKG\_USER-MOLFILE=yes" enables the package, and setting
+Using "-D PKG_USER-MOLFILE=yes" enables the package, and setting
-"-D MOLFILE\_INCLUDE DIRS" allows to provide a custom location for
+"-D MOLFILE_INCLUDE DIRS" allows to provide a custom location for
 the molfile plugin header files. These should match the ABI of the
 plugin files used, and thus one typically sets them to include
 folder of the local VMD installation in use. LAMMPS ships with a
@@ -1109,7 +1110,7 @@ on your system.
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_USER-NETCDF=yes".
+No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
 
 This should auto-detect the NETCDF library if it is installed on your
 system at standard locations.  Several advanced CMake NETCDF options
@@ -1133,7 +1134,7 @@ USER-OMP package
 
 **CMake build**\ :
 
-No additional settings are required besides "-D PKG\_USER-OMP=yes".  If
+No additional settings are required besides "-D PKG_USER-OMP=yes".  If
 CMake detects OpenMP support, the USER-OMP code will be compiled with
 multi-threading support enabled, otherwise as optimized serial code.
 
@@ -1246,14 +1247,14 @@ lib/quip/README file for details on how to do this.
    -D QUIP_LIBRARY=path     # path to libquip.a (only needed if a custom location)
 
 CMake will not download and build the QUIP library.  But once you have
-done that, a CMake build of LAMMPS with "-D PKG\_USER-QUIP=yes" should
+done that, a CMake build of LAMMPS with "-D PKG_USER-QUIP=yes" should
-work.  Set QUIP\_LIBRARY if CMake cannot find the QUIP library.
+work.  Set QUIP_LIBRARY if CMake cannot find the QUIP library.
 
 **Traditional make**\ :
 
 The download/build procedure for the QUIP library, described in
 lib/quip/README file requires setting two environment variables,
-QUIP\_ROOT and QUIP\_ARCH.  These are accessed by the
+QUIP_ROOT and QUIP_ARCH.  These are accessed by the
 lib/quip/Makefile.lammps file which is used when you compile and link
 LAMMPS with this package.  You should only need to edit
 Makefile.lammps if the LAMMPS build can not use its settings to
@@ -1278,11 +1279,11 @@ To build with this package, you must download and build the `ScaFaCoS Coulomb so
    -D SCAFACOS_LIBRARY=path      # ScaFaCos library file (only needed if at custom location)
    -D SCAFACOS_INCLUDE_DIR=path  # ScaFaCoS include directory (only needed if at custom location)
 
-If DOWNLOAD\_SCAFACOS is set, the ScaFaCoS library will be downloaded
+If DOWNLOAD_SCAFACOS is set, the ScaFaCoS library will be downloaded
 and built inside the CMake build directory.  If the ScaFaCoS library
 is already on your system (in a location CMake cannot find it),
-SCAFACOS\_LIBRARY is the filename (plus path) of the ScaFaCoS library
+SCAFACOS_LIBRARY is the filename (plus path) of the ScaFaCoS library
-file, not the directory the library file is in.  SCAFACOS\_INCLUDE\_DIR
+file, not the directory the library file is in.  SCAFACOS_INCLUDE_DIR
 is the directory the ScaFaCoS include file is in.
 
 **Traditional make**\ :
@@ -1319,9 +1320,9 @@ Eigen3 is a template library, so you do not need to build it.
    -D DOWNLOAD_EIGEN3            # download Eigen3, value = no (default) or yes
    -D EIGEN3_INCLUDE_DIR=path    # path to Eigen library (only needed if a custom location)
 
-If DOWNLOAD\_EIGEN3 is set, the Eigen3 library will be downloaded and
+If DOWNLOAD_EIGEN3 is set, the Eigen3 library will be downloaded and
 inside the CMake build directory.  If the Eigen3 library is already on
-your system (in a location CMake cannot find it), EIGEN3\_INCLUDE\_DIR
+your system (in a location CMake cannot find it), EIGEN3_INCLUDE_DIR
 is the directory the Eigen3++ include file is in.
 
 **Traditional make**\ :
@@ -1354,7 +1355,7 @@ your system.
 
 **CMake build**\ :
 
-No additional settings are needed besides "-D PKG\_USER-VTK=yes".
+No additional settings are needed besides "-D PKG_USER-VTK=yes".
 
 This should auto-detect the VTK library if it is installed on your
 system at standard locations.  Several advanced VTK options exist if

doc/src/Build_link.rst

@@ -11,7 +11,7 @@ The :doc:`Build basics <Build_basics>` doc page explains how to build
 LAMMPS as either a shared or static library.  This results in one of
 these 2 files:
 
-.. parsed-literal::
+.. code-block:: bash
 
    liblammps.so      # shared library
    liblammps.a       # static library
@@ -25,7 +25,7 @@ these 2 files:
    then its mpi.h file needs to be included.  While it is technically
    possible to use a full MPI library in the calling code and link to
    a serial LAMMPS library compiled with MPI STUBS, it is recommended
-   to use the *same* MPI library for both, and then use MPI\_Comm\_split()
+   to use the *same* MPI library for both, and then use MPI_Comm_split()
    in the calling code to pass a suitable communicator with a subset
    of MPI ranks to the function creating the LAMMPS instance.
 
@@ -43,7 +43,7 @@ executable code from the library is copied into the calling executable.
 *CMake build*\ :
 
 This assumes that LAMMPS has been configured with "-D BUILD_LIB=yes"
-and installed with "make install" and the PKG\_CONFIG\_PATH environment
+and installed with "make install" and the PKG_CONFIG_PATH environment
 variable updated to include the *liblammps.pc* file installed into the
 configured destination folder, if needed.  The commands to compile and
 link the coupled executable are then:
@@ -167,7 +167,7 @@ traditional make build using "make mode=shlib serial" becomes:
 However, now the `liblammps.so` file is required at runtime and needs
 to be in a folder, where the shared linker program of the operating
 system can find it.  This would be either a folder like "/usr/local/lib64"
-or "${HOME}/.local/lib64" or a folder pointed to by the LD\_LIBRARY\_PATH
+or "${HOME}/.local/lib64" or a folder pointed to by the LD_LIBRARY_PATH
 environment variable. You can type
 
 .. code-block:: bash
@@ -177,7 +177,7 @@ environment variable. You can type
 to see what directories are in that list.
 
 Or you can add the LAMMPS src directory (or the directory you performed
-a CMake style build in) to your LD\_LIBRARY\_PATH, so that the current
+a CMake style build in) to your LD_LIBRARY_PATH, so that the current
 version of the shared library is always available to programs that use it.
 
 For the Bourne or Korn shells (/bin/sh, /bin/ksh, /bin/bash etc.), you
@@ -229,7 +229,7 @@ If a required library is missing, you would get a 'not found' entry:
 Either flavor of library (static or shared) allows one or more LAMMPS
 objects to be instantiated from the calling program. When used from a
 C++ program, most of the symbols and functions in LAMMPS are wrapped
-in a LAMMPS\_NS namespace; you can safely use any of its classes and
+in a LAMMPS_NS namespace; you can safely use any of its classes and
 methods from within the calling code, as needed, and you will not incur
 conflicts with functions and variables in your code that share the name.
 This, however, does not extend to all additional libraries bundled with

doc/src/Build_make.rst

@@ -31,7 +31,7 @@ machines, especially workstations, desktops, and laptops, so we suggest
 you try it first when building LAMMPS in those cases.
 
 The commands below perform a default LAMMPS build, producing the LAMMPS
-executable lmp\_serial and lmp\_mpi in lammps/src:
+executable lmp_serial and lmp_mpi in lammps/src:
 
 .. code-block:: bash
 
@@ -73,7 +73,7 @@ in the LAMMPS distribution.  Typing "make machine" uses
 use Makefile.serial and Makefile.mpi, respectively.  Other makefiles
 are in these directories:
 
-.. parsed-literal::
+.. code-block:: bash
 
    OPTIONS      # Makefiles which enable specific options
    MACHINES     # Makefiles for specific machines

doc/src/Build_package.rst

@@ -47,13 +47,13 @@ versus make.
 
 **CMake build**\ :
 
-.. code-block:: bash
+.. code-block:: csh
 
    -D PKG_NAME=value          # yes or no (default)
 
 Examples:
 
-.. code-block:: bash
+.. code-block:: csh
 
    -D PKG_MANYBODY=yes
    -D PKG_USER-INTEL=yes
@@ -185,7 +185,7 @@ one of them as a starting point and customize it to your needs.
 
 The following commands are useful for managing package source files
 and their installation when building LAMMPS via traditional make.
-Just type "make" in lammps/src to see a one-line summary.
+Just type ``make`` in lammps/src to see a one-line summary.
 
 These commands install/un-install sets of packages:
 
@@ -202,8 +202,8 @@ These commands install/un-install sets of packages:
     make yes-ext                        # install packages that require external libraries
     make no-ext                         # uninstall packages that require external libraries
 
-which install/un-install various sets of packages.  Typing "make
+which install/un-install various sets of packages.  Typing ``make
-package" will list all the these commands.
+package`` will list all the these commands.
 
 .. note::
 
@@ -220,23 +220,23 @@ need to use these commands unless you are editing LAMMPS files or are
 :doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web
 site.
 
-Type "make package-status" or "make ps" to show which packages are
+Type ``make package-status`` or ``make ps`` to show which packages are
 currently installed.  For those that are installed, it will list any
 files that are different in the src directory and package
 sub-directory.
 
-Type "make package-installed" or "make pi" to show which packages are
+Type ``make package-installed`` or ``make pi`` to show which packages are
 currently installed, without listing the status of packages that are
 not installed.
 
-Type "make package-update" or "make pu" to overwrite src files with
+Type ``make package-update`` or ``make pu`` to overwrite src files with
 files from the package sub-directories if the package is installed.
 It should be used after a :doc:`patch has been applied <Install_patch>`,
 since patches only update the files in the package sub-directory, but
 not the src files.
 
-Type "make package-overwrite" to overwrite files in the package
+Type ``make package-overwrite`` to overwrite files in the package
 sub-directories with src files.
 
-Type "make package-diff" to list all differences between pairs of
+Type ``make package-diff`` to list all differences between pairs of
 files in both the source directory and the package directory.

doc/src/Build_settings.rst

@@ -85,7 +85,7 @@ to assist:
    FFT_INC = -DFFT_MKL_THREADS   # enable using threaded FFTs with MKL libraries
    FFT_INC = -DFFT_PACK_ARRAY    # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
 
-# default is FFT\_PACK\_ARRAY if not specified
+# default is FFT_PACK_ARRAY if not specified
 
 .. code-block:: make
 
@@ -100,9 +100,9 @@ to assist:
    FFT_LIB =       -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core      # MKL with GNU compiler, threaded interface
    FFT_LIB =       -lmkl_rt            # MKL with automatic runtime selection of interface libs
 
-As with CMake, you do not need to set paths in FFT\_INC or FFT\_PATH, if
+As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
 the compiler can find the FFT header and library files in its default search path.
-You must specify FFT\_LIB with the appropriate FFT libraries to include in the link.
+You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
 
 **CMake and make info**\ :
 
@@ -126,14 +126,15 @@ platform and can be faster than the KISS FFT library.  You can
 download it from `www.fftw.org <http://www.fftw.org>`_.  LAMMPS requires
 version 3.X; the legacy version 2.1.X is no longer supported.
 
-Building FFTW for your box should be as simple as ./configure; make;
+Building FFTW for your box should be as simple as ``./configure; make;
-make install.  The install command typically requires root privileges
+make install``\ .  The install command typically requires root privileges
 (e.g. invoke it via sudo), unless you specify a local directory with
-the "--prefix" option of configure.  Type "./configure --help" to see
+the "--prefix" option of configure.  Type ``./configure --help`` to see
 various options.
 
 The Intel MKL math library is part of the Intel compiler suite.  It
-can be used with the Intel or GNU compiler (see FFT\_LIB setting above).
+can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
+above).
 
 Performing 3d FFTs in parallel can be time consuming due to data
 access and required communication.  This cost can be reduced by
@@ -142,15 +143,15 @@ precision means the real and imaginary parts of a complex datum are
 4-byte floats.  Double precision means they are 8-byte doubles.  Note
 that Fourier transform and related PPPM operations are somewhat less
 sensitive to floating point truncation errors and thus the resulting
-error is less than the difference in precision. Using the -DFFT\_SINGLE
+error is less than the difference in precision. Using the ``-DFFT_SINGLE``
 setting trades off a little accuracy for reduced memory use and
 parallel communication costs for transposing 3d FFT data.
 
-When using -DFFT\_SINGLE with FFTW3 you may need to build the FFTW
+When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
 library a second time with support for single-precision.
 
 For FFTW3, do the following, which should produce the additional
-library libfftw3f.a or libfftw3f.so.
+library ``libfftw3f.a`` or ``libfftw3f.so``\ .
 
 .. code-block:: bash
 
@@ -159,7 +160,7 @@ library libfftw3f.a or libfftw3f.so.
 
 Performing 3d FFTs requires communication to transpose the 3d FFT
 grid.  The data packing/unpacking for this can be done in one of 3
-modes (ARRAY, POINTER, MEMCPY) as set by the FFT\_PACK syntax above.
+modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
 Depending on the machine, the size of the FFT grid, the number of
 processors used, one option may be slightly faster.  The default is
 ARRAY mode.
@@ -187,7 +188,8 @@ adequate.
 
    LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
 
-# default is LAMMPS\_SMALLBIG if not specified
+The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
+
 **CMake and make info**\ :
 
 The default "smallbig" setting allows for simulations with:
@@ -235,7 +237,7 @@ than crashing randomly or corrupting data.
 Also note that the GPU package requires its lib/gpu library to be
 compiled with the same size setting, or the link will fail.  A CMake
 build does this automatically.  When building with make, the setting
-in whichever lib/gpu/Makefile is used must be the same as above.
+in whichever ``lib/gpu/Makefile`` is used must be the same as above.
 
 ----------
 
@@ -286,15 +288,16 @@ variables:
    JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
    JPG_LIB = -ljpeg -lpng -lz       # library names
 
-As with CMake, you do not need to set JPG\_INC or JPG\_PATH, if make can
+As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
-find the graphics header and library files.  You must specify JPG\_LIB
+if make can find the graphics header and library files.  You must
+specify ``JPG_LIB``
 with a list of graphics libraries to include in the link.  You must
 insure ffmpeg is in a directory where LAMMPS can find it at runtime,
 that is a directory in your PATH environment variable.
 
 **CMake and make info**\ :
 
-Using ffmpeg to output movie files requires that your machine
+Using ``ffmpeg`` to output movie files requires that your machine
 supports the "popen" function in the standard runtime library.
 
 .. note::
@@ -351,7 +354,7 @@ found by LAMMPS during a run.
 Memory allocation alignment
 ---------------------------------------
 
-This setting enables the use of the posix\_memalign() call instead of
+This setting enables the use of the posix_memalign() call instead of
 malloc() when LAMMPS allocates large chunks or memory.  This can make
 vector instructions on CPUs more efficient, if dynamically allocated
 memory is aligned on larger-than-default byte boundaries.
@@ -366,7 +369,7 @@ aligned on 64-byte boundaries.
 
    -D LAMMPS_MEMALIGN=value            # 0, 8, 16, 32, 64 (default)
 
-Use a LAMMPS\_MEMALIGN value of 0 to disable using posix\_memalign()
+Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using posix_memalign()
 and revert to using the malloc() C-library function instead.  When
 compiling LAMMPS for Windows systems, malloc() will always be used
 and this setting ignored.
@@ -377,8 +380,8 @@ and this setting ignored.
 
    LMP_INC = -DLAMMPS_MEMALIGN=value   # 8, 16, 32, 64
 
-Do not set -DLAMMPS\_MEMALIGN, if you want to have memory allocated
+Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory allocated
-with the malloc() function call instead. -DLAMMPS\_MEMALIGN **cannot**
+with the malloc() function call instead. ``-DLAMMPS_MEMALIGN`` **cannot**
 be used on Windows, as it does use different function calls for
 allocating aligned memory, that are not compatible with how LAMMPS
 manages its dynamical memory.

doc/src/Build_windows.rst

@@ -55,8 +55,8 @@ and the corresponding new code. A machine makefile for using cygwin for
 the old build system is provided. Using CMake for this mode of compilation
 is untested and not likely to work.
 
-When compiling for Windows do **not** set the -DLAMMPS\_MEMALIGN define
+When compiling for Windows do **not** set the -DLAMMPS_MEMALIGN define
-in the LMP\_INC makefile variable and add -lwsock32 -lpsapi to the linker
+in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
 flags in LIB makefile variable. Try adding -static-libgcc or -static or
 both to the linker flags when your resulting LAMMPS Windows executable
 complains about missing .dll files. The CMake configuration should set

doc/src/Commands_input.rst

@@ -46,7 +46,7 @@ is to have the desired effect.  For example, the
 :doc:`read_data <read_data>` command initializes the system by setting
 up the simulation box and assigning atoms to processors.  If default
 values are not desired, the :doc:`processors <processors>` and
-:doc:`boundary <boundary>` commands need to be used before read\_data to
+:doc:`boundary <boundary>` commands need to be used before read_data to
 tell LAMMPS how to map processors to the simulation box.
 
 Many input script errors are detected by LAMMPS and an ERROR or

doc/src/Commands_parse.rst

@@ -101,7 +101,7 @@ LAMMPS:
       print           "B2 = ${b$a}"
 
    Nor can you specify an expression like "$($x-1.0)" for an immediate
-   variable, but you could use $(v\_x-1.0), since the latter is valid
+   variable, but you could use $(v_x-1.0), since the latter is valid
    syntax for an :doc:`equal-style variable <variable>`.
 
    See the :doc:`variable <variable>` command for more details of how

doc/src/Errors_common.rst

@@ -69,14 +69,14 @@ but a floating-point number 1.0 is provided):
 
 Some commands allow for using variable references in place of numeric
 constants so that the value can be evaluated and may change over the
-course of a run.  This is typically done with the syntax *v\_name* for a
+course of a run.  This is typically done with the syntax *v_name* for a
 parameter, where name is the name of the variable. On the other hand,
 immediate variable expansion with the syntax ${name} is performed while
 reading the input and before parsing commands,
 
 .. note::
 
-   Using a variable reference (i.e. *v\_name*) is only allowed if
+   Using a variable reference (i.e. *v_name*) is only allowed if
    the documentation of the corresponding command explicitly says it is.
    Otherwise, you will receive an error message of this kind:
 

doc/src/Errors_warnings.rst

@@ -37,7 +37,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Angles are defined but no angle style is set*
    The topology contains angles, but there are no angle forces computed
-   since there was no angle\_style command.
+   since there was no angle_style command.
 
 *Atom style in data file differs from currently defined atom style*
    Self-explanatory.
@@ -62,7 +62,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Bonds are defined but no bond style is set*
    The topology contains bonds, but there are no bond forces computed
-   since there was no bond\_style command.
+   since there was no bond_style command.
 
 *Bond/angle/dihedral extent > half of periodic box length*
    This is a restriction because LAMMPS can be confused about which image
@@ -83,8 +83,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
    Self-explanatory.
 
-*Calling write\_dump before a full system init.*
+*Calling write_dump before a full system init.*
-   The write\_dump command is used before the system has been fully
+   The write_dump command is used before the system has been fully
    initialized as part of a 'run' or 'minimize' command. Not all dump
    styles and features are fully supported at this point and thus the
    command may fail or produce incomplete or incorrect output. Insert
@@ -131,11 +131,11 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    degrees-of-freedom for the atoms in those partial rigid bodies will
    not be accounted for.
 
-*Create\_bonds max distance > minimum neighbor cutoff*
+*Create_bonds max distance > minimum neighbor cutoff*
    This means atom pairs for some atom types may not be in the neighbor
    list and thus no bond can be created between them.
 
-*Delete\_atoms cutoff > minimum neighbor cutoff*
+*Delete_atoms cutoff > minimum neighbor cutoff*
    This means atom pairs for some atom types may not be in the neighbor
    list and thus an atom in that pair cannot be deleted.
 
@@ -158,7 +158,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Dihedrals are defined but no dihedral style is set*
    The topology contains dihedrals, but there are no dihedral forces computed
-   since there was no dihedral\_style command.
+   since there was no dihedral_style command.
 
 *Dump dcd/xtc timestamp may be wrong with fix dt/reset*
    If the fix changes the timestep, the dump dcd file will not
@@ -172,7 +172,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Estimated error in splitting of dispersion coeffs is %g*
    Error is greater than 0.0001 percent.
 
-*Ewald/disp Newton solver failed, using old method to estimate g\_ewald*
+*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
    Self-explanatory. Choosing a different cutoff value may help.
 
 *FENE bond too long*
@@ -209,8 +209,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    This is probably an error, since you should not delete only one atom
    of a molecule.
 
-*Fix gcmc using full\_energy option*
+*Fix gcmc using full_energy option*
-   Fix gcmc has automatically turned on the full\_energy option since it
+   Fix gcmc has automatically turned on the full_energy option since it
    is required for systems like the one specified by the user. User input
    included one or more of the following: kspace, triclinic, a hybrid
    pair style, an eam pair style, or no "single" function for the pair
@@ -265,19 +265,19 @@ This will most likely cause errors in kinetic fluctuations.
 *Fixes cannot send data in Kokkos communication, switching to classic communication*
    This is current restriction with Kokkos.
 
-*For better accuracy use 'pair\_modify table 0'*
+*For better accuracy use 'pair_modify table 0'*
    The user-specified force accuracy cannot be achieved unless the table
-   feature is disabled by using 'pair\_modify table 0'.
+   feature is disabled by using 'pair_modify table 0'.
 
 *Geometric mixing assumed for 1/r\^6 coefficients*
    Self-explanatory.
 
-*Group for fix\_modify temp != fix group*
+*Group for fix_modify temp != fix group*
-   The fix\_modify command is specifying a temperature computation that
+   The fix_modify command is specifying a temperature computation that
    computes a temperature on a different group of atoms than the fix
    itself operates on.  This is probably not what you want to do.
 
-*H matrix size has been exceeded: m\_fill=%d H.m=%d\n*
+*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
    This is the size of the matrix.
 
 *Ignoring unknown or incorrect info command flag*
@@ -299,7 +299,7 @@ This will most likely cause errors in kinetic fluctuations.
 
 *Impropers are defined but no improper style is set*
    The topology contains impropers, but there are no improper forces computed
-   since there was no improper\_style command.
+   since there was no improper_style command.
 
 *Inconsistent image flags*
    The image flags for a pair on bonded atoms appear to be inconsistent.
@@ -334,22 +334,22 @@ This will most likely cause errors in kinetic fluctuations.
 *KIM Model does not provide 'particleVirial'; virial per atom will be zero*
    Self-explanatory.
 
-*Kspace\_modify slab param < 2.0 may cause unphysical behavior*
+*Kspace_modify slab param < 2.0 may cause unphysical behavior*
-   The kspace\_modify slab parameter should be larger to insure periodic
+   The kspace_modify slab parameter should be larger to insure periodic
    grids padded with empty space do not overlap.
 
 *Less insertions than requested*
    The fix pour command was unsuccessful at finding open space
    for as many particles as it tried to insert.
 
-*Library error in lammps\_gather\_atoms*
+*Library error in lammps_gather_atoms*
    This library function cannot be used if atom IDs are not defined
    or are not consecutively numbered.
 
-*Library error in lammps\_scatter\_atoms*
+*Library error in lammps_scatter_atoms*
    This library function cannot be used if atom IDs are not defined or
    are not consecutively numbered, or if no atom map is defined.  See the
-   atom\_modify command for details about atom maps.
+   atom_modify command for details about atom maps.
 
 *Likewise 1-2 special neighbor interactions != 1.0*
    The topology contains bonds, but there is no bond style defined
@@ -372,15 +372,15 @@ This will most likely cause errors in kinetic fluctuations.
    pairs in the neighbor list in expectation of interactions for
    those pairs being computed from the dihedral style.
 
-*Lost atoms via change\_box: original %ld current %ld*
+*Lost atoms via change_box: original %ld current %ld*
    The command options you have used caused atoms to be lost.
 
-*Lost atoms via displace\_atoms: original %ld current %ld*
+*Lost atoms via displace_atoms: original %ld current %ld*
    The command options you have used caused atoms to be lost.
 
 *Lost atoms: original %ld current %ld*
    Lost atoms are checked for each time thermo output is done.  See the
-   thermo\_modify lost command for options.  Lost atoms usually indicate
+   thermo_modify lost command for options.  Lost atoms usually indicate
    bad dynamics, e.g. atoms have been blown far out of the simulation
    box, or moved further than one processor's sub-domain away before
    reneighboring.
@@ -403,8 +403,8 @@ This will most likely cause errors in kinetic fluctuations.
    This means the bonded atoms will not be excluded in pair-wise
    interactions.
 
-*Molecule template for create\_atoms has multiple molecules*
+*Molecule template for create_atoms has multiple molecules*
-   The create\_atoms command will only create molecules of a single type,
+   The create_atoms command will only create molecules of a single type,
    i.e. the first molecule in the template.
 
 *Molecule template for fix gcmc has multiple molecules*
@@ -469,21 +469,21 @@ This will most likely cause errors in kinetic fluctuations.
 *Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
    This is because excluding specific pair interactions also excludes
    them from long-range interactions which may not be the desired effect.
-   The special\_bonds command handles this consistently by insuring
+   The special_bonds command handles this consistently by insuring
    excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
    consistently by both the short-range pair style and the long-range
    solver.  This is not done for exclusions of charged atom pairs via the
-   neigh\_modify exclude command.
+   neigh_modify exclude command.
 
-*New thermo\_style command, previous thermo\_modify settings will be lost*
+*New thermo_style command, previous thermo_modify settings will be lost*
-   If a thermo\_style command is used after a thermo\_modify command, the
+   If a thermo_style command is used after a thermo_modify command, the
-   settings changed by the thermo\_modify command will be reset to their
+   settings changed by the thermo_modify command will be reset to their
-   default values.  This is because the thermo\_modify command acts on
+   default values.  This is because the thermo_modify command acts on
-   the currently defined thermo style, and a thermo\_style command creates
+   the currently defined thermo style, and a thermo_style command creates
    a new style.
 
 *No Kspace calculation with verlet/split*
-   The 2nd partition performs a kspace calculation so the kspace\_style
+   The 2nd partition performs a kspace calculation so the kspace_style
    command must be used.
 
 *No automatic unit conversion to XTC file format conventions possible for units lj*
@@ -507,7 +507,7 @@ This will most likely cause errors in kinetic fluctuations.
    of two and the number of grid points in one or more directions have been
    adjusted to meet this requirement.
 
-*OMP\_NUM\_THREADS environment is not set.*
+*OMP_NUM_THREADS environment is not set.*
    This environment variable must be set appropriately to use the
    USER-OMP package.
 
@@ -541,10 +541,10 @@ This will most likely cause errors in kinetic fluctuations.
 *Pair dpd needs newton pair on for momentum conservation*
    Self-explanatory.
 
-*Pair dsmc: num\_of\_collisions > number\_of\_A*
+*Pair dsmc: num_of_collisions > number_of_A*
    Collision model in DSMC is breaking down.
 
-*Pair dsmc: num\_of\_collisions > number\_of\_B*
+*Pair dsmc: num_of_collisions > number_of_B*
    Collision model in DSMC is breaking down.
 
 *Pair style in data file differs from currently defined pair style*
@@ -569,15 +569,15 @@ This will most likely cause errors in kinetic fluctuations.
    sub-domain before reneighboring is triggered.
 
 *Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Replacing a fix, but new group != old group*
@@ -590,19 +590,19 @@ This will most likely cause errors in kinetic fluctuations.
    dimension to be replicated; this may cause unwanted behavior.
 
 *Resetting reneighboring criteria during PRD*
-   A PRD simulation requires that neigh\_modify settings be delay = 0,
+   A PRD simulation requires that neigh_modify settings be delay = 0,
    every = 1, check = yes.  Since these settings were not in place,
    LAMMPS changed them and will restore them to their original values
    after the PRD simulation.
 
 *Resetting reneighboring criteria during TAD*
-   A TAD simulation requires that neigh\_modify settings be delay = 0,
+   A TAD simulation requires that neigh_modify settings be delay = 0,
    every = 1, check = yes.  Since these settings were not in place,
    LAMMPS changed them and will restore them to their original values
    after the PRD simulation.
 
 *Resetting reneighboring criteria during minimization*
-   Minimization requires that neigh\_modify settings be delay = 0, every =
+   Minimization requires that neigh_modify settings be delay = 0, every =
    1, check = yes.  Since these settings were not in place, LAMMPS
    changed them and will restore them to their original values after the
    minimization.
@@ -706,7 +706,7 @@ This will most likely cause errors in kinetic fluctuations.
    which does operate on group all, so this may be inconsistent.
 
 *Temperature for thermo pressure is not for group all*
-   User-assigned temperature to thermo via the thermo\_modify command does
+   User-assigned temperature to thermo via the thermo_modify command does
    not compute temperature for all atoms.  Since thermo computes a global
    pressure, the kinetic energy contribution from the temperature is
    assumed to also be for all atoms.  Thus the pressure printed by thermo
@@ -738,12 +738,12 @@ This will most likely cause errors in kinetic fluctuations.
    LAMMPS simulation may be inefficient as a result.
 
 *Use special bonds = 0,1,1 with bond style fene*
-   Most FENE models need this setting for the special\_bonds command.
+   Most FENE models need this setting for the special_bonds command.
 
 *Use special bonds = 0,1,1 with bond style fene/expand*
-   Most FENE models need this setting for the special\_bonds command.
+   Most FENE models need this setting for the special_bonds command.
 
-*Using a many-body potential with bonds/angles/dihedrals and special\_bond exclusions*
+*Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions*
    This is likely not what you want to do.  The exclusion settings will
    eliminate neighbors in the neighbor list, which the many-body potential
    needs to calculated its terms correctly.
@@ -772,13 +772,13 @@ This will most likely cause errors in kinetic fluctuations.
 *Using largest cutoff for lj/long/coul/long*
    Self-explanatory.
 
-*Using largest cutoff for pair\_style lj/long/tip4p/long*
+*Using largest cutoff for pair_style lj/long/tip4p/long*
    Self-explanatory.
 
 *Using package gpu without any pair style defined*
    Self-explanatory.
 
-*Using pair potential shift with pair\_modify compute no*
+*Using pair potential shift with pair_modify compute no*
    The shift effects will thus not be computed.
 
 *Using pair tail corrections with nonperiodic system*
@@ -786,8 +786,8 @@ This will most likely cause errors in kinetic fluctuations.
    computed by integrating the density of a periodic system out to
    infinity.
 
-*Using pair tail corrections with pair\_modify compute no*
+*Using pair tail corrections with pair_modify compute no*
    The tail corrections will thus not be computed.
 
-*pair style reax is now deprecated and will soon be retired. Users should switch to pair\_style reax/c*
+*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
    Self-explanatory.

doc/src/Examples.rst

@@ -132,7 +132,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | reax        | RDX and TATB models using the ReaxFF                             |
 +-------------+------------------------------------------------------------------+
-| rerun       | use of rerun and read\_dump commands                             |
+| rerun       | use of rerun and read_dump commands                              |
 +-------------+------------------------------------------------------------------+
 | rigid       | rigid bodies modeled as independent or coupled                   |
 +-------------+------------------------------------------------------------------+
@@ -155,7 +155,7 @@ Lowercase directories
 
 Here is how you can run and visualize one of the sample problems:
 
-.. parsed-literal::
+.. code-block:: bash
 
    cd indent
    cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
@@ -170,16 +170,16 @@ web site.
 If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
 script a series of JPG images will be produced by the run (assuming
 you built LAMMPS with JPG support; see the
-:doc:`Build\_settings <Build_settings>` doc page for details).  These can
+:doc:`Build_settings <Build_settings>` doc page for details).  These can
 be viewed individually or turned into a movie or animated by tools
 like ImageMagick or QuickTime or various Windows-based tools.  See the
 :doc:`dump image <dump_image>` doc page for more details.  E.g. this
 Imagemagick command would create a GIF file suitable for viewing in a
 browser.
 
-.. parsed-literal::
+.. code-block:: bash
 
-   % convert -loop 1 \*.jpg foo.gif
+   % convert -loop 1 *.jpg foo.gif
 
 ----------
 
@@ -195,7 +195,7 @@ Uppercase directories
 +------------+--------------------------------------------------------------------------------------------------+
 | ELASTIC    | compute elastic constants at zero temperature                                                    |
 +------------+--------------------------------------------------------------------------------------------------+
-| ELASTIC\_T | compute elastic constants at finite temperature                                                  |
+| ELASTIC_T  | compute elastic constants at finite temperature                                                  |
 +------------+--------------------------------------------------------------------------------------------------+
 | HEAT       | compute thermal conductivity for LJ and water via fix ehex                                       |
 +------------+--------------------------------------------------------------------------------------------------+
@@ -219,7 +219,7 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the :doc:`Packages\_details <Packages_details>` doc
+instructions.  See the :doc:`Packages_details <Packages_details>` doc
 page for more info on specific USER packages.
 
 .. _openkim: https://openkim.org

doc/src/Howto_2d.rst

@@ -8,7 +8,7 @@ command.  This is the default.
 
 If using the :doc:`create box <create_box>` command to define a
 simulation box, set the z dimensions narrow, but finite, so that the
-create\_atoms command will tile the 3d simulation box with a single z
+create_atoms command will tile the 3d simulation box with a single z
 plane of atoms - e.g.
 
 .. code-block:: LAMMPS
@@ -17,7 +17,7 @@ plane of atoms - e.g.
 
 If using the :doc:`read data <read_data>` command to read in a file of
 atom coordinates, set the "zlo zhi" values to be finite but narrow,
-similar to the create\_box command settings just described.  For each
+similar to the create_box command settings just described.  For each
 atom in the file, assign a z coordinate so it falls inside the
 z-boundaries of the box - e.g. 0.0.
 

doc/src/Howto_bash.rst

@@ -147,7 +147,7 @@ Compiling serial version
    cd src/
    make -j 4 serial
 
-This will create an executable called lmp\_serial in the src/ directory
+This will create an executable called lmp_serial in the src/ directory
 
 Compiling MPI version
 """""""""""""""""""""
@@ -157,7 +157,7 @@ Compiling MPI version
    cd src/
    make -j 4 mpi
 
-This will create an executable called lmp\_mpi in the src/ directory
+This will create an executable called lmp_mpi in the src/ directory
 
 ----------
 
@@ -192,8 +192,8 @@ examples/melt folder
 
    cd ../examples/melt
 
-The full path of the serial executable is $LAMMPS\_DIR/lmp\_serial, while the mpi
+The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
-version is $LAMMPS\_DIR/lmp\_mpi. You can run the melt example with either
+version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
 version as follows:
 
 .. code-block:: bash
@@ -206,7 +206,7 @@ or
 
    mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt
 
-Note the use of our variable $LAMMPS\_DIR, which expands into the full path of
+Note the use of our variable $LAMMPS_DIR, which expands into the full path of
 the LAMMPS src folder we saved earlier.
 
 Adding your executable directory to your PATH
@@ -241,7 +241,7 @@ and add this line
 
 **Example:**
 
-For an executable lmp\_serial with a full path
+For an executable lmp_serial with a full path
 
 .. code-block:: bash
 

doc/src/Howto_body.rst

@@ -112,7 +112,7 @@ vanilla, prototypical example of a body particle, although as
 mentioned above, the :doc:`fix rigid <fix_rigid>` command already
 duplicates its functionality.
 
-The atom\_style body command for this body style takes two additional
+The atom_style body command for this body style takes two additional
 arguments:
 
 .. parsed-literal::
@@ -188,14 +188,14 @@ The *bflag2* argument is ignored.
 The *rounded/polygon* body style represents body particles as a 2d
 polygon with a variable number of N vertices.  This style can only be
 used for 2d models; see the :doc:`boundary <boundary>` command.  See the
-"pair\_style body/rounded/polygon" doc page for a diagram of two
+"pair_style body/rounded/polygon" doc page for a diagram of two
 squares with rounded circles at the vertices.  Special cases for N = 1
 (circle) and N = 2 (rod with rounded ends) can also be specified.
 
 One use of this body style is for 2d discrete element models, as
 described in :ref:`Fraige <body-Fraige>`.
 
-Similar to body style *nparticle*\ , the atom\_style body command for
+Similar to body style *nparticle*\ , the atom_style body command for
 this body style takes two additional arguments:
 
 .. parsed-literal::
@@ -301,7 +301,7 @@ body particles with a wall.
 The *rounded/polyhedron* body style represents body particles as a 3d
 polyhedron with a variable number of N vertices, E edges and F faces.
 This style can only be used for 3d models; see the
-:doc:`boundary <boundary>` command.  See the "pair\_style
+:doc:`boundary <boundary>` command.  See the "pair_style
 body/rounded/polygon" doc page for a diagram of a two 2d squares with
 rounded circles at the vertices.  A 3d cube with rounded spheres at
 the 8 vertices and 12 rounded edges would be similar.  Special cases
@@ -311,7 +311,7 @@ specified.
 This body style is for 3d discrete element models, as described in
 :ref:`Wang <body-Wang>`.
 
-Similar to body style *rounded/polygon*\ , the atom\_style body command
+Similar to body style *rounded/polygon*\ , the atom_style body command
 for this body style takes two additional arguments:
 
 .. parsed-literal::

doc/src/Howto_client_server.rst

@@ -93,22 +93,22 @@ client or server code:
 
 * examples/message
 * examples/COUPLE/README
-* examples/COUPLE/lammps\_mc
+* examples/COUPLE/lammps_mc
-* examples/COUPLE/lammps\_nwchem
+* examples/COUPLE/lammps_nwchem
-* examples/COUPLE/lammps\_vasp
+* examples/COUPLE/lammps_vasp
 
 The examples/message directory couples a client instance of LAMMPS to a
 server instance of LAMMPS.
 
-The files in the *lammps\_mc* folder show how to couple LAMMPS as
+The files in the *lammps_mc* folder show how to couple LAMMPS as
 a server to a simple Monte Carlo client code as the driver.
 
-The files in the *lammps\_nwchem* folder show how to couple LAMMPS
+The files in the *lammps_nwchem* folder show how to couple LAMMPS
 as a client code running MD timestepping to NWChem acting as a
 server providing quantum DFT forces, through a Python wrapper script
 on NWChem.
 
-The files in the *lammps\_vasp* folder show how to couple LAMMPS as
+The files in the *lammps_vasp* folder show how to couple LAMMPS as
 a client code running MD timestepping to VASP acting as a server
 providing quantum DFT forces, through a Python wrapper script on VASP.
 

doc/src/Howto_couple.rst

@@ -64,9 +64,9 @@ examples/COUPLE/README for more details:
   library
 * plugin: simple driver program in C which invokes LAMMPS as a plugin
   from a shared library.
-* lammps\_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
+* lammps_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
   MD with quantum forces calculated by a density functional code
-* lammps\_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
+* lammps_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
   a kinetic Monte Carlo model for grain growth using MD to calculate
   strain induced across grain boundaries
 
@@ -89,7 +89,7 @@ The files src/library.cpp and library.h contain the C-style interface
 to LAMMPS.  See the :doc:`Howto library <Howto_library>` doc page for a
 description of the interface and how to extend it for your needs.
 
-Note that the lammps\_open() function that creates an instance of
+Note that the lammps_open() function that creates an instance of
 LAMMPS takes an MPI communicator as an argument.  This means that
 instance of LAMMPS will run on the set of processors in the
 communicator.  Thus the calling code can run LAMMPS on all or a subset

doc/src/Howto_dispersion.rst

@@ -29,7 +29,7 @@ that provide fast and accurate simulations, there are two approaches,
 which both have their up- and downsides.
 
 The first approach is to set desired real-space an kspace accuracies
-via the *kspace\_modify force/disp/real* and *kspace\_modify
+via the *kspace_modify force/disp/real* and *kspace_modify
 force/disp/kspace* commands. Note that the accuracies have to be
 specified in force units and are thus dependent on the chosen unit
 settings. For real units, 0.0001 and 0.002 seem to provide reasonable
@@ -37,14 +37,14 @@ accurate and efficient computations for the real-space and kspace
 accuracies.  0.002 and 0.05 work well for most systems using lj
 units. PPPM parameters will be generated based on the desired
 accuracies. The upside of this approach is that it usually provides a
-good set of parameters and will work for both the *kspace\_modify diff
+good set of parameters and will work for both the *kspace_modify diff
-ad* and *kspace\_modify diff ik* options.  The downside of the method
+ad* and *kspace_modify diff ik* options.  The downside of the method
 is that setting the PPPM parameters will take some time during the
 initialization of the simulation.
 
 The second approach is to set the parameters for the pppm/disp
-explicitly using the *kspace\_modify mesh/disp*, *kspace\_modify
+explicitly using the *kspace_modify mesh/disp*, *kspace_modify
-order/disp*, and *kspace\_modify gewald/disp* commands. This approach
+order/disp*, and *kspace_modify gewald/disp* commands. This approach
 requires a more experienced user who understands well the impact of
 the choice of parameters on the simulation accuracy and
 performance. This approach provides a fast initialization of the
@@ -60,12 +60,12 @@ To avoid inaccurate or inefficient simulations, the pppm/disp stops
 simulations with an error message if no action is taken to control the
 PPPM parameters. If the automatic parameter generation is desired and
 real-space and kspace accuracies are desired to be equal, this error
-message can be suppressed using the *kspace\_modify disp/auto yes*
+message can be suppressed using the *kspace_modify disp/auto yes*
 command.
 
 A reasonable approach that combines the upsides of both methods is to
-make the first run using the *kspace\_modify force/disp/real* and
+make the first run using the *kspace_modify force/disp/real* and
-*kspace\_modify force/disp/kspace* commands, write down the PPPM
+*kspace_modify force/disp/kspace* commands, write down the PPPM
 parameters from the output, and specify these parameters using the
 second approach in subsequent runs (which have the same composition,
 force field, and approximately the same volume).
@@ -82,8 +82,8 @@ The second is that the mixing rule of the pair style has an impact on
 the computation time when using the pppm/disp. Fastest computations
 are achieved when using the geometric mixing rule. Using the
 arithmetic mixing rule substantially increases the computational cost.
-The computational overhead can be reduced using the *kspace\_modify
+The computational overhead can be reduced using the *kspace_modify
-mix/disp geom* and *kspace\_modify splittol* commands. The first
+mix/disp geom* and *kspace_modify splittol* commands. The first
 command simply enforces geometric mixing of the dispersion
 coefficients in kspace computations.  This introduces some error in
 the computations but will also significantly speed-up the
@@ -94,7 +94,7 @@ command, but will usually also not provide an equally good increase of
 efficiency.
 
 Finally, pppm/disp can also be used when no mixing rules apply.
-This can be achieved using the *kspace\_modify mix/disp none* command.
+This can be achieved using the *kspace_modify mix/disp none* command.
 Note that the code does not check automatically whether any mixing
 rule is fulfilled. If mixing rules do not apply, the user will have
 to specify this command explicitly.

doc/src/Howto_drude.rst

@@ -48,7 +48,7 @@ for a Langevin thermostat, or :doc:`fix drude/transform/\* <fix_drude_transform>
 thermostat. The former requires use of the command :doc:`comm_modify vel yes <comm_modify>`. The latter requires two separate integration
 fixes like *nvt* or *npt*\ . The correct temperatures of the reduced
 degrees of freedom can be calculated using the :doc:`compute temp/drude <compute_temp_drude>`. This requires also to use the
-command *comm\_modify vel yes*.
+command *comm_modify vel yes*.
 
 Short-range damping of the induced dipole interactions can be achieved
 using Thole functions through the :doc:`pair style thole <pair_thole>` in :doc:`pair_style hybrid/overlay <pair_hybrid>`

doc/src/Howto_drude2.rst

@@ -76,14 +76,14 @@ important features:
 **Preparation of the data file**
 
 The data file is similar to a standard LAMMPS data file for
-*atom\_style full*.  The DPs and the *harmonic bonds* connecting them
+*atom_style full*.  The DPs and the *harmonic bonds* connecting them
 to their DC should appear in the data file as normal atoms and bonds.
 
 You can use the *polarizer* tool (Python script distributed with the
 USER-DRUDE package) to convert a non-polarizable data file (here
 *data.102494.lmp*\ ) to a polarizable data file (\ *data-p.lmp*\ )
 
-.. parsed-literal::
+.. code-block:: bash
 
    polarizer -q -f phenol.dff data.102494.lmp data-p.lmp
 
@@ -159,9 +159,9 @@ Let us assume we want to run a simple NVT simulation at 300 K.  Note
 that Drude oscillators need to be thermalized at a low temperature in
 order to approximate a self-consistent field (SCF), therefore it is not
 possible to simulate an NVE ensemble with this package.  Since dipoles
-are approximated by a charged DC-DP pair, the *pair\_style* must
+are approximated by a charged DC-DP pair, the *pair_style* must
 include Coulomb interactions, for instance *lj/cut/coul/long* with
-*kspace\_style pppm*. For example, with a cutoff of 10. and a precision
+*kspace_style pppm*. For example, with a cutoff of 10. and a precision
 1.e-4:
 
 .. code-block:: LAMMPS
@@ -169,9 +169,9 @@ include Coulomb interactions, for instance *lj/cut/coul/long* with
    pair_style lj/cut/coul/long 10.0
    kspace_style pppm 1.0e-4
 
-As compared to the non-polarizable input file, *pair\_coeff* lines need
+As compared to the non-polarizable input file, *pair_coeff* lines need
 to be added for the DPs.  Since the DPs have no Lennard-Jones
-interactions, their :math:`\epsilon` is 0. so the only *pair\_coeff* line
+interactions, their :math:`\epsilon` is 0. so the only *pair_coeff* line
 that needs to be added is
 
 .. code-block:: LAMMPS
@@ -222,7 +222,7 @@ modification of forces but no position/velocity updates), the fix
    fix NVE all nve
 
 Finally, do not forget to update the atom type elements if you use
-them in a *dump\_modify ... element ...* command, by adding the element
+them in a *dump_modify ... element ...* command, by adding the element
 type of the DPs. Here for instance
 
 .. code-block:: LAMMPS
@@ -232,19 +232,19 @@ type of the DPs. Here for instance
 
 The input file should now be ready for use!
 
-You will notice that the global temperature *thermo\_temp* computed by
+You will notice that the global temperature *thermo_temp* computed by
 LAMMPS is not 300. K as wanted.  This is because LAMMPS treats DPs as
 standard atoms in his default compute.  If you want to output the
 temperatures of the DC-DP pair centers of mass and of the DPs relative
-to their DCs, you should use the :doc:`compute temp\_drude <compute_temp_drude>`
+to their DCs, you should use the :doc:`compute temp_drude <compute_temp_drude>`
 
 .. code-block:: LAMMPS
 
    compute TDRUDE all temp/drude
 
 And then output the correct temperatures of the Drude oscillators
-using *thermo\_style custom* with respectively *c\_TDRUDE[1]* and
+using *thermo_style custom* with respectively *c_TDRUDE[1]* and
-*c\_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
+*c_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
 
 .. code-block:: LAMMPS
 
@@ -263,8 +263,8 @@ between nearby dipoles on the same molecule may be exaggerated.  Often,
 special bond relations prevent bonded neighboring atoms to see the
 charge of each other's DP, so that the problem does not always appear.
 It is possible to use screened dipole-dipole interactions by using the
-:doc:`*pair\_style thole* <pair_thole>`.  This is implemented as a
+:doc:`*pair_style thole* <pair_thole>`.  This is implemented as a
-correction to the Coulomb pair\_styles, which dampens at short distance
+correction to the Coulomb pair_styles, which dampens at short distance
 the interactions between the charges representing the induced dipoles.
 It is to be used as *hybrid/overlay* with any standard *coul* pair
 style.  In our example, we would use
@@ -273,15 +273,15 @@ style.  In our example, we would use
 
    pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0
 
-This tells LAMMPS that we are using two pair\_styles.  The first one is
+This tells LAMMPS that we are using two pair_styles.  The first one is
 as above (\ *lj/cut/coul/long 10.0*\ ).  The second one is a *thole*
-pair\_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
+pair_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
 cutoff 10.0.
 
 Since *hybrid/overlay* does not support mixing rules, the interaction
 coefficients of all the pairs of atom types with i < j should be
 explicitly defined.  The output of the *polarizer* script can be used
-to complete the *pair\_coeff* section of the input file.  In our
+to complete the *pair_coeff* section of the input file.  In our
 example, this will look like:
 
 .. code-block:: LAMMPS
@@ -324,17 +324,17 @@ For the *thole* pair style the coefficients are
 
 #. the atom polarizability in units of cubic length
 #. the screening factor of the Thole function (optional, default value
-   specified by the pair\_style command)
+   specified by the pair_style command)
-#. the cutoff (optional, default value defined by the pair\_style command)
+#. the cutoff (optional, default value defined by the pair_style command)
 
 The special neighbors have charge-charge and charge-dipole
-interactions screened by the *coul* factors of the *special\_bonds*
+interactions screened by the *coul* factors of the *special_bonds*
 command (0.0, 0.0, and 0.5 in the example above).  Without using the
-pair\_style *thole*\ , dipole-dipole interactions are screened by the
+pair_style *thole*\ , dipole-dipole interactions are screened by the
-same factor.  By using the pair\_style *thole*\ , dipole-dipole
+same factor.  By using the pair_style *thole*\ , dipole-dipole
 interactions are screened by Thole's function, whatever their special
 relationship (except within each DC-DP pair of course).  Consider for
-example 1-2 neighbors: using the pair\_style *thole*\ , their dipoles
+example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
 will see each other (despite the *coul* factor being 0.) and the
 interactions between these dipoles will be damped by Thole's function.
 
@@ -375,7 +375,7 @@ For our phenol example, the groups would be defined as
    group DRUDES type 6 7 8     # DPs
 
 Note that with the fixes *drude/transform*\ , it is not required to
-specify *comm\_modify vel yes* because the fixes do it anyway (several
+specify *comm_modify vel yes* because the fixes do it anyway (several
 times and for the forces also).  To avoid the flying ice cube artifact
 :ref:`(Lamoureux) <Lamoureux2>`, where the atoms progressively freeze and the
 center of mass of the whole system drifts faster and faster, the *fix
@@ -392,7 +392,7 @@ DPs should be *nvt* (or vice versa).  Second, the *fix npt* computes a
 global pressure and thus a global temperature whatever the fix group.
 We do want the pressure to correspond to the whole system, but we want
 the temperature to correspond to the fix group only.  We must then use
-the *fix\_modify* command for this.  In the end, the block of
+the *fix_modify* command for this.  In the end, the block of
 instructions for thermostatting and barostatting will look like
 
 .. code-block:: LAMMPS

doc/src/Howto_elastic.rst

@@ -4,14 +4,14 @@ Calculate elastic constants
 Elastic constants characterize the stiffness of a material. The formal
 definition is provided by the linear relation that holds between the
 stress and strain tensors in the limit of infinitesimal deformation.
-In tensor notation, this is expressed as s\_ij = C\_ijkl \* e\_kl, where
+In tensor notation, this is expressed as s_ij = C_ijkl \* e_kl, where
-the repeated indices imply summation. s\_ij are the elements of the
+the repeated indices imply summation. s_ij are the elements of the
-symmetric stress tensor. e\_kl are the elements of the symmetric strain
+symmetric stress tensor. e_kl are the elements of the symmetric strain
-tensor. C\_ijkl are the elements of the fourth rank tensor of elastic
+tensor. C_ijkl are the elements of the fourth rank tensor of elastic
 constants. In three dimensions, this tensor has 3\^4=81 elements. Using
-Voigt notation, the tensor can be written as a 6x6 matrix, where C\_ij
+Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
-is now the derivative of s\_i w.r.t. e\_j. Because s\_i is itself a
+is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
-derivative w.r.t. e\_i, it follows that C\_ij is also symmetric, with at
+derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
 most 7\*6/2 = 21 distinct elements.
 
 At zero temperature, it is easy to estimate these derivatives by

doc/src/Howto_github.rst

@@ -287,10 +287,10 @@ After each push, the automated checks are run again.
 
 LAMMPS developers may add labels to your pull request to assign it to
 categories (mostly for bookkeeping purposes), but a few of them are
-important: needs\_work, work\_in\_progress, test-for-regression, and
+important: needs_work, work_in_progress, test-for-regression, and
 full-regression-test. The first two indicate, that your pull request
-is not considered to be complete. With "needs\_work" the burden is on
+is not considered to be complete. With "needs_work" the burden is on
-exclusively on you; while "work\_in\_progress" can also mean, that a
+exclusively on you; while "work_in_progress" can also mean, that a
 LAMMPS developer may want to add changes. Please watch the comments
 to the pull requests. The two "test" labels are used to trigger
 extended tests before the code is merged. This is sometimes done by
@@ -458,7 +458,7 @@ should be submitted, there is now also an "unstable" and a "stable"
 branch; these have the same content as "master", but are only updated
 after a patch release or stable release was made.
 Furthermore, the naming of the patches now follow the pattern
-"patch\_<Day><Month><Year>" to simplify comparisons between releases.
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
 Finally, all patches and submissions are subject to automatic testing
 and code checks to make sure they at the very least compile.
 

doc/src/Howto_granular.rst

@@ -22,7 +22,7 @@ Use one of these 3 pair potentials, which compute forces and torques
 between interacting pairs of particles:
 
 * :doc:`pair_style <pair_style>` gran/history
-* :doc:`pair_style <pair_style>` gran/no\_history
+* :doc:`pair_style <pair_style>` gran/no_history
 * :doc:`pair_style <pair_style>` gran/hertzian
 
 These commands implement fix options specific to granular systems:

doc/src/Howto_kappa.rst

@@ -56,7 +56,7 @@ two preceding non-equilibrium methods, where energy flows continuously
 between hot and cold regions of the simulation box.
 
 The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
-the needed heat flux and describes how to implement the Green\_Kubo
+the needed heat flux and describes how to implement the Green_Kubo
 formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
 auto-correlation.  See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
 that calculates the thermal conductivity of solid Ar via the GK

doc/src/Howto_library.rst

@@ -12,7 +12,7 @@ functions therein have a C-style argument list, but contain C++ code
 you could write yourself in a C++ application that was invoking LAMMPS
 directly.  The C++ code in the functions illustrates how to invoke
 internal LAMMPS operations.  Note that LAMMPS classes are defined
-within a LAMMPS namespace (LAMMPS\_NS) if you use them from another C++
+within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
 application.
 
 The examples/COUPLE and python/examples directories have example C++
@@ -34,7 +34,7 @@ interface LAMMPS to Fortran libraries, or the code uses static variables
 
 Another major issue to deal with is to correctly handle MPI.  Creating
 a LAMMPS instance requires passing an MPI communicator, or it assumes
-the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
+the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
 When creating multiple LAMMPS object instances from different threads,
 this communicator has to be different for each thread or else collisions
 can happen, or it has to be guaranteed, that only one thread at a time
@@ -70,11 +70,11 @@ details.
    void lammps_commands_string(void *, char *)
    void lammps_free(void *)
 
-The lammps\_open() function is used to initialize LAMMPS, passing in a
+The lammps_open() function is used to initialize LAMMPS, passing in a
 list of strings as if they were :doc:`command-line arguments <Run_options>` when LAMMPS is run in stand-alone mode
 from the command line, and a MPI communicator for LAMMPS to run under.
 It returns a ptr to the LAMMPS object that is created, and which is
-used in subsequent library calls.  The lammps\_open() function can be
+used in subsequent library calls.  The lammps_open() function can be
 called multiple times, to create multiple instances of LAMMPS.
 
 LAMMPS will run on the set of processors in the communicator.  This
@@ -86,14 +86,14 @@ half to the other code and run both codes simultaneously before
 syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
 
-The lammps\_open\_no\_mpi() function is similar except that no MPI
+The lammps_open_no_mpi() function is similar except that no MPI
-communicator is passed from the caller.  Instead, MPI\_COMM\_WORLD is
+communicator is passed from the caller.  Instead, MPI_COMM_WORLD is
 used to instantiate LAMMPS, and MPI is initialized if necessary.
 
-The lammps\_close() function is used to shut down an instance of LAMMPS
+The lammps_close() function is used to shut down an instance of LAMMPS
 and free all its memory.
 
-The lammps\_version() function can be used to determined the specific
+The lammps_version() function can be used to determined the specific
 version of the underlying LAMMPS code. This is particularly useful
 when loading LAMMPS as a shared library via dlopen(). The code using
 the library interface can than use this information to adapt to
@@ -101,8 +101,8 @@ changes to the LAMMPS command syntax between versions. The returned
 LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
 20150902) that grows with every new LAMMPS version.
 
-The lammps\_file(), lammps\_command(), lammps\_commands\_list(), and
+The lammps_file(), lammps_command(), lammps_commands_list(), and
-lammps\_commands\_string() functions are used to pass one or more
+lammps_commands_string() functions are used to pass one or more
 commands to LAMMPS to execute, the same as if they were coming from an
 input script.
 
@@ -113,19 +113,19 @@ can interleave the command function calls with operations it performs,
 calls to extract information from or set information within LAMMPS, or
 calls to another code's library.
 
-The lammps\_file() function passes the filename of an input script.
+The lammps_file() function passes the filename of an input script.
-The lammps\_command() function passes a single command as a string.
+The lammps_command() function passes a single command as a string.
-The lammps\_commands\_list() function passes multiple commands in a
+The lammps_commands_list() function passes multiple commands in a
-char\*\* list.  In both lammps\_command() and lammps\_commands\_list(),
+char\*\* list.  In both lammps_command() and lammps_commands_list(),
 individual commands may or may not have a trailing newline.  The
-lammps\_commands\_string() function passes multiple commands
+lammps_commands_string() function passes multiple commands
 concatenated into one long string, separated by newline characters.
-In both lammps\_commands\_list() and lammps\_commands\_string(), a single
+In both lammps_commands_list() and lammps_commands_string(), a single
 command can be spread across multiple lines, if the last printable
 character of all but the last line is "&", the same as if the lines
 appeared in an input script.
 
-The lammps\_free() function is a clean-up function to free memory that
+The lammps_free() function is a clean-up function to free memory that
 the library allocated previously via other function calls.  See
 comments in src/library.cpp file for which other functions need this
 clean-up.
@@ -146,15 +146,15 @@ which quantities can be queried by name:
    void *lammps_extract_fix(void *, char *, int, int, int, int)
    void *lammps_extract_variable(void *, char *, char *)
 
-The extract\_setting() function returns info on the size
+The extract_setting() function returns info on the size
 of data types (e.g. 32-bit or 64-bit atom IDs) used
 by the LAMMPS executable (a compile-time choice).
 
 The other extract functions return a pointer to various global or
 per-atom quantities stored in LAMMPS or to values calculated by a
 compute, fix, or variable.  The pointer returned by the
-extract\_global() function can be used as a permanent reference to a
+extract_global() function can be used as a permanent reference to a
-value which may change.  For the extract\_atom() method, see the
+value which may change.  For the extract_atom() method, see the
 extract() method in the src/atom.cpp file for a list of valid per-atom
 properties.  New names could easily be added if the property you want
 is not listed.  For the other extract functions, the underlying
@@ -169,18 +169,18 @@ function to assure a current pointer or returned value(s).
    int lammps_set_variable(void *, char *, char *)
    void lammps_reset_box(void *, double *, double *, double, double, double)
 
-The lammps\_get\_thermo() function returns the current value of a thermo
+The lammps_get_thermo() function returns the current value of a thermo
 keyword as a double precision value.
 
-The lammps\_get\_natoms() function returns the total number of atoms in
+The lammps_get_natoms() function returns the total number of atoms in
 the system and can be used by the caller to allocate memory for the
-lammps\_gather\_atoms() and lammps\_scatter\_atoms() functions.
+lammps_gather_atoms() and lammps_scatter_atoms() functions.
 
-The lammps\_set\_variable() function can set an existing string-style
+The lammps_set_variable() function can set an existing string-style
 variable to a new string value, so that subsequent LAMMPS commands can
 access the variable.
 
-The lammps\_reset\_box() function resets the size and shape of the
+The lammps_reset_box() function resets the size and shape of the
 simulation box, e.g. as part of restoring a previously extracted and
 saved state of a simulation.
 
@@ -202,17 +202,17 @@ owned by different processors.
 .. warning::
 
    These functions are not compatible with the
-   -DLAMMPS\_BIGBIG setting when compiling LAMMPS.  Dummy functions
+   -DLAMMPS_BIGBIG setting when compiling LAMMPS.  Dummy functions
    that result in an error message and abort will be substituted
    instead of resulting in random crashes and memory corruption.
 
-The lammps\_gather\_atoms() function does this for all N atoms in the
+The lammps_gather_atoms() function does this for all N atoms in the
 system, ordered by atom ID, from 1 to N.  The
-lammps\_gather\_atoms\_concat() function does it for all N atoms, but
+lammps_gather_atoms_concat() function does it for all N atoms, but
 simply concatenates the subset of atoms owned by each processor.  The
 resulting vector is not ordered by atom ID.  Atom IDs can be requested
 by the same function if the caller needs to know the ordering.  The
-lammps\_gather\_subset() function allows the caller to request values
+lammps_gather_subset() function allows the caller to request values
 for only a subset of atoms (identified by ID).
 For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
 If the count is specified as 1, they are returned
@@ -220,10 +220,10 @@ in a packed format with all three image flags stored in a single integer.
 If the count is specified as 3, the values are unpacked into xyz flags
 by the library before returning them.
 
-The lammps\_scatter\_atoms() function takes a list of values for all N
+The lammps_scatter_atoms() function takes a list of values for all N
 atoms in the system, ordered by atom ID, from 1 to N, and assigns
 those values to each atom in the system.  The
-lammps\_scatter\_atoms\_subset() function takes a subset of IDs as an
+lammps_scatter_atoms_subset() function takes a subset of IDs as an
 argument and only scatters those values to the owning atoms.
 
 .. code-block:: c
@@ -231,12 +231,12 @@ argument and only scatters those values to the owning atoms.
    void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
                             imageint *, int)
 
-The lammps\_create\_atoms() function takes a list of N atoms as input
+The lammps_create_atoms() function takes a list of N atoms as input
 with atom types and coords (required), an optionally atom IDs and
 velocities and image flags.  It uses the coords of each atom to assign
 it as a new atom to the processor that owns it.  This function is
 useful to add atoms to a simulation or (in tandem with
-lammps\_reset\_box()) to restore a previously extracted and saved state
+lammps_reset_box()) to restore a previously extracted and saved state
 of a simulation.  Additional properties for the new atoms can then be
-assigned via the lammps\_scatter\_atoms() or lammps\_extract\_atom()
+assigned via the lammps_scatter_atoms() or lammps_extract_atom()
 functions.

doc/src/Howto_manifold.rst

@@ -19,17 +19,17 @@ to the relevant fixes.
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | cylinder       | R              | x\^2 + y\^2 - R\^2 = 0                                                                                                                 | Cylinder along z-axis, axis going through (0,0,0)                                                                                  |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| cylinder\_dent | R l a          | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise                                           | A cylinder with a dent around z = 0                                                                                                |
+| cylinder_dent  | R l a          | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise                                           | A cylinder with a dent around z = 0                                                                                                |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | dumbbell       | a A B c        | -( x\^2 + y\^2 ) + (a\^2 - z\^2/c\^2) \* ( 1 + (A\*sin(B\*z\^2))\^4) = 0                                                               | A dumbbell                                                                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | ellipsoid      | a  b c         | (x/a)\^2 + (y/b)\^2 + (z/c)\^2 = 0                                                                                                     | An ellipsoid                                                                                                                       |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| gaussian\_bump | A l rc1 rc2    | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z                           | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.                                                              |
+| gaussian_bump  | A l rc1 rc2    | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z                           | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.                                                              |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | plane          | a b c x0 y0 z0 | a\*(x-x0) + b\*(y-y0) + c\*(z-z0) = 0                                                                                                  | A plane with normal (a,b,c) going through point (x0,y0,z0)                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| plane\_wiggle  | a w            | z - a\*sin(w\*x) = 0                                                                                                                   | A plane with a sinusoidal modulation on z along x.                                                                                 |
+| plane_wiggle   | a w            | z - a\*sin(w\*x) = 0                                                                                                                   | A plane with a sinusoidal modulation on z along x.                                                                                 |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | sphere         | R              | x\^2 + y\^2 + z\^2 - R\^2 = 0                                                                                                          | A sphere of radius R                                                                                                               |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
@@ -37,7 +37,7 @@ to the relevant fixes.
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | spine          | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | An approximation to a dendritic spine                                                                                              |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| spine\_two     | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine                                                                                         |
+| spine_two      | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine                                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | thylakoid      | wB LB lB       | Various, see :ref:`(Paquay) <Paquay1>`                                                                                                 | A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+

doc/src/Howto_output.rst

@@ -68,11 +68,11 @@ notation, where ID in this case is the ID of a compute.  The leading
 "c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
 
 +-------------+--------------------------------------------+
-| c\_ID       | entire scalar, vector, or array            |
+| c_ID        | entire scalar, vector, or array            |
 +-------------+--------------------------------------------+
-| c\_ID[I]    | one element of vector, one column of array |
+| c_ID[I]     | one element of vector, one column of array |
 +-------------+--------------------------------------------+
-| c\_ID[I][J] | one element of array                       |
+| c_ID[I][J]  | one element of array                       |
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the data
@@ -92,7 +92,7 @@ The frequency and format of thermodynamic output is set by the
 :doc:`thermo_style <thermo_style>` command also specifies what values
 are calculated and written out.  Pre-defined keywords can be specified
 (e.g. press, etotal, etc).  Three additional kinds of keywords can
-also be specified (c\_ID, f\_ID, v\_name), where a :doc:`compute <compute>`
+also be specified (c_ID, f_ID, v_name), where a :doc:`compute <compute>`
 or :doc:`fix <fix>` or :doc:`variable <variable>` provides the value to be
 output.  In each case, the compute, fix, or variable must generate
 global values for input to the :doc:`thermo_style custom <dump>`
@@ -121,7 +121,7 @@ pre-defined formats (dump atom, dump xtc, etc).
 There is also a :doc:`dump custom <dump>` format where the user
 specifies what values are output with each atom.  Pre-defined atom
 attributes can be specified (id, x, fx, etc).  Three additional kinds
-of keywords can also be specified (c\_ID, f\_ID, v\_name), where a
+of keywords can also be specified (c_ID, f_ID, v_name), where a
 :doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
 provides the values to be output.  In each case, the compute, fix, or
 variable must generate per-atom values for input to the :doc:`dump custom <dump>` command.
@@ -129,7 +129,7 @@ variable must generate per-atom values for input to the :doc:`dump custom <dump>
 There is also a :doc:`dump local <dump>` format where the user specifies
 what local values to output.  A pre-defined index keyword can be
 specified to enumerate the local values.  Two additional kinds of
-keywords can also be specified (c\_ID, f\_ID), where a
+keywords can also be specified (c_ID, f_ID), where a
 :doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
 provides the values to be output.  In each case, the compute or fix
 must generate local values for input to the :doc:`dump local <dump>`

doc/src/Howto_restart.rst

@@ -46,8 +46,8 @@ last 50 timesteps:
    run             50
 
 Note that the following commands do not need to be repeated because
-their settings are included in the restart file: *units, atom\_style,
+their settings are included in the restart file: *units, atom_style,
-special\_bonds, pair\_style, bond\_style*.  However these commands do
+special_bonds, pair_style, bond_style*.  However these commands do
 need to be used, since their settings are not in the restart file:
 *neighbor, fix, timestep*\ .
 
@@ -89,7 +89,7 @@ Then, this script could be used to re-run the last 50 steps:
    run             50
 
 Note that nearly all the settings specified in the original *in.chain*
-script must be repeated, except the *pair\_coeff* and *bond\_coeff*
+script must be repeated, except the *pair_coeff* and *bond_coeff*
 commands since the new data file lists the force field coefficients.
 Also, the :doc:`reset_timestep <reset_timestep>` command is used to tell
 LAMMPS the current timestep.  This value is stored in restart files,

doc/src/Howto_spherical.rst

@@ -115,7 +115,7 @@ such interactions.  These are the various :doc:`pair styles <pair_style>` that g
 
 * :doc:`pair_style gran/history <pair_gran>`
 * :doc:`pair_style gran/hertzian <pair_gran>`
-* :doc:`pair_style gran/no\_history <pair_gran>`
+* :doc:`pair_style gran/no_history <pair_gran>`
 * :doc:`pair_style dipole/cut <pair_dipole>`
 * :doc:`pair_style gayberne <pair_gayberne>`
 * :doc:`pair_style resquared <pair_resquared>`

doc/src/Howto_triclinic.rst

@@ -221,7 +221,7 @@ calculated from the 9 triclinic box parameters
    zhi_bound = zhi
 
 These formulas can be inverted if you need to convert the bounding box
-back into the triclinic box parameters, e.g. xlo = xlo\_bound -
+back into the triclinic box parameters, e.g. xlo = xlo_bound -
 MIN(0.0,xy,xz,xy+xz).
 
 One use of triclinic simulation boxes is to model solid-state crystals

doc/src/Install_git.rst

@@ -16,7 +16,7 @@ commands explained below to communicate with the git servers on
 GitHub.  For people still using subversion (svn), GitHub also
 provides `limited support for subversion clients <svn_>`_.
 
-.. warning::
+.. note::
 
    As of October 2016, the official home of public LAMMPS development is
    on GitHub.  The previously advertised LAMMPS git repositories on

doc/src/Install_linux.rst

@@ -38,7 +38,7 @@ To install LAMMPS do the following once:
 
    $ sudo apt-get install lammps-daily
 
-This downloads an executable named "lmp\_daily" to your box, which
+This downloads an executable named "lmp_daily" to your box, which
 can then be used in the usual way to run input scripts:
 
 .. code-block:: bash
@@ -103,10 +103,10 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
 lammps-openmpi-devel), the header for compiling programs using
 the C library interface (lammps-headers), and the LAMMPS python
 module for Python 3. All packages can be installed at the same
-time and the name of the LAMMPS executable is *lmp* and *lmp\_openmpi*
+time and the name of the LAMMPS executable is *lmp* and *lmp_openmpi*
-or *lmp\_mpich* respectively.  By default, *lmp* will refer to the
+or *lmp_mpich* respectively.  By default, *lmp* will refer to the
 serial executable, unless one of the MPI environment modules is loaded
-("module load mpi/mpich-x86\_64" or "module load mpi/openmpi-x86\_64").
+("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
 Then the corresponding parallel LAMMPS executable can be used.
 The same mechanism applies when loading the LAMMPS python module.
 

doc/src/Install_mac.rst

@@ -14,7 +14,7 @@ the following commands:
 
    % brew install lammps
 
-This will install the executables "lammps\_serial" and "lammps\_mpi", as well as
+This will install the executables "lammps_serial" and "lammps_mpi", as well as
 the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
 
 Once LAMMPS is installed, you can test the installation with the

doc/src/Install_tarball.rst

@@ -26,7 +26,7 @@ command:
 
 .. code-block:: bash
 
-   $ tar -xzvf lammps\*.tar.gz
+   $ tar -xzvf lammps*.tar.gz
 
 This will create a LAMMPS directory with the version date
 in its name, e.g. lammps-23Jun18.
@@ -40,7 +40,7 @@ a lammps-master dir:
 
 .. code-block:: bash
 
-   $ unzip lammps\*.zip
+   $ unzip lammps*.zip
 
 This version is the most up-to-date LAMMPS development version.  It
 will have the date of the most recent patch release (see the file

doc/src/Install_windows.rst

@@ -4,7 +4,9 @@ Download an executable for Windows
 Pre-compiled Windows installers which install LAMMPS executables on a
 Windows system can be downloaded from this site:
 
-`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
+.. parsed-literal::
+
+  `http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
 
 Note that each installer package has a date in its name, which
 corresponds to the LAMMPS version of the same date.  Installers for
@@ -26,7 +28,7 @@ When you download the installer package, you run it on your Windows
 machine.  It will then prompt you with a dialog, where you can choose
 the installation directory, unpack and copy several executables,
 potential files, documentation pdfs, selected example files, etc.  It
-will then update a few system settings (e.g. PATH, LAMMPS\_POTENTIALS)
+will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
 and add an entry into the Start Menu (with references to the
 documentation, LAMMPS homepage and more).  From that menu, there is
 also a link to an uninstaller that removes the files and undoes the

doc/src/Manual_build.rst

@@ -5,7 +5,7 @@ Depending on how you obtained LAMMPS, the doc directory has up
 to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
 plus 2 e-book format files:
 
-.. parsed-literal::
+.. code-block:: bash
 
    src             # content files for LAMMPS documentation
    html            # HTML version of the LAMMPS manual (see html/Manual.html)
@@ -28,8 +28,8 @@ and PDF files are not included.  Instead you need to create them, in one
 of two ways:
 
 a. You can "fetch" the current HTML and PDF files from the LAMMPS web
-   site.  Just type "make fetch".  This should download a html\_www
+   site.  Just type "make fetch".  This should download a html_www
-   directory and Manual\_www.pdf/Developer\_www.pdf files.  Note that if
+   directory and Manual_www.pdf/Developer_www.pdf files.  Note that if
    new LAMMPS features have been added more recently than the date of
    your LAMMPS version, the fetched documentation will include those
    changes (but your source code will not, unless you update your local

doc/src/Modify_atom.rst

@@ -8,78 +8,78 @@ style can be created if one of the existing atom styles does not
 define all the attributes you need to store and communicate with
 atoms.
 
-Atom\_vec\_atomic.cpp is a simple example of an atom style.
+Atom_vec_atomic.cpp is a simple example of an atom style.
 
 Here is a brief description of methods you define in your new derived
-class.  See atom\_vec.h for details.
+class.  See atom_vec.h for details.
 
 +-------------------------+--------------------------------------------------------------------------------+
 | init                    | one time setup (optional)                                                      |
 +-------------------------+--------------------------------------------------------------------------------+
 | grow                    | re-allocate atom arrays to longer lengths (required)                           |
 +-------------------------+--------------------------------------------------------------------------------+
-| grow\_reset             | make array pointers in Atom and AtomVec classes consistent (required)          |
+| grow_reset              | make array pointers in Atom and AtomVec classes consistent (required)          |
 +-------------------------+--------------------------------------------------------------------------------+
 | copy                    | copy info for one atom to another atom's array locations (required)            |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_comm              | store an atom's info in a buffer communicated every timestep (required)        |
+| pack_comm               | store an atom's info in a buffer communicated every timestep (required)        |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_comm\_vel         | add velocity info to communication buffer (required)                           |
+| pack_comm_vel           | add velocity info to communication buffer (required)                           |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_comm\_hybrid      | store extra info unique to this atom style (optional)                          |
+| pack_comm_hybrid        | store extra info unique to this atom style (optional)                          |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_comm            | retrieve an atom's info from the buffer (required)                             |
+| unpack_comm             | retrieve an atom's info from the buffer (required)                             |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_comm\_vel       | also retrieve velocity info (required)                                         |
+| unpack_comm_vel         | also retrieve velocity info (required)                                         |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_comm\_hybrid    | retrieve extra info unique to this atom style (optional)                       |
+| unpack_comm_hybrid      | retrieve extra info unique to this atom style (optional)                       |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_reverse           | store an atom's info in a buffer communicating partial forces  (required)      |
+| pack_reverse            | store an atom's info in a buffer communicating partial forces  (required)      |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_reverse\_hybrid   | store extra info unique to this atom style (optional)                          |
+| pack_reverse_hybrid     | store extra info unique to this atom style (optional)                          |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_reverse         | retrieve an atom's info from the buffer (required)                             |
+| unpack_reverse          | retrieve an atom's info from the buffer (required)                             |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_reverse\_hybrid | retrieve extra info unique to this atom style (optional)                       |
+| unpack_reverse_hybrid   | retrieve extra info unique to this atom style (optional)                       |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_border            | store an atom's info in a buffer communicated on neighbor re-builds (required) |
+| pack_border             | store an atom's info in a buffer communicated on neighbor re-builds (required) |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_border\_vel       | add velocity info to buffer (required)                                         |
+| pack_border_vel         | add velocity info to buffer (required)                                         |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_border\_hybrid    | store extra info unique to this atom style (optional)                          |
+| pack_border_hybrid      | store extra info unique to this atom style (optional)                          |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_border          | retrieve an atom's info from the buffer (required)                             |
+| unpack_border           | retrieve an atom's info from the buffer (required)                             |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_border\_vel     | also retrieve velocity info (required)                                         |
+| unpack_border_vel       | also retrieve velocity info (required)                                         |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_border\_hybrid  | retrieve extra info unique to this atom style (optional)                       |
+| unpack_border_hybrid    | retrieve extra info unique to this atom style (optional)                       |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_exchange          | store all an atom's info to migrate to another processor (required)            |
+| pack_exchange           | store all an atom's info to migrate to another processor (required)            |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_exchange        | retrieve an atom's info from the buffer (required)                             |
+| unpack_exchange         | retrieve an atom's info from the buffer (required)                             |
 +-------------------------+--------------------------------------------------------------------------------+
-| size\_restart           | number of restart quantities associated with proc's atoms (required)           |
+| size_restart            | number of restart quantities associated with proc's atoms (required)           |
 +-------------------------+--------------------------------------------------------------------------------+
-| pack\_restart           | pack atom quantities into a buffer (required)                                  |
+| pack_restart            | pack atom quantities into a buffer (required)                                  |
 +-------------------------+--------------------------------------------------------------------------------+
-| unpack\_restart         | unpack atom quantities from a buffer (required)                                |
+| unpack_restart          | unpack atom quantities from a buffer (required)                                |
 +-------------------------+--------------------------------------------------------------------------------+
-| create\_atom            | create an individual atom of this style (required)                             |
+| create_atom             | create an individual atom of this style (required)                             |
 +-------------------------+--------------------------------------------------------------------------------+
-| data\_atom              | parse an atom line from the data file (required)                               |
+| data_atom               | parse an atom line from the data file (required)                               |
 +-------------------------+--------------------------------------------------------------------------------+
-| data\_atom\_hybrid      | parse additional atom info unique to this atom style (optional)                |
+| data_atom_hybrid        | parse additional atom info unique to this atom style (optional)                |
 +-------------------------+--------------------------------------------------------------------------------+
-| data\_vel               | parse one line of velocity information from data file (optional)               |
+| data_vel                | parse one line of velocity information from data file (optional)               |
 +-------------------------+--------------------------------------------------------------------------------+
-| data\_vel\_hybrid       | parse additional velocity data unique to this atom style (optional)            |
+| data_vel_hybrid         | parse additional velocity data unique to this atom style (optional)            |
 +-------------------------+--------------------------------------------------------------------------------+
-| memory\_usage           | tally memory allocated by atom arrays (required)                               |
+| memory_usage            | tally memory allocated by atom arrays (required)                               |
 +-------------------------+--------------------------------------------------------------------------------+
 
 The constructor of the derived class sets values for several variables
 that you must set when defining a new atom style, which are documented
-in atom\_vec.h.  New atom arrays are defined in atom.cpp.  Search for
+in atom_vec.h.  New atom arrays are defined in atom.cpp.  Search for
 the word "customize" and you will find locations you will need to
 modify.
 
@@ -95,12 +95,12 @@ modify.
 New :doc:`pair styles <pair_style>`, :doc:`fixes <fix>`, or
 :doc:`computes <compute>` can be added to LAMMPS, as discussed below.
 The code for these classes can use the per-atom properties defined by
-fix property/atom.  The Atom class has a find\_custom() method that is
+fix property/atom.  The Atom class has a find_custom() method that is
 useful in this context:
 
-.. parsed-literal::
+.. code-block:: c++
 
-   int index = atom->find_custom(char \*name, int &flag);
+   int index = atom->find_custom(char *name, int &flag);
 
 The "name" of a custom attribute, as specified in the :doc:`fix property/atom <fix_property_atom>` command, is checked to verify
 that it exists and its index is returned.  The method also sets flag =
@@ -108,10 +108,10 @@ that it exists and its index is returned.  The method also sets flag =
 The vector of values associated with the attribute can then be
 accessed using the returned index as
 
-.. parsed-literal::
+.. code-block:: c++
 
-   int \*ivector = atom->ivector[index];
+   int *ivector = atom->ivector[index];
-   double \*dvector = atom->dvector[index];
+   double *dvector = atom->dvector[index];
 
 Ivector or dvector are vectors of length Nlocal = # of owned atoms,
 which store the attributes of individual atoms.

doc/src/Modify_body.rst

@@ -10,14 +10,14 @@ See the :doc:`Howto body <Howto_body>` doc page for an overview of using
 body particles and the various body styles LAMMPS supports.  New
 styles can be created to add new kinds of body particles to LAMMPS.
 
-Body\_nparticle.cpp is an example of a body particle that is treated as
+Body_nparticle.cpp is an example of a body particle that is treated as
 a rigid body containing N sub-particles.
 
 Here is a brief description of methods you define in your new derived
 class.  See body.h for details.
 
 +----------------------+-----------------------------------------------------------+
-| data\_body           | process a line from the Bodies section of a data file     |
+| data_body            | process a line from the Bodies section of a data file     |
 +----------------------+-----------------------------------------------------------+
 | noutrow              | number of sub-particles output is generated for           |
 +----------------------+-----------------------------------------------------------+
@@ -25,11 +25,11 @@ class.  See body.h for details.
 +----------------------+-----------------------------------------------------------+
 | output               | output values for the Mth sub-particle                    |
 +----------------------+-----------------------------------------------------------+
-| pack\_comm\_body     | body attributes to communicate every timestep             |
+| pack_comm_body       | body attributes to communicate every timestep             |
 +----------------------+-----------------------------------------------------------+
-| unpack\_comm\_body   | unpacking of those attributes                             |
+| unpack_comm_body     | unpacking of those attributes                             |
 +----------------------+-----------------------------------------------------------+
-| pack\_border\_body   | body attributes to communicate when reneighboring is done |
+| pack_border_body     | body attributes to communicate when reneighboring is done |
 +----------------------+-----------------------------------------------------------+
-| unpack\_border\_body | unpacking of those attributes                             |
+| unpack_border_body   | unpacking of those attributes                             |
 +----------------------+-----------------------------------------------------------+

doc/src/Modify_bond.rst

@@ -5,7 +5,7 @@ Classes that compute molecular interactions are derived from the Bond,
 Angle, Dihedral, and Improper classes.  New styles can be created to
 add new potentials to LAMMPS.
 
-Bond\_harmonic.cpp is the simplest example of a bond style.  Ditto for
+Bond_harmonic.cpp is the simplest example of a bond style.  Ditto for
 the harmonic forms of the angle, dihedral, and improper style
 commands.
 
@@ -14,9 +14,9 @@ new derived class.  See bond.h, angle.h, dihedral.h, and improper.h
 for details and specific additional methods.
 
 +-----------------------+---------------------------------------------------------------------------+
-| init                  | check if all coefficients are set, calls *init\_style* (optional)         |
+| init                  | check if all coefficients are set, calls *init_style* (optional)          |
 +-----------------------+---------------------------------------------------------------------------+
-| init\_style           | check if style specific conditions are met (optional)                     |
+| init_style            | check if style specific conditions are met (optional)                     |
 +-----------------------+---------------------------------------------------------------------------+
 | compute               | compute the molecular interactions (required)                             |
 +-----------------------+---------------------------------------------------------------------------+
@@ -24,13 +24,13 @@ for details and specific additional methods.
 +-----------------------+---------------------------------------------------------------------------+
 | coeff                 | set coefficients for one type (required)                                  |
 +-----------------------+---------------------------------------------------------------------------+
-| equilibrium\_distance | length of bond, used by SHAKE (required, bond only)                       |
+| equilibrium_distance  | length of bond, used by SHAKE (required, bond only)                       |
 +-----------------------+---------------------------------------------------------------------------+
-| equilibrium\_angle    | opening of angle, used by SHAKE (required, angle only)                    |
+| equilibrium_angle     | opening of angle, used by SHAKE (required, angle only)                    |
 +-----------------------+---------------------------------------------------------------------------+
-| write & read\_restart | writes/reads coeffs to restart files (required)                           |
+| write & read_restart  | writes/reads coeffs to restart files (required)                           |
 +-----------------------+---------------------------------------------------------------------------+
 | single                | force and energy of a single bond or angle (required, bond or angle only) |
 +-----------------------+---------------------------------------------------------------------------+
-| memory\_usage         | tally memory allocated by the style (optional)                            |
+| memory_usage          | tally memory allocated by the style (optional)                            |
 +-----------------------+---------------------------------------------------------------------------+

doc/src/Modify_command.rst

@@ -2,8 +2,8 @@ Input script command style
 ==========================
 
 New commands can be added to LAMMPS input scripts by adding new
-classes that have a "command" method.  For example, the create\_atoms,
+classes that have a "command" method.  For example, the create_atoms,
-read\_data, velocity, and run commands are all implemented in this
+read_data, velocity, and run commands are all implemented in this
 fashion.  When such a command is encountered in the LAMMPS input
 script, LAMMPS simply creates a class with the corresponding name,
 invokes the "command" method of the class, and passes it the arguments

doc/src/Modify_compute.rst

@@ -7,8 +7,8 @@ quantities like kinetic energy and the centro-symmetry parameter
 are derived from the Compute class.  New styles can be created
 to add new calculations to LAMMPS.
 
-Compute\_temp.cpp is a simple example of computing a scalar
+Compute_temp.cpp is a simple example of computing a scalar
-temperature.  Compute\_ke\_atom.cpp is a simple example of computing
+temperature.  Compute_ke_atom.cpp is a simple example of computing
 per-atom kinetic energy.
 
 Here is a brief description of methods you define in your new derived
@@ -17,41 +17,41 @@ class.  See compute.h for details.
 +-----------------------+------------------------------------------------------------------+
 | init                  | perform one time setup (required)                                |
 +-----------------------+------------------------------------------------------------------+
-| init\_list            | neighbor list setup, if needed (optional)                        |
+| init_list             | neighbor list setup, if needed (optional)                        |
 +-----------------------+------------------------------------------------------------------+
-| compute\_scalar       | compute a scalar quantity (optional)                             |
+| compute_scalar        | compute a scalar quantity (optional)                             |
 +-----------------------+------------------------------------------------------------------+
-| compute\_vector       | compute a vector of quantities (optional)                        |
+| compute_vector        | compute a vector of quantities (optional)                        |
 +-----------------------+------------------------------------------------------------------+
-| compute\_peratom      | compute one or more quantities per atom (optional)               |
+| compute_peratom       | compute one or more quantities per atom (optional)               |
 +-----------------------+------------------------------------------------------------------+
-| compute\_local        | compute one or more quantities per processor (optional)          |
+| compute_local         | compute one or more quantities per processor (optional)          |
 +-----------------------+------------------------------------------------------------------+
-| pack\_comm            | pack a buffer with items to communicate (optional)               |
+| pack_comm             | pack a buffer with items to communicate (optional)               |
 +-----------------------+------------------------------------------------------------------+
-| unpack\_comm          | unpack the buffer (optional)                                     |
+| unpack_comm           | unpack the buffer (optional)                                     |
 +-----------------------+------------------------------------------------------------------+
-| pack\_reverse         | pack a buffer with items to reverse communicate (optional)       |
+| pack_reverse          | pack a buffer with items to reverse communicate (optional)       |
 +-----------------------+------------------------------------------------------------------+
-| unpack\_reverse       | unpack the buffer (optional)                                     |
+| unpack_reverse        | unpack the buffer (optional)                                     |
 +-----------------------+------------------------------------------------------------------+
-| remove\_bias          | remove velocity bias from one atom (optional)                    |
+| remove_bias           | remove velocity bias from one atom (optional)                    |
 +-----------------------+------------------------------------------------------------------+
-| remove\_bias\_all     | remove velocity bias from all atoms in group (optional)          |
+| remove_bias_all       | remove velocity bias from all atoms in group (optional)          |
 +-----------------------+------------------------------------------------------------------+
-| restore\_bias         | restore velocity bias for one atom after remove\_bias (optional) |
+| restore_bias          | restore velocity bias for one atom after remove_bias (optional)  |
 +-----------------------+------------------------------------------------------------------+
-| restore\_bias\_all    | same as before, but for all atoms in group (optional)            |
+| restore_bias_all      | same as before, but for all atoms in group (optional)            |
 +-----------------------+------------------------------------------------------------------+
-| pair\_tally\_callback | callback function for *tally*\ -style computes (optional).       |
+| pair_tally_callback   | callback function for *tally*\ -style computes (optional).       |
 +-----------------------+------------------------------------------------------------------+
-| memory\_usage         | tally memory usage (optional)                                    |
+| memory_usage          | tally memory usage (optional)                                    |
 +-----------------------+------------------------------------------------------------------+
 
 Tally-style computes are a special case, as their computation is done
 in two stages: the callback function is registered with the pair style
-and then called from the Pair::ev\_tally() function, which is called for
+and then called from the Pair::ev_tally() function, which is called for
 each pair after force and energy has been computed for this pair. Then
-the tallied values are retrieved with the standard compute\_scalar or
+the tallied values are retrieved with the standard compute_scalar or
-compute\_vector or compute\_peratom methods. The USER-TALLY package
+compute_vector or compute_peratom methods. The USER-TALLY package
-provides *examples*\ \_compute\_tally.html for utilizing this mechanism.
+provides *examples*\ _compute_tally.html for utilizing this mechanism.

doc/src/Modify_contribute.rst

@@ -90,8 +90,8 @@ packages in the src directory for examples. If you are uncertain, please ask.
 
 * All source files you provide must compile with the most current
   version of LAMMPS with multiple configurations. In particular you
-  need to test compiling LAMMPS from scratch with -DLAMMPS\_BIGBIG
+  need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
-  set in addition to the default -DLAMMPS\_SMALLBIG setting. Your code
+  set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
   will need to work correctly in serial and in parallel using MPI.
 
 * For consistency with the rest of LAMMPS and especially, if you want
@@ -106,7 +106,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
   (<cstdlib>, <cstdio>, or <cstring>) instead of the C-style names
   <stdlib.h>, <stdio.h>, or <string.h>), and forward declarations
   used where possible or needed to avoid including headers.
-  All added code should be placed into the LAMMPS\_NS namespace or a
+  All added code should be placed into the LAMMPS_NS namespace or a
   sub-namespace; global or static variables should be avoided, as they
   conflict with the modular nature of LAMMPS and the C++ class structure.
   Header files must **not** import namespaces with *using*\ .
@@ -164,7 +164,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
   mathematical expression or figures (see doc/JPG for examples).
   Additional PDF files with further details (see doc/PDF for examples)
   may also be included.  The doc page should also include literature
-  citations as appropriate; see the bottom of doc/fix\_nh.rst for
+  citations as appropriate; see the bottom of doc/fix_nh.rst for
   examples and the earlier part of the same file for how to format the
   cite itself.  Citation labels must be unique across all .rst files.
   The "Restrictions" section of the doc page should indicate if your
@@ -191,7 +191,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
 * If there is a paper of yours describing your feature (either the
   algorithm/science behind the feature itself, or its initial usage, or
   its implementation in LAMMPS), you can add the citation to the \*.cpp
-  source file.  See src/USER-EFF/atom\_vec\_electron.cpp for an example.
+  source file.  See src/USER-EFF/atom_vec_electron.cpp for an example.
   A LaTeX citation is stored in a variable at the top of the file and a
   single line of code that references the variable is added to the
   constructor of the class.  Whenever a user invokes your feature from

doc/src/Modify_dump.rst

@@ -4,21 +4,21 @@ Dump styles
 Classes that dump per-atom info to files are derived from the Dump
 class.  To dump new quantities or in a new format, a new derived dump
 class can be added, but it is typically simpler to modify the
-DumpCustom class contained in the dump\_custom.cpp file.
+DumpCustom class contained in the dump_custom.cpp file.
 
-Dump\_atom.cpp is a simple example of a derived dump class.
+Dump_atom.cpp is a simple example of a derived dump class.
 
 Here is a brief description of methods you define in your new derived
 class.  See dump.h for details.
 
 +---------------+---------------------------------------------------+
-| write\_header | write the header section of a snapshot of atoms   |
+| write_header  | write the header section of a snapshot of atoms   |
 +---------------+---------------------------------------------------+
 | count         | count the number of lines a processor will output |
 +---------------+---------------------------------------------------+
 | pack          | pack a proc's output data into a buffer           |
 +---------------+---------------------------------------------------+
-| write\_data   | write a proc's data to a file                     |
+| write_data    | write a proc's data to a file                     |
 +---------------+---------------------------------------------------+
 
 See the :doc:`dump <dump>` command and its *custom* style for a list of

doc/src/Modify_fix.rst

@@ -10,7 +10,7 @@ constraints or boundary conditions (SHAKE or walls), and diagnostics
 (compute a diffusion coefficient).  New styles can be created to add
 new options to LAMMPS.
 
-Fix\_setforce.cpp is a simple example of setting forces on atoms to
+Fix_setforce.cpp is a simple example of setting forces on atoms to
 prescribed values.  There are dozens of fix options already in LAMMPS;
 choose one as a template that is similar to what you want to
 implement.
@@ -23,105 +23,105 @@ derived class.  See fix.h for details.
 +---------------------------+--------------------------------------------------------------------------------------------+
 | init                      | initialization before a run (optional)                                                     |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| setup\_pre\_exchange      | called before atom exchange in setup (optional)                                            |
+| setup_pre_exchange        | called before atom exchange in setup (optional)                                            |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| setup\_pre\_force         | called before force computation in setup (optional)                                        |
+| setup_pre_force           | called before force computation in setup (optional)                                        |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | setup                     | called immediately before the 1st timestep and after forces are computed (optional)        |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_setup\_pre\_force    | like setup\_pre\_force, but for minimizations instead of MD runs (optional)                |
+| min_setup_pre_force       | like setup_pre_force, but for minimizations instead of MD runs (optional)                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_setup                | like setup, but for minimizations instead of MD runs (optional)                            |
+| min_setup                 | like setup, but for minimizations instead of MD runs (optional)                            |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| initial\_integrate        | called at very beginning of each timestep (optional)                                       |
+| initial_integrate         | called at very beginning of each timestep (optional)                                       |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pre\_exchange             | called before atom exchange on re-neighboring steps (optional)                             |
+| pre_exchange              | called before atom exchange on re-neighboring steps (optional)                             |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pre\_neighbor             | called before neighbor list build (optional)                                               |
+| pre_neighbor              | called before neighbor list build (optional)                                               |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pre\_force                | called before pair & molecular forces are computed (optional)                              |
+| pre_force                 | called before pair & molecular forces are computed (optional)                              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| post\_force               | called after pair & molecular forces are computed and communicated (optional)              |
+| post_force                | called after pair & molecular forces are computed and communicated (optional)              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| final\_integrate          | called at end of each timestep (optional)                                                  |
+| final_integrate           | called at end of each timestep (optional)                                                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| end\_of\_step             | called at very end of timestep (optional)                                                  |
+| end_of_step               | called at very end of timestep (optional)                                                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| write\_restart            | dumps fix info to restart file (optional)                                                  |
+| write_restart             | dumps fix info to restart file (optional)                                                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | restart                   | uses info from restart file to re-initialize the fix (optional)                            |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| grow\_arrays              | allocate memory for atom-based arrays used by fix (optional)                               |
+| grow_arrays               | allocate memory for atom-based arrays used by fix (optional)                               |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| copy\_arrays              | copy atom info when an atom migrates to a new processor (optional)                         |
+| copy_arrays               | copy atom info when an atom migrates to a new processor (optional)                         |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pack\_exchange            | store atom's data in a buffer (optional)                                                   |
+| pack_exchange             | store atom's data in a buffer (optional)                                                   |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| unpack\_exchange          | retrieve atom's data from a buffer (optional)                                              |
+| unpack_exchange           | retrieve atom's data from a buffer (optional)                                              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pack\_restart             | store atom's data for writing to restart file (optional)                                   |
+| pack_restart              | store atom's data for writing to restart file (optional)                                   |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| unpack\_restart           | retrieve atom's data from a restart file buffer (optional)                                 |
+| unpack_restart            | retrieve atom's data from a restart file buffer (optional)                                 |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| size\_restart             | size of atom's data (optional)                                                             |
+| size_restart              | size of atom's data (optional)                                                             |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| maxsize\_restart          | max size of atom's data (optional)                                                         |
+| maxsize_restart           | max size of atom's data (optional)                                                         |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| setup\_pre\_force\_respa  | same as setup\_pre\_force, but for rRESPA (optional)                                       |
+| setup_pre_force_respa     | same as setup_pre_force, but for rRESPA (optional)                                         |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| initial\_integrate\_respa | same as initial\_integrate, but for rRESPA (optional)                                      |
+| initial_integrate_respa   | same as initial_integrate, but for rRESPA (optional)                                       |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| post\_integrate\_respa    | called after the first half integration step is done in rRESPA (optional)                  |
+| post_integrate_respa      | called after the first half integration step is done in rRESPA (optional)                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pre\_force\_respa         | same as pre\_force, but for rRESPA (optional)                                              |
+| pre_force_respa           | same as pre_force, but for rRESPA (optional)                                               |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| post\_force\_respa        | same as post\_force, but for rRESPA (optional)                                             |
+| post_force_respa          | same as post_force, but for rRESPA (optional)                                              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| final\_integrate\_respa   | same as final\_integrate, but for rRESPA (optional)                                        |
+| final_integrate_respa     | same as final_integrate, but for rRESPA (optional)                                         |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_pre\_force           | called after pair & molecular forces are computed in minimizer (optional)                  |
+| min_pre_force             | called after pair & molecular forces are computed in minimizer (optional)                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_post\_force          | called after pair & molecular forces are computed and communicated in minimizer (optional) |
+| min_post_force            | called after pair & molecular forces are computed and communicated in minimizer (optional) |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_store                | store extra data for linesearch based minimization on a LIFO stack (optional)              |
+| min_store                 | store extra data for linesearch based minimization on a LIFO stack (optional)              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_pushstore            | push the minimization LIFO stack one element down (optional)                               |
+| min_pushstore             | push the minimization LIFO stack one element down (optional)                               |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_popstore             | pop the minimization LIFO stack one element up (optional)                                  |
+| min_popstore              | pop the minimization LIFO stack one element up (optional)                                  |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_clearstore           | clear minimization LIFO stack (optional)                                                   |
+| min_clearstore            | clear minimization LIFO stack (optional)                                                   |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_step                 | reset or move forward on line search minimization (optional)                               |
+| min_step                  | reset or move forward on line search minimization (optional)                               |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| min\_dof                  | report number of degrees of freedom *added* by this fix in minimization (optional)         |
+| min_dof                   | report number of degrees of freedom *added* by this fix in minimization (optional)         |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| max\_alpha                | report maximum allowed step size during linesearch minimization (optional)                 |
+| max_alpha                 | report maximum allowed step size during linesearch minimization (optional)                 |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pack\_comm                | pack a buffer to communicate a per-atom quantity (optional)                                |
+| pack_comm                 | pack a buffer to communicate a per-atom quantity (optional)                                |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| unpack\_comm              | unpack a buffer to communicate a per-atom quantity (optional)                              |
+| unpack_comm               | unpack a buffer to communicate a per-atom quantity (optional)                              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| pack\_reverse\_comm       | pack a buffer to reverse communicate a per-atom quantity (optional)                        |
+| pack_reverse_comm         | pack a buffer to reverse communicate a per-atom quantity (optional)                        |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| unpack\_reverse\_comm     | unpack a buffer to reverse communicate a per-atom quantity (optional)                      |
+| unpack_reverse_comm       | unpack a buffer to reverse communicate a per-atom quantity (optional)                      |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | dof                       | report number of degrees of freedom *removed* by this fix during MD (optional)             |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| compute\_scalar           | return a global scalar property that the fix computes (optional)                           |
+| compute_scalar            | return a global scalar property that the fix computes (optional)                           |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| compute\_vector           | return a component of a vector property that the fix computes (optional)                   |
+| compute_vector            | return a component of a vector property that the fix computes (optional)                   |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| compute\_array            | return a component of an array property that the fix computes (optional)                   |
+| compute_array             | return a component of an array property that the fix computes (optional)                   |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | deform                    | called when the box size is changed (optional)                                             |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| reset\_target             | called when a change of the target temperature is requested during a run (optional)        |
+| reset_target              | called when a change of the target temperature is requested during a run (optional)        |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| reset\_dt                 | is called when a change of the time step is requested during a run (optional)              |
+| reset_dt                  | is called when a change of the time step is requested during a run (optional)              |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| modify\_param             | called when a fix\_modify request is executed (optional)                                   |
+| modify_param              | called when a fix_modify request is executed (optional)                                    |
 +---------------------------+--------------------------------------------------------------------------------------------+
-| memory\_usage             | report memory used by fix (optional)                                                       |
+| memory_usage              | report memory used by fix (optional)                                                       |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | thermo                    | compute quantities for thermodynamic output (optional)                                     |
 +---------------------------+--------------------------------------------------------------------------------------------+
@@ -129,12 +129,12 @@ derived class.  See fix.h for details.
 Typically, only a small fraction of these methods are defined for a
 particular fix.  Setmask is mandatory, as it determines when the fix
 will be invoked during the timestep.  Fixes that perform time
-integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial\_integrate() and
+integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial_integrate() and
-final\_integrate() to perform velocity Verlet updates.  Fixes that
+final_integrate() to perform velocity Verlet updates.  Fixes that
-constrain forces implement post\_force().
+constrain forces implement post_force().
 
-Fixes that perform diagnostics typically implement end\_of\_step().  For
+Fixes that perform diagnostics typically implement end_of_step().  For
-an end\_of\_step fix, one of your fix arguments must be the variable
+an end_of_step fix, one of your fix arguments must be the variable
 "nevery" which is used to determine when to call the fix and you must
 set this variable in the constructor of your fix.  By convention, this
 is the first argument the fix defines (after the ID, group-ID, style).
@@ -142,12 +142,12 @@ is the first argument the fix defines (after the ID, group-ID, style).
 If the fix needs to store information for each atom that persists from
 timestep to timestep, it can manage that memory and migrate the info
 with the atoms as they move from processors to processor by
-implementing the grow\_arrays, copy\_arrays, pack\_exchange, and
+implementing the grow_arrays, copy_arrays, pack_exchange, and
-unpack\_exchange methods.  Similarly, the pack\_restart and
+unpack_exchange methods.  Similarly, the pack_restart and
-unpack\_restart methods can be implemented to store information about
+unpack_restart methods can be implemented to store information about
 the fix in restart files.  If you wish an integrator or force
 constraint fix to work with rRESPA (see the :doc:`run_style <run_style>`
-command), the initial\_integrate, post\_force\_integrate, and
+command), the initial_integrate, post_force_integrate, and
-final\_integrate\_respa methods can be implemented.  The thermo method
+final_integrate_respa methods can be implemented.  The thermo method
 enables a fix to contribute values to thermodynamic output, as printed
 quantities and/or to be summed to the potential energy of the system.

doc/src/Modify_kspace.rst

@@ -17,5 +17,5 @@ class.  See kspace.h for details.
 +---------------+----------------------------------------------+
 | compute       | every-timestep computation                   |
 +---------------+----------------------------------------------+
-| memory\_usage | tally of memory usage                        |
+| memory_usage  | tally of memory usage                        |
 +---------------+----------------------------------------------+

doc/src/Modify_min.rst

@@ -5,7 +5,7 @@ Classes that perform energy minimization derived from the Min class.
 New styles can be created to add new minimization algorithms to
 LAMMPS.
 
-Min\_cg.cpp is an example of conjugate gradient minimization.
+Min_cg.cpp is an example of conjugate gradient minimization.
 
 Here is a brief description of methods you define in your new derived
 class.  See min.h for details.
@@ -15,5 +15,5 @@ class.  See min.h for details.
 +---------------+------------------------------------------+
 | run           | perform the minimization                 |
 +---------------+------------------------------------------+
-| memory\_usage | tally of memory usage                    |
+| memory_usage  | tally of memory usage                    |
 +---------------+------------------------------------------+

doc/src/Modify_overview.rst

@@ -25,8 +25,8 @@ and variables needed to define the new feature are in the 2 files you
 write, and thus shouldn't make the rest of LAMMPS more complex or
 cause side-effect bugs.
 
-Here is a concrete example.  Suppose you write 2 files pair\_foo.cpp
+Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
-and pair\_foo.h that define a new class PairFoo that computes pairwise
+and pair_foo.h that define a new class PairFoo that computes pairwise
 potentials described in the classic 1997 :ref:`paper <Foo>` by Foo, et al.
 If you wish to invoke those potentials in a LAMMPS input script with a
 command like
@@ -35,7 +35,7 @@ command like
 
    pair_style foo 0.1 3.5
 
-then your pair\_foo.h file should be structured as follows:
+then your pair_foo.h file should be structured as follows:
 
 .. code-block:: c++
 
@@ -47,12 +47,12 @@ then your pair\_foo.h file should be structured as follows:
    ...
    #endif
 
-where "foo" is the style keyword in the pair\_style command, and
+where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair\_foo.cpp and pair\_foo.h
+PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
 files.
 
 When you re-build LAMMPS, your new pairwise potential becomes part of
-the executable and can be invoked with a pair\_style command like the
+the executable and can be invoked with a pair_style command like the
 example above.  Arguments like 0.1 and 3.5 can be defined and
 processed by your new class.
 
@@ -80,7 +80,7 @@ that are not set to 0 are functions you may override or not.  Those
 are usually defined with an empty function body.
 
 Additionally, new output options can be added directly to the
-thermo.cpp, dump\_custom.cpp, and variable.cpp files.  These are also
+thermo.cpp, dump_custom.cpp, and variable.cpp files.  These are also
 listed on the :doc:`Modify page <Modify>`.
 
 Here are additional guidelines for modifying LAMMPS and adding new

doc/src/Modify_pair.rst

@@ -7,7 +7,7 @@ such as EAM or Tersoff where particles interact without a static bond
 topology.  New styles can be created to add new pair potentials to
 LAMMPS.
 
-Pair\_lj\_cut.cpp is a simple example of a Pair class, though it
+Pair_lj_cut.cpp is a simple example of a Pair class, though it
 includes some optional methods to enable its use with rRESPA.
 
 Here is a brief description of the class methods in pair.h:
@@ -19,17 +19,17 @@ Here is a brief description of the class methods in pair.h:
 +---------------------------------+-------------------------------------------------------------------+
 | coeff                           | set coefficients for one i,j type pair                            |
 +---------------------------------+-------------------------------------------------------------------+
-| init\_one                       | perform initialization for one i,j type pair                      |
+| init_one                        | perform initialization for one i,j type pair                      |
 +---------------------------------+-------------------------------------------------------------------+
-| init\_style                     | initialization specific to this pair style                        |
+| init_style                      | initialization specific to this pair style                        |
 +---------------------------------+-------------------------------------------------------------------+
-| write & read\_restart           | write/read i,j pair coeffs to restart files                       |
+| write & read_restart            | write/read i,j pair coeffs to restart files                       |
 +---------------------------------+-------------------------------------------------------------------+
-| write & read\_restart\_settings | write/read global settings to restart files                       |
+| write & read_restart_settings   | write/read global settings to restart files                       |
 +---------------------------------+-------------------------------------------------------------------+
 | single                          | force and energy of a single pairwise interaction between 2 atoms |
 +---------------------------------+-------------------------------------------------------------------+
-| compute\_inner/middle/outer     | versions of compute used by rRESPA                                |
+| compute_inner/middle/outer      | versions of compute used by rRESPA                                |
 +---------------------------------+-------------------------------------------------------------------+
 
 The inner/middle/outer routines are optional.

doc/src/Modify_region.rst

@@ -6,7 +6,7 @@ class.  Regions are used elsewhere in LAMMPS to group atoms, delete
 atoms to create a void, insert atoms in a specified region, etc.  New
 styles can be created to add new region shapes to LAMMPS.
 
-Region\_sphere.cpp is an example of a spherical region.
+Region_sphere.cpp is an example of a spherical region.
 
 Here is a brief description of methods you define in your new derived
 class.  See region.h for details.
@@ -14,9 +14,9 @@ class.  See region.h for details.
 +-------------------+---------------------------------------------------------------------+
 | inside            | determine whether a point is in the region                          |
 +-------------------+---------------------------------------------------------------------+
-| surface\_interior | determine if a point is within a cutoff distance inside of surface  |
+| surface_interior  | determine if a point is within a cutoff distance inside of surface  |
 +-------------------+---------------------------------------------------------------------+
-| surface\_exterior | determine if a point is within a cutoff distance outside of surface |
+| surface_exterior  | determine if a point is within a cutoff distance outside of surface |
 +-------------------+---------------------------------------------------------------------+
-| shape\_update     | change region shape if set by time-dependent variable               |
+| shape_update      | change region shape if set by time-dependent variable               |
 +-------------------+---------------------------------------------------------------------+

doc/src/Packages_details.rst

@@ -10,7 +10,7 @@ scripts, and pictures/movies (if available) that illustrate use of the
 package.
 
 The majority of packages can be included in a LAMMPS build with a
-single setting (-D PGK\_NAME for CMake) or command ("make yes-name" for
+single setting (-D PGK_NAME for CMake) or command ("make yes-name" for
 make).  See the :doc:`Build package <Build_package>` doc page for more
 info.  A few packages may require additional steps; this is indicated
 in the descriptions below.  The :doc:`Build extras <Build_extras>` doc
@@ -123,8 +123,8 @@ particle models including ellipsoids, 2d lines, and 3d triangles.
 * :doc:`Howto spherical <Howto_spherical>`
 * :doc:`pair_style gayberne <pair_gayberne>`
 * :doc:`pair_style resquared <pair_resquared>`
-* `doc/PDF/pair\_gayberne\_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
+* `doc/PDF/pair_gayberne_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
-* `doc/PDF/pair\_resquared\_extra.pdf <PDF/pair_resquared_extra.pdf>`_
+* `doc/PDF/pair_resquared_extra.pdf <PDF/pair_resquared_extra.pdf>`_
 * examples/ASPHERE
 * examples/ellipse
 * https://lammps.sandia.gov/movies.html#line
@@ -147,7 +147,7 @@ overview.
 **Supporting info:**
 
 * src/BODY filenames -> commands
-* :doc:`Howto\_body <Howto_body>`
+* :doc:`Howto_body <Howto_body>`
 * :doc:`atom_style body <atom_style>`
 * :doc:`fix nve/body <fix_nve_body>`
 * :doc:`pair_style body/nparticle <pair_body_nparticle>`
@@ -367,7 +367,7 @@ This package contains a set of commands that serve as a wrapper on the
 `Open Knowledgebase of Interatomic Models (OpenKIM) <https://openkim.org>`_
 repository of interatomic models (IMs)
 enabling compatible ones to be used in LAMMPS simulations.
-This includes :doc:`kim_init and kim\_interactions <kim_commands>`
+This includes :doc:`kim_init and kim_interactions <kim_commands>`
 commands to select, initialize and instantiate the IM, and a
 :doc:`kim_query <kim_commands>` command to perform web queries
 for material property predictions of OpenKIM IMs.
@@ -377,7 +377,7 @@ is provided by the :doc:`pair_style kim <pair_kim>` command.
 
 .. note::
 
-   The command *pair\_style kim* is called by *kim\_interactions* and
+   The command *pair_style kim* is called by *kim_interactions* and
    is not recommended to be directly used in input scripts.
 
 To use this package you must have the KIM API library available on your
@@ -392,7 +392,7 @@ The KIM project is led by Ellad Tadmor and Ryan Elliott (U Minnesota)
 and is funded by the `National Science Foundation <https://www.nsf.gov/>`_.
 
 **Authors:** Ryan Elliott (U Minnesota) is the main developer for the KIM
-API and the *pair\_style kim* command. Axel Kohlmeyer (Temple U) and
+API and the *pair_style kim* command. Axel Kohlmeyer (Temple U) and
 Ellad Tadmor (U Minnesota) contributed to the :doc:`kim_commands <kim_commands>`
 interface in close collaboration with Ryan Elliott.
 
@@ -782,9 +782,9 @@ Foster (UTSA).
 **Supporting info:**
 
 * src/PERI: filenames -> commands
-* `doc/PDF/PDLammps\_overview.pdf <PDF/PDLammps_overview.pdf>`_
+* `doc/PDF/PDLammps_overview.pdf <PDF/PDLammps_overview.pdf>`_
-* `doc/PDF/PDLammps\_EPS.pdf <PDF/PDLammps_EPS.pdf>`_
+* `doc/PDF/PDLammps_EPS.pdf <PDF/PDLammps_EPS.pdf>`_
-* `doc/PDF/PDLammps\_VES.pdf <PDF/PDLammps_VES.pdf>`_
+* `doc/PDF/PDLammps_VES.pdf <PDF/PDLammps_VES.pdf>`_
 * :doc:`atom_style peri <atom_style>`
 * :doc:`pair_style peri/\* <pair_peri>`
 * :doc:`compute damage/atom <compute_damage_atom>`
@@ -1890,7 +1890,7 @@ And a :doc:`dynamical_matrix <dynamical_matrix>` as well as a
 and third order tensor from finite differences.
 
 **Authors:** Ling-Ti Kong (Shanghai Jiao Tong University) for "fix phonon"
-and Charlie Sievers (UC Davis) for "dynamical\_matrix" and "third\_order"
+and Charlie Sievers (UC Davis) for "dynamical_matrix" and "third_order"
 
 **Supporting info:**
 
@@ -1918,8 +1918,8 @@ Matching methodology.
 
 **Supporting info:**
 
-* src/USER-PTM: filenames not starting with ptm\\_ -> commands
+* src/USER-PTM: filenames not starting with ptm\_ -> commands
-* src/USER-PTM: filenames starting with ptm\\_ -> supporting code
+* src/USER-PTM: filenames starting with ptm\_ -> supporting code
 * src/USER-PTM/LICENSE
 * :doc:`compute ptm/atom <compute_ptm_atom>`
 
@@ -2132,7 +2132,7 @@ is an extension of smoothed particle hydrodynamics (SPH) to mesoscale
 where thermal fluctuations are important (see the
 :ref:`USER-SPH package <PKG-USER-SPH>`).
 Also two fixes for moving and rigid body integration of SPH/SDPD particles
-(particles of atom\_style meso).
+(particles of atom_style meso).
 
 **Author:** Morteza Jalalvand (Institute for Advanced Studies in Basic
 Sciences, Iran).
@@ -2180,7 +2180,7 @@ This package has :ref:`specific installation instructions <user-smd>` on the :do
 
 * src/USER-SMD: filenames -> commands
 * src/USER-SMD/README
-* doc/PDF/SMD\_LAMMPS\_userguide.pdf
+* doc/PDF/SMD_LAMMPS_userguide.pdf
 * examples/USER/smd
 * https://lammps.sandia.gov/movies.html#smd
 
@@ -2237,7 +2237,7 @@ Dynamics, Ernst Mach Institute, Germany).
 
 * src/USER-SPH: filenames -> commands
 * src/USER-SPH/README
-* doc/PDF/SPH\_LAMMPS\_userguide.pdf
+* doc/PDF/SPH_LAMMPS_userguide.pdf
 * examples/USER/sph
 * https://lammps.sandia.gov/movies.html#sph
 

doc/src/Python_call.rst

@@ -59,7 +59,7 @@ new potential.
 To use any of these commands, you only need to build LAMMPS with the
 PYTHON package installed:
 
-.. parsed-literal::
+.. code-block:: bash
 
    make yes-python
    make machine

doc/src/Python_examples.rst

@@ -20,16 +20,16 @@ distribution.
 +----------------------------------------------------------------+--------------------------------------------------+
 | GUI go/stop/temperature-slider to control LAMMPS               | plot.py                                          |
 +----------------------------------------------------------------+--------------------------------------------------+
-| real-time temperature plot with GnuPlot via Pizza.py           | viz\_tool.py                                     |
+| real-time temperature plot with GnuPlot via Pizza.py           | viz_tool.py                                      |
 +----------------------------------------------------------------+--------------------------------------------------+
-| real-time viz via some viz package                             | vizplotgui\_tool.py                              |
+| real-time viz via some viz package                             | vizplotgui_tool.py                               |
 +----------------------------------------------------------------+--------------------------------------------------+
-| combination of viz\_tool.py and plot.py and gui.py             |                                                  |
+| combination of viz_tool.py and plot.py and gui.py             |                                                   |
 +----------------------------------------------------------------+--------------------------------------------------+
 
 ----------
 
-For the viz\_tool.py and vizplotgui\_tool.py commands, replace "tool"
+For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
 with "gl" or "atomeye" or "pymol" or "vmd", depending on what
 visualization package you have installed.
 
@@ -79,7 +79,7 @@ variables that have to match the VMD installation on your system.
 See the python/README file for instructions on how to run them and the
 source code for individual scripts for comments about what they do.
 
-Here are screenshots of the vizplotgui\_tool.py script in action for
+Here are screenshots of the vizplotgui_tool.py script in action for
 different visualization package options.  Click to see larger images:
 
 .. image:: JPG/screenshot_gl_small.jpg

doc/src/Python_head.rst

@@ -27,7 +27,7 @@ its library interface, or to hook multiple pieces of software
 together, such as a simulation code plus a visualization tool, or to
 run a coupled multiscale or multiphysics model.
 
-See the :doc:`Howto\_couple <Howto_couple>` doc page for more ideas about
+See the :doc:`Howto_couple <Howto_couple>` doc page for more ideas about
 coupling LAMMPS to other codes.  See the :doc:`Howto library <Howto_library>` doc page for a description of the LAMMPS
 library interface provided in src/library.h and src/library.h.  That
 interface is exposed to Python either when calling LAMMPS from Python

doc/src/Python_install.rst

@@ -31,12 +31,12 @@ If you set the paths to these files as environment variables, you only
 have to do it once.  For the csh or tcsh shells, add something like
 this to your ~/.cshrc file, one line for each of the two files:
 
-.. parsed-literal::
+.. code-block:: csh
 
    setenv PYTHONPATH ${PYTHONPATH}:/home/sjplimp/lammps/python
    setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/home/sjplimp/lammps/src
 
-On MacOSX you may also need to set DYLD\_LIBRARY\_PATH accordingly.
+On MacOSX you may also need to set DYLD_LIBRARY_PATH accordingly.
 For Bourne/Korn shells accordingly into the corresponding files using
 the "export" shell builtin.
 
@@ -58,11 +58,11 @@ you can invoke install.py from the python directory manually as
 * and the optional -d flag to a custom (legacy) installation folder
 
 If you use a legacy installation folder, you will need to set your
-PYTHONPATH and LD\_LIBRARY\_PATH (and/or DYLD\_LIBRARY\_PATH) environment
+PYTHONPATH and LD_LIBRARY_PATH (and/or DYLD_LIBRARY_PATH) environment
 variables accordingly, as described above.
 
 Note that if you want Python to be able to load different versions of
 the LAMMPS shared library (see :doc:`this section <Python_shlib>`), you will
-need to manually copy files like liblammps\_g++.so into the appropriate
+need to manually copy files like liblammps_g++.so into the appropriate
-system directory.  This is not needed if you set the LD\_LIBRARY\_PATH
+system directory.  This is not needed if you set the LD_LIBRARY_PATH
 environment variable as described above.

doc/src/Python_library.rst

@@ -135,21 +135,21 @@ script, and coordinate and run multiple simulations, e.g.
    lmp1.file("in.file1")
    lmp2.file("in.file2")
 
-The file(), command(), commands\_list(), commands\_string() methods
+The file(), command(), commands_list(), commands_string() methods
 allow an input script, a single command, or multiple commands to be
 invoked.
 
-The extract\_setting(), extract\_global(), extract\_box(),
+The extract_setting(), extract_global(), extract_box(),
-extract\_atom(), extract\_compute(), extract\_fix(), and
+extract_atom(), extract_compute(), extract_fix(), and
-extract\_variable() methods return values or pointers to data
+extract_variable() methods return values or pointers to data
 structures internal to LAMMPS.
 
-For extract\_global() see the src/library.cpp file for the list of
+For extract_global() see the src/library.cpp file for the list of
 valid names.  New names could easily be added.  A double or integer is
 returned.  You need to specify the appropriate data type via the type
 argument.
 
-For extract\_atom(), a pointer to internal LAMMPS atom-based data is
+For extract_atom(), a pointer to internal LAMMPS atom-based data is
 returned, which you can use via normal Python subscripting.  See the
 extract() method in the src/atom.cpp file for a list of valid names.
 Again, new names could easily be added if the property you want is not
@@ -157,7 +157,7 @@ listed.  A pointer to a vector of doubles or integers, or a pointer to
 an array of doubles (double \*\*) or integers (int \*\*) is returned.  You
 need to specify the appropriate data type via the type argument.
 
-For extract\_compute() and extract\_fix(), the global, per-atom, or
+For extract_compute() and extract_fix(), the global, per-atom, or
 local data calculated by the compute or fix can be accessed.  What is
 returned depends on whether the compute or fix calculates a scalar or
 vector or array.  For a scalar, a single double value is returned.  If
@@ -173,7 +173,7 @@ data types.  See the doc pages for individual :doc:`computes <compute>`
 and :doc:`fixes <fix>` for a description of what they calculate and
 store.
 
-For extract\_variable(), an :doc:`equal-style or atom-style variable <variable>` is evaluated and its result returned.
+For extract_variable(), an :doc:`equal-style or atom-style variable <variable>` is evaluated and its result returned.
 
 For equal-style variables a single double value is returned and the
 group argument is ignored.  For atom-style variables, a vector of
@@ -181,17 +181,17 @@ doubles is returned, one value per atom, which you can use via normal
 Python subscripting. The values will be zero for atoms not in the
 specified group.
 
-The get\_thermo() method returns the current value of a thermo
+The get_thermo() method returns the current value of a thermo
 keyword as a float.
 
-The get\_natoms() method returns the total number of atoms in the
+The get_natoms() method returns the total number of atoms in the
 simulation, as an int.
 
-The set\_variable() method sets an existing string-style variable to a
+The set_variable() method sets an existing string-style variable to a
 new string value, so that subsequent LAMMPS commands can access the
 variable.
 
-The reset\_box() method resets the size and shape of the simulation
+The reset_box() method resets the size and shape of the simulation
 box, e.g. as part of restoring a previously extracted and saved state
 of a simulation.
 
@@ -203,19 +203,19 @@ passed by all calling processors, to individual atoms, which may be
 owned by different processors.
 
 Note that the data returned by the gather methods,
-e.g. gather\_atoms("x"), is different from the data structure returned
+e.g. gather_atoms("x"), is different from the data structure returned
-by extract\_atom("x") in four ways.  (1) Gather\_atoms() returns a
+by extract_atom("x") in four ways.  (1) Gather_atoms() returns a
-vector which you index as x[i]; extract\_atom() returns an array
+vector which you index as x[i]; extract_atom() returns an array
-which you index as x[i][j].  (2) Gather\_atoms() orders the atoms
+which you index as x[i][j].  (2) Gather_atoms() orders the atoms
-by atom ID while extract\_atom() does not.  (3) Gather\_atoms() returns
+by atom ID while extract_atom() does not.  (3) Gather_atoms() returns
-a list of all atoms in the simulation; extract\_atoms() returns just
+a list of all atoms in the simulation; extract_atoms() returns just
-the atoms local to each processor.  (4) Finally, the gather\_atoms()
+the atoms local to each processor.  (4) Finally, the gather_atoms()
 data structure is a copy of the atom coords stored internally in
-LAMMPS, whereas extract\_atom() returns an array that effectively
+LAMMPS, whereas extract_atom() returns an array that effectively
 points directly to the internal data.  This means you can change
 values inside LAMMPS from Python by assigning a new values to the
-extract\_atom() array.  To do this with the gather\_atoms() vector, you
+extract_atom() array.  To do this with the gather_atoms() vector, you
-need to change values in the vector, then invoke the scatter\_atoms()
+need to change values in the vector, then invoke the scatter_atoms()
 method.
 
 For the scatter methods, the array of coordinates passed to must be a

doc/src/Python_mpi.rst

@@ -18,7 +18,7 @@ LAMMPS instances on subsets of the total MPI ranks.
 To install mpi4py (version mpi4py-3.0.3 as of Nov 2019), unpack it
 and from its main directory, type
 
-.. parsed-literal::
+.. code-block:: bash
 
    python setup.py build
    sudo python setup.py install
@@ -27,27 +27,27 @@ Again, the "sudo" is only needed if required to copy mpi4py files into
 your Python distribution's site-packages directory. To install with
 user privilege into the user local directory type
 
-.. parsed-literal::
+.. code-block:: bash
 
    python setup.py install --user
 
 If you have successfully installed mpi4py, you should be able to run
 Python and type
 
-.. parsed-literal::
+.. code-block:: python
 
    from mpi4py import MPI
 
 without error.  You should also be able to run python in parallel
 on a simple test script
 
-.. parsed-literal::
+.. code-block:: bash
 
    % mpirun -np 4 python test.py
 
 where test.py contains the lines
 
-.. parsed-literal::
+.. code-block:: python
 
    from mpi4py import MPI
    comm = MPI.COMM_WORLD
@@ -64,7 +64,7 @@ and see one line of output for each processor you run on.
    it is using, since you specify the details in your low-level
    src/MAKE/Makefile.foo file.  Mpi4py uses the "mpicc" command to find
    information about the MPI it uses to build against.  And it tries to
-   load "libmpi.so" from the LD\_LIBRARY\_PATH.  This may or may not find
+   load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
    the MPI library that LAMMPS is using.  If you have problems running
    both mpi4py and LAMMPS together, this is an issue you may need to
    address, e.g. by moving other MPI installations so that mpi4py finds

doc/src/Python_shlib.rst

@@ -5,19 +5,19 @@ Build LAMMPS as a shared library using make
 -------------------------------------------
 
 Instructions on how to build LAMMPS as a shared library are given on
-the :doc:`Build\_basics <Build_basics>` doc page.  A shared library is
+the :doc:`Build_basics <Build_basics>` doc page.  A shared library is
 one that is dynamically loadable, which is what Python requires to
 wrap LAMMPS.  On Linux this is a library file that ends in ".so", not
 ".a".
 
 From the src directory, type
 
-.. parsed-literal::
+.. code-block:: bash
 
    make foo mode=shlib
 
 where foo is the machine target name, such as mpi or serial.
-This should create the file liblammps\_foo.so in the src directory, as
+This should create the file liblammps_foo.so in the src directory, as
 well as a soft link liblammps.so, which is what the Python wrapper will
 load by default.  Note that if you are building multiple machine
 versions of the shared library, the soft link is always set to the
@@ -29,7 +29,7 @@ most recently built version.
    auxiliary libraries (used by various packages), then all of these
    extra libraries must also be shared libraries.  If the LAMMPS
    shared-library build fails with an error complaining about this, see
-   the :doc:`Build\_basics <Build_basics>` doc page.
+   the :doc:`Build_basics <Build_basics>` doc page.
 
 Build LAMMPS as a shared library using CMake
 --------------------------------------------
@@ -37,7 +37,7 @@ Build LAMMPS as a shared library using CMake
 When using CMake the following two options are necessary to generate the LAMMPS
 shared library:
 
-.. parsed-literal::
+.. code-block:: bash
 
    -D BUILD_LIB=on            # enable building LAMMPS as a library
    -D BUILD_SHARED_LIBS=on    # enable building of LAMMPS shared library (both options are needed!)
@@ -45,12 +45,12 @@ shared library:
 What this does is create a liblammps.so which contains the majority of LAMMPS
 code. The generated lmp binary also dynamically links to this library. This
 means that either this liblammps.so file has to be in the same directory, a system
-library path (e.g. /usr/lib64/) or in the LD\_LIBRARY\_PATH.
+library path (e.g. /usr/lib64/) or in the LD_LIBRARY_PATH.
 
 If you want to use the shared library with Python the recommended way is to create a virtualenv and use it as
-CMAKE\_INSTALL\_PREFIX.
+CMAKE_INSTALL_PREFIX.
 
-.. parsed-literal::
+.. code-block:: bash
 
    # create virtualenv
    virtualenv --python=$(which python3) myenv3
@@ -66,12 +66,12 @@ CMAKE\_INSTALL\_PREFIX.
    make install
 
 This will also install the Python module into your virtualenv. Since virtualenv
-doesn't change your LD\_LIBRARY\_PATH, you still need to add its lib64 folder to
+doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to
 it, which contains the installed liblammps.so.
 
-.. parsed-literal::
+.. code-block:: bash
 
    export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib64:$LD_LIBRARY_PATH
 
 Starting Python outside (!) of your build directory, but with the virtualenv
-enabled and with the LD\_LIBRARY\_PATH set gives you access to LAMMPS via Python.
+enabled and with the LD_LIBRARY_PATH set gives you access to LAMMPS via Python.

doc/src/Python_test.rst

@@ -31,8 +31,8 @@ first importing from the lammps.py file:
    >>> CDLL("liblammps.so")
 
 If an error occurs, carefully go through the steps on the
-:doc:`Build\_basics <Build_basics>` doc page about building a shared
+:doc:`Build_basics <Build_basics>` doc page about building a shared
-library and the :doc:`Python\_install <Python_install>` doc page about
+library and the :doc:`Python_install <Python_install>` doc page about
 insuring Python can find the necessary two files it needs.
 
 Test LAMMPS and Python in serial:
@@ -49,7 +49,7 @@ interactively from the bench directory:
 
 Or put the same lines in the file test.py and run it as
 
-.. parsed-literal::
+.. code-block:: bash
 
    % python test.py
 
@@ -68,7 +68,7 @@ To run LAMMPS in parallel, assuming you have installed the
 `PyPar <https://github.com/daleroberts/pypar>`_ package as discussed
 above, create a test.py file containing these lines:
 
-.. parsed-literal::
+.. code-block:: python
 
    import pypar
    from lammps import lammps
@@ -81,7 +81,7 @@ To run LAMMPS in parallel, assuming you have installed the
 `mpi4py <https://bitbucket.org/mpi4py/mpi4py>`_ package as discussed
 above, create a test.py file containing these lines:
 
-.. parsed-literal::
+.. code-block:: python
 
    from mpi4py import MPI
    from lammps import lammps
@@ -94,13 +94,13 @@ above, create a test.py file containing these lines:
 
 You can either script in parallel as:
 
-.. parsed-literal::
+.. code-block:: bash
 
    % mpirun -np 4 python test.py
 
 and you should see the same output as if you had typed
 
-.. parsed-literal::
+.. code-block:: bash
 
    % mpirun -np 4 lmp_g++ -in in.lj
 
@@ -124,7 +124,7 @@ Running Python scripts:
 Note that any Python script (not just for LAMMPS) can be invoked in
 one of several ways:
 
-.. parsed-literal::
+.. code-block:: bash
 
    % python foo.script
    % python -i foo.script
@@ -133,7 +133,7 @@ one of several ways:
 The last command requires that the first line of the script be
 something like this:
 
-.. parsed-literal::
+.. code-block:: bash
 
    #!/usr/local/bin/python
    #!/usr/local/bin/python -i
@@ -141,7 +141,7 @@ something like this:
 where the path points to where you have Python installed, and that you
 have made the script file executable:
 
-.. parsed-literal::
+.. code-block:: bash
 
    % chmod +x foo.script
 

doc/src/Run_basics.rst

@@ -65,7 +65,7 @@ or "-bind-to core" (MPICH) can be used.
 
 If the LAMMPS command(s) you are using support multi-threading, you
 can set the number of threads per MPI task via the environment
-variable OMP\_NUM\_THREADS, before you launch LAMMPS:
+variable OMP_NUM_THREADS, before you launch LAMMPS:
 
 .. code-block:: bash
 

doc/src/Run_options.rst

@@ -23,7 +23,7 @@ letter abbreviation can be used:
 * :ref:`-sf or -suffix <suffix>`
 * :ref:`-v or -var <var>`
 
-For example, the lmp\_mpi executable might be launched as follows:
+For example, the lmp_mpi executable might be launched as follows:
 
 .. code-block:: bash
 
@@ -50,8 +50,8 @@ set by using the :doc:`echo <echo>` command in the input script itself.
 **-help**
 
 Print a brief help summary and a list of options compiled into this
-executable for each LAMMPS style (atom\_style, fix, compute,
+executable for each LAMMPS style (atom_style, fix, compute,
-pair\_style, bond\_style, etc).  This can tell you if the command you
+pair_style, bond_style, etc).  This can tell you if the command you
 want to use was included via the appropriate package at compile time.
 LAMMPS will print the info and immediately exit if this switch is
 used.
@@ -65,7 +65,7 @@ used.
 Specify a file to use as an input script.  This is an optional switch
 when running LAMMPS in one-partition mode.  If it is not specified,
 LAMMPS reads its script from standard input, typically from a script
-via I/O redirection; e.g. lmp\_linux < in.run.  I/O redirection should
+via I/O redirection; e.g. lmp_linux < in.run.  I/O redirection should
 also work in parallel, but if it does not (in the unlikely case that
 an MPI implementation does not support it), then use the -in flag.
 Note that this is a required switch when running LAMMPS in
@@ -201,8 +201,8 @@ command which also launches another executable(s) at the same time.
 (The other executable could be LAMMPS as well.)  The color is an
 integer value which should be different for each executable (another
 application may set this value in a different way).  LAMMPS and the
-other executable(s) perform an MPI\_Comm\_split() with their own colors
+other executable(s) perform an MPI_Comm_split() with their own colors
-to shrink the MPI\_COMM\_WORLD communication to be the subset of
+to shrink the MPI_COMM_WORLD communication to be the subset of
 processors they are actually running on.
 
 Currently, this is only used in LAMMPS to perform client/server
@@ -284,7 +284,7 @@ log files are created.  This overrides the filename specified in the
 -log command-line option.  This option is useful when working with
 large numbers of partitions, allowing the partition log files to be
 suppressed (-plog none) or placed in a sub-directory (-plog
-replica\_files/log.lammps) If this option is not used the log file for
+replica_files/log.lammps) If this option is not used the log file for
 partition N is log.lammps.N or whatever is specified by the -log
 command-line option.
 
@@ -300,7 +300,7 @@ partition screen files are created.  This overrides the filename
 specified in the -screen command-line option.  This option is useful
 when working with large numbers of partitions, allowing the partition
 screen files to be suppressed (-pscreen none) or placed in a
-sub-directory (-pscreen replica\_files/screen).  If this option is not
+sub-directory (-pscreen replica_files/screen).  If this option is not
 used the screen file for partition N is screen.N or whatever is
 specified by the -screen command-line option.
 
@@ -469,7 +469,7 @@ The syntax following restartfile (or remap), namely
 
 is identical to the arguments of the :doc:`write_dump <write_dump>`
 command.  See its doc page for details.  This includes what per-atom
-fields are written to the dump file and optional dump\_modify settings,
+fields are written to the dump file and optional dump_modify settings,
 including ones that affect how parallel dump files are written, e.g.
 the *nfile* and *fileper* keywords.  See the
 :doc:`dump_modify <dump_modify>` doc page for details.
@@ -520,7 +520,7 @@ having to edit an input script.
 
 As an example, all of the packages provide a :doc:`pair_style lj/cut <pair_lj>` variant, with style names lj/cut/gpu,
 lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt.  A variant style
-can be specified explicitly in your input script, e.g. pair\_style
+can be specified explicitly in your input script, e.g. pair_style
 lj/cut/gpu.  If the -suffix switch is used the specified suffix
 (gpu,intel,kk,omp,opt) is automatically appended whenever your input
 script command creates a new :doc:`atom <atom_style>`,

doc/src/Run_output.rst

@@ -168,7 +168,7 @@ additional information is printed, e.g.
 The first line is the time spent doing 3d FFTs (several per timestep)
 and the fraction it represents of the total KSpace time (listed
 above).  Each 3d FFT requires computation (3 sets of 1d FFTs) and
-communication (transposes).  The total flops performed is 5Nlog\_2(N),
+communication (transposes).  The total flops performed is 5Nlog_2(N),
 where N is the number of points in the 3d grid.  The FFTs are timed
 with and without the communication and a Gflop rate is computed.  The
 3d rate is with communication; the 1d rate is without (just the 1d

doc/src/Run_windows.rst

@@ -7,14 +7,14 @@ To run a serial (non-MPI) executable, follow these steps:
   then typing "cmd".
 * Move to the directory where you have your input script,
   (e.g. by typing: cd "Documents").
-* At the command prompt, type "lmp\_serial -in in.file", where
+* At the command prompt, type "lmp_serial -in in.file", where
   in.file is the name of your LAMMPS input script.
 
 Note that the serial executable includes support for multi-threading
 parallelization from the styles in the USER-OMP packages.  To run with
 4 threads, you can type this:
 
-.. parsed-literal::
+.. code-block:: bash
 
    lmp_serial -in in.lj -pk omp 4 -sf omp
 
@@ -43,7 +43,7 @@ into the MPICH2 installation directory, then into the sub-directory
 
 Then type something like this:
 
-.. parsed-literal::
+.. code-block:: bash
 
    mpiexec -localonly 4 lmp_mpi -in in.file
    mpiexec -np 4 lmp_mpi -in in.file
@@ -58,13 +58,13 @@ patient before the output shows up.
 The parallel executable can also run on a single processor by typing
 something like this:
 
-.. parsed-literal::
+.. code-block:: bash
 
    lmp_mpi -in in.lj
 
 Note that the parallel executable also includes OpenMP
 multi-threading, which can be combined with MPI using something like:
 
-.. parsed-literal::
+.. code-block:: bash
 
    mpiexec -localonly 2 lmp_mpi -in in.lj -pk omp 2 -sf omp

doc/src/Speed_compare.rst

@@ -66,7 +66,7 @@ section below for examples where this has been done.
   acceleration and instead run it - concurrently with a GPU accelerated
   pair style - on the CPU. This can often be easily achieved with placing
   a *suffix off* command before and a *suffix on* command after the
-  *kspace\_style pppm* command.
+  *kspace_style pppm* command.
 * The KOKKOS/OpenMP and USER-OMP package have different thread management
   strategies, which should result in USER-OMP being more efficient for a
   small number of threads with increasing overhead as the number of threads

doc/src/Speed_gpu.rst

@@ -35,9 +35,9 @@ toolkit software on your system (this is primarily tested on Linux
 and completely unsupported on Windows):
 
 * Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/\*/information
-* Go to http://www.nvidia.com/object/cuda\_get.html
+* Go to http://www.nvidia.com/object/cuda_get.html
 * Install a driver and toolkit appropriate for your system (SDK is not necessary)
-* Run lammps/lib/gpu/nvc\_get\_devices (after building the GPU library, see below) to
+* Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to
   list supported devices and properties
 
 To compile and use this package in OpenCL mode, you currently need
@@ -47,7 +47,7 @@ installed. There can be multiple of them for the same or different hardware
 (GPUs, CPUs, Accelerators) installed at the same time. OpenCL refers to those
 as 'platforms'.  The GPU library will select the **first** suitable platform,
 but this can be overridden using the device option of the :doc:`package <package>`
-command. run lammps/lib/gpu/ocl\_get\_devices to get a list of available
+command. run lammps/lib/gpu/ocl_get_devices to get a list of available
 platforms and devices with a suitable ICD available.
 
 **Building LAMMPS with the GPU package:**
@@ -76,7 +76,7 @@ automatically append "gpu" to styles that support it.  Use the "-pk
 gpu Ng" :doc:`command-line switch <Run_options>` to set Ng = # of
 GPUs/node to use.
 
-.. parsed-literal::
+.. code-block:: bash
 
    lmp_machine -sf gpu -pk gpu 1 -in in.script                         # 1 MPI task uses 1 GPU
    mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script           # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
@@ -106,7 +106,7 @@ and use of multiple MPI tasks/GPU is the same.
 Use the :doc:`suffix gpu <suffix>` command, or you can explicitly add an
 "gpu" suffix to individual styles in your input script, e.g.
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    pair_style lj/cut/gpu 2.5
 

doc/src/Speed_intel.rst

@@ -79,7 +79,7 @@ order of operations compared to LAMMPS without acceleration:
 * The *newton* setting applies to all atoms, not just atoms shared
   between MPI tasks
 * Vectorization can change the order for adding pairwise forces
-* When using the -DLMP\_USE\_MKL\_RNG define (all included intel optimized
+* When using the -DLMP_USE_MKL_RNG define (all included intel optimized
   makefiles do) at build time, the random number generator for
   dissipative particle dynamics (pair style dpd/intel) uses the Mersenne
   Twister generator included in the Intel MKL library (that should be
@@ -102,8 +102,8 @@ LAMMPS should be built with the USER-INTEL package installed.
 Simulations should be run with 1 MPI task per physical *core*\ ,
 not *hardware thread*\ .
 
-* Edit src/MAKE/OPTIONS/Makefile.intel\_cpu\_intelmpi as necessary.
+* Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary.
-* Set the environment variable KMP\_BLOCKTIME=0
+* Set the environment variable KMP_BLOCKTIME=0
 * "-pk intel 0 omp $t -sf intel" added to LAMMPS command-line
 * $t should be 2 for Intel Xeon CPUs and 2 or 4 for Intel Xeon Phi
 * For some of the simple 2-body potentials without long-range
@@ -111,26 +111,26 @@ not *hardware thread*\ .
   the "newton off" setting added to the input script
 * For simulations on higher node counts, add "processors \* \* \* grid
   numa" to the beginning of the input script for better scalability
-* If using *kspace\_style pppm* in the input script, add
+* If using *kspace_style pppm* in the input script, add
-  "kspace\_modify diff ad" for better performance
+  "kspace_modify diff ad" for better performance
 
 For Intel Xeon Phi CPUs:
 
 * Runs should be performed using MCDRAM.
 
-For simulations using *kspace\_style pppm* on Intel CPUs supporting
+For simulations using *kspace_style pppm* on Intel CPUs supporting
 AVX-512:
 
-* Add "kspace\_modify diff ad" to the input script
+* Add "kspace_modify diff ad" to the input script
 * The command-line option should be changed to
   "-pk intel 0 omp $r lrt yes -sf intel" where $r is the number of
   threads minus 1.
-* Do not use thread affinity (set KMP\_AFFINITY=none)
+* Do not use thread affinity (set KMP_AFFINITY=none)
 * The "newton off" setting may provide better scalability
 
 For Intel Xeon Phi co-processors (Offload):
 
-* Edit src/MAKE/OPTIONS/Makefile.intel\_co-processor as necessary
+* Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary
 * "-pk intel N omp 1" added to command-line where N is the number of
   co-processors per node.
 
@@ -205,7 +205,7 @@ For building with make, several example Makefiles for building with
 the Intel compiler are included with LAMMPS in the src/MAKE/OPTIONS/
 directory:
 
-.. parsed-literal::
+.. code-block:: bash
 
    Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
    Makefile.knl                # Intel Compiler, Intel MPI, No Offload
@@ -213,7 +213,7 @@ directory:
    Makefile.intel_cpu_openpmi  # Intel Compiler, OpenMPI, No Offload
    Makefile.intel_co-processor  # Intel Compiler, Intel MPI, Offload
 
-Makefile.knl is identical to Makefile.intel\_cpu\_intelmpi except that
+Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
 it explicitly specifies that vectorization should be for Intel Xeon
 Phi x200 processors making it easier to cross-compile. For users with
 recent installations of Intel Parallel Studio, the process can be as
@@ -234,12 +234,12 @@ without offload support will produce a smaller binary.
 The general requirements for Makefiles with the USER-INTEL package
 are as follows. When using Intel compilers, "-restrict" is required
 and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS.
-CCFLAGS should include "-DLMP\_INTEL\_USELRT" (unless POSIX Threads
+CCFLAGS should include "-DLMP_INTEL_USELRT" (unless POSIX Threads
-are not supported in the build environment) and "-DLMP\_USE\_MKL\_RNG"
+are not supported in the build environment) and "-DLMP_USE_MKL_RNG"
 (unless Intel Math Kernel Library (MKL) is not available in the build
 environment). For Intel compilers, LIB should include "-ltbbmalloc"
-or if the library is not available, "-DLMP\_INTEL\_NO\_TBB" can be added
+or if the library is not available, "-DLMP_INTEL_NO_TBB" can be added
-to CCFLAGS. For builds supporting offload, "-DLMP\_INTEL\_OFFLOAD" is
+to CCFLAGS. For builds supporting offload, "-DLMP_INTEL_OFFLOAD" is
 required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
 recommended CCFLAG options for best performance are "-O2 -fno-alias
 -ansi-alias -qoverride-limits fp-model fast=2 -no-prec-div".
@@ -297,9 +297,9 @@ almost all cases.
    OpenMP threads on the host (CPU) will be set by default on the host
    *when using offload to a co-processor*\ . In this case, it is unnecessary
    to use other methods to control affinity (e.g. taskset, numactl,
-   I\_MPI\_PIN\_DOMAIN, etc.). This can be disabled with the *no\_affinity*
+   I_MPI_PIN_DOMAIN, etc.). This can be disabled with the *no_affinity*
    option to the :doc:`package intel <package>` command or by disabling the
-   option at build time (by adding -DINTEL\_OFFLOAD\_NOAFFINITY to the
+   option at build time (by adding -DINTEL_OFFLOAD_NOAFFINITY to the
    CCFLAGS line of your Makefile). Disabling this option is not
    recommended, especially when running on a machine with Intel
    Hyper-Threading technology disabled.
@@ -313,7 +313,7 @@ editing the input script. This switch will automatically append
 :doc:`package intel 1 <package>`. This package command is used to set
 options for the USER-INTEL package.  The default package command will
 specify that USER-INTEL calculations are performed in mixed precision,
-that the number of OpenMP threads is specified by the OMP\_NUM\_THREADS
+that the number of OpenMP threads is specified by the OMP_NUM_THREADS
 environment variable, and that if co-processors are present and the
 binary was built with offload support, that 1 co-processor per node
 will be used with automatic balancing of work between the CPU and the
@@ -324,11 +324,11 @@ the "-pk intel Nphi" :doc:`command-line switch <Run_options>` with
 keyword/value pairs as specified in the documentation. Here, Nphi = #
 of Xeon Phi co-processors/node (ignored without offload
 support). Common options to the USER-INTEL package include *omp* to
-override any OMP\_NUM\_THREADS setting and specify the number of OpenMP
+override any OMP_NUM_THREADS setting and specify the number of OpenMP
 threads, *mode* to set the floating-point precision mode, and *lrt* to
 enable Long-Range Thread mode as described below. See the :doc:`package intel <package>` command for details, including the default values
 used for all its options if not specified, and how to set the number
-of OpenMP threads via the OMP\_NUM\_THREADS environment variable if
+of OpenMP threads via the OMP_NUM_THREADS environment variable if
 desired.
 
 Examples (see documentation for your MPI/Machine for differences in
@@ -375,7 +375,7 @@ Long-Range Thread (LRT) mode is an option to the :doc:`package intel <package>`
 with SMT. It generates an extra pthread for each MPI task. The thread
 is dedicated to performing some of the PPPM calculations and MPI
 communications. This feature requires setting the pre-processor flag
--DLMP\_INTEL\_USELRT in the makefile when compiling LAMMPS. It is unset
+-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
 in the default makefiles (\ *Makefile.mpi* and *Makefile.serial*\ ) but
 it is set in all makefiles tuned for the USER-INTEL package.  On Intel
 Xeon Phi x200 series CPUs, the LRT feature will likely improve
@@ -387,7 +387,7 @@ normally be used for the run and add the "lrt yes" option to the "-pk"
 command-line suffix or "package intel" command. For example, if a run
 would normally perform best with "-pk intel 0 omp 4", instead use
 "-pk intel 0 omp 3 lrt yes". When using LRT, you should set the
-environment variable "KMP\_AFFINITY=none". LRT mode is not supported
+environment variable "KMP_AFFINITY=none". LRT mode is not supported
 when using offload.
 
 .. note::
@@ -425,7 +425,7 @@ alternative to LRT mode and the two cannot be used together.
 
 Currently, when using Intel MPI with Intel Xeon Phi x200 series
 CPUs, better performance might be obtained by setting the
-environment variable "I\_MPI\_SHM\_LMT=shm" for Linux kernels that do
+environment variable "I_MPI_SHM_LMT=shm" for Linux kernels that do
 not yet have full support for AVX-512. Runs on Intel Xeon Phi x200
 series processors will always perform better using MCDRAM. Please
 consult your system documentation for the best approach to specify
@@ -513,7 +513,7 @@ When offloading to a co-processor, :doc:`hybrid <pair_hybrid>` styles
 that require skip lists for neighbor builds cannot be offloaded.
 Using :doc:`hybrid/overlay <pair_hybrid>` is allowed.  Only one intel
 accelerated style may be used with hybrid styles when offloading.
-:doc:`Special\_bonds <special_bonds>` exclusion lists are not currently
+:doc:`Special_bonds <special_bonds>` exclusion lists are not currently
 supported with offload, however, the same effect can often be
 accomplished by setting cutoffs for excluded atom types to 0.  None of
 the pair styles in the USER-INTEL package currently support the

doc/src/Speed_kokkos.rst

@@ -21,7 +21,7 @@ package was developed primarily by Christian Trott (Sandia) and Stan
 Moore (Sandia) with contributions of various styles by others,
 including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
 (Sandia). For more information on developing using Kokkos abstractions
-see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos\_PG.pdf.
+see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
 
 Kokkos currently provides support for 3 modes of execution (per MPI
 task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
@@ -108,8 +108,8 @@ below.
 .. note::
 
    When using a single OpenMP thread, the Kokkos Serial back end (i.e.
-   Makefile.kokkos\_mpi\_only) will give better performance than the OpenMP
+   Makefile.kokkos_mpi_only) will give better performance than the OpenMP
-   back end (i.e. Makefile.kokkos\_omp) because some of the overhead to make
+   back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
    the code thread-safe is removed.
 
 .. note::
@@ -134,8 +134,8 @@ small numbers of threads (i.e. 8 or less) but does increase memory
 footprint and is not scalable to large numbers of threads. An
 alternative to data duplication is to use thread-level atomic operations
 which do not require data duplication. The use of atomic operations can
-be enforced by compiling LAMMPS with the "-DLMP\_KOKKOS\_USE\_ATOMICS"
+be enforced by compiling LAMMPS with the "-DLMP_KOKKOS_USE_ATOMICS"
-pre-processor flag. Most but not all Kokkos-enabled pair\_styles support
+pre-processor flag. Most but not all Kokkos-enabled pair_styles support
 data duplication. Alternatively, full neighbor lists avoid the need for
 duplication or atomic operations but require more compute operations per
 atom.  When using the Kokkos Serial back end or the OpenMP back end with
@@ -159,9 +159,9 @@ for your MPI installation), binding can be forced with these flags:
 For binding threads with KOKKOS OpenMP, use thread affinity
 environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
 later, intel 12 or later) setting the environment variable
-OMP\_PROC\_BIND=true should be sufficient. In general, for best
+OMP_PROC_BIND=true should be sufficient. In general, for best
-performance with OpenMP 4.0 or better set OMP\_PROC\_BIND=spread and
+performance with OpenMP 4.0 or better set OMP_PROC_BIND=spread and
-OMP\_PLACES=threads.  For binding threads with the KOKKOS pthreads
+OMP_PLACES=threads.  For binding threads with the KOKKOS pthreads
 option, compile LAMMPS the KOKKOS HWLOC=yes option as described below.
 
 **Running on Knight's Landing (KNL) Intel Xeon Phi:**
@@ -290,7 +290,7 @@ one or more nodes, each with two GPUs:
 .. note::
 
    To get an accurate timing breakdown between time spend in pair,
-   kspace, etc., you must set the environment variable CUDA\_LAUNCH\_BLOCKING=1.
+   kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
    However, this will reduce performance and is not recommended for production runs.
 
 **Run with the KOKKOS package by editing an input script:**
@@ -320,8 +320,8 @@ wish to change any of its option defaults, as set by the "-k on"
 
 With the KOKKOS package, both OpenMP multi-threading and GPUs can be
 used together in a few special cases. In the Makefile, the
-KOKKOS\_DEVICES variable must include both "Cuda" and "OpenMP", as is
+KOKKOS_DEVICES variable must include both "Cuda" and "OpenMP", as is
-the case for /src/MAKE/OPTIONS/Makefile.kokkos\_cuda\_mpi
+the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
 
 .. code-block:: bash
 
@@ -357,7 +357,7 @@ GPU. First compile with "--default-stream per-thread" added to CCFLAGS
 in the Kokkos CUDA Makefile.  Then explicitly use the "/kk/host"
 suffix for kspace and bonds, angles, etc.  in the input file and the
 "kk" suffix (equal to "kk/device") on the command line.  Also make
-sure the environment variable CUDA\_LAUNCH\_BLOCKING is not set to "1"
+sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
 so CPU/GPU overlap can occur.
 
 **Speed-ups to expect:**
@@ -394,34 +394,34 @@ Makefile.machine, or they can be specified as CMake variables.  Each
 takes a value shown below.  The default value is listed, which is set
 in the lib/kokkos/Makefile.kokkos file.
 
-* KOKKOS\_DEBUG, values = *yes*\ , *no*\ , default = *no*
+* KOKKOS_DEBUG, values = *yes*\ , *no*\ , default = *no*
-* KOKKOS\_USE\_TPLS, values = *hwloc*\ , *librt*\ , *experimental\_memkind*, default = *none*
+* KOKKOS_USE_TPLS, values = *hwloc*\ , *librt*\ , *experimental_memkind*, default = *none*
-* KOKKOS\_CXX\_STANDARD, values = *c++11*\ , *c++1z*\ , default = *c++11*
+* KOKKOS_CXX_STANDARD, values = *c++11*\ , *c++1z*\ , default = *c++11*
-* KOKKOS\_OPTIONS, values = *aggressive\_vectorization*, *disable\_profiling*, default = *none*
+* KOKKOS_OPTIONS, values = *aggressive_vectorization*, *disable_profiling*, default = *none*
-* KOKKOS\_CUDA\_OPTIONS, values = *force\_uvm*, *use\_ldg*, *rdc*\ , *enable\_lambda*, default = *enable\_lambda*
+* KOKKOS_CUDA_OPTIONS, values = *force_uvm*, *use_ldg*, *rdc*\ , *enable_lambda*, default = *enable_lambda*
 
-KOKKOS\_USE\_TPLS=hwloc binds threads to hardware cores, so they do not
+KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
-migrate during a simulation. KOKKOS\_USE\_TPLS=hwloc should always be
+migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
-used if running with KOKKOS\_DEVICES=Pthreads for pthreads. It is not
+used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
-necessary for KOKKOS\_DEVICES=OpenMP for OpenMP, because OpenMP
+necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
 provides alternative methods via environment variables for binding
 threads to hardware cores.  More info on binding threads to cores is
 given on the :doc:`Speed omp <Speed_omp>` doc page.
 
-KOKKOS\_USE\_TPLS=librt enables use of a more accurate timer mechanism
+KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
 on most Unix platforms. This library is not available on all
 platforms.
 
-KOKKOS\_DEBUG is only useful when developing a Kokkos-enabled style
+KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
-within LAMMPS. KOKKOS\_DEBUG=yes enables printing of run-time
+within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
 debugging information that can be useful. It also enables runtime
 bounds checking on Kokkos data structures.
 
-KOKKOS\_CXX\_STANDARD and KOKKOS\_OPTIONS are typically not changed when
+KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when
 building LAMMPS.
 
-KOKKOS\_CUDA\_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
+KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
-package must be compiled with the *enable\_lambda* option when using
+package must be compiled with the *enable_lambda* option when using
 GPUs.
 
 Restrictions

doc/src/Speed_measure.rst

@@ -14,7 +14,7 @@ timings; you can simply extrapolate from short runs.
 
 For the set of runs, look at the timing data printed to the screen and
 log file at the end of each LAMMPS run.  The
-:doc:`Run\_output <Run_output>` doc page gives an overview.
+:doc:`Run_output <Run_output>` doc page gives an overview.
 
 Running on one (or a few processors) should give a good estimate of
 the serial performance and what portions of the timestep are taking
@@ -42,5 +42,5 @@ inaccurate relative timing data, because processors have to wait when
 communication occurs for other processors to catch up.  Thus the
 reported times for "Communication" or "Other" may be higher than they
 really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI\_Barrier() lines in src/timer.cpp, and re-compile
+uncomment the MPI_Barrier() lines in src/timer.cpp, and re-compile
 LAMMPS, to obtain synchronized timings.

doc/src/Speed_omp.rst

@@ -23,7 +23,7 @@ instructions.
 
 These examples assume one or more 16-core nodes.
 
-.. parsed-literal::
+.. code-block:: bash
 
    env OMP_NUM_THREADS=16 lmp_omp -sf omp -in in.script           # 1 MPI task, 16 threads according to OMP_NUM_THREADS
    lmp_mpi -sf omp -in in.script                                  # 1 MPI task, no threads, optimized kernels
@@ -43,14 +43,14 @@ node), otherwise performance will suffer.
 As in the lines above, use the "-sf omp" :doc:`command-line switch <Run_options>`, which will automatically append "omp" to
 styles that support it.  The "-sf omp" switch also issues a default
 :doc:`package omp 0 <package>` command, which will set the number of
-threads per MPI task via the OMP\_NUM\_THREADS environment variable.
+threads per MPI task via the OMP_NUM_THREADS environment variable.
 
 You can also use the "-pk omp Nt" :doc:`command-line switch <Run_options>`, to explicitly set Nt = # of OpenMP threads
 per MPI task to use, as well as additional options.  Its syntax is the
 same as the :doc:`package omp <package>` command whose doc page gives
 details, including the default values used if it is not specified.  It
 also gives more details on how to set the number of threads via the
-OMP\_NUM\_THREADS environment variable.
+OMP_NUM_THREADS environment variable.
 
 **Or run with the USER-OMP package by editing an input script:**
 
@@ -60,14 +60,14 @@ and threads/MPI task is the same.
 Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
 "omp" suffix to individual styles in your input script, e.g.
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    pair_style lj/cut/omp 2.5
 
 You must also use the :doc:`package omp <package>` command to enable the
 USER-OMP package.  When you do this you also specify how many threads
 per MPI task to use.  The command doc page explains other options and
-how to set the number of threads via the OMP\_NUM\_THREADS environment
+how to set the number of threads via the OMP_NUM_THREADS environment
 variable.
 
 **Speed-ups to expect:**

doc/src/Speed_opt.rst

@@ -17,7 +17,7 @@ See the :ref:`Build extras <opt>` doc page for instructions.
 
 **Run with the OPT package from the command line:**
 
-.. parsed-literal::
+.. code-block:: bash
 
    lmp_mpi -sf opt -in in.script                # run in serial
    mpirun -np 4 lmp_mpi -sf opt -in in.script   # run in parallel
@@ -30,7 +30,7 @@ automatically append "opt" to styles that support it.
 Use the :doc:`suffix opt <suffix>` command, or you can explicitly add an
 "opt" suffix to individual styles in your input script, e.g.
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    pair_style lj/cut/opt 2.5
 

doc/src/Speed_packages.rst

@@ -90,13 +90,13 @@ listed above:
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
 | re-build LAMMPS                                                                                                                | make machine                                                         |
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| prepare and test a regular LAMMPS simulation                                                                                   | lmp\_machine -in in.script; mpirun -np 32 lmp\_machine -in in.script |
+| prepare and test a regular LAMMPS simulation                                                                                   | lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script   |
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
 | enable specific accelerator support via '-k on' :doc:`command-line switch <Run_options>`,                                      | only needed for KOKKOS package                                       |
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
 | set any needed options for the package via "-pk" :doc:`command-line switch <Run_options>` or :doc:`package <package>` command, | only if defaults need to be changed                                  |
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| use accelerated styles in your input via "-sf" :doc:`command-line switch <Run_options>` or :doc:`suffix <suffix>` command      | lmp\_machine -in in.script -sf gpu                                   |
+| use accelerated styles in your input via "-sf" :doc:`command-line switch <Run_options>` or :doc:`suffix <suffix>` command      | lmp_machine -in in.script -sf gpu                                    |
 +--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
 
 Note that the first 4 steps can be done as a single command with
@@ -132,7 +132,7 @@ packages.  As an example, here is a command that builds with all the
 GPU related packages installed (GPU, KOKKOS with Cuda), including
 settings to build the needed auxiliary GPU libraries for Kepler GPUs:
 
-.. parsed-literal::
+.. code-block:: bash
 
    Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi   -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi
 

doc/src/Tools.rst

@@ -99,7 +99,7 @@ binary2txt tool
 The file binary2txt.cpp converts one or more binary LAMMPS dump file
 into ASCII text files.  The syntax for running the tool is
 
-.. parsed-literal::
+.. code-block:: bash
 
    binary2txt file1 file2 ...
 
@@ -149,7 +149,7 @@ chains and solvent atoms can strongly overlap, so LAMMPS needs to run
 the system initially with a "soft" pair potential to un-overlap it.
 The syntax for running the tool is
 
-.. parsed-literal::
+.. code-block:: bash
 
    chain < def.chain > data.file
 
@@ -171,18 +171,18 @@ To compile the tools, edit the makefile for your system and run "make".
 Please report problems and issues the colvars library and its tools
 at: https://github.com/colvars/colvars/issues
 
-abf\_integrate:
+abf_integrate:
 
 MC-based integration of multidimensional free energy gradient
 Version 20110511
 
 .. parsed-literal::
 
-   Syntax: ./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0\|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >]
+   ./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0\|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >]
 
 The LAMMPS interface to the colvars collective variable library, as
 well as these tools, were created by Axel Kohlmeyer (akohlmey at
-gmail.com) at ICTP, Italy.
+gmail.com) while at ICTP, Italy.
 
 ----------
 
@@ -238,7 +238,7 @@ at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
 eam database tool
 -----------------------------
 
-The tools/eam\_database directory contains a Fortran program that will
+The tools/eam_database directory contains a Fortran program that will
 generate EAM alloy setfl potential files for any combination of 16
 elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
 Zr.  The files can then be used with the :doc:`pair_style eam/alloy <pair_eam>` command.
@@ -256,7 +256,7 @@ X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
 eam generate tool
 -----------------------------
 
-The tools/eam\_generate directory contains several one-file C programs
+The tools/eam_generate directory contains several one-file C programs
 that convert an analytic formula into a tabulated :doc:`embedded atom method (EAM) <pair_eam>` setfl potential file.  The potentials they
 produce are in the potentials directory, and can be used with the
 :doc:`pair_style eam/alloy <pair_eam>` command.
@@ -427,7 +427,7 @@ atoms can strongly overlap, so LAMMPS needs to run the system
 initially with a "soft" pair potential to un-overlap it.  The syntax
 for running the tool is
 
-.. parsed-literal::
+.. code-block:: bash
 
    micelle2d < def.micelle2d > data.file
 
@@ -512,10 +512,10 @@ This tool was written by Zachary Kraus at Georgia Tech.
 
 .. _pymol:
 
-pymol\_asphere tool
+pymol_asphere tool
 -------------------------------
 
-The pymol\_asphere sub-directory contains a tool for converting a
+The pymol_asphere sub-directory contains a tool for converting a
 LAMMPS dump file that contains orientation info for ellipsoidal
 particles into an input file for the `PyMol visualization package <pymolhome_>`_ or its `open source variant <pymolopen_>`_.
 
@@ -525,7 +525,7 @@ particles into an input file for the `PyMol visualization package <pymolhome_>`_
 
 Specifically, the tool triangulates the ellipsoids so they can be
 viewed as true ellipsoidal particles within PyMol.  See the README and
-examples directory within pymol\_asphere for more information.
+examples directory within pymol_asphere for more information.
 
 This tool was written by Mike Brown at Sandia.
 
@@ -555,7 +555,7 @@ README for more info on Pizza.py and how to use these scripts.
 replica tool
 --------------------------
 
-The tools/replica directory contains the reorder\_remd\_traj python script which
+The tools/replica directory contains the reorder_remd_traj python script which
 can be used to reorder the replica trajectories (resulting from the use of the
 temper command) according to temperature. This will produce discontinuous
 trajectories with all frames at the same temperature in each trajectory.
@@ -568,7 +568,7 @@ while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
 
 ----------
 
-.. _reax\_tool:
+.. _reax_tool:
 
 reax tool
 --------------------------
@@ -587,7 +587,7 @@ These tools were written by Aidan Thompson at Sandia.
 smd tool
 ------------------
 
-The smd sub-directory contains a C++ file dump2vtk\_tris.cpp and
+The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
 Makefile which can be compiled and used to convert triangle output
 files created by the Smooth-Mach Dynamics (USER-SMD) package into a
 VTK-compatible unstructured grid file.  It could then be read in and
@@ -610,7 +610,7 @@ The spin sub-directory contains a C file interpolate.c which can
 be compiled and used to perform a cubic polynomial interpolation of
 the MEP following a GNEB calculation.
 
-See the README file in tools/spin/interpolate\_gneb for more details.
+See the README file in tools/spin/interpolate_gneb for more details.
 
 This tool was written by the SPIN package author, Julien
 Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
@@ -618,7 +618,7 @@ Ivanov, at University of Iceland (ali5 at hi.is).
 
 ----------
 
-.. _singularity\_tool:
+.. _singularity_tool:
 
 singularity tool
 ----------------------------------------

doc/src/angle_charmm.rst

@@ -36,7 +36,7 @@ The *charmm* angle style uses the potential
 
    E = K (\theta - \theta_0)^2 + K_{ub} (r - r_{ub})^2
 
-with an additional Urey\_Bradley term based on the distance :math:`r` between
+with an additional Urey_Bradley term based on the distance :math:`r` between
 the 1st and 3rd atoms in the angle.  :math:`K`, :math:`\theta_0`,
 :math:`K_{ub}`, and :math:`R_{ub}` are coefficients defined for each angle
 type.

doc/src/angle_cross.rst

@@ -53,7 +53,7 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-USER\_YAFF package.  See the :doc:`Build package <Build_package>` doc
+USER_YAFF package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/angle_fourier.rst

@@ -66,7 +66,7 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-USER\_MISC package.  See the :doc:`Build package <Build_package>` doc
+USER_MISC package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/angle_fourier_simple.rst

@@ -65,7 +65,7 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-USER\_MISC package.  See the :doc:`Build package <Build_package>` doc
+USER_MISC package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/angle_hybrid.rst

@@ -34,7 +34,7 @@ command or in the data file.
 
 In the :doc:`angle_coeff <angle_coeff>` commands, the name of an angle style must be added
 after the angle type, with the remaining coefficients being those
-appropriate to that style.  In the example above, the 2 angle\_coeff
+appropriate to that style.  In the example above, the 2 angle_coeff
 commands set angles of angle type 1 to be computed with a *harmonic*
 potential with coefficients 80.0, 30.0 for :math:`K`, :math:`\theta_0`.  All other angle
 types :math:`(2 - N)` are computed with a *cosine* potential with coefficient

doc/src/angle_mm3.rst

@@ -47,7 +47,7 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-USER\_YAFF package.  See the :doc:`Build package <Build_package>` doc
+USER_YAFF package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/angle_quartic.rst

@@ -72,7 +72,7 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-USER\_MISC package.  See the :doc:`Build package <Build_package>` doc
+USER_MISC package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/angle_sdk.rst

@@ -37,7 +37,7 @@ where :math:`\theta_0` is the equilibrium value of the angle and
 *lj/sdk* pair style between the atoms 1 and 3.  This angle potential is
 intended for coarse grained MD simulations with the CMM parameterization
 using the :doc:`pair_style lj/sdk <pair_sdk>`.  Relative to the
-pair\_style *lj/sdk*\ , however, the energy is shifted by
+pair_style *lj/sdk*\ , however, the energy is shifted by
 :math:`\epsilon`, to avoid sudden jumps.  Note that the usual 1/2 factor
 is included in :math:`K`.
 
@@ -50,7 +50,7 @@ The following coefficients must be defined for each angle type via the
 :math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of :math:`K` are in energy/radian\^2.
 The also required *lj/sdk* parameters will be extracted automatically
-from the pair\_style.
+from the pair_style.
 
 ----------
 

doc/src/angle_style.rst

@@ -41,7 +41,7 @@ files which means angle_style and :doc:`angle_coeff <angle_coeff>`
 commands do not need to be re-specified in an input script that
 restarts a simulation.  See the :doc:`read_restart <read_restart>`
 command for details on how to do this.  The one exception is that
-angle\_style *hybrid* only stores the list of sub-styles in the restart
+angle_style *hybrid* only stores the list of sub-styles in the restart
 file; angle coefficients need to be re-specified.
 
 .. note::
@@ -61,7 +61,7 @@ the style to display the formula it computes and coefficients
 specified by the associated :doc:`angle_coeff <angle_coeff>` command.
 
 Click on the style to display the formula it computes, any additional
-arguments specified in the angle\_style command, and coefficients
+arguments specified in the angle_style command, and coefficients
 specified by the associated :doc:`angle_coeff <angle_coeff>` command.
 
 There are also additional accelerated pair styles included in the
@@ -98,7 +98,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 Restrictions
 """"""""""""
 
-Angle styles can only be set for atom\_styles that allow angles to be
+Angle styles can only be set for atom_styles that allow angles to be
 defined.
 
 Most angle styles are part of the MOLECULE package.  They are only

doc/src/angle_table.rst

@@ -87,7 +87,7 @@ keyword followed by one or more numeric values.
 The parameter "N" is required and its value is the number of table
 entries that follow.  Note that this may be different than the *N*
 specified in the :doc:`angle_style table <angle_style>` command.  Let
-Ntable = *N* in the angle\_style command, and Nfile = "N" in the
+Ntable = *N* in the angle_style command, and Nfile = "N" in the
 tabulated file.  What LAMMPS does is a preliminary interpolation by
 creating splines using the Nfile tabulated values as nodal points.  It
 uses these to interpolate as needed to generate energy and derivative
@@ -148,12 +148,12 @@ instructions on how to use the accelerated styles effectively.
 
 **Restart info:**
 
-This angle style writes the settings for the "angle\_style table"
+This angle style writes the settings for the "angle_style table"
-command to :doc:`binary restart files <restart>`, so a angle\_style
+command to :doc:`binary restart files <restart>`, so a angle_style
 command does not need to specified in an input script that reads a
 restart file.  However, the coefficient information is not stored in
 the restart file, since it is tabulated in the potential files.  Thus,
-angle\_coeff commands do need to be specified in the restart input
+angle_coeff commands do need to be specified in the restart input
 script.
 
 Restrictions

doc/src/atom_modify.rst

@@ -60,8 +60,8 @@ The only reason not to use atom IDs is if you are running an atomic
 simulation so large that IDs cannot be uniquely assigned.  For a
 default LAMMPS build this limit is 2\^31 or about 2 billion atoms.
 However, even in this case, you can use 64-bit atom IDs, allowing 2\^63
-or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS\_BIGBIG
+or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
-switch.  This is described on the :doc:`Build\_settings <Build_settings>`
+switch.  This is described on the :doc:`Build_settings <Build_settings>`
 doc page.  If atom IDs are not used, they must be specified as 0 for
 all atoms, e.g. in a data or restart file.
 
@@ -108,7 +108,7 @@ this command.  Note that specifying "all" as the group-ID effectively
 turns off the *first* option.
 
 It is OK to use the *first* keyword with a group that has not yet been
-defined, e.g. to use the atom\_modify first command at the beginning of
+defined, e.g. to use the atom_modify first command at the beginning of
 your input script.  LAMMPS does not use the group until a simulation
 is run.
 

doc/src/atom_style.rst

@@ -119,7 +119,7 @@ quantities.
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *tri*        | corner points, angular momentum                     | rigid bodies                         |
 +--------------+-----------------------------------------------------+--------------------------------------+
-| *wavepacket* | charge, spin, eradius, etag, cs\_re, cs\_im         | AWPMD                                |
+| *wavepacket* | charge, spin, eradius, etag, cs_re, cs_im           | AWPMD                                |
 +--------------+-----------------------------------------------------+--------------------------------------+
 
 .. note::
@@ -158,7 +158,7 @@ For the *dipole* style, a point dipole is defined for each point
 particle.  Note that if you wish the particles to be finite-size
 spheres as in a Stockmayer potential for a dipolar fluid, so that the
 particles can rotate due to dipole-dipole interactions, then you need
-to use atom\_style hybrid sphere dipole, which will assign both a
+to use atom_style hybrid sphere dipole, which will assign both a
 diameter and dipole moment to each particle.
 
 For the *electron* style, the particles representing electrons are 3d
@@ -171,14 +171,14 @@ per-particle mass and volume.
 The *dpd* style is for dissipative particle dynamics (DPD) particles.
 Note that it is part of the USER-DPD package, and is not for use with
 the :doc:`pair_style dpd or dpd/stat <pair_dpd>` commands, which can
-simply use atom\_style atomic.  Atom\_style dpd extends DPD particle
+simply use atom_style atomic.  Atom_style dpd extends DPD particle
 properties with internal temperature (dpdTheta), internal conductive
 energy (uCond), internal mechanical energy (uMech), and internal
 chemical energy (uChem).
 
 The *edpd* style is for energy-conserving dissipative particle
-dynamics (eDPD) particles which store a temperature (edpd\_temp), and
+dynamics (eDPD) particles which store a temperature (edpd_temp), and
-heat capacity(edpd\_cv).
+heat capacity(edpd_cv).
 
 The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
 particles which store a density (rho) for considering
@@ -186,7 +186,7 @@ density-dependent many-body interactions.
 
 The *tdpd* style is for transport dissipative particle dynamics (tDPD)
 particles which store a set of chemical concentration. An integer
-"cc\_species" is required to specify the number of chemical species
+"cc_species" is required to specify the number of chemical species
 involved in a tDPD system.
 
 The *meso* style is for smoothed particle hydrodynamics (SPH)
@@ -205,7 +205,7 @@ Those spins have a norm (their magnetic moment) and a direction.
 
 The *wavepacket* style is similar to *electron*\ , but the electrons may
 consist of several Gaussian wave packets, summed up with coefficients
-cs= (cs\_re,cs\_im).  Each of the wave packets is treated as a separate
+cs= (cs_re,cs_im).  Each of the wave packets is treated as a separate
 particle in LAMMPS, wave packets belonging to the same electron must
 have identical *etag* values.
 
@@ -232,7 +232,7 @@ can be advantageous for large-scale coarse-grained systems.
 .. note::
 
    When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
-   insure the atom types, bond types, angle\_types, etc in all the
+   insure the atom types, bond types, angle_types, etc in all the
    molecules are consistent.  E.g. if one molecule represents H2O and
    another CO2, then you probably do not want each molecule file to
    define 2 atom types and a single bond type, because they will conflict
@@ -256,7 +256,7 @@ orientation and position can be time integrated due to forces and
 torques.
 
 Note that there may be additional arguments required along with the
-*bstyle* specification, in the atom\_style body command.  These
+*bstyle* specification, in the atom_style body command.  These
 arguments are described on the :doc:`Howto body <Howto_body>` doc page.
 
 ----------
@@ -271,7 +271,7 @@ If some atoms have bonds, but others do not, use the *bond* style.
 The only scenario where the *hybrid* style is needed is if there is no
 single style which defines all needed properties of all atoms.  For
 example, as mentioned above, if you want dipolar particles which will
-rotate due to torque, you need to use "atom\_style hybrid sphere
+rotate due to torque, you need to use "atom_style hybrid sphere
 dipole".  When a hybrid style is used, atoms store and communicate the
 union of all quantities implied by the individual styles.
 
@@ -351,7 +351,7 @@ Related commands
 Default
 """""""
 
-atom\_style atomic
+atom_style atomic
 
 ----------
 

doc/src/balance.rst

@@ -197,7 +197,7 @@ The "grid" methods can be used with either of the
 :doc:`comm_style <comm_style>` command options, *brick* or *tiled*\ .  The
 "tiling" methods can only be used with :doc:`comm_style tiled <comm_style>`.  Note that it can be useful to use a "grid"
 method with :doc:`comm_style tiled <comm_style>` to return the domain
-partitioning to a logical 3d grid of processors so that "comm\_style
+partitioning to a logical 3d grid of processors so that "comm_style
 brick" can afterwords be specified for subsequent :doc:`run <run>`
 commands.
 
@@ -228,7 +228,7 @@ that specify the position of the cutting planes.  This requires
 knowing Ps = Px or Py or Pz = the number of processors assigned by
 LAMMPS to the relevant dimension.  This assignment is made (and the
 Px, Py, Pz values printed out) when the simulation box is created by
-the "create\_box" or "read\_data" or "read\_restart" command and is
+the "create_box" or "read_data" or "read_restart" command and is
 influenced by the settings of the :doc:`processors <processors>`
 command.
 
@@ -333,7 +333,7 @@ particles in that sub-box.
 
 ----------
 
-.. _weighted\_balance:
+.. _weighted_balance:
 
 This sub-section describes how to perform weighted load balancing
 using the *weight* keyword.
@@ -462,7 +462,7 @@ velocity, the volume of its Voronoi cell, etc.
 
 The *store* weight style does not compute a weight factor.  Instead it
 stores the current accumulated weights in a custom per-atom property
-specified by *name*\ .  This must be a property defined as *d\_name* via
+specified by *name*\ .  This must be a property defined as *d_name* via
 the :doc:`fix property/atom <fix_property_atom>` command.  Note that
 these custom per-atom properties can be output in a :doc:`dump <dump>`
 file, so this is a way to examine, debug, or visualize the

doc/src/bond_coeff.rst

@@ -40,7 +40,7 @@ leading asterisk means all types from 1 to n (inclusive).  A trailing
 asterisk means all types from n to N (inclusive).  A middle asterisk
 means all types from m to n (inclusive).
 
-Note that using a bond\_coeff command can override a previous setting
+Note that using a bond_coeff command can override a previous setting
 for the same bond type.  For example, these commands set the coeffs
 for all bond types, then overwrite the coeffs for just bond type 2:
 
@@ -50,7 +50,7 @@ for all bond types, then overwrite the coeffs for just bond type 2:
    bond_coeff 2 200.0 1.2
 
 A line in a data file that specifies bond coefficients uses the exact
-same format as the arguments of the bond\_coeff command in an input
+same format as the arguments of the bond_coeff command in an input
 script, except that wild-card asterisks should not be used since
 coefficients for all N types must be listed in the file.  For example,
 under the "Bond Coeffs" section of a data file, the line that
@@ -68,7 +68,7 @@ compact form on the :doc:`Commands bond <Commands_bond>` doc page.
 
 On either of those pages, click on the style to display the formula it
 computes and its coefficients as specified by the associated
-bond\_coeff command.
+bond_coeff command.
 
 ----------
 

doc/src/bond_hybrid.rst

@@ -32,9 +32,9 @@ be computed with a *harmonic* potential.  The assignment of bond type
 to style is made via the :doc:`bond_coeff <bond_coeff>` command or in
 the data file.
 
-In the bond\_coeff commands, the name of a bond style must be added
+In the bond_coeff commands, the name of a bond style must be added
 after the bond type, with the remaining coefficients being those
-appropriate to that style.  In the example above, the 2 bond\_coeff
+appropriate to that style.  In the example above, the 2 bond_coeff
 commands set bonds of bond type 1 to be computed with a *harmonic*
 potential with coefficients 80.0, 1.2 for :math:`K`, :math:`r_0`.  All other bond types
 (2-N) are computed with a *fene* potential with coefficients 30.0,
@@ -54,7 +54,7 @@ line in the "Bond Coeffs" section, e.g.
    ...
 
 A bond style of *none* with no additional coefficients can be used in
-place of a bond style, either in a input script bond\_coeff command or
+place of a bond style, either in a input script bond_coeff command or
 in the data file, if you desire to turn off interactions for specific
 bond types.
 
@@ -69,7 +69,7 @@ info.
 
 Unlike other bond styles, the hybrid bond style does not store bond
 coefficient info for individual sub-styles in a :doc:`binary restart files <restart>`.  Thus when restarting a simulation from a restart
-file, you need to re-specify bond\_coeff commands.
+file, you need to re-specify bond_coeff commands.
 
 Related commands
 """"""""""""""""

doc/src/bond_mm3.rst

@@ -47,7 +47,7 @@ Restrictions
 """"""""""""
 
 This bond style can only be used if LAMMPS was built with the
-USER\_YAFF package.  See the :doc:`Build package <Build_package>` doc
+USER_YAFF package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands

doc/src/bond_style.rst

@@ -47,10 +47,10 @@ The coefficients associated with a bond style can be specified in a
 data or restart file or via the :doc:`bond_coeff <bond_coeff>` command.
 
 All bond potentials store their coefficient data in binary restart
-files which means bond\_style and :doc:`bond_coeff <bond_coeff>` commands
+files which means bond_style and :doc:`bond_coeff <bond_coeff>` commands
 do not need to be re-specified in an input script that restarts a
 simulation.  See the :doc:`read_restart <read_restart>` command for
-details on how to do this.  The one exception is that bond\_style
+details on how to do this.  The one exception is that bond_style
 *hybrid* only stores the list of sub-styles in the restart file; bond
 coefficients need to be re-specified.
 
@@ -71,7 +71,7 @@ the style to display the formula it computes and coefficients
 specified by the associated :doc:`bond_coeff <bond_coeff>` command.
 
 Click on the style to display the formula it computes, any additional
-arguments specified in the bond\_style command, and coefficients
+arguments specified in the bond_style command, and coefficients
 specified by the associated :doc:`bond_coeff <bond_coeff>` command.
 
 There are also additional accelerated pair styles included in the

doc/src/bond_table.rst

@@ -146,12 +146,12 @@ instructions on how to use the accelerated styles effectively.
 
 **Restart info:**
 
-This bond style writes the settings for the "bond\_style table"
+This bond style writes the settings for the "bond_style table"
-command to :doc:`binary restart files <restart>`, so a bond\_style
+command to :doc:`binary restart files <restart>`, so a bond_style
 command does not need to specified in an input script that reads a
 restart file.  However, the coefficient information is not stored in
 the restart file, since it is tabulated in the potential files.  Thus,
-bond\_coeff commands do need to be specified in the restart input
+bond_coeff commands do need to be specified in the restart input
 script.
 
 Restrictions

doc/src/bond_zero.rst

@@ -33,7 +33,7 @@ atoms listed in the data file read by the :doc:`read_data <read_data>`
 command.  If no bond style is defined, this command cannot be used.
 
 The optional *nocoeff* flag allows to read data files with a BondCoeff
-section for any bond style. Similarly, any bond\_coeff commands
+section for any bond style. Similarly, any bond_coeff commands
 will only be checked for the bond type number and the rest ignored.
 
 Note that the :doc:`bond_coeff <bond_coeff>` command must be used for

doc/src/change_box.rst

@@ -102,10 +102,10 @@ new owning processors.
 
 .. note::
 
-   This means that you cannot use the change\_box command to enlarge
+   This means that you cannot use the change_box command to enlarge
    a shrink-wrapped box, e.g. to make room to insert more atoms via the
    :doc:`create_atoms <create_atoms>` command, because the simulation box
-   will be re-shrink-wrapped before the change\_box command completes.
+   will be re-shrink-wrapped before the change_box command completes.
    Instead you could do something like this, assuming the simulation box
    is non-periodic and atoms extend from 0 to 20 in all dimensions:
 
@@ -120,7 +120,7 @@ new owning processors.
 
 .. note::
 
-   Unlike the earlier "displace\_box" version of this command, atom
+   Unlike the earlier "displace_box" version of this command, atom
    remapping is NOT performed by default.  This command allows remapping
    to be done in a more general way, exactly when you specify it (zero or
    more times) in the sequence of transformations.  Thus if you do not
@@ -280,7 +280,7 @@ command.  This command allows the boundary conditions to be changed
 later in your input script.  Also note that the
 :doc:`read_restart <read_restart>` will change boundary conditions to
 match what is stored in the restart file.  So if you wish to change
-them, you should use the change\_box command after the read\_restart
+them, you should use the change_box command after the read_restart
 command.
 
 ----------
@@ -308,7 +308,7 @@ useful if you wish to use the *remap* keyword more than once or if you
 wish it to be applied to an intermediate box size/shape in a sequence
 of keyword operations.  Note that the box size/shape is saved before
 any of the keywords are processed, i.e. the box size/shape at the time
-the create\_box command is encountered in the input script.
+the create_box command is encountered in the input script.
 
 The *remap* keyword remaps atom coordinates from the last saved box
 size/shape to the current box state.  For example, if you stretch the
@@ -343,7 +343,7 @@ the input script when this command is issued, no :doc:`dumps <dump>` can
 be active, nor can a :doc:`fix deform <fix_deform>` be active.  This is
 because these commands test whether the simulation box is orthogonal
 when they are first issued.  Note that these commands can be used in
-your script before a change\_box command is issued, so long as an
+your script before a change_box command is issued, so long as an
 :doc:`undump <undump>` or :doc:`unfix <unfix>` command is also used to
 turn them off.
 

doc/src/comm_modify.rst

@@ -49,9 +49,9 @@ processors and stored as properties of ghost atoms.
    you specify a :doc:`comm_style <comm_style>` or
    :doc:`read_restart <read_restart>` command, all communication settings
    are restored to their default or stored values, including those
-   previously reset by a comm\_modify command.  Thus if your input script
+   previously reset by a comm_modify command.  Thus if your input script
-   specifies a comm\_style or read\_restart command, you should use the
+   specifies a comm_style or read_restart command, you should use the
-   comm\_modify command after it.
+   comm_modify command after it.
 
 The *mode* keyword determines whether a single or multiple cutoff
 distances are used to determine which atoms to communicate.
@@ -82,7 +82,7 @@ printed. Specifying a cutoff value of 0.0 will reset any previous value
 to the default. If bonded interactions exist and equilibrium bond length
 information is available, then also a heuristic based on that bond length
 is computed. It is used as communication cutoff, if there is no pair
-style present and no *comm\_modify cutoff* command used. Otherwise a
+style present and no *comm_modify cutoff* command used. Otherwise a
 warning is printed, if this bond based estimate is larger than the
 communication cutoff used. A
 

doc/src/compute.rst

@@ -72,11 +72,11 @@ discussed below, it can be referenced via the following bracket
 notation, where ID is the ID of the compute:
 
 +-------------+--------------------------------------------+
-| c\_ID       | entire scalar, vector, or array            |
+| c_ID        | entire scalar, vector, or array            |
 +-------------+--------------------------------------------+
-| c\_ID[I]    | one element of vector, one column of array |
+| c_ID[I]     | one element of vector, one column of array |
 +-------------+--------------------------------------------+
-| c\_ID[I][J] | one element of array                       |
+| c_ID[I][J]  | one element of array                       |
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the
@@ -88,7 +88,7 @@ vector or array.
 Note that commands and :doc:`variables <variable>` which use compute
 quantities typically do not allow for all kinds, e.g. a command may
 require a vector of values, not a scalar.  This means there is no
-ambiguity about referring to a compute quantity as c\_ID even if it
+ambiguity about referring to a compute quantity as c_ID even if it
 produces, for example, both a scalar and vector.  The doc pages for
 various commands explain the details.
 
@@ -116,7 +116,7 @@ e.g. temperature.  Extensive means the value scales with the number of
 atoms in the simulation, e.g. total rotational kinetic energy.
 :doc:`Thermodynamic output <thermo_style>` will normalize extensive
 values by the number of atoms in the system, depending on the
-"thermo\_modify norm" setting.  It will not normalize intensive values.
+"thermo_modify norm" setting.  It will not normalize intensive values.
 If a compute value is accessed in another way, e.g. by a
 :doc:`variable <variable>`, you may want to know whether it is an
 intensive or extensive value.  See the doc page for individual
@@ -125,8 +125,8 @@ computes for further info.
 ----------
 
 LAMMPS creates its own computes internally for thermodynamic output.
-Three computes are always created, named "thermo\_temp",
+Three computes are always created, named "thermo_temp",
-"thermo\_press", and "thermo\_pe", as if these commands had been invoked
+"thermo_press", and "thermo_pe", as if these commands had been invoked
 in the input script:
 
 .. code-block:: LAMMPS

doc/src/compute_adf.rst

@@ -64,7 +64,7 @@ neighbor atom in each requested ADF.
    those pairs will not be included in the ADF. This does not apply when
    using long-range coulomb interactions (\ *coul/long*\ , *coul/msm*\ ,
    *coul/wolf* or similar.  One way to get around this would be to set
-   special\_bond scaling factors to very tiny numbers that are not exactly
+   special_bond scaling factors to very tiny numbers that are not exactly
    zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
    use the :doc:`rerun <rerun>` command to compute the ADF for snapshots in
    the dump file.  The rerun script can use a
@@ -106,7 +106,7 @@ in the range of types represented by *ktypeN*\ .
 If no *itypeN*\ , *jtypeN*\ , *ktypeN* settings are specified, then
 LAMMPS will generate a single ADF for all atoms in the group.
 The inner cutoff is set to zero and the outer cutoff is set
-to the force cutoff. If no pair\_style is specified, there is no
+to the force cutoff. If no pair_style is specified, there is no
 force cutoff and LAMMPS will give an error message. Note that
 in most cases, generating an ADF for all atoms is not a good thing.
 Such an ADF is both uninformative and

doc/src/compute_angle.rst

@@ -24,8 +24,8 @@ Description
 """""""""""
 
 Define a computation that extracts the angle energy calculated by each
-of the angle sub-styles used in the  "angle\_style
+of the angle sub-styles used in the  "angle_style
-hybrid" angle\_hybrid.html command.  These values are made accessible
+hybrid" angle_hybrid.html command.  These values are made accessible
 for output or further processing by other commands.  The group
 specified for this command is ignored.
 
@@ -35,7 +35,7 @@ energy contributed by one or more of the hybrid sub-styles.
 **Output info:**
 
 This compute calculates a global vector of length N where N is the
-number of sub\_styles defined by the :doc:`angle_style hybrid <angle_style>` command, which can be accessed by indices
+number of sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command, which can be accessed by indices
 1-N.  These values can be used by any command that uses global scalar
 or vector values from a compute as input.  See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
 options.

doc/src/compute_angle_local.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * angle/local = style name of this compute command
 * one or more values may be appended
-* value = *theta* or *eng* or *v\_name*
+* value = *theta* or *eng* or *v_name*
 
   .. parsed-literal::
 
@@ -51,9 +51,9 @@ The value *theta* is the angle for the 3 atoms in the interaction.
 
 The value *eng* is the interaction energy for the angle.
 
-The value *v\_name* can be used together with the *set* keyword to
+The value *v_name* can be used together with the *set* keyword to
 compute a user-specified function of the angle theta.  The *name*
-specified for the *v\_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
+specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
 variable which will store the angle theta.  This other variable must
 be an :doc:`internal-style variable <variable>` defined in the input
 script; its initial numeric value can be anything.  It must be an

doc/src/compute_body_local.rst

@@ -61,7 +61,7 @@ group.
 For a body particle, the *integer* keywords refer to fields calculated
 by the body style for each sub-particle.  The body style, as specified
 by the :doc:`atom_style body <atom_style>`, determines how many fields
-exist and what they are.  See the :doc:`Howto\_body <Howto_body>` doc
+exist and what they are.  See the :doc:`Howto_body <Howto_body>` doc
 page for details of the different styles.
 
 Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute.  If fields 1,2,3 for the

doc/src/compute_bond.rst

@@ -35,7 +35,7 @@ or more of the hybrid sub-styles.
 **Output info:**
 
 This compute calculates a global vector of length N where N is the
-number of sub\_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
+number of sub_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
 options.