Merge pull request #2498 from rbberger/next_lammps_version

Step version string for next LAMMPS release

.github/CONTRIBUTING.md

@@ -108,7 +108,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 
 For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
 Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
-Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assesment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
+Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
 You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
 If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.

README

@@ -37,14 +37,14 @@ tools                      pre- and post-processing tools
 
 Point your browser at any of these files to get started:
 
-https://lammps.sandia.gov/doc/Manual.html         LAMMPS user manual
+https://lammps.sandia.gov/doc/Manual.html         LAMMPS manual
 https://lammps.sandia.gov/doc/Intro.html          hi-level introduction
 https://lammps.sandia.gov/doc/Build.html          how to build LAMMPS
 https://lammps.sandia.gov/doc/Run_head.html       how to run LAMMPS
 https://lammps.sandia.gov/doc/Commands_all.html   Table of available commands
-https://lammps.sandia.gov/doc/pg_library.html     LAMMPS programmer guide
+https://lammps.sandia.gov/doc/Library.html        LAMMPS library interfaces
 https://lammps.sandia.gov/doc/Modify.html         how to modify and extend LAMMPS
-https://lammps.sandia.gov/doc/pg_developer.html   LAMMPS developer guide
+https://lammps.sandia.gov/doc/Developer.html      LAMMPS developer info
 
 You can also create these doc pages locally:
 

cmake/Modules/Packages/KIM.cmake

@@ -34,8 +34,8 @@ if(DOWNLOAD_KIM)
   enable_language(C)
   enable_language(Fortran)
   ExternalProject_Add(kim_build
-    URL https://s3.openkim.org/kim-api/kim-api-2.1.3.txz
-    URL_MD5 6ee829a1bbba5f8b9874c88c4c4ebff8
+    URL https://s3.openkim.org/kim-api/kim-api-2.2.0.txz
+    URL_MD5 e7f944e1593cffd7444679a660607f6c
     BINARY_DIR build
     CMAKE_ARGS ${CMAKE_REQUEST_PIC}
                -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
@@ -53,11 +53,28 @@ if(DOWNLOAD_KIM)
   add_library(LAMMPS::KIM UNKNOWN IMPORTED)
   set_target_properties(LAMMPS::KIM PROPERTIES
     IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX}"
-    INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include/kim-api")
-  target_link_libraries(lammps PRIVATE LAMMPS::KIM)
+    INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include/kim-api"
+    )
   add_dependencies(LAMMPS::KIM kim_build)
+  target_link_libraries(lammps PRIVATE LAMMPS::KIM)
+  # Set rpath so lammps build directory is relocatable
+  if("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
+    set(_rpath_prefix "@loader_path")
+  else()
+    set(_rpath_prefix "$ORIGIN")
+  endif()
+  set_target_properties(lmp PROPERTIES
+    BUILD_RPATH "${_rpath_prefix}/kim_build-prefix/lib"
+    )
 else()
-  find_package(PkgConfig REQUIRED)
-  pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=${KIM-API_MIN_VERSION})
-  target_link_libraries(lammps PRIVATE PkgConfig::KIM-API)
+  if(KIM-API_FOUND AND KIM_API_VERSION VERSION_GREATER_EQUAL 2.2.0)
+    # For kim-api >= 2.2.0
+    find_package(KIM-API ${KIM-API_MIN_VERSION} CONFIG REQUIRED)
+    target_link_libraries(lammps PRIVATE KIM-API::kim-api)
+  else()
+    # For kim-api 2.1.3 (consistent with previous version of this file)
+    find_package(PkgConfig REQUIRED)
+    pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=KIM-API_MIN_VERSION)
+    target_link_libraries(lammps PRIVATE PkgConfig::KIM-API)
+  endif()
 endif()

cmake/Modules/Packages/KOKKOS.cmake

@@ -35,8 +35,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
   ExternalProject_Add(kokkos_build
-    URL https://github.com/kokkos/kokkos/archive/3.2.00.tar.gz
-    URL_MD5 81569170fe232e5e64ab074f7cca5e50
+    URL https://github.com/kokkos/kokkos/archive/3.2.01.tar.gz
+    URL_MD5 ba72440e285ccde05b403694ea0c92e5
     CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
     BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a
   )
@@ -50,7 +50,7 @@ if(DOWNLOAD_KOKKOS)
   target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS)
   add_dependencies(LAMMPS::KOKKOS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.2.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.2.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

cmake/Modules/YAML.cmake

@@ -0,0 +1,32 @@
+message(STATUS "Downloading and building YAML library")
+
+include(ExternalProject)
+set(YAML_URL "https://pyyaml.org/download/libyaml/yaml-0.2.5.tar.gz" CACHE STRING "URL for libyaml tarball")
+mark_as_advanced(YAML_URL)
+ExternalProject_Add(libyaml
+                    URL               ${YAML_URL}
+                    URL_MD5           bb15429d8fb787e7d3f1c83ae129a999
+                    SOURCE_DIR        "${CMAKE_BINARY_DIR}/yaml-src"
+                    BINARY_DIR        "${CMAKE_BINARY_DIR}/yaml-build"
+                    CONFIGURE_COMMAND <SOURCE_DIR>/configure ${CONFIGURE_REQUEST_PIC}
+                                      CXX=${CMAKE_CXX_COMPILER}
+                                      CC=${CMAKE_C_COMPILER}
+                                      --prefix=<INSTALL_DIR> --disable-shared
+                    BUILD_BYPRODUCTS  <INSTALL_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}yaml.a
+                    TEST_COMMAND      "")
+
+ExternalProject_Get_Property(libyaml INSTALL_DIR)
+set(YAML_INCLUDE_DIR ${INSTALL_DIR}/include)
+set(YAML_LIBRARY_DIR ${INSTALL_DIR}/lib)
+
+# workaround for CMake 3.10 on ubuntu 18.04
+file(MAKE_DIRECTORY ${YAML_INCLUDE_DIR})
+file(MAKE_DIRECTORY ${YAML_LIBRARY_DIR})
+
+set(YAML_LIBRARY_PATH ${INSTALL_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}yaml.a)
+
+add_library(Yaml::Yaml UNKNOWN IMPORTED)
+set_target_properties(Yaml::Yaml PROPERTIES
+        IMPORTED_LOCATION ${YAML_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${YAML_INCLUDE_DIR})
+add_dependencies(Yaml::Yaml libyaml)

doc/github-development-workflow.md

@@ -95,7 +95,7 @@ on the pull request discussion page on GitHub, so that other developers
 can later review the entire discussion after the fact and understand the
 rationale behind choices made.  Exceptions to this policy are technical
 discussions, that are centered on tools or policies themselves
-(git, github, c++) rather than on the content of the pull request.
+(git, GitHub, c++) rather than on the content of the pull request.
 
 ### Checklist for Pull Requests
 

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "29 October 2020" "2020-10-29"
+.TH LAMMPS "30 November 2020" "2020-10-29"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.

doc/src/Build_development.rst

@@ -108,11 +108,18 @@ results over a given number of steps and operations within a given
 error margin).  The status of this automated testing can be viewed on
 `https://ci.lammps.org <https://ci.lammps.org>`_.
 
+The scripts and inputs for integration, run, and regression testing
+are maintained in a
+`separate repository <https://github.com/lammps/lammps-testing>`_
+of the LAMMPS project on GitHub.
+
 The unit testing facility is integrated into the CMake build process
 of the LAMMPS source code distribution itself.  It can be enabled by
 setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
-It requires the `PyYAML <http://pyyaml.org/>`_ library and development
-headers to compile and will download and compile a recent version of the
+It requires the `YAML <http://pyyaml.org/>`_ library and development
+headers (if those are not found locally a recent version will be
+downloaded and compiled along with LAMMPS and the test program) to
+compile and will download and compile a specific recent version of the
 `Googletest <https://github.com/google/googletest/>`_ C++ test framework
 for implementing the tests.
 
@@ -162,22 +169,21 @@ The ``ctest`` command has many options, the most important ones are:
 In its full implementation, the unit test framework will consist of multiple
 kinds of tests implemented in different programming languages (C++, C, Python,
 Fortran) and testing different aspects of the LAMMPS software and its features.
-At the moment only tests for "force styles" are implemented. More on those
-in the next section.
+The tests will adapt to the compilation settings of LAMMPS, so that tests
+will be skipped if prerequisite features are not available in LAMMPS.
 
 .. note::
 
-   The unit test framework is new and still under development.
-   The coverage is only minimal and will be expanded over time.
-   Tests styles of the same kind of style (e.g. pair styles or
-   bond styles) are performed with the same executable using
-   different input files in YAML format.  So to add a test for
-   another pair style can be done by copying the YAML file and
-   editing the style settings and then running the individual test
-   program with a flag to update the computed reference data.
-   Detailed documentation about how to add new test program and
-   the contents of the YAML files for existing test programs
-   will be provided in time as well.
+   The unit test framework was added in spring 2020 and is under active
+   development.  The coverage is not complete and will be expanded over
+   time.
+
+Tests for styles of the same kind of style (e.g. pair styles or bond
+styles) are performed with the same test executable using different
+input files in YAML format.  So to add a test for another style of the
+same kind it may be sufficient to add a suitable YAML file.
+:doc:`Detailed instructions for adding tests <Developer_unittest>` are
+provided in the Programmer Guide part of the manual.
 
 Unit tests for force styles
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^

doc/src/Commands_bond.rst

@@ -35,6 +35,7 @@ OPT.
    * :doc:`class2 (ko) <bond_class2>`
    * :doc:`fene (iko) <bond_fene>`
    * :doc:`fene/expand (o) <bond_fene_expand>`
+   * :doc:`gaussian <bond_gaussian>`
    * :doc:`gromos (o) <bond_gromos>`
    * :doc:`harmonic (iko) <bond_harmonic>`
    * :doc:`harmonic/shift (o) <bond_harmonic_shift>`
@@ -84,6 +85,7 @@ OPT.
    * :doc:`dipole (o) <angle_dipole>`
    * :doc:`fourier (o) <angle_fourier>`
    * :doc:`fourier/simple (o) <angle_fourier_simple>`
+   * :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
    * :doc:`harmonic (iko) <angle_harmonic>`
    * :doc:`mm3 <angle_mm3>`
    * :doc:`quartic (o) <angle_quartic>`

doc/src/Commands_fix.rst

@@ -62,6 +62,7 @@ OPT.
    * :doc:`efield <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electron/stopping <fix_electron_stopping>`
+   * :doc:`electron/stopping/fit <fix_electron_stopping>`
    * :doc:`enforce2d (k) <fix_enforce2d>`
    * :doc:`eos/cv <fix_eos_cv>`
    * :doc:`eos/table <fix_eos_table>`
@@ -195,7 +196,7 @@ OPT.
    * :doc:`saed/vtk <fix_saed_vtk>`
    * :doc:`setforce (k) <fix_setforce>`
    * :doc:`setforce/spin <fix_setforce>`
-   * :doc:`shake <fix_shake>`
+   * :doc:`shake (k) <fix_shake>`
    * :doc:`shardlow (k) <fix_shardlow>`
    * :doc:`smd <fix_smd>`
    * :doc:`smd/adjust_dt <fix_smd_adjust_dt>`

doc/src/Commands_pair.rst

@@ -241,6 +241,7 @@ OPT.
    * :doc:`spin/dipole/long <pair_spin_dipole>`
    * :doc:`spin/dmi <pair_spin_dmi>`
    * :doc:`spin/exchange <pair_spin_exchange>`
+   * :doc:`spin/exchange/biquadratic <pair_spin_exchange>`
    * :doc:`spin/magelec <pair_spin_magelec>`
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`

doc/src/Developer.rst

@@ -13,5 +13,6 @@ of time and requests from the LAMMPS user community.
    Developer_org
    Developer_flow
    Developer_write
+   Developer_unittest
    Classes
    Developer_utils

doc/src/Developer_unittest.rst

@@ -0,0 +1,523 @@
+Adding tests for unit testing
+-----------------------------
+
+This section discusses adding or expanding tests for the unit test
+infrastructure included into the LAMMPS source code distribution.
+Unlike example inputs, unit tests focus on testing the "local" behavior
+of individual features, tend to run very fast, and should be set up to
+cover as much of the added code as possible.  When contributing code to
+the distribution, the LAMMPS developers will appreciate if additions
+to the integrated unit test facility are included.
+
+Given the complex nature of MD simulations where many operations can
+only be performed when suitable "real" simulation environment has been
+set up, not all tests will be unit tests in the strict definition of
+the term.  They are rather executed on a more abstract level by issuing
+LAMMPS script commands and then inspecting the changes to the internal
+data.  For some classes of tests, generic test programs have been
+written that can be applied to parts of LAMMPS that use the same
+interface (via polymorphism) and those are driven by input files, so
+tests can be added by simply adding more of those input files.  Those
+tests should be seen more as a hybrid between unit and regression tests.
+
+When adding tests it is recommended to also :ref:`enable support for
+code coverage reporting <testing>`, and study the coverage reports
+so that it is possible to monitor which parts of the code of a given
+file are executed during the tests and which tests would need to be
+added to increase the coverage.
+
+The tests are grouped into categories and corresponding folders.
+The following sections describe how the tests are implemented and
+executed in those categories with increasing complexity of tests
+and implementation.
+
+
+Tests for utility functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These tests are driven by programs in the ``unittest/utils`` folder
+and most closely resemble conventional unit tests. There is one test
+program for each namespace or group of classes or file. The naming
+convention for the sources and executables is that they start with
+with ``test_``.  The following sources and groups of tests are currently
+available:
+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+   :align: left
+
+   * - File name:
+     - Test name:
+     - Description:
+   * - ``test_fmtlib.cpp``
+     - FmtLib
+     - Tests for ``fmtlib::`` functions used by LAMMPS
+   * - ``test_math_eigen_impl.cpp``
+     - MathEigen
+     - Tests for ``MathEigen::`` classes and functions
+   * - ``test_mempool.cpp``
+     - MemPool
+     - Tests for :cpp:class:`MyPage <LAMMPS_NS::MyPage>` and :cpp:class:`MyPoolChunk <LAMMPS_NS::MyPoolChunk>`
+   * - ``test_tokenizer.cpp``
+     - Tokenizer
+     - Tests for :cpp:class:`Tokenizer <LAMMPS_NS::Tokenizer>` and :cpp:class:`ValueTokenizer <LAMMPS_NS::ValueTokenizer>`
+   * - ``test_utils.cpp``
+     - Utils
+     - Tests for ``utils::`` :doc:`functions <Developer_utils>`
+
+To add tests either an existing source file needs to be modified or a
+new source file needs to be added to the distribution and enabled for
+testing.  To add a new file suitable CMake script code needs to be added
+to the ``CMakeLists.txt`` file in the ``unittest/utils`` folder.  Example:
+
+.. code-block:: cmake
+
+   add_executable(test_tokenizer test_tokenizer.cpp)
+   target_link_libraries(test_tokenizer PRIVATE lammps GTest::GMockMain GTest::GMock GTest::GTest)
+   add_test(Tokenizer test_tokenizer)
+
+This adds instructions to build the ``test_tokenizer`` executable from
+``test_tokenizer.cpp`` and links it with the GoogleTest libraries and the
+LAMMPS library as well as it uses the ``main()`` function from the
+GoogleMock library of GoogleTest.  The third line registers the executable
+as a test program to be run from ``ctest`` under the name ``Tokenizer``.
+
+The test executable itself will execute multiple individual tests
+through the GoogleTest framework. In this case each test consists of
+creating a tokenizer class instance with a given string and explicit or
+default separator choice, and then executing member functions of the
+class and comparing their results with expected values. A few examples:
+
+.. code-block:: c++
+
+   TEST(Tokenizer, empty_string)
+   {
+       Tokenizer t("", " ");
+       ASSERT_EQ(t.count(), 0);
+   }
+
+   TEST(Tokenizer, two_words)
+   {
+       Tokenizer t("test word", " ");
+       ASSERT_EQ(t.count(), 2);
+   }
+
+   TEST(Tokenizer, default_separators)
+   {
+       Tokenizer t(" \r\n test \t word \f");
+       ASSERT_THAT(t.next(), Eq("test"));
+       ASSERT_THAT(t.next(), Eq("word"));
+       ASSERT_EQ(t.count(), 2);
+   }
+
+Each of these TEST functions will become an individual
+test run by the test program. When using the ``ctest``
+command as a front end to run the tests, their output
+will be suppressed and only a summary printed, but adding
+the '-V' option will then produce output from the tests
+above like the following:
+
+.. code-block::
+
+   [...]
+   1: [ RUN      ] Tokenizer.empty_string
+   1: [       OK ] Tokenizer.empty_string (0 ms)
+   1: [ RUN      ] Tokenizer.two_words
+   1: [       OK ] Tokenizer.two_words (0 ms)
+   1: [ RUN      ] Tokenizer.default_separators
+   1: [       OK ] Tokenizer.default_separators (0 ms)
+   [...]
+
+The MathEigen test collection has been adapted from a standalone test
+and does not use the GoogleTest framework and thus not representative.
+The other test sources, however, can serve as guiding examples for
+additional tests.
+
+Tests for individual LAMMPS commands
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The tests ``unittest/commands`` are a bit more complex as they require
+to first create a :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class instance
+and then use the :doc:`C++ API <Cplusplus>` to pass individual commands
+to that LAMMPS instance.  For that reason these tests use a GoogleTest
+"test fixture", i.e. a class derived from ``testing::Test`` that will
+create (and delete) the required LAMMPS class instance for each set of
+tests in a ``TEST_F()`` function.  Please see the individual source files
+for different examples of setting up suitable test fixtures.  Here is an
+example for implementing a test using a fixture by first checking the
+default value and then issuing LAMMPS commands and checking whether they
+have the desired effect:
+
+.. code-block:: c++
+
+   TEST_F(SimpleCommandsTest, ResetTimestep)
+   {
+       ASSERT_EQ(lmp->update->ntimestep, 0);
+
+       if (!verbose) ::testing::internal::CaptureStdout();
+       lmp->input->one("reset_timestep 10");
+       if (!verbose) ::testing::internal::GetCapturedStdout();
+       ASSERT_EQ(lmp->update->ntimestep, 10);
+
+       if (!verbose) ::testing::internal::CaptureStdout();
+       lmp->input->one("reset_timestep 0");
+       if (!verbose) ::testing::internal::GetCapturedStdout();
+       ASSERT_EQ(lmp->update->ntimestep, 0);
+   }
+
+Please note the use of the (global) verbose variable to control whether
+the LAMMPS command will be silent by capturing the output or not.  In
+the default case, verbose == false, the test output will be compact and
+not mixed with LAMMPS output. However setting the verbose flag (via
+setting the ``TEST_ARGS`` environment variable, ``TEST_ARGS=-v``) can be
+helpful to understand why tests fail unexpectedly.
+
+Another complexity of these tests stems from the need to capture
+situations where LAMMPS will stop with an error, i.e. handle so-called
+"death tests".  Here the LAMMPS code will operate differently depending
+on whether it was configured to throw C++ exceptions on errors or call
+either ``exit()`` or ``MPI_Abort()``.  In the latter case, the test code
+also needs to detect whether LAMMPS was compiled with the OpenMPI
+library, as OpenMPI is **only** compatible the death test options of the
+GoogleTest library when C++ exceptions are enabled; otherwise those
+"death tests" must be skipped to avoid reporting bogus failures.  The
+specifics of this step are implemented in the ``TEST_FAILURE()``
+macro. These tests operate by capturing the screen output when executing
+the failing command and then comparing that with a provided regular
+expression string pattern.  Example:
+
+.. code-block:: C++
+
+   TEST_F(SimpleCommandsTest, UnknownCommand)
+   {
+       TEST_FAILURE(".*ERROR: Unknown command.*", lmp->input->one("XXX one two"););
+   }
+
+The following test programs are currently available:
+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+   :align: left
+
+   * - File name:
+     - Test name:
+     - Description:
+   * - ``test_simple_commands.cpp``
+     - SimpleCommands
+     - Tests for LAMMPS commands that do not require a box
+   * - ``test_lattice_region.cpp``
+     - LatticeRegion
+     - Tests to validate the :doc:`lattice <lattice>` and :doc:`region <region>` commands
+   * - ``test_kim_commands.cpp``
+     - KimCommands
+     - Tests for several commands from the :ref:`KIM package <PKG-KIM>`
+   * - ``test_reset_ids.cpp``
+     - ResetIDs
+     - Tests to validate the :doc:`reset_atom_ids <reset_atom_ids>` and :doc:`reset_mol_ids <reset_mol_ids>` commands
+
+
+Tests for the C-style library interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Tests for validating the LAMMPS C-style library interface are in the
+``unittest/c-library`` folder.  They are implemented in either way used
+for utility functions and for LAMMPS commands, but use the functions
+implemented in the ``src/library.cpp`` file as much as possible.  There
+may be some overlap with other tests, but only in as much as is required
+to test the C-style library API.  The tests are distributed over
+multiple test programs which tries to match the grouping of the
+functions in the source code and :ref:`in the manual <lammps_c_api>`.
+
+This group of tests also includes tests invoking LAMMPS in parallel
+through the library interface, provided that LAMMPS was compiled with
+MPI support.  These include tests where LAMMPS is run in multi-partition
+mode or only on a subset of the MPI world communicator.  The CMake
+script code for adding this kind of test looks like this:
+
+.. code-block:: CMake
+
+   if (BUILD_MPI)
+     add_executable(test_library_mpi test_library_mpi.cpp)
+     target_link_libraries(test_library_mpi PRIVATE lammps GTest::GTest GTest::GMock)
+     target_compile_definitions(test_library_mpi PRIVATE ${TEST_CONFIG_DEFS})
+     add_mpi_test(NAME LibraryMPI NUM_PROCS 4 COMMAND $<TARGET_FILE:test_library_mpi>)
+   endif()
+
+Note the custom function ``add_mpi_test()`` which adapts how ``ctest``
+will execute the test so it is launched in parallel (with 4 MPI ranks).
+
+Tests for the Python module and package
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``unittest/python`` folder contains primarily tests for classes and
+functions in the LAMMPS python module but also for commands in the
+PYTHON package.  These tests are only enabled, if the necessary
+prerequisites are detected or enabled during configuration and
+compilation of LAMMPS (shared library build enabled, Python interpreter
+found, Python development files found).
+
+The Python tests are implemented using the ``unittest`` standard Python
+module and split into multiple files with similar categories as the
+tests for the C-style library interface.
+
+Tests for the Fortran interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Tests for using the Fortran module are in the ``unittest/fortran``
+folder.  Since they are also using the GoogleTest library, they require
+to also implement test wrappers in C++ that will call fortran functions
+which provide a C function interface through ISO_C_BINDINGS that will in
+turn call the functions in the LAMMPS Fortran module.  This part of the
+unit tests is incomplete since the Fortran module it is based on is
+incomplete as well.
+
+Tests for the C++-style library interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The tests in the ``unittest/cplusplus`` folder are somewhat similar to
+the tests for the C-style library interface, but do not need to test the
+several convenience and utility functions that are only available through
+the C-style interface.  Instead it can focus on the more generic features
+that are used internally.  This part of the unit tests is currently still
+mostly in the planning stage.
+
+Tests for reading and writing file formats
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``unittest/formats`` folder contains test programs for reading and
+writing files like data files, restart files, potential files or dump files.
+This covers simple things like the file i/o convenience functions in the
+``utils::`` namespace to complex tests of atom styles where creating and
+deleting of atoms with different properties is tested in different ways
+and through script commands or reading and writing of data or restart files.
+
+Tests for styles computing or modifying forces
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These are tests common configurations for pair styles, bond styles,
+angle styles, kspace styles and certain fix styles.  Those are tests
+driven by some test executables build from sources in the
+``unittest/force-styles`` folder and use LAMMPS input template and data
+files as well as input files in YAML format from the
+``unittest/force-styles/tests`` folder. The YAML file names have to
+follow some naming conventions so they get associated with the test
+programs and categorized and listed with canonical names in the list
+of tests as displayed by ``ctest -N``.  If you add a new YAML file,
+you need to re-run CMake to update the corresponding list of tests.
+
+A minimal YAML file for a (molecular) pair style test will looks
+something like the following (see ``mol-pair-zero.yaml``):
+
+.. code-block:: yaml
+
+   ---
+   lammps_version: 24 Aug 2020
+   date_generated: Tue Sep 15 09:44:21 202
+   epsilon: 1e-14
+   prerequisites: ! |
+     atom full
+     pair zero
+   pre_commands: ! ""
+   post_commands: ! ""
+   input_file: in.fourmol
+   pair_style: zero 8.0
+   pair_coeff: ! |
+     * *
+   extract: ! ""
+   natoms: 29
+   init_vdwl: 0
+   init_coul: 0
+
+   [...]
+
+The following table describes the available keys and their purpose for
+testing pair styles:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Key:
+     - Description:
+   * - lammps_version
+     - LAMMPS version used to last update the reference data
+   * - date_generated
+     - date when the file was last updated
+   * - epsilon
+     - base value for the relative precision required for tests to pass
+   * - prerequisites
+     - list of style kind / style name pairs required to run the test
+   * - pre_commands
+     - LAMMPS commands to be executed before the input template file is read
+   * - post_commands
+     - LAMMPS commands to be executed right before the actual tests
+   * - input_file
+     - LAMMPS input file template based on pair style zero
+   * - pair_style
+     - arguments to the pair_style command to be tested
+   * - pair_coeff
+     - list of pair_coeff arguments to set parameters for the input template
+   * - extract
+     - list of keywords supported by ``Pair::extract()`` and their dimension
+   * - natoms
+     - number of atoms in the input file template
+   * - init_vdwl
+     - non-Coulomb pair energy after "run 0"
+   * - init_coul
+     - Coulomb pair energy after "run 0"
+   * - init_stress
+     - stress tensor after "run 0"
+   * - init_forces
+     - forces on atoms after "run 0"
+   * - run_vdwl
+     - non-Coulomb pair energy after "run 4"
+   * - run_coul
+     - Coulomb pair energy after "run 4"
+   * - run_stress
+     - stress tensor after "run 4"
+   * - run_forces
+     - forces on atoms after "run 4"
+
+The test program will read all this data from the YAML file and then
+create a LAMMPS instance, apply the settings/commands from the YAML file
+as needed and then issue a "run 0" command, write out a restart file, a
+data file and a coeff file. The actual test will then compare computed
+energies, stresses, and forces with the reference data, issue a "run 4"
+command and compare to the second set of reference data.  This will be
+run with both the newton_pair setting enabled and disabled and is
+expected to generate the same results (allowing for some numerical
+noise). Then it will restart from the previously generated restart and
+compare with the reference and also start from the data file.  A final
+check will use multi-cutoff r-RESPA (if supported by the pair style) at
+a 1:1 split and compare to the Verlet results.  These sets of tests are
+run with multiple test fixtures for accelerated styles (OPT, USER-OMP,
+USER-INTEL) and for the latter two with 4 OpenMP threads enabled.  For
+these tests the relative error (epsilon) is lowered by a common factor
+due to the additional numerical noise, but the tests are still comparing
+to the same reference data.
+
+Additional tests will check whether all listed extract keywords are
+supported and have the correct dimensionality and the final set of tests
+will set up a few pairs of atoms explicitly and in such a fashion that
+the forces on the atoms computed from ``Pair::compute()`` will match
+individually with the results from ``Pair::single()``, if the pair style
+does support that functionality.
+
+With this scheme a large fraction of the code of any tested pair style
+will be executed and consistent results are required for different
+settings and between different accelerated pair style variants and the
+base class, as well as for computing individual pairs through the
+``Pair::single()`` where supported.
+
+The ``test_pair_style`` tester is used with 4 categories of test inputs:
+
+- pair styles compatible with molecular systems using bonded
+  interactions and exclusions.  For pair styles requiring a KSpace style
+  the KSpace computations are disabled.  The YAML files match the
+  pattern "mol-pair-\*.yaml" and the tests are correspondingly labeled
+  with "MolPairStyle:\*"
+- pair styles not compatible with the previous input template.
+  The YAML files match the pattern "atomic-pair-\*.yaml" and the tests are
+  correspondingly labeled with "AtomicPairStyle:\*"
+- manybody pair styles.
+  The YAML files match the pattern "atomic-pair-\*.yaml" and the tests are
+  correspondingly labeled with "AtomicPairStyle:\*"
+- kspace styles.
+  The YAML files match the pattern "kspace-\*.yaml" and the tests are
+  correspondingly labeled with "KSpaceStyle:\*". In these cases a compatible
+  pair style is defined, but the computation of the pair style contributions
+  is disabled.
+
+The ``test_bond_style`` and ``test_angle_style`` are set up in a similar
+fashion and share support functions with the pair style tester.  The final
+group of tests in this section is for fix styles that add/manipulate forces
+and velocities, e.g. for time integration, thermostats and more.
+
+Adding a new test is easiest done by copying and modifying an existing test
+for a style that is similar to one to be tested.  The file name should follow
+the naming conventions described above and after copying the file, the first
+step is to replace the style names where needed.  The coefficient values
+do not have to be meaningful, just in a reasonable range for the given system.
+It does not matter if some forces are large, for as long as they do not diverge.
+
+The template input files define a large number of index variables at the top
+that can be modified inside the YAML file to control the behavior.  For example,
+if a pair style requires a "newton on" setting, the following can be used in
+as the "pre_commands" section:
+
+.. code-block:: yaml
+
+   pre_commands: ! |
+     variable newton_pair delete
+     variable newton_pair index on
+
+And for a pair style requiring a kspace solver the following would be used as
+the "post_commands" section:
+
+.. code-block:: yaml
+
+   post_commands: ! |
+     pair_modify table 0
+     kspace_style pppm/tip4p 1.0e-6
+     kspace_modify gewald 0.3
+     kspace_modify compute no
+
+Note that this disables computing the kspace contribution, but still will run
+the setup.  The "gewald" parameter should be set explicitly to speed up the run.
+For styles with long-range electrostatics, typically two tests are added one using
+the (slower) analytic approximation of the erfc() function and the other using
+the tabulated coulomb, to test both code paths. The reference results in the YAML
+files then should be compared manually, if they agree well enough within the limits
+of those two approximations.
+
+The ``test_pair_style`` and equivalent programs have special command line options
+to update the YAML files. Running a command like
+
+.. code-block:: bash
+
+   $ test_pair_style mol-pair-lennard_mdf.yaml -g new.yaml
+
+will read the settings from the ``mol-pair-lennard_mdf.yaml`` file and then compute
+the reference data and write a new file with to ``new.yaml``.  If this step fails,
+there are likely some (LAMMPS or YAML) syntax issues in the YAML file that need to
+be resolved and then one can compare the two files to see if the output is as expected.
+
+It is also possible to do an update in place with:
+
+.. code-block:: bash
+
+   $ test_pair_style mol-pair-lennard_mdf.yaml -u
+
+And one can finally run the full set of tests with:
+
+.. code-block:: bash
+
+   $ test_pair_style mol-pair-lennard_mdf.yaml
+
+This will just print a summary of the groups of tests.  When using the "-v" flag
+the test will also keep any LAMMPS output and when using the "-s" flag, there
+will be some statistics reported on the relative errors for the individual checks
+which can help to figure out what would be a good choice of the epsilon parameter.
+It should be as small as possible to catch any unintended side effects from changes
+elsewhere, but large enough to accommodate the numerical noise due to the implementation
+of the potentials and differences in compilers.
+
+.. note::
+
+   These kinds of tests can be very sensitive to compiler optimization and
+   thus the expectation is that they pass with compiler optimization turned
+   off. When compiler optimization is enabled, there may be some failures, but
+   one has to carefully check whether those are acceptable due to the enhanced
+   numerical noise from reordering floating-point math operations or due to
+   the compiler mis-compiling the code. That is not always obvious.
+
+
+Tests for programs in the tools folder
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``unittest/tools`` folder contains tests for programs in the
+``tools`` folder.  This currently only contains tests for the LAMMPS
+shell, which are implemented as a python scripts using the ``unittest``
+Python module and launching the tool commands through the ``subprocess``
+Python module.

doc/src/Errors_warnings.rst

@@ -119,7 +119,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    :doc:`pair style zero <pair_zero>` with a suitable cutoff or use :doc:`comm_modify cutoff <comm_modify>`.
 
 *Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
-
    Since LAMMPS stores topology data with individual atoms, all atoms
    comprising a bond, angle, dihedral or improper must be present on any
    sub-domain that "owns" the atom with the information, either as a

doc/src/Howto_drude2.rst

@@ -36,7 +36,7 @@ polarizability :math:`\alpha` by
 
 Ideally, the mass of the Drude particle should be small, and the
 stiffness of the harmonic bond should be large, so that the Drude
-particle remains close ot the core. The values of Drude mass, Drude
+particle remains close to the core. The values of Drude mass, Drude
 charge, and force constant can be chosen following different
 strategies, as in the following examples of polarizable force
 fields:

doc/src/Howto_github.rst

@@ -72,7 +72,7 @@ explained in more detail here: `feature branch workflow <https://www.atlassian.c
 
 **Feature branches**
 
-First of all, create a clone of your version on github on your local
+First of all, create a clone of your version on GitHub on your local
 machine via HTTPS:
 
 .. code-block:: bash
@@ -155,7 +155,7 @@ useful message that explains the change.
 
 .. code-block:: bash
 
-     $ git commit -m 'Finally updated the github tutorial'
+     $ git commit -m 'Finally updated the GitHub tutorial'
 
 After the commit, the changes can be pushed to the same branch on GitHub:
 

doc/src/Howto_walls.rst

@@ -67,5 +67,5 @@ rotate.
 
 The only frictional idealized walls currently in LAMMPS are flat or
 curved surfaces specified by the :doc:`fix wall/gran <fix_wall_gran>`
-command.  At some point we plan to allow regoin surfaces to be used as
+command.  At some point we plan to allow region surfaces to be used as
 frictional walls, as well as triangulated surfaces.

doc/src/Intro_citing.rst

@@ -24,13 +24,15 @@ DOI for the LAMMPS code
 LAMMPS developers use the `Zenodo service at CERN
 <https://zenodo.org/>`_ to create digital object identifies (DOI) for
 stable releases of the LAMMPS code. There are two types of DOIs for the
-LAMMPS source code: 1) the canonical DOI for **all** versions of LAMMPS,
-which will always point to the latest stable release version is:
+LAMMPS source code: the canonical DOI for **all** versions of LAMMPS,
+which will always point to the **latest** stable release version is:
 
-  `DOI: 10.5281/zenodo.3726416 <https://dx.doi/org/10.5281/zenodo.3726416>`_
+- DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
 
-In addition there are DOIs for individual stable releases starting with
-the `3 March 2020 version, DOI:10.5281/zenodo.3726417 <https://dx.doi/org/10.5281/zenodo.3726416>`_
+In addition there are DOIs for individual stable releases. Currently there are:
+
+- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
+- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
 
 
 Home page

doc/src/Packages_details.rst

@@ -1036,9 +1036,11 @@ the usual manner via MD.  Various pair, fix, and compute styles.
 * :doc:`pair_style spin/dipole/long <pair_spin_dipole>`
 * :doc:`pair_style spin/dmi <pair_spin_dmi>`
 * :doc:`pair_style spin/exchange <pair_spin_exchange>`
+* :doc:`pair_style spin/exchange/biquadratic <pair_spin_exchange>`
 * :doc:`pair_style spin/magelec <pair_spin_magelec>`
 * :doc:`pair_style spin/neel <pair_spin_neel>`
 * :doc:`fix nve/spin <fix_nve_spin>`
+* :doc:`fix langevin/spin <fix_langevin_spin>`
 * :doc:`fix precession/spin <fix_precession_spin>`
 * :doc:`compute spin <compute_spin>`
 * :doc:`neb/spin <neb_spin>`

doc/src/Run_options.rst

@@ -62,15 +62,18 @@ used.
 
 **-in file**
 
-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
-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.
+Specify a file to use as an input script.  This is an optional but
+recommended 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.
+With many MPI implementations I/O redirection also works in parallel,
+but using the -in flag will always work.
+
 Note that this is a required switch when running LAMMPS in
 multi-partition mode, since multiple processors cannot all read from
-stdin.
+stdin concurrently.  The file name may be "none" for starting
+multi-partition calculations without reading an initial input file
+from the library interface.
 
 ----------
 
@@ -296,7 +299,7 @@ command-line option.
 **-pscreen file**
 
 Specify the base name for the partition screen file, so partition N
-writes screen information to file.N. If file is none, then no
+writes screen information to file.N. If file is "none", then no
 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

doc/src/angle_gaussian.rst

@@ -0,0 +1,69 @@
+.. index:: angle_style gaussian
+
+angle_style gaussian command
+================================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style gaussian
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style gaussian
+   angle_coeff 1 300.0 2 0.0128 0.375 80.0 0.0730 0.148 123.0
+
+Description
+"""""""""""
+
+The *gaussian* angle style uses the potential:
+
+.. math::
+
+   E = -k_B T ln\left(\sum_{i=1}^{n} \frac{A_i}{w_i \sqrt{\pi/2}} exp\left( \frac{-(\theta-\theta_{i})^2}{w_i^2})\right) \right)
+
+This analytical form is a suitable potential for obtaining
+mesoscale effective force fields which can reproduce target atomistic distributions :ref:`(Milano) <Milano1>`
+The following coefficients must be defined for each angle type via the
+:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands:
+
+* T temperature at which the potential was derived
+* :math:`n` (integer >=1)
+* :math:`A_1` (-)
+* :math:`w_1` (-)
+* :math:`\theta_1` (degrees)
+* ...
+* :math:`A_n` (-)
+* :math:`w_n` (-)
+* :math:`\theta_n` (degrees)
+
+
+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
+page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Milano1:
+
+**(Milano)** G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005).

doc/src/angle_style.rst

@@ -87,6 +87,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
 * :doc:`fourier <angle_fourier>` - angle with multiple cosine terms
 * :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term
+* :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
 * :doc:`harmonic <angle_harmonic>` - harmonic angle
 * :doc:`mm3 <angle_mm3>` - anharmonic angle
 * :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms

doc/src/atc_output.rst

@@ -14,7 +14,7 @@ Syntax
 * AtC fixID = ID of :doc:`fix atc <fix_atc>` instance
 * *output* or *output index* = name of the AtC sub-command
 * filename_prefix = prefix for data files (for *output*)
-* frequency = frequency of output in time-steps (for *output*)
+* frequency = frequency of output in timesteps (for *output*)
 * optional keywords for *output*:
 
   - text = creates text output of index, step and nodal variable values for unique nodes

doc/src/balance.rst

@@ -78,14 +78,16 @@ or particles and thus indirectly the computational cost (load) more
 evenly across processors.  The load balancing is "static" in the sense
 that this command performs the balancing once, before or between
 simulations.  The processor sub-domains will then remain static during
-the subsequent run.  To perform "dynamic" balancing, see the :doc:`fix balance <fix_balance>` command, which can adjust processor
-sub-domain sizes and shapes on-the-fly during a :doc:`run <run>`.
+the subsequent run.  To perform "dynamic" balancing, see the :doc:`fix
+balance <fix_balance>` command, which can adjust processor sub-domain
+sizes and shapes on-the-fly during a :doc:`run <run>`.
 
 Load-balancing is typically most useful if the particles in the
 simulation box have a spatially-varying density distribution or when
 the computational cost varies significantly between different
 particles.  E.g. a model of a vapor/liquid interface, or a solid with
-an irregular-shaped geometry containing void regions, or :doc:`hybrid pair style simulations <pair_hybrid>` which combine pair styles with
+an irregular-shaped geometry containing void regions, or :doc:`hybrid
+pair style simulations <pair_hybrid>` which combine pair styles with
 different computational cost.  In these cases, the LAMMPS default of
 dividing the simulation box volume into a regular-spaced grid of 3d
 bricks, with one equal-volume sub-domain per processor, may assign
@@ -101,13 +103,14 @@ which typically induces a different number of atoms assigned to each
 processor.  Details on the various weighting options and examples for
 how they can be used are :ref:`given below <weighted_balance>`.
 
-Note that the :doc:`processors <processors>` command allows some control
-over how the box volume is split across processors.  Specifically, for
-a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
-Pz, subject to the constraint that Px \* Py \* Pz = P, the total number
-of processors.  This is sufficient to achieve good load-balance for
-some problems on some processor counts.  However, all the processor
-sub-domains will still have the same shape and same volume.
+Note that the :doc:`processors <processors>` command allows some
+control over how the box volume is split across processors.
+Specifically, for a Px by Py by Pz grid of processors, it allows
+choice of Px, Py, and Pz, subject to the constraint that Px \* Py \*
+Pz = P, the total number of processors.  This is sufficient to achieve
+good load-balance for some problems on some processor counts.
+However, all the processor sub-domains will still have the same shape
+and same volume.
 
 The requested load-balancing operation is only performed if the
 current "imbalance factor" in particles owned by each processor
@@ -170,12 +173,12 @@ The method used to perform a load balance is specified by one of the
 listed styles (or more in the case of *x*\ ,\ *y*\ ,\ *z*\ ), which are
 described in detail below.  There are 2 kinds of styles.
 
-The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which produce
-a logical 3d grid of processors.  They operate by changing the cutting
-planes (or lines) between processors in 3d (or 2d), to adjust the
-volume (area in 2d) assigned to each processor, as in the following 2d
-diagram where processor sub-domains are shown and particles are
-colored by the processor that owns them.
+The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which
+produce a logical 3d grid of processors.  They operate by changing the
+cutting planes (or lines) between processors in 3d (or 2d), to adjust
+the volume (area in 2d) assigned to each processor, as in the
+following 2d diagram where processor sub-domains are shown and
+particles are colored by the processor that owns them.
 
 .. |balance1| image:: img/balance_uniform.jpg
    :width: 32%
@@ -190,20 +193,20 @@ colored by the processor that owns them.
 
 The leftmost diagram is the default partitioning of the simulation box
 across processors (one sub-box for each of 16 processors); the middle
-diagram is after a "grid" method has been applied.  The *rcb* style is a
-"tiling" method which does not produce a logical 3d grid of processors.
-Rather it tiles the simulation domain with rectangular sub-boxes of
-varying size and shape in an irregular fashion so as to have equal
-numbers of particles (or weight) in each sub-box, as in the rightmost
-diagram above.
+diagram is after a "grid" method has been applied.  The *rcb* style is
+a "tiling" method which does not produce a logical 3d grid of
+processors.  Rather it tiles the simulation domain with rectangular
+sub-boxes of varying size and shape in an irregular fashion so as to
+have equal numbers of particles (or weight) in each sub-box, as in the
+rightmost diagram above.
 
-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
-brick" can afterwords be specified for subsequent :doc:`run <run>`
-commands.
+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 brick" can
+afterwords be specified for subsequent :doc:`run <run>` commands.
 
 When a "grid" method is specified, the current domain partitioning can
 be either a logical 3d grid or a tiled partitioning.  In the former
@@ -280,6 +283,14 @@ information, so that they become closer together over time.  Thus as
 the recursion progresses, the count of particles on either side of the
 plane gets closer to the target value.
 
+After the balanced plane positions are determined, if any pair of
+adjacent planes are closer together than the neighbor skin distance
+(as specified by the :doc`neigh_modify <neigh_modify>` command), then
+the plane positions are shifted to separate them by at least this
+amount.  This is to prevent particles being lost when dynamics are run
+with processor subdomains that are too narrow in one or more
+dimensions.
+
 Once the re-balancing is complete and final processor sub-domains
 assigned, particles are migrated to their new owning processor, and
 the balance procedure ends.
@@ -293,7 +304,7 @@ the balance procedure ends.
    *Niter* is specified as 10, the cutting plane will typically be
    positioned to 1 part in 1000 accuracy (relative to the perfect target
    position).  For *Niter* = 20, it will be accurate to 1 part in a
-   million.  Thus there is no need ot set *Niter* to a large value.
+   million.  Thus there is no need to set *Niter* to a large value.
    LAMMPS will check if the threshold accuracy is reached (in a
    dimension) is less iterations than *Niter* and exit early.  However,
    *Niter* should also not be set too small, since it will take roughly
@@ -416,7 +427,8 @@ The *time* weight style uses :doc:`timer data <timer>` to estimate
 weights.  It assigns the same weight to each particle owned by a
 processor based on the total computational time spent by that
 processor.  See details below on what time window is used.  It uses
-the same timing information as is used for the :doc:`MPI task timing breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ ,
+the same timing information as is used for the :doc:`MPI task timing
+breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ ,
 *Kspace*\ , and *Neigh*\ .  The time spent in those portions of the
 timestep are measured for each MPI rank, summed, then divided by the
 number of particles owned by that processor.  I.e. the weight is an

doc/src/bond_gaussian.rst

@@ -0,0 +1,70 @@
+.. index:: bond_style gaussian
+
+bond_style gaussian command
+================================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   bond_style gaussian
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   bond_style gaussian
+   bond_coeff 1 300.0 2 0.0128 0.375 3.37 0.0730 0.148 3.63
+
+Description
+"""""""""""
+
+The *gaussian* bond style uses the potential:
+
+.. math::
+
+   E = -k_B T ln\left(\sum_{i=1}^{n} \frac{A_i}{w_i \sqrt{\pi/2}} exp\left( \frac{-(r-r_{i})^2}{w_i^2})\right) \right)
+
+This analytical form is a suitable potential for obtaining
+mesoscale effective force fields which can reproduce target atomistic distributions :ref:`(Milano) <Milano0>`
+
+The following coefficients must be defined for each bond type via the
+:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands:
+
+* T temperature at which the potential was derived
+* :math:`n` (integer >=1)
+* :math:`A_1` (-)
+* :math:`w_1` (-)
+* :math:`r_1` (length)
+* ...
+* :math:`A_n` (-)
+* :math:`w_n` (-)
+* :math:`r_n` (length)
+
+
+Restrictions
+""""""""""""
+
+This bond style can only be used if LAMMPS was built with the
+USER-MISC package.  See the :doc:`Build package <Build_package>` doc
+page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`bond_coeff <bond_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Milano0:
+
+**(Milano)** G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005).

doc/src/bond_style.rst

@@ -87,6 +87,7 @@ accelerated styles exist.
 * :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
 * :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
 * :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
+* :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
 * :doc:`gromos <bond_gromos>` - GROMOS force field bond
 * :doc:`harmonic <bond_harmonic>` - harmonic bond
 * :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond

doc/src/change_box.rst

@@ -301,9 +301,13 @@ command.
 
 .. note::
 
-   Changing a periodic boundary to a non-periodic one will also
-   cause the image flag for that dimension to be reset to 0 for
-   all atoms.  LAMMPS will print a warning message, if that happens.
+   Changing a periodic boundary to a non-periodic one will also cause
+   the image flag for that dimension of all atoms to be reset to 0.
+   LAMMPS will print a warning message, if that happens.
+   Please note that this reset can lead to undesired changes when
+   atoms are involved in bonded interactions that straddle periodic
+   boundaries and thus the values of the image flag differs for those
+   atoms.
 
 ----------
 

doc/src/compute_reduce_chunk.rst

@@ -38,7 +38,7 @@ Description
 Define a calculation that reduces one or more per-atom vectors into
 per-chunk values.  This can be useful for diagnostic output.  Or when
 used in conjunction with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can be
-used ot create per-atom values that induce a new set of chunks with a
+used to create per-atom values that induce a new set of chunks with a
 second :doc:`compute chunk/atom <compute_chunk_atom>` command.  An
 example is given below.
 

doc/src/compute_stress_atom.rst

@@ -33,32 +33,31 @@ Examples
 Description
 """""""""""
 
-Define a computation that computes per-atom stress
-tensor for each atom in a group.  In case of compute *stress/atom*,
-the tensor for each atom is symmetric with 6
-components and is stored as a 6-element vector in the following order:
-:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`.
-In case of compute *centroid/stress/atom*,
-the tensor for each atom is asymmetric with 9 components
-and is stored as a 9-element vector in the following order:
-:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`,
-:math:`yx`, :math:`zx`, :math:`zy`.
-See the :doc:`compute pressure <compute_pressure>` command if you want the stress tensor
+Define a computation that computes per-atom stress tensor for each
+atom in a group.  In case of compute *stress/atom*, the tensor for
+each atom is symmetric with 6 components and is stored as a 6-element
+vector in the following order: :math:`xx`, :math:`yy`, :math:`zz`,
+:math:`xy`, :math:`xz`, :math:`yz`.  In case of compute
+*centroid/stress/atom*, the tensor for each atom is asymmetric with 9
+components and is stored as a 9-element vector in the following order:
+:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`,
+:math:`yz`, :math:`yx`, :math:`zx`, :math:`zy`.  See the :doc:`compute
+pressure <compute_pressure>` command if you want the stress tensor
 (pressure) of the entire system.
 
-The stress tensor for atom :math:`I` is given by the following formula,
-where :math:`a` and :math:`b` take on values :math:`x`, :math:`y`, :math:`z`
-to generate the components of the tensor:
+The stress tensor for atom :math:`I` is given by the following
+formula, where :math:`a` and :math:`b` take on values :math:`x`,
+:math:`y`, :math:`z` to generate the components of the tensor:
 
 .. math::
 
    S_{ab}  =  - m v_a v_b - W_{ab}
 
-The first term is a kinetic energy contribution for atom :math:`I`.  See
-details below on how the specified *temp-ID* can affect the velocities
-used in this calculation. The second term is the virial
-contribution due to intra and intermolecular interactions,
-where the exact computation details are determined by the compute style.
+The first term is a kinetic energy contribution for atom :math:`I`.
+See details below on how the specified *temp-ID* can affect the
+velocities used in this calculation. The second term is the virial
+contribution due to intra and intermolecular interactions, where the
+exact computation details are determined by the compute style.
 
 In case of compute *stress/atom*, the virial contribution is:
 
@@ -68,29 +67,26 @@ In case of compute *stress/atom*, the virial contribution is:
   & + \frac{1}{3} \sum_{n = 1}^{N_a} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b}) + \frac{1}{4} \sum_{n = 1}^{N_d} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) \\
   & + \frac{1}{4} \sum_{n = 1}^{N_i} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
 
-The first term is a pairwise energy
-contribution where :math:`n` loops over the :math:`N_p`
-neighbors of atom :math:`I`, :math:`\mathbf{r}_1` and :math:`\mathbf{r}_2`
-are the positions of the 2 atoms in the pairwise interaction,
-and :math:`\mathbf{F}_1` and :math:`\mathbf{F}_2` are the forces
-on the 2 atoms resulting from the pairwise interaction.
-The second term is a bond contribution of
-similar form for the :math:`N_b` bonds which atom :math:`I` is part of.
-There are similar terms for the :math:`N_a` angle, :math:`N_d` dihedral,
-and :math:`N_i` improper interactions atom :math:`I` is part of.
-There is also a term for the KSpace
-contribution from long-range Coulombic interactions, if defined.
-Finally, there is a term for the :math:`N_f` :doc:`fixes <fix>` that apply
-internal constraint forces to atom :math:`I`. Currently, only the
-:doc:`fix shake <fix_shake>` and :doc:`fix rigid <fix_rigid>` commands
-contribute to this term.
-As the coefficients in the formula imply, a virial contribution
-produced by a small set of atoms (e.g. 4 atoms in a dihedral or 3
-atoms in a Tersoff 3-body interaction) is assigned in equal portions
-to each atom in the set.  E.g. 1/4 of the dihedral virial to each of
-the 4 atoms, or 1/3 of the fix virial due to SHAKE constraints applied
-to atoms in a water molecule via the :doc:`fix shake <fix_shake>`
-command.
+The first term is a pairwise energy contribution where :math:`n` loops
+over the :math:`N_p` neighbors of atom :math:`I`, :math:`\mathbf{r}_1`
+and :math:`\mathbf{r}_2` are the positions of the 2 atoms in the
+pairwise interaction, and :math:`\mathbf{F}_1` and
+:math:`\mathbf{F}_2` are the forces on the 2 atoms resulting from the
+pairwise interaction.  The second term is a bond contribution of
+similar form for the :math:`N_b` bonds which atom :math:`I` is part
+of.  There are similar terms for the :math:`N_a` angle, :math:`N_d`
+dihedral, and :math:`N_i` improper interactions atom :math:`I` is part
+of.  There is also a term for the KSpace contribution from long-range
+Coulombic interactions, if defined.  Finally, there is a term for the
+:math:`N_f` :doc:`fixes <fix>` that apply internal constraint forces
+to atom :math:`I`. Currently, only the :doc:`fix shake <fix_shake>`
+and :doc:`fix rigid <fix_rigid>` commands contribute to this term.  As
+the coefficients in the formula imply, a virial contribution produced
+by a small set of atoms (e.g. 4 atoms in a dihedral or 3 atoms in a
+Tersoff 3-body interaction) is assigned in equal portions to each atom
+in the set.  E.g. 1/4 of the dihedral virial to each of the 4 atoms,
+or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
+a water molecule via the :doc:`fix shake <fix_shake>` command.
 
 In case of compute *centroid/stress/atom*, the virial contribution is:
 
@@ -99,71 +95,69 @@ In case of compute *centroid/stress/atom*, the virial contribution is:
    W_{ab} & = \sum_{n = 1}^{N_p} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_b} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_a} r_{I0_a}  F_{I_b} + \sum_{n = 1}^{N_d} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_i} r_{I0_a} F_{I_b} \\
   & + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
 
-As with compute *stress/atom*, the first, second, third, fourth and fifth terms
-are pairwise, bond, angle, dihedral and improper contributions,
-but instead of assigning the virial contribution equally to each atom,
-only the force :math:`\mathbf{F}_I` acting on atom :math:`I`
-due to the interaction and the relative
-position :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
-of the interacting atoms, i.e. centroid, is used.
-As the geometric center is different
-for each interaction, the :math:`\mathbf{r}_{I0}` also differs.
-The sixth and seventh terms, Kspace and :doc:`fix <fix>` contribution
-respectively, are computed identical to compute *stress/atom*.
-Although the total system virial is the same as compute *stress/atom*,
-compute *centroid/stress/atom* is know to result in more consistent
-heat flux values for angle, dihedrals and improper contributions
-when computed via :doc:`compute heat/flux <compute_heat_flux>`.
+As with compute *stress/atom*, the first, second, third, fourth and
+fifth terms are pairwise, bond, angle, dihedral and improper
+contributions, but instead of assigning the virial contribution
+equally to each atom, only the force :math:`\mathbf{F}_I` acting on
+atom :math:`I` due to the interaction and the relative position
+:math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
+of the interacting atoms, i.e. centroid, is used.  As the geometric
+center is different for each interaction, the :math:`\mathbf{r}_{I0}`
+also differs.  The sixth and seventh terms, Kspace and :doc:`fix
+<fix>` contribution respectively, are computed identical to compute
+*stress/atom*.  Although the total system virial is the same as
+compute *stress/atom*, compute *centroid/stress/atom* is know to
+result in more consistent heat flux values for angle, dihedrals and
+improper contributions when computed via :doc:`compute heat/flux
+<compute_heat_flux>`.
 
-If no extra keywords are listed, the kinetic contribution
-all of the virial contribution terms are
-included in the per-atom stress tensor.  If any extra keywords are
-listed, only those terms are summed to compute the tensor.  The
-*virial* keyword means include all terms except the kinetic energy
-*ke*\ .
+If no extra keywords are listed, the kinetic contribution all of the
+virial contribution terms are included in the per-atom stress tensor.
+If any extra keywords are listed, only those terms are summed to
+compute the tensor.  The *virial* keyword means include all terms
+except the kinetic energy *ke*\ .
 
 Note that the stress for each atom is due to its interaction with all
 other atoms in the simulation, not just with other atoms in the group.
 
-Details of how compute *stress/atom* obtains the virial for individual atoms for
-either pairwise or many-body potentials, and including the effects of
-periodic boundary conditions is discussed in :ref:`(Thompson) <Thompson2>`.
-The basic idea for many-body potentials is to treat each component of
-the force computation between a small cluster of atoms in the same
-manner as in the formula above for bond, angle, dihedral, etc
-interactions.  Namely the quantity :math:`\mathbf{r} \cdot \mathbf{F}`
-is summed over the atoms in
-the interaction, with the :math:`r` vectors unwrapped by periodic boundaries
-so that the cluster of atoms is close together.  The total
+Details of how compute *stress/atom* obtains the virial for individual
+atoms for either pairwise or many-body potentials, and including the
+effects of periodic boundary conditions is discussed in
+:ref:`(Thompson) <Thompson2>`.  The basic idea for many-body
+potentials is to treat each component of the force computation between
+a small cluster of atoms in the same manner as in the formula above
+for bond, angle, dihedral, etc interactions.  Namely the quantity
+:math:`\mathbf{r} \cdot \mathbf{F}` is summed over the atoms in the
+interaction, with the :math:`r` vectors unwrapped by periodic
+boundaries so that the cluster of atoms is close together.  The total
 contribution for the cluster interaction is divided evenly among those
-atoms. Details of how compute *centroid/stress/atom* obtains
-the virial for individual atoms
-is given in :ref:`(Surblys) <Surblys1>`,
-where the idea is that the virial of the atom :math:`I`
-is the result of only the force :math:`\mathbf{F}_I` on the atom due
-to the interaction
-and its positional vector :math:`\mathbf{r}_{I0}`,
-relative to the geometric center of the
-interacting atoms, regardless of the number of participating atoms.
-The periodic boundary treatment is identical to
+atoms.
+
+Details of how compute *centroid/stress/atom* obtains the virial for
+individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
+idea is that the virial of the atom :math:`I` is the result of only
+the force :math:`\mathbf{F}_I` on the atom due to the interaction and
+its positional vector :math:`\mathbf{r}_{I0}`, relative to the
+geometric center of the interacting atoms, regardless of the number of
+participating atoms.  The periodic boundary treatment is identical to
 that of compute *stress/atom*, and both of them reduce to identical
-expressions for two-body interactions,
-i.e. computed values for contributions from bonds and two-body pair styles,
-such as :doc:`Lennard-Jones <pair_lj>`, will be the same,
-while contributions from angles, dihedrals and impropers will be different.
+expressions for two-body interactions, i.e. computed values for
+contributions from bonds and two-body pair styles, such as
+:doc:`Lennard-Jones <pair_lj>`, will be the same, while contributions
+from angles, dihedrals and impropers will be different.
 
 The :doc:`dihedral_style charmm <dihedral_charmm>` style calculates
 pairwise interactions between 1-4 atoms.  The virial contribution of
 these terms is included in the pair virial, not the dihedral virial.
 
 The KSpace contribution is calculated using the method in
-:ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology described
-in :ref:`(Sirk) <Sirk1>` for PPPM.  The choice of KSpace solver is specified
-by the :doc:`kspace_style pppm <kspace_style>` command.  Note that for
-PPPM, the calculation requires 6 extra FFTs each timestep that
-per-atom stress is calculated.  Thus it can significantly increase the
-cost of the PPPM calculation if it is needed on a large fraction of
-the simulation timesteps.
+:ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology
+described in :ref:`(Sirk) <Sirk1>` for PPPM.  The choice of KSpace
+solver is specified by the :doc:`kspace_style pppm <kspace_style>`
+command.  Note that for PPPM, the calculation requires 6 extra FFTs
+each timestep that per-atom stress is calculated.  Thus it can
+significantly increase the cost of the PPPM calculation if it is
+needed on a large fraction of the simulation timesteps.
 
 The *temp-ID* argument can be used to affect the per-atom velocities
 used in the kinetic energy contribution to the total stress.  If the
@@ -189,10 +183,10 @@ See the :doc:`compute voronoi/atom <compute_voronoi_atom>` command for
 one possible way to estimate a per-atom volume.
 
 Thus, if the diagonal components of the per-atom stress tensor are
-summed for all atoms in the system and the sum is divided by :math:`dV`, where
-:math:`d` = dimension and :math:`V` is the volume of the system,
-the result should be :math:`-P`, where :math:`P`
-is the total pressure of the system.
+summed for all atoms in the system and the sum is divided by
+:math:`dV`, where :math:`d` = dimension and :math:`V` is the volume of
+the system, the result should be :math:`-P`, where :math:`P` is the
+total pressure of the system.
 
 These lines in an input script for a 3d system should yield that
 result. I.e. the last 2 columns of thermo output will be the same:
@@ -207,33 +201,43 @@ result. I.e. the last 2 columns of thermo output will be the same:
 .. note::
 
    The per-atom stress does not include any Lennard-Jones tail
-   corrections to the pressure added by the :doc:`pair_modify tail yes <pair_modify>` command, since those are contributions to the
-   global system pressure.
+   corrections to the pressure added by the :doc:`pair_modify tail yes
+   <pair_modify>` command, since those are contributions to the global
+   system pressure.
 
 Output info
 """""""""""
 
-This compute *stress/atom* calculates a per-atom array with 6 columns, which can be
-accessed by indices 1-6 by any command that uses per-atom values from
-a compute as input.
-The compute *centroid/stress/atom* produces a per-atom array with 9 columns,
-but otherwise can be used in an identical manner to compute *stress/atom*.
-See the :doc:`Howto output <Howto_output>` doc page
-for an overview of LAMMPS output options.
+Compute *stress/atom* calculates a per-atom array with 6 columns,
+which can be accessed by indices 1-6 by any command that uses per-atom
+values from a compute as input.  Compute *centroid/stress/atom*
+produces a per-atom array with 9 columns, but otherwise can be used in
+an identical manner to compute *stress/atom*.  See the :doc:`Howto
+output <Howto_output>` doc page for an overview of LAMMPS output
+options.
 
-The per-atom array values will be in pressure\*volume
-:doc:`units <units>` as discussed above.
+The per-atom array values will be in pressure\*volume :doc:`units
+<units>` as discussed above.
 
 Restrictions
 """"""""""""
 
-Currently (Spring 2020), compute *centroid/stress/atom* does not support
-pair styles with many-body interactions, such as :doc:`Tersoff
-<pair_tersoff>`, or pair styles with long-range Coulomb interactions.
-LAMMPS will generate an error in such cases.  In principal, equivalent
-formulation to that of angle, dihedral and improper contributions in the
-virial :math:`W_{ab}` formula can also be applied to the many-body pair
-styles, and is planned in the future.
+Currently, compute *centroid/stress/atom* does not support pair styles
+with many-body interactions (:doc:`EAM <pair_eam>` is an exception,
+since its computations are performed pairwise), nor granular pair
+styles with pairwise forces which are not aligned with the vector
+between the pair of particles.  All bond styles are supported.  All
+angle, dihedral, improper styles are supported with the exception of
+USER-INTEL and KOKKOS variants of specific styles.  It also does not
+support models with long-range Coulombic or dispersion forces,
+i.e. the kspace_style command in LAMMPS.  It also does not support the
+following fixes which add rigid-body constraints: :doc:`fix shake
+<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
+<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
+
+LAMMPS will generate an error if one of these options is included in
+your model.  Extension of centroid stress calculations to these force
+and fix styles is planned for the future.
 
 Related commands
 """"""""""""""""

doc/src/fix.rst

@@ -205,6 +205,7 @@ accelerated styles exist.
 * :doc:`efield <fix_efield>` - impose electric field on system
 * :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm
 * :doc:`electron/stopping <fix_electron_stopping>` - electronic stopping power as a friction force
+* :doc:`electron/stopping/fit <fix_electron_stopping>` - electronic stopping power as a friction force
 * :doc:`enforce2d <fix_enforce2d>` - zero out z-dimension velocity and force
 * :doc:`eos/cv <fix_eos_cv>` -
 * :doc:`eos/table <fix_eos_table>` -

doc/src/fix_bond_react.rst

@@ -35,8 +35,8 @@ Syntax
 * react-ID = user-assigned name for the reaction
 * react-group-ID = only atoms in this group are considered for the reaction
 * Nevery = attempt reaction every this many steps
-* Rmin = bonding pair atoms must be separated by more than Rmin to initiate reaction (distance units)
-* Rmax = bonding pair atoms must be separated by less than Rmax to initiate reaction (distance units)
+* Rmin = initiator atoms must be separated by more than Rmin to initiate reaction (distance units)
+* Rmax = initiator atoms must be separated by less than Rmax to initiate reaction (distance units)
 * template-ID(pre-reacted) = ID of a molecule template containing pre-reaction topology
 * template-ID(post-reacted) = ID of a molecule template containing post-reaction topology
 * map_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates
@@ -55,6 +55,10 @@ Syntax
          *custom_charges* value = *no* or *fragmentID*
            no = update all atomic charges (default)
            fragmentID = ID of molecule fragment whose charges are updated
+         *molecule* value = *off* or *inter* or *intra*
+           off = allow both inter- and intramolecular reactions (default)
+           inter = search for reactions between molecules with different IDs
+           intra = search for reactions within the same molecule
 
 Examples
 """"""""
@@ -172,8 +176,8 @@ timesteps. *Nevery* can be specified with an equal-style
 integer.
 
 Three physical conditions must be met for a reaction to occur. First,
-a bonding atom pair must be identified within the reaction distance
-cutoffs. Second, the topology surrounding the bonding atom pair must
+an initiator atom pair must be identified within the reaction distance
+cutoffs. Second, the topology surrounding the initiator atom pair must
 match the topology of the pre-reaction template. Only atom types and
 bond connectivity are used to identify a valid reaction site (not bond
 types, etc.). Finally, any reaction constraints listed in the map file
@@ -181,10 +185,10 @@ types, etc.). Finally, any reaction constraints listed in the map file
 reaction site is eligible to be modified to match the post-reaction
 template.
 
-A bonding atom pair will be identified if several conditions are met.
-First, a pair of atoms I,J within the specified react-group-ID of type
-itype and jtype must be separated by a distance between *Rmin* and
-*Rmax*\ . *Rmin* and *Rmax* can be specified with equal-style
+An initiator atom pair will be identified if several conditions are
+met. First, a pair of atoms I,J within the specified react-group-ID of
+type itype and jtype must be separated by a distance between *Rmin*
+and *Rmax*\ . *Rmin* and *Rmax* can be specified with equal-style
 :doc:`variables <variable>`. For example, these reaction cutoffs can
 be a function of the reaction conversion using the following commands:
 
@@ -194,20 +198,20 @@ be a function of the reaction conversion using the following commands:
    fix myrxn all bond/react react myrxn1 all 1 0 v_rmax mol1 mol2 map_file.txt
    variable rmax equal 3+f_myrxn[1]/100 # arbitrary function of reaction count
 
-The following criteria are used if multiple candidate bonding atom
-pairs are identified within the cutoff distance: 1) If the bonding
+The following criteria are used if multiple candidate initiator atom
+pairs are identified within the cutoff distance: 1) If the initiator
 atoms in the pre-reaction template are not 1-2 neighbors (i.e. not
 directly bonded) the closest potential partner is chosen. 2)
-Otherwise, if the bonding atoms in the pre-reaction template are 1-2
+Otherwise, if the initiator atoms in the pre-reaction template are 1-2
 neighbors (i.e. directly bonded) the farthest potential partner is
 chosen. 3) Then, if both an atom I and atom J have each other as their
-bonding partners, these two atoms are identified as the bonding atom
-pair of the reaction site. Note that it can be helpful to select
-unique atom types for the bonding atoms: if a bonding atom pair is
-identified, as described in the previous steps, but does not
+initiator partners, these two atoms are identified as the initiator
+atom pair of the reaction site. Note that it can be helpful to select
+unique atom types for the initiator atoms: if an initiator atom pair
+is identified, as described in the previous steps, but does not
 correspond to the same pair specified in the pre-reaction template, an
 otherwise eligible reaction could be prevented from occurring. Once
-this unique bonding atom pair is identified for each reaction, there
+this unique initiator atom pair is identified for each reaction, there
 could be two or more reactions that involve the same atom on the same
 timestep. If this is the case, only one such reaction is permitted to
 occur. This reaction is chosen randomly from all potential reactions
@@ -217,7 +221,7 @@ with user-specified probabilities.
 
 The pre-reacted molecule template is specified by a molecule command.
 This molecule template file contains a sample reaction site and its
-surrounding topology. As described below, the bonding atom pairs of
+surrounding topology. As described below, the initiator atom pairs of
 the pre-reacted template are specified by atom ID in the map file. The
 pre-reacted molecule template should contain as few atoms as possible
 while still completely describing the topology of all atoms affected
@@ -231,18 +235,18 @@ missing topology with respect to the simulation. For example, the
 pre-reacted template may contain an atom that, in the simulation, is
 currently connected to the rest of a long polymer chain. These are
 referred to as edge atoms, and are also specified in the map file. All
-pre-reaction template atoms should be linked to a bonding atom, via at
-least one path that does not involve edge atoms. When the pre-reaction
-template contains edge atoms, not all atoms, bonds, charges, etc.
-specified in the reaction templates will be updated. Specifically,
-topology that involves only atoms that are 'too near' to template
-edges will not be updated. The definition of 'too near the edge'
-depends on which interactions are defined in the simulation. If the
-simulation has defined dihedrals, atoms within two bonds of edge atoms
-are considered 'too near the edge.' If the simulation defines angles,
-but not dihedrals, atoms within one bond of edge atoms are considered
-'too near the edge.' If just bonds are defined, only edge atoms are
-considered 'too near the edge.'
+pre-reaction template atoms should be linked to an initiator atom, via
+at least one path that does not involve edge atoms. When the
+pre-reaction template contains edge atoms, not all atoms, bonds,
+charges, etc. specified in the reaction templates will be updated.
+Specifically, topology that involves only atoms that are 'too near' to
+template edges will not be updated. The definition of 'too near the
+edge' depends on which interactions are defined in the simulation. If
+the simulation has defined dihedrals, atoms within two bonds of edge
+atoms are considered 'too near the edge.' If the simulation defines
+angles, but not dihedrals, atoms within one bond of edge atoms are
+considered 'too near the edge.' If just bonds are defined, only edge
+atoms are considered 'too near the edge.'
 
 .. note::
 
@@ -298,23 +302,23 @@ The optional keywords are 'edgeIDs', 'deleteIDs', 'chiralIDs' and
 
 The body of the map file contains two mandatory sections and four
 optional sections. The first mandatory section begins with the keyword
-'BondingIDs' and lists the atom IDs of the bonding atom pair in the
-pre-reacted molecule template. The second mandatory section begins
-with the keyword 'Equivalences' and lists a one-to-one correspondence
-between atom IDs of the pre- and post-reacted templates. The first
-column is an atom ID of the pre-reacted molecule template, and the
-second column is the corresponding atom ID of the post-reacted
-molecule template. The first optional section begins with the keyword
-'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted
-molecule template. The second optional section begins with the keyword
-'DeleteIDs' and lists the atom IDs of pre-reaction template atoms to
-delete. The third optional section begins with the keyword 'ChiralIDs'
-lists the atom IDs of chiral atoms whose handedness should be
-enforced. The fourth optional section begins with the keyword
-'Constraints' and lists additional criteria that must be satisfied in
-order for the reaction to occur. Currently, there are five types of
-constraints available, as discussed below: 'distance', 'angle',
-'dihedral', 'arrhenius', and 'rmsd'.
+'InitiatorIDs' and lists the two atom IDs of the initiator atom pair
+in the pre-reacted molecule template. The second mandatory section
+begins with the keyword 'Equivalences' and lists a one-to-one
+correspondence between atom IDs of the pre- and post-reacted
+templates. The first column is an atom ID of the pre-reacted molecule
+template, and the second column is the corresponding atom ID of the
+post-reacted molecule template. The first optional section begins with
+the keyword 'EdgeIDs' and lists the atom IDs of edge atoms in the
+pre-reacted molecule template. The second optional section begins with
+the keyword 'DeleteIDs' and lists the atom IDs of pre-reaction
+template atoms to delete. The third optional section begins with the
+keyword 'ChiralIDs' lists the atom IDs of chiral atoms whose
+handedness should be enforced. The fourth optional section begins with
+the keyword 'Constraints' and lists additional criteria that must be
+satisfied in order for the reaction to occur. Currently, there are
+five types of constraints available, as discussed below: 'distance',
+'angle', 'dihedral', 'arrhenius', and 'rmsd'.
 
 A sample map file is given below:
 
@@ -327,7 +331,7 @@ A sample map file is given below:
    7 equivalences
    2 edgeIDs
 
-   BondingIDs
+   InitiatorIDs
 
    3
    5
@@ -462,7 +466,7 @@ A few capabilities to note: 1) You may specify as many *react*
 arguments as desired. For example, you could break down a complicated
 reaction mechanism into several reaction steps, each defined by its
 own *react* argument. 2) While typically a bond is formed or removed
-between the bonding atom pairs specified in the pre-reacted molecule
+between the initiator atoms specified in the pre-reacted molecule
 template, this is not required. 3) By reversing the order of the pre-
 and post- reacted molecule templates in another *react* argument, you
 can allow for the possibility of one or more reverse reactions.
@@ -491,12 +495,20 @@ situations, decreasing rather than increasing this parameter will
 result in an increase in stability.
 
 The *custom_charges* keyword can be used to specify which atoms'
-atomic charges are updated. When the value is set to 'no,' all atomic
+atomic charges are updated. When the value is set to 'no', all atomic
 charges are updated to those specified by the post-reaction template
 (default). Otherwise, the value should be the name of a molecule
 fragment defined in the pre-reaction molecule template. In this case,
 only the atomic charges of atoms in the molecule fragment are updated.
 
+The *molecule* keyword can be used to force the reaction to be
+intermolecular, intramolecular or either. When the value is set to
+'off', molecule IDs are not considered when searching for reactions
+(default). When the value is set to 'inter', the initiator atoms must
+have different molecule IDs in order to be considered for the
+reaction. When the value is set to 'intra', only initiator atoms with
+the same molecule ID are considered for the reaction.
+
 A few other considerations:
 
 Many reactions result in one or more atoms that are considered
@@ -558,7 +570,7 @@ These is 1 quantity for each react argument:
 No parameter of this fix can be used with the *start/stop* keywords
 of the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
 
-When fix bond/react is 'unfixed,' all internally-created groups are
+When fix bond/react is 'unfixed', all internally-created groups are
 deleted. Therefore, fix bond/react can only be unfixed after unfixing
 all other fixes that use any group created by fix bond/react.
 
@@ -581,10 +593,14 @@ Default
 """""""
 
 The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
-reset_mol_ids = yes, custom_charges = no
+reset_mol_ids = yes, custom_charges = no, molecule = off
 
 ----------
 
 .. _Gissinger:
 
 **(Gissinger)** Gissinger, Jensen and Wise, Polymer, 128, 211 (2017).
+
+.. _Gissinger2020:
+
+**(Gissinger)** Gissinger, Jensen and Wise, Macromolecules (2020, in press).

doc/src/fix_electron_stopping.rst

@@ -1,28 +1,41 @@
 .. index:: fix electron/stopping
+.. index:: fix electron/stopping/fit
 
 fix electron/stopping command
 =============================
 
+fix electron/stopping/fit command
+=================================
+
 Syntax
 """"""
 
 .. parsed-literal::
 
-   fix ID group-ID electron/stopping Ecut file keyword value ...
+   fix ID group-ID style args
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
-* electron/stopping = style name of this fix command
-* Ecut = minimum kinetic energy for electronic stopping (energy units)
-* file = name of the file containing the electronic stopping power table
-* zero or more keyword/value pairs may be appended to args
-* keyword = *region* or *minneigh*
+* style = *electron/stopping* or *electron/stopping/fit*
 
   .. parsed-literal::
 
+   *electron/stopping* args = Ecut file keyword value ...
+     Ecut  = minimum kinetic energy for electronic stopping (energy units)
+     file  = name of the file containing the electronic stopping power table
+
+   *electron/stopping/fit* args = Ecut c1 c2 ...
+     Ecut  = minimum kinetic energy for electronic stopping (energy units)
+     c1 c2 = linear and quadratic coefficients for the fitted quadratic polynomial
+
+* zero or more keyword/value pairs may be appended to args for style = *electron/stopping*
+
+  .. parsed-literal::
+
+    keyword = *region* or *minneigh*
        *region* value = region-ID
-         region-ID = region, whose atoms will be affected by this fix
+          region-ID = region whose atoms will be affected by this fix
        *minneigh* value = minneigh
-         minneigh = minimum number of neighbors an atom to have stopping applied
+          minneigh = minimum number of neighbors an atom to have stopping applied
 
 Examples
 """"""""
@@ -32,6 +45,8 @@ Examples
    fix el all electron/stopping 10.0 elstop-table.txt
    fix el all electron/stopping 10.0 elstop-table.txt minneigh 3
    fix el mygroup electron/stopping 1.0 elstop-table.txt region bulk
+   fix 1 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
+   fix 1 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
 
 Description
 """""""""""
@@ -129,6 +144,19 @@ scientific publications, experimental databases or by using
 of the impact parameter of the ion; these results can be used
 to derive the stopping power.
 
+----------
+
+Style *electron/stopping/fit* calculates the electronic stopping power
+and cumulative energy lost to the electron gas via a quadratic functional
+and applies a drag force to the classical equations-of-motion for all
+atoms moving above some minimum cutoff velocity (i.e., kinetic energy).
+These coefficients can be determined by fitting a quadratic polynomial to
+electronic stopping data predicted by, for example, SRIM or TD-DFT. Multiple
+'Ecut c1 c2' values can be provided for multi-species simulations in the order
+of the atom types. There is an examples/USER/misc/electron_stopping/ directory,
+which illustrates uses of this command. Details of this implementation are
+further described in :ref:`Stewart2018 <Stewart2018>` and :ref:`Lee2020 <Lee2020>`.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
@@ -181,3 +209,11 @@ The default is no limitation by region, and minneigh = 1.
 .. _PASS:
 
 **(PASS)** PASS webpage: https://www.sdu.dk/en/DPASS
+
+.. _Stewart2018:
+
+**(Stewart2018)** J.A. Stewart, et al. (2018) Journal of Applied Physics, 123(16), 165902.
+
+.. _Lee2020:
+
+**(Lee2020)** C.W. Lee, et al. (2020) Physical Review B, 102(2), 024107.

doc/src/fix_filter_corotate.rst

@@ -56,7 +56,7 @@ is slightly modified only for the computation of long-range forces. A
 good cluster decomposition constitutes in building clusters which
 contain the fastest covalent bonds inside clusters.
 
-If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer time-steps of at least 8fs.
+If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer timesteps of at least 8fs.
 
 ----------
 

doc/src/fix_phonon.rst

@@ -121,7 +121,7 @@ A detailed description of this method can be found in
 
 The *sysdim* keyword is optional.  If specified with a value smaller
 than the dimensionality of the LAMMPS simulation, its value is used
-for the dynamical matrix calculation.  For example, using LAMMPS ot
+for the dynamical matrix calculation.  For example, using LAMMPS to
 model a 2D or 3D system, the phonon dispersion of a 1D atomic chain
 can be computed using *sysdim* = 1.
 

doc/src/fix_precession_spin.rst

@@ -62,7 +62,7 @@ with:
 
 The field value in Tesla is multiplied by the gyromagnetic
 ratio, :math:`g \cdot \mu_B/\hbar`, converting it into a precession frequency in
-rad.THz (in metal units and with :math:`\mu_B = 5.788 eV/T`).
+rad.THz (in metal units and with :math:`\mu_B = 5.788\cdot 10^{-5}` eV/T).
 
 As a comparison, the figure below displays the simulation of a
 single spin (of norm :math:`\mu_i = 1.0`) submitted to an external

doc/src/fix_rx.rst

@@ -90,10 +90,10 @@ accepted, *h* is increased by a proportional amount, and the next ODE step is be
 Otherwise, *h* is shrunk and the ODE step is repeated.
 
 Run-time diagnostics are available for the rkf45 ODE solver. The frequency
-(in time-steps) that diagnostics are reported is controlled by the last (optional)
+(in timesteps) that diagnostics are reported is controlled by the last (optional)
 12th argument. A negative frequency means that diagnostics are reported once at the
 end of each run. A positive value N means that the diagnostics are reported once
-per N time-steps.
+per N timesteps.
 
 The diagnostics report the average # of integrator steps and RHS function evaluations
 and run-time per ODE as well as the average/RMS/min/max per process. If the

doc/src/fix_shake.rst

@@ -1,9 +1,12 @@
 .. index:: fix shake
+.. index:: fix shake/kk
 .. index:: fix rattle
 
 fix shake command
 =================
 
+Accelerator Variants: *shake/kk*
+
 fix rattle command
 ==================
 

doc/src/message.rst

@@ -34,7 +34,7 @@ Examples
    message server md file tmp.couple
 
    message client md zmq localhost:5555
-   message server md zmq \*:5555
+   message server md zmq *:5555
 
    message client md mpi/one
    message server md mpi/one

doc/src/molecule.rst

@@ -201,11 +201,12 @@ bonds between nuclear cores and Drude electrons in a different manner.
 
 Each section is listed below in alphabetic order.  The format of each
 section is described including the number of lines it must contain and
-rules (if any) for whether it can appear in the data file.  In each
-case the ID is ignored; it is simply included for readability, and
-should be a number from 1 to Nlines for the section, indicating which
-atom (or bond, etc) the entry applies to.  The lines are assumed to be
-listed in order from 1 to Nlines, but LAMMPS does not check for this.
+rules (if any) for whether it can appear in the data file.  For per-
+atom sections, entries should be numbered from 1 to Natoms (where
+Natoms is the number of atoms in the template), indicating which atom
+(or bond, etc) the entry applies to.  Per-atom sections need to
+include a setting for every atom, but the atoms can be listed in any
+order.
 
 ----------
 

doc/src/package.rst

@@ -448,8 +448,7 @@ does not require atomic operations in the calculation of pair forces. For
 that reason, *full* is the default setting for GPUs. However, when
 running on CPUs, a *half* neighbor list is the default because it are
 often faster, just as it is for non-accelerated pair styles. Similarly,
-the *neigh/qeq* keyword determines how neighbor lists are built for :doc:`fix qeq/reax/kk <fix_qeq_reax>`. If not explicitly set, the value of
-*neigh/qeq* will match *neigh*\ .
+the *neigh/qeq* keyword determines how neighbor lists are built for :doc:`fix qeq/reax/kk <fix_qeq_reax>`.
 
 If the *neigh/thread* keyword is set to *off*\ , then the KOKKOS package
 threads only over atoms. However, for small systems, this may not expose

doc/src/pair_atm.rst

@@ -143,7 +143,7 @@ combinations, else an error will result.
 Mixing, shift, table, tail correction, restart, rRESPA info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This pair styles do not support the :doc:`pair_modify <pair_modify>`
+This pair style do not support the :doc:`pair_modify <pair_modify>`
 mix, shift, table, and tail options.
 
 This pair style writes its information to :doc:`binary restart files

doc/src/pair_buck_long.rst

@@ -117,7 +117,7 @@ global Coulombic cutoff is allowed.
 Mixing, shift, table, tail correction, restart, rRESPA info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This pair styles does not support mixing.  Thus, coefficients for all
+This pair style does not support mixing.  Thus, coefficients for all
 I,J pairs must be specified explicitly.
 
 This pair style supports the :doc:`pair_modify <pair_modify>` shift

doc/src/pair_gayberne.rst

@@ -160,7 +160,7 @@ For atom type pairs I,J and I != J, the epsilon and sigma coefficients
 and cutoff distance for this pair style can be mixed.  The default mix
 value is *geometric*\ .  See the "pair_modify" command for details.
 
-This pair styles supports the :doc:`pair_modify <pair_modify>` shift
+This pair style supports the :doc:`pair_modify <pair_modify>` shift
 option for the energy of the Lennard-Jones portion of the pair
 interaction, but only for sphere-sphere interactions.  There is no
 shifting performed for ellipsoidal interactions due to the anisotropic

doc/src/pair_lcbop.rst

@@ -75,14 +75,15 @@ This pair style can only be used via the *pair* keyword of the
 Restrictions
 """"""""""""
 
-This pair styles is part of the MANYBODY package.  It is only enabled
-if LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` doc page for more info.
+This pair style is part of the MANYBODY package.  It is only enabled
+if LAMMPS was built with that package.
+See the :doc:`Build package <Build_package>` doc page for more info.
 
 This pair potential requires the :doc:`newton <newton>` setting to be
 "on" for pair interactions.
 
-The C.lcbop potential file provided with LAMMPS (see the potentials
-directory) is parameterized for metal :doc:`units <units>`.  You can use
+The ``C.lcbop`` potential file provided with LAMMPS (see the potentials
+directory) is parameterized for :doc:`metal units <units>`.  You can use
 the LCBOP potential with any LAMMPS units, but you would need to
 create your own LCBOP potential file with coefficients listed in the
 appropriate units if your simulation does not use "metal" units.

doc/src/pair_polymorphic.rst

@@ -298,7 +298,7 @@ described above.  For each of the F functions, nx values are listed.
 Mixing, shift, table, tail correction, restart, rRESPA info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This pair styles does not support the :doc:`pair_modify <pair_modify>`
+This pair style does not support the :doc:`pair_modify <pair_modify>`
 shift, table, and tail options.
 
 This pair style does not write their information to :doc:`binary restart

doc/src/pair_resquared.rst

@@ -173,7 +173,7 @@ equation for the Hamaker constant presented here.  Mixing of sigma and
 epsilon followed by calculation of the energy prefactors using the
 equations above is recommended.
 
-This pair styles supports the :doc:`pair_modify <pair_modify>` shift
+This pair style supports the :doc:`pair_modify <pair_modify>` shift
 option for the energy of the Lennard-Jones portion of the pair
 interaction, but only for sphere-sphere interactions.  There is no
 shifting performed for ellipsoidal interactions due to the anisotropic

doc/src/pair_spin_exchange.rst

@@ -1,14 +1,19 @@
 .. index:: pair_style spin/exchange
+.. index:: pair_style spin/exchange/biquadratic
 
 pair_style spin/exchange command
 ================================
 
+pair_style spin/exchange/biquadratic command
+============================================
+
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
    pair_style spin/exchange cutoff
+   pair_style spin/exchange/biquadratic cutoff
 
 * cutoff = global cutoff pair (distance in metal units)
 
@@ -19,7 +24,11 @@ Examples
 
    pair_style spin/exchange 4.0
    pair_coeff * * exchange 4.0 0.0446928 0.003496 1.4885
-   pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965
+   pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965 offset yes
+
+   pair_style spin/exchange/biquadratic 4.0
+   pair_coeff * * biquadratic 4.0 0.05 0.03 1.48 0.05 0.03 1.48 offset no
+   pair_coeff 1 2 biquadratic 6.0 -0.01 0.0 1.9 0.0 0.1 19
 
 Description
 """""""""""
@@ -31,69 +40,163 @@ pairs of magnetic spins:
 
    H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,\vec{s}_i \cdot \vec{s}_j
 
-where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two neighboring magnetic spins of two particles,
-:math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance between the two
-particles. The summation is over pairs of nearest neighbors.
-:math:`J(r_{ij})` is a function defining the intensity and the sign of the exchange
-interaction for different neighboring shells. This function is defined as:
+where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two unit vectors representing
+the magnetic spins of two particles (usually atoms), and
+:math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance
+between those two particles. The summation is over pairs of nearest neighbors.
+:math:`J(r_{ij})` is a function defining the intensity and the sign of the
+exchange interaction for different neighboring shells.
+
+Style *spin/exchange/biquadratic* computes a biquadratic exchange interaction
+between pairs of magnetic spins:
 
 .. math::
 
-    {J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d}  \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d}  \right)^2 \right) e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij})
+   H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
+                      \vec{s}_{i}\cdot \vec{s}_{j}
+                      -\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
+                      \left(\vec{s}_{i}\cdot
+                      \vec{s}_{j}\right)^2
 
-where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients defined in the associated
-"pair_coeff" command, and :math:`R_c` is the radius cutoff associated to
-the pair interaction (see below for more explanations).
+where :math:`\vec{s}_i`,  :math:`\vec{s}_j`,  :math:`r_{ij}` and
+:math:`J(r_{ij})` have the same definitions as above, and :math:`K(r_{ij})` is
+a second function, defining the intensity and the sign of the biquadratic term.
 
-The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that the function above matches with
-the value of the exchange interaction for the :math:`N` neighbor shells taken into account.
-Examples and more explanations about this function and its parameterization are reported
-in :ref:`(Tranchida) <Tranchida3>`.
+The interatomic dependence of :math:`J(r_{ij})` and :math:`K(r_{ij})` in both
+interactions above is defined by the following function:
+
+.. math::
+
+    {f}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d}  \right)^2
+    \left( 1 - b \left( \frac{r_{ij}}{d}  \right)^2 \right)
+    e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij})
+
+where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients
+defined in the associated "pair_coeff" command, and :math:`R_c` is the radius
+cutoff associated to the pair interaction (see below for more explanations).
+
+The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that
+the function above matches with the value of the exchange interaction for the
+:math:`N` neighbor shells taken into account.
+Examples and more explanations about this function and its parameterization
+are reported in :ref:`(Tranchida) <Tranchida3>`.
+
+When a *spin/exchange/biquadratic* pair style is defined, six coefficients
+(three for :math:`J(r_{ij})`, and three for :math:`K(r_{ij})`) have to be
+fitted.
 
 From this exchange interaction, each spin :math:`i` will be submitted
-to a magnetic torque :math:`\vec{\omega}`, and its associated atom can be submitted to a
-force :math:`\vec{F}` for spin-lattice calculations (see :doc:`fix nve/spin <fix_nve_spin>`),
-such as:
+to a magnetic torque :math:`\vec{\omega}_{i}`, and its associated atom can be
+submitted to a force :math:`\vec{F}_{i}` for spin-lattice calculations (see
+:doc:`fix nve/spin <fix_nve_spin>`), such as:
 
 .. math::
 
    \vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
    \left(r_{ij} \right)\,\vec{s}_{j}
    ~~{\rm and}~~
-   \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{ \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
+   \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
+   \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
 
-with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij} = \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit
+with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij}
+= \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit
 vector between sites :math:`i` and :math:`j`.
+Equivalent forces and magnetic torques are generated for the biquadratic term
+when a *spin/exchange/biquadratic* pair style is defined.
 
 More details about the derivation of these torques/forces are reported in
 :ref:`(Tranchida) <Tranchida3>`.
 
-For the *spin/exchange* pair style, the following coefficients must be defined
-for each pair of atoms types via the :doc:`pair_coeff <pair_coeff>` command as in
-the examples above, or in the data file or restart files read by the
-:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>` commands, and
-set in the following order:
+For the *spin/exchange* and *spin/exchange/biquadratic* pair styles, the
+following coefficients must be defined for each pair of atoms types via the
+:doc:`pair_coeff <pair_coeff>` command as in the examples above, or in the data
+file or restart files read by the :doc:`read_data <read_data>` or
+:doc:`read_restart <read_restart>` commands, and set in the following order:
 
 * :math:`R_c` (distance units)
 * :math:`a`  (energy units)
 * :math:`b`  (adim parameter)
 * :math:`d`  (distance units)
 
-Note that :math:`R_c` is the radius cutoff of the considered exchange interaction,
-and :math:`a`, :math:`b` and :math:`d` are the three coefficients performing the parameterization
-of the function :math:`J(r_{ij})` defined above.
+for the *spin/exchange* pair style, and:
+
+* :math:`R_c` (distance units)
+* :math:`a_j`  (energy units)
+* :math:`b_j`  (adim parameter)
+* :math:`d_j`  (distance units)
+* :math:`a_k`  (energy units)
+* :math:`b_k`  (adim parameter)
+* :math:`d_k`  (distance units)
+
+for the *spin/exchange/biquadratic* pair style.
+
+Note that :math:`R_c` is the radius cutoff of the considered exchange
+interaction, and :math:`a`, :math:`b` and :math:`d` are the three coefficients
+performing the parameterization of the function :math:`J(r_{ij})` defined
+above (in the *biquadratic* style, :math:`a_j`, :math:`b_j`, :math:`d_j` and
+:math:`a_k`, :math:`b_k`, :math:`d_k` are the coefficients of :math:`J(r_{ij})`
+and :math:`K(r_{ij})` respectively).
+
 
 None of those coefficients is optional. If not specified, the
 *spin/exchange* pair style cannot be used.
 
 ----------
 
+**Offsetting magnetic forces and energies**\ :
+
+For spin-lattice simulation, it can be useful to offset the
+mechanical forces and energies generated by the exchange
+interaction.
+The *offset* keyword allows to apply this offset.
+By setting *offset* to *yes*, the energy definitions above are
+replaced by:
+
+.. math::
+
+   H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,[ \vec{s}_i \cdot \vec{s}_j-1 ]
+
+for the *spin/exchange* pair style, and:
+
+.. math::
+
+   H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
+                      [ \vec{s}_{i}\cdot \vec{s}_{j} -1 ]
+                      -\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
+                      [ \left(\vec{s}_{i}\cdot
+                      \vec{s}_{j}\right)^2 -1]
+
+for the *spin/exchange/biquadratic* pair style.
+
+Note that this offset only affects the calculation of the energy
+and mechanical forces. It does not modify the calculation of the
+precession vectors (and thus does no impact the purely magnetic
+properties).
+This ensures that when all spins are aligned, the magnetic energy
+and the associated mechanical forces (and thus the pressure
+generated by the magnetic potential) are null.
+
+.. note::
+  This offset term can be very important when calculations such as
+  equations of state (energy vs volume, or energy vs pressure) are
+  being performed. Indeed, setting the *offset* term ensures that
+  at the ground state of the crystal and at the equilibrium magnetic
+  configuration (typically ferromagnetic), the pressure is null,
+  as expected.
+  Otherwise, magnetic forces could generate a residual pressure.
+
+When the *offset* option is set to *no*, no offset is applied
+(also corresponding to the default option).
+
+----------
+
 Restrictions
 """"""""""""
 
 All the *pair/spin* styles are part of the SPIN package.  These styles
 are only enabled if LAMMPS was built with this package, and if the
-atom_style "spin" was declared.  See the :doc:`Build package <Build_package>` doc page for more info.
+atom_style "spin" was declared.
+See the :doc:`Build package <Build_package>` doc page for more info.
 
 Related commands
 """"""""""""""""
@@ -105,7 +208,7 @@ Default
 """""""
 
 
-none
+The default *offset* keyword value is *no*.
 
 ----------
 

doc/src/pair_srp.rst

@@ -124,7 +124,7 @@ at the cutoff distance :math:`r_c`.
 Mixing, shift, table, tail correction, restart, rRESPA info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This pair styles does not support mixing.
+This pair style does not support mixing.
 
 This pair style does not support the :doc:`pair_modify <pair_modify>`
 shift option for the energy of the pair interaction. Note that as

doc/src/pair_style.rst

@@ -305,6 +305,7 @@ accelerated styles exist.
 * :doc:`spin/dipole/long <pair_spin_dipole>` -
 * :doc:`spin/dmi <pair_spin_dmi>` -
 * :doc:`spin/exchange <pair_spin_exchange>` -
+* :doc:`spin/exchange/biquadratic <pair_spin_exchange>` -
 * :doc:`spin/magelec <pair_spin_magelec>` -
 * :doc:`spin/neel <pair_spin_neel>` -
 * :doc:`srp <pair_srp>` -

doc/src/read_data.rst

@@ -345,10 +345,11 @@ Similarly, the z dimension should be periodic if xz or yz is non-zero.
 LAMMPS does not require this periodicity, but you may lose atoms if
 this is not the case.
 
-Also note that if your simulation will tilt the box, e.g. via the :doc:`fix deform <fix_deform>` command, the simulation box must be setup to
-be triclinic, even if the tilt factors are initially 0.0.  You can
-also change an orthogonal box to a triclinic box or vice versa by
-using the :doc:`change box <change_box>` command with its *ortho* and
+Also note that if your simulation will tilt the box, e.g. via the
+:doc:`fix deform <fix_deform>` command, the simulation box must be setup
+to be triclinic, even if the tilt factors are initially 0.0.  You can
+also change an orthogonal box to a triclinic box or vice versa by using
+the :doc:`change box <change_box>` command with its *ortho* and
 *triclinic* options.
 
 For 2d simulations, the *zlo zhi* values should be set to bound the z
@@ -364,24 +365,53 @@ periodic remapping will be performed using simulation box bounds that
 are the union of the existing box and the box boundaries in the new
 data file.
 
+If the system is non-periodic (in a dimension), then an image flag for
+that direction has no meaning, since there cannot be periodic images
+without periodicity and the data file is therefore - technically speaking
+- invalid.  This situation would happen when a data file was written
+with periodic boundaries and then read back for non-periodic boundaries.
+Accepting a non-zero image flag can lead to unexpected results for any
+operations and computations in LAMMPS that internally use unwrapped
+coordinates (for example computing the center of mass of a group of
+atoms). Thus all non-zero image flags for non-periodic dimensions will
+be be reset to zero on reading the data file and LAMMPS will print a
+warning message, if that happens.  This is equivalent to wrapping atoms
+individually back into the principal unit cell in that direction.  This
+operation is equivalent to the behavior of the :doc:`change_box command
+<change_box>` when used to change periodicity.
+
+
+If those atoms with non-zero image flags are involved in bonded
+interactions, this reset can lead to undesired changes, when the image
+flag values differ between the atoms, i.e. the bonded interaction
+straddles domain boundaries.  For example a bond can become stretched
+across the unit cell if one of its atoms is wrapped to one side of the
+cell and the second atom to the other. In those cases the data file
+needs to be pre-processed externally to become valid again.  This can be
+done by first unwrapping coordinates and then wrapping entire molecules
+instead of individual atoms back into the principal simulation cell and
+finally expanding the cell dimensions in the non-periodic direction as
+needed, so that the image flag would be zero.
+
 .. note::
 
-   If the system is non-periodic (in a dimension), then all atoms
-   in the data file must have coordinates (in that dimension) that are
-   "greater than or equal to" the lo value and "less than or equal to"
-   the hi value.  If the non-periodic dimension is of style "fixed" (see
-   the :doc:`boundary <boundary>` command), then the atom coords must be
+   If the system is non-periodic (in a dimension), then all atoms in the
+   data file must have coordinates (in that dimension) that are "greater
+   than or equal to" the lo value and "less than or equal to" the hi
+   value.  If the non-periodic dimension is of style "fixed" (see the
+   :doc:`boundary <boundary>` command), then the atom coords must be
    strictly "less than" the hi value, due to the way LAMMPS assign atoms
    to processors.  Note that you should not make the lo/hi values
    radically smaller/larger than the extent of the atoms.  For example,
    if your atoms extend from 0 to 50, you should not specify the box
-   bounds as -10000 and 10000.  This is because LAMMPS uses the specified
-   box size to layout the 3d grid of processors.  A huge (mostly empty)
-   box will be sub-optimal for performance when using "fixed" boundary
+   bounds as -10000 and 10000 unless you also use the :doc:`processors
+   command <processors>`.  This is because LAMMPS uses the specified box
+   size to layout the 3d grid of processors.  A huge (mostly empty) box
+   will be sub-optimal for performance when using "fixed" boundary
    conditions (see the :doc:`boundary <boundary>` command).  When using
    "shrink-wrap" boundary conditions (see the :doc:`boundary <boundary>`
-   command), a huge (mostly empty) box may cause a parallel simulation to
-   lose atoms when LAMMPS shrink-wraps the box around the atoms.  The
+   command), a huge (mostly empty) box may cause a parallel simulation
+   to lose atoms when LAMMPS shrink-wraps the box around the atoms.  The
    read_data command will generate an error in this case.
 
 The "extra bond per atom" setting (angle, dihedral, improper) is only

doc/src/read_dump.rst

@@ -370,6 +370,8 @@ needed to generate absolute, unscaled coordinates.
 Restrictions
 """"""""""""
 
+The *native* dump file reader does not support binary .bin dump files.
+
 To read gzipped dump files, you must compile LAMMPS with the
 -DLAMMPS_GZIP option.  See the :doc:`Build settings <Build_settings>`
 doc page for details.

doc/src/rerun.rst

@@ -99,14 +99,15 @@ files do not match the specified output frequency.
 ----------
 
 If more than one dump file is specified, the dump files are read one
-after the other.  It is assumed that snapshot timesteps will be in
-ascending order.  If a snapshot is encountered that is not in
-ascending order, it will skip the snapshot until it reads one that is.
+after the other in the order specified.  It is assumed that snapshot
+timesteps will be in ascending order.  If a snapshot is encountered that
+is not in ascending order, it will skip the snapshot until it reads one
+that is.
 This allows skipping of a duplicate snapshot (same timestep),
 e.g. that appeared at the end of one file and beginning of the next.
 However if you specify a series of dump files in an incorrect order
 (with respect to the timesteps they contain), you may skip large
-numbers of snapshots
+numbers of snapshots.
 
 Note that the dump files specified as part of the *dump* keyword can be
 parallel files, i.e. written as multiple files either per processor
@@ -118,17 +119,24 @@ and write parallel dump files.
 
 The *first*\ , *last*\ , *every*\ , *skip* keywords determine which
 snapshots are read from the dump file(s).  Snapshots are skipped until
-they have a timestamp >= *Nfirst*\ .  When a snapshot with a timestamp >
-*Nlast* is encountered, the rerun command finishes.  Note below that
+they have a timestep >= *Nfirst*\ .  When a snapshot with a timestep >
+*Nlast* is encountered, the rerun command finishes.  Note that
 the defaults for *first* and *last* are to read all snapshots.  If the
 *every* keyword is set to a value > 0, then only snapshots with
-timestamps that are a multiple of *Nevery* are read (the first
+timesteps that are a multiple of *Nevery* are read (the first
 snapshot is always read).  If *Nevery* = 0, then this criterion is
 ignored, i.e. every snapshot is read that meets the other criteria.
 If the *skip* keyword is used, then after the first snapshot is read,
 every Nth snapshot is read, where N = *Nskip*\ .  E.g. if *Nskip* = 3,
 then only 1 out of every 3 snapshots is read, assuming the snapshot
-timestamp is also consistent with the other criteria.
+timestep is also consistent with the other criteria.
+
+.. note::
+
+   Not all dump formats contain the timestep and not all dump readers
+   support reading it.  In that case individual snapshots are assigned
+   consecutive timestep numbers starting at 1.
+
 
 The *start* and *stop* keywords do not affect which snapshots are read
 from the dump file(s).  Rather, they have the same meaning that they
@@ -205,9 +213,8 @@ thermodynamic output or new dump file output.
 Restrictions
 """"""""""""
 
-To read gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option.  See the :doc:`Build settings <Build_settings>`
-doc page for details.
+The *rerun* command is subject to all restrictions of
+the :doc:`read_dump <read_dump>` command.
 
 Related commands
 """"""""""""""""

doc/src/set.rst

@@ -13,7 +13,16 @@ Syntax
 * style = *atom* or *type* or *mol* or *group* or *region*
 * ID = atom ID range or type range or mol ID range or group ID or region ID
 * one or more keyword/value pairs may be appended
-* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol* or *x* or *y* or *z* or           *charge* or *dipole* or *dipole/random* or *quat* or           *spin* or *spin/random* or *quat* or           *quat/random* or *diameter* or *shape* or           *length* or *tri* or *theta* or *theta/random* or           *angmom* or *omega* or           *mass* or *density* or *density/disc* or *volume* or *image* or           *bond* or *angle* or *dihedral* or *improper* or           *sph/e* or *sph/cv* or *sph/rho* or           *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or           *edpd/temp* or *edpd/cv* or *cc* or *i_name* or *d_name*
+* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol*
+  or *x* or *y* or *z* or *vx* or *vy* or *vz*
+  or *charge* or *dipole* or *dipole/random* or *spin* or *spin/random*
+  or *quat* *quat/random* or *diameter* or *shape* or *length* or *tri*
+  or *theta* or *theta/random* or *angmom* or *omega* or *mass*
+  or *density* or *density/disc* or *volume* or *image*
+  or *bond* or *angle* or *dihedral* or *improper*
+  or *sph/e* or *sph/cv* or *sph/rho* or *smd/contact/radius* or *smd/mass/density*
+  or *dpd/theta* or *edpd/temp* or *edpd/cv* or *cc*
+  or *i_name* or *d_name*
 
   .. parsed-literal::
 

doc/src/units.rst

@@ -66,11 +66,15 @@ generality, LAMMPS sets the fundamental quantities mass, :math:`\sigma`,
 masses, distances, energies you specify are multiples of these
 fundamental values.  The formulas relating the reduced or unitless
 quantity (with an asterisk) to the same quantity with units is also
-given.  Thus you can use the mass & :math:`\sigma` & :math:`\epsilon`
+given.  Thus you can use the mass, :math:`\sigma`, and :math:`\epsilon`
 values for a specific material and convert the results from a unitless
-LJ simulation into physical quantities.
+LJ simulation into physical quantities.  Please note that using
+these three properties as base, your unit of time has to conform
+to the relation :math:`\epsilon = \frac{m \sigma^2}{\tau^2}` since
+energy is a derived unit (in SI units you equivalently have the relation
+:math:`1\mathsf{J} = 1\frac{\mathsf{kg}\cdot\mathsf{m}^2}{\mathsf{s}^2}`).
 
-* mass = mass or *m*
+* mass = mass or :math:`m`, where :math:`M^* = \frac{M}{m}`
 * distance = :math:`\sigma`, where :math:`x^* = \frac{x}{\sigma}`
 * time = :math:`\tau`, where :math:`\tau^* = \tau \sqrt{\frac{\epsilon}{m \sigma^2}}`
 * energy = :math:`\epsilon`, where :math:`E^* = \frac{E}{\epsilon}`

doc/utils/sphinx-config/false_positives.txt

@@ -148,6 +148,7 @@ athomps
 atm
 atomeye
 atomfile
+AtomicPairStyle
 atomID
 atomistic
 attogram
@@ -240,6 +241,7 @@ bigint
 Bij
 bilayer
 bilayers
+biquadratic
 binsize
 binstyle
 binutils
@@ -277,7 +279,6 @@ Boltzman
 BondAngle
 BondBond
 bondchk
-BondingIDs
 bondmax
 bondtype
 Bonet
@@ -1118,12 +1119,15 @@ gmail
 gmake
 gmask
 Gmask
+GMock
 gneb
 GNEB
 Goldfarb
 Gonzalez-Melchor
 googlemail
+googletest
 Gordan
+Goudeau
 GPa
 gpu
 gpuID
@@ -1324,6 +1328,7 @@ inhomogeneous
 init
 initialdelay
 initializations
+InitiatorIDs
 initio
 InP
 inregion
@@ -1542,6 +1547,7 @@ ksh
 kspace
 Kspace
 KSpace
+KSpaceStyle
 Kspring
 kT
 kTequil
@@ -1882,6 +1888,7 @@ mie
 Mie
 Mij
 Mikami
+Milano
 Militzer
 Minary
 mincap
@@ -1927,6 +1934,7 @@ mol
 Mol
 molfile
 Molfile
+MolPairStyle
 moltemplate
 momb
 Monaghan
@@ -1984,6 +1992,7 @@ multi
 multibody
 Multibody
 multicenter
+multicentered
 multicmd
 multicomponent
 multicore
@@ -2004,6 +2013,7 @@ muVT
 mux
 muy
 muz
+Müller
 mv
 mV
 Mvapich
@@ -2301,7 +2311,6 @@ ortho
 orthonormal
 orthorhombic
 oso
-ot
 Otype
 Ouldridge
 outfile
@@ -2452,6 +2461,7 @@ polydispersity
 polyelectrolyte
 polyhedra
 polymorphism
+Polym
 popen
 Popov
 popstore
@@ -2614,7 +2624,6 @@ Ree
 refactored
 refactoring
 reflectionstyle
-regoin
 Reinders
 reinit
 relaxbox
@@ -2784,6 +2793,7 @@ Schulten
 Schunk
 Schuring
 Schwen
+Sci
 screenshot
 screenshots
 Scripps
@@ -2979,6 +2989,8 @@ Subclassed
 subcutoff
 subcycle
 subcycling
+subhi
+sublo
 Subramaniyan
 subscripted
 subscripting
@@ -3287,6 +3299,7 @@ vdfmax
 vdim
 vdisplace
 vdW
+vdwl
 vec
 vectorial
 vectorization
@@ -3454,6 +3467,7 @@ xyz
 xz
 xzhou
 yaff
+yaml
 YAFF
 Yamada
 Yaser

examples/COUPLE/fortran2/Makefile

@@ -14,7 +14,7 @@ CXXLIB = -lstdc++    # replace with your C++ runtime libs
 # Flags for Fortran compiler, C++ compiler, and C preprocessor, respectively
 FFLAGS = -O2 -fPIC
 CXXFLAGS = -O2 -fPIC
-CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX
+CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX -DLAMMPS_LIB_MPI
 
 all : liblammps_fortran.a liblammps_fortran.so
 

examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp

@@ -26,7 +26,7 @@ velocity 	all create 100 4928459 rot yes dist gaussian
 #pair_style 	hybrid/overlay eam/alloy spin/exchange 4.0 spin/neel 4.0
 pair_style 	hybrid/overlay eam/alloy spin/exchange 4.0
 pair_coeff 	* * eam/alloy Co_PurjaPun_2012.eam.alloy Co
-pair_coeff 	* * spin/exchange exchange 4.0 -0.3593 1.135028015e-05 1.064568567
+pair_coeff 	* * spin/exchange exchange 4.0 -0.3593 1.135028015e-05 1.0645 offset yes
 #pair_coeff 	* * spin/neel neel 4.0 0.0048 0.234 1.168 2.6905 0.705 0.652  
 
 neighbor 	0.1 bin

examples/SPIN/iron/in.spin.iron

@@ -25,7 +25,7 @@ velocity 	all create 100 4928459 rot yes dist gaussian
 
 pair_style 	hybrid/overlay eam/alloy spin/exchange 3.5
 pair_coeff 	* * eam/alloy Fe_Mishin2006.eam.alloy Fe
-pair_coeff 	* * spin/exchange exchange 3.4 0.02726 0.2171 1.841
+pair_coeff 	* * spin/exchange exchange 3.4 0.02726 0.2171 1.841 offset yes
 
 neighbor 	0.1 bin
 neigh_modify 	every 10 check yes delay 20

examples/SPIN/iron/in.spin.iron_cubic

@@ -21,9 +21,9 @@ mass		1 55.845
 set 		group all spin 2.2 -1.0 0.0 0.0
 velocity 	all create 100 4928459 rot yes dist gaussian
 
-pair_style 	hybrid/overlay eam/alloy spin/exchange 3.5
+pair_style 	hybrid/overlay eam/alloy spin/exchange/biquadratic 3.5
 pair_coeff 	* * eam/alloy Fe_Mishin2006.eam.alloy Fe
-pair_coeff 	* * spin/exchange exchange 3.4 0.02726 0.2171 1.841
+pair_coeff 	* * spin/exchange/biquadratic biquadratic 3.4 0.02726 0.2171 1.841 0.0 0.0 2.0 offset yes
 neighbor 	0.1 bin
 neigh_modify 	every 10 check yes delay 20
 

examples/SPIN/test_problems/validation_damped_exchange/llg_exchange.py

@@ -6,9 +6,17 @@ import matplotlib.pyplot as plt
 import mpmath as mp
 
 hbar=0.658212           # Planck's constant (eV.fs/rad)
-J0=0.05                 # per-neighbor exchange interaction (eV)
+# J0=0.05                 # per-neighbor exchange interaction (eV)
+
+# exchange interaction parameters
+J1 = 11.254 # in eV 
+J2 = 0.0    # adim
+J3 = 1.0    # in Ang.
+
+# initial spins
 S1 = np.array([1.0, 0.0, 0.0])
 S2 = np.array([0.0, 1.0, 0.0])
+
 alpha=0.01              # damping coefficient
 pi=math.pi
 
@@ -30,6 +38,14 @@ def rotation_matrix(axis, theta):
       [2 * (bc - ad), aa + cc - bb - dd, 2 * (cd + ab)],
       [2 * (bd + ac), 2 * (cd - ab), aa + dd - bb - cc]])
 
+#Definition of the Bethe-Slater function
+def func_BS(x,a,b,c):
+    return 4*a*((x/c)**2)*(1-b*(x/c)**2)*np.exp(-(x/c)**2)
+
+#Definition of the derivative of the Bethe-Slater function
+def func_dBS(x,a,b,c):
+    return 4*a*((x/c)**2)*(1-b*(x/c)**2)*np.exp(-(x/c)**2)
+
 # calculating precession field of spin Sr
 def calc_rot_vector(Sr,Sf):
   rot = (J0/hbar)*(Sf-alpha*np.cross(Sf,Sr))/(1.0+alpha**2)
@@ -65,6 +81,6 @@ for t in range (0,N):
   # calc. average magnetization
   Sm = (S1+S2)*0.5
   # calc. energy
-  en = -2.0*J0*(np.dot(S1,S2))
+  en = -J0*(np.dot(S1,S2))
   # print res. in ps for comparison with LAMMPS
   print(t*dt/1000.0,Sm[0],Sm[1],Sm[2],en)

examples/SPIN/test_problems/validation_damped_exchange/run-test-exchange.sh

@@ -13,7 +13,7 @@ en="$(echo "$en-$in" | bc -l)"
 tail -n +$in log.lammps | head -n $en > res_lammps.dat
 
 # compute Langevin
-python3 -m llg_exchange.py > res_llg.dat
+python3 llg_exchange.py > res_llg.dat
 
 # plot results
-python3 -m plot_precession.py res_lammps.dat res_llg.dat
+python3 plot_precession.py res_lammps.dat res_llg.dat

examples/SPIN/test_problems/validation_damped_exchange/test-spin-precession.in

@@ -5,22 +5,24 @@ atom_style      spin
 atom_modify     map array
 boundary        f f f 
 
-read_data	two_spins.data
+atom_modify 	map array 
+lattice 	sc 3.0
+region 		box block 0 2 0 1 0 1 
+create_box 	1 box
+create_atoms 	1 box
+
+mass		1 55.845
+set 		atom 1 spin 2.0 1.0 0.0 0.0
+set 		atom 2 spin 2.0 0.0 1.0 0.0
 
 pair_style      spin/exchange 3.1
 pair_coeff	* * exchange 3.1 11.254 0.0 1.0
 
-group bead      type 1  
- 
-variable        H equal 0.0
-variable        Kan equal 0.0
 variable        Temperature equal 0.0 
 variable        RUN equal 30000
 
-fix             1 all nve/spin lattice no
-fix             2 all precession/spin zeeman ${H} 0.0 0.0 1.0 anisotropy ${Kan} 0.0 0.0 1.0
-fix_modify      2 energy yes
-fix             3 all langevin/spin ${Temperature} 0.01 12345
+fix             1 all nve/spin lattice frozen
+fix             2 all langevin/spin ${Temperature} 0.01 12345
 
 compute		out_mag    all spin
 compute		out_pe     all pe
@@ -34,6 +36,9 @@ variable	emag      equal c_out_mag[5]
 thermo_style    custom step time v_magx v_magy v_magz v_emag pe etotal
 thermo          10
 
+compute 	outsp all property/atom spx spy spz sp fmx fmy fmz
+dump 		1 all custom 10 dump.data type x y z c_outsp[1] c_outsp[2] c_outsp[3] fx fy fz
+
 timestep	0.0001
 
 run             ${RUN}

examples/SPIN/test_problems/validation_damped_exchange/two_spins.data

@@ -1,22 +0,0 @@
-LAMMPS data file via write_data, version 19 Sep 2019, timestep = 0
-
-2 atoms
-1 atom types
-
-0.0 6.0 xlo xhi
-0.0 3.0 ylo yhi
-0.0 3.0 zlo zhi
-
-Masses
-
-1 1
-
-Atoms # spin
-
-1 1 2.0 0.0 0.0 0.0 1.0 0.0 0.0 0 0 0
-2 1 2.0 3.0 0.0 0.0 0.0 1.0 0.0 0 0 0
-
-Velocities
-
-1 0.0 0.0 0.0
-2 0.0 0.0 0.0

examples/SPIN/test_problems/validation_nve/run-test-nve.sh

@@ -13,4 +13,4 @@ en="$(echo "$en-$in" | bc -l)"
 tail -n +$in log.lammps | head -n $en > res_lammps.dat
 
 # plot results
-python3 -m plot_nve.py res_lammps.dat res_llg.dat
+python3 plot_nve.py res_lammps.dat res_llg.dat

examples/SPIN/test_problems/validation_nvt/in.spin.nvt_lattice

@@ -30,7 +30,7 @@ neighbor 	0.1 bin
 neigh_modify 	every 10 check yes delay 20
 
 fix 		1 all precession/spin zeeman 0.0 0.0 0.0 1.0
-fix             2 all langevin 200.0 200.0 10.0 48279
+fix             2 all langevin 200.0 200.0 1.0 48279
 fix 		3 all langevin/spin 0.0 0.00001 321
 fix 		4 all nve/spin lattice moving
 timestep	0.001

examples/SPIN/test_problems/validation_nvt/in.spin.nvt_spin

@@ -29,7 +29,7 @@ neighbor 	0.1 bin
 neigh_modify 	every 10 check yes delay 20
 
 fix 		1 all precession/spin zeeman 0.0 0.0 0.0 1.0
-fix 		2 all langevin/spin 200.0 0.1 321
+fix 		2 all langevin/spin 200.0 0.01 321
 fix 		3 all nve/spin lattice moving
 timestep	0.001
 

examples/SPIN/test_problems/validation_nvt/plot_nvt.py

@@ -39,5 +39,5 @@ plt.xlabel('Time (in ps)')
 plt.legend()
 plt.show()
 
-fig.savefig(os.path.join(os.getcwd(), "nve_spin_lattice.pdf"), bbox_inches="tight")
+fig.savefig(os.path.join(os.getcwd(), "nvt_spin_lattice.pdf"), bbox_inches="tight")
 plt.close(fig)

examples/USER/misc/electron_stopping/in.cascade_AlCu

@@ -0,0 +1,38 @@
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Al lattice with a single incident Cu atom - multiple species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          fcc 4.0495
+
+region           box block -10 10 -10 10 -10 10
+create_box       2 box
+create_atoms     1 box
+
+pair_style	 eam/alloy
+pair_coeff	 * * ../../../../potentials/AlCu.eam.alloy Al Cu
+
+mass             1 26.982
+mass             2 63.546
+
+velocity         all create 300 42534 mom yes rot yes
+
+set              atom 1 type 2
+group            pka id 1
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100

examples/USER/misc/electron_stopping/in.cascade_SiSi

@@ -0,0 +1,36 @@
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Si lattice with one primary knock-on atom (PKA) - single species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          diamond 5.431
+
+region           box block -10 10 -10 10 -10 10
+create_box       1 box
+create_atoms     1 box
+
+pair_style       tersoff/zbl
+pair_coeff       * * ../../../../potentials/SiC.tersoff.zbl Si
+
+mass             1 28.0855
+
+velocity         all create 300 42534 mom yes rot yes
+
+group            pka id 1
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100

examples/USER/misc/electron_stopping/log.18Sep2020.cascade_AlCu.intel.1

@@ -0,0 +1,115 @@
+LAMMPS (18 Sep 2020)
+OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
+  using 1 OpenMP thread(s) per MPI task
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Al lattice with a single incident Cu atom - multiple species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          fcc 4.0495
+Lattice spacing in x,y,z = 4.0495000 4.0495000 4.0495000
+
+region           box block -10 10 -10 10 -10 10
+create_box       2 box
+Created orthogonal box = (-40.495000 -40.495000 -40.495000) to (40.495000 40.495000 40.495000)
+  1 by 1 by 1 MPI processor grid
+create_atoms     1 box
+Created 32000 atoms
+  create_atoms CPU = 0.004 seconds
+
+pair_style	 eam/alloy
+pair_coeff	 * * ../../../../potentials/AlCu.eam.alloy Al Cu
+Reading eam/alloy potential file ../../../../potentials/AlCu.eam.alloy with DATE: 2008-10-01
+
+mass             1 26.982
+mass             2 63.546
+
+velocity         all create 300 42534 mom yes rot yes
+
+set              atom 1 type 2
+Setting atom values ...
+  1 settings made for type
+group            pka id 1
+1 atoms in group pka
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100
+Neighbor list info ...
+  update every 1 steps, delay 10 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 8.6825
+  ghost atom cutoff = 8.6825
+  binsize = 4.34125, bins = 19 19 19
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair eam/alloy, perpetual
+      attributes: half, newton on
+      pair build: half/bin/atomonly/newton
+      stencil: half/bin/3d/newton
+      bin: standard
+Per MPI rank memory allocation (min/avg/max) = 23.27 | 23.27 | 23.27 Mbytes
+Step Dt Time Temp PotEng KinEng f_3 
+       0 2.4879625e-05            0    53029.167   -106186.96       219339            0 
+       5 2.4881895e-05 0.00012440247    53019.542    -106184.2    219299.18    36.968257 
+      10 1.0341799e-05 0.00021830163    53006.803   -106159.67    219246.49    64.866504 
+      15 5.6753071e-06 0.0002583636     52996.09   -106127.26    219202.18    76.766363 
+      20 4.0862476e-06 0.0002830119    52987.566   -106099.31    219166.93    84.086344 
+      25 3.3677164e-06 0.00030179992     52980.99   -106077.67    219139.73    89.665096 
+      30 3.0218093e-06 0.00031784053    52976.302   -106063.03    219120.34    94.427505 
+      35 2.8935922e-06 0.00033262008    52973.489   -106055.77     219108.7    98.815168 
+      40 2.9394209e-06 0.00034711037    52972.541   -106056.15    219104.78    103.11678 
+      45 3.1822694e-06 0.00036220043    52973.425    -106064.3    219108.44    107.59642 
+      50 3.743784e-06 0.00037905999    52976.072   -106080.26    219119.38    112.60152 
+      55 5.0685177e-06 0.0003999287    52980.344   -106104.15    219137.05    118.79722 
+      60 1.0189784e-05 0.00043198334    52985.861   -106136.52    219159.88    128.31484 
+      65 1.8636384e-05 0.00052946777    52985.275   -106162.53    219157.45     157.2625 
+      70 1.844772e-05 0.00061001061    52977.927   -106155.89    219127.06    181.17691 
+      75 2.4893022e-05 0.00072690857    52972.391   -106168.08    219104.16    215.88136 
+      80 7.390618e-06 0.00081149431    52959.379   -106139.89    219050.34    240.98969 
+      85 4.1547853e-06 0.00084037647    52948.078   -106101.74    219003.59    249.56079 
+      90 2.9763749e-06 0.00085843347     52938.03   -106065.54    218962.03    254.91825 
+      95 2.3727508e-06 0.00087197081    52929.043   -106032.37    218924.86    258.93397 
+     100 2.0138478e-06 0.00088304936    52921.103   -106002.81    218892.02    262.21977 
+Loop time of 9.53154 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 0.002 ns/day, 13147.213 hours/ns, 10.491 timesteps/s
+99.7% CPU use with 1 MPI tasks x 1 OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 8.815      | 8.815      | 8.815      |   0.0 | 92.48
+Neigh   | 0.38408    | 0.38408    | 0.38408    |   0.0 |  4.03
+Comm    | 0.029049   | 0.029049   | 0.029049   |   0.0 |  0.30
+Output  | 0.0025912  | 0.0025912  | 0.0025912  |   0.0 |  0.03
+Modify  | 0.28624    | 0.28624    | 0.28624    |   0.0 |  3.00
+Other   |            | 0.01456    |            |       |  0.15
+
+Nlocal:        32000.0 ave       32000 max       32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:        26825.0 ave       26825 max       26825 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    2.81599e+06 ave 2.81599e+06 max 2.81599e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 2815993
+Ave neighs/atom = 87.999781
+Neighbor list builds = 5
+Dangerous builds = 3
+
+Please see the log.cite file for references relevant to this simulation
+
+Total wall time: 0:00:09

examples/USER/misc/electron_stopping/log.18Sep2020.cascade_AlCu.intel.4

@@ -0,0 +1,115 @@
+LAMMPS (18 Sep 2020)
+OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
+  using 1 OpenMP thread(s) per MPI task
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Al lattice with a single incident Cu atom - multiple species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          fcc 4.0495
+Lattice spacing in x,y,z = 4.0495000 4.0495000 4.0495000
+
+region           box block -10 10 -10 10 -10 10
+create_box       2 box
+Created orthogonal box = (-40.495000 -40.495000 -40.495000) to (40.495000 40.495000 40.495000)
+  1 by 2 by 2 MPI processor grid
+create_atoms     1 box
+Created 32000 atoms
+  create_atoms CPU = 0.001 seconds
+
+pair_style	 eam/alloy
+pair_coeff	 * * ../../../../potentials/AlCu.eam.alloy Al Cu
+Reading eam/alloy potential file ../../../../potentials/AlCu.eam.alloy with DATE: 2008-10-01
+
+mass             1 26.982
+mass             2 63.546
+
+velocity         all create 300 42534 mom yes rot yes
+
+set              atom 1 type 2
+Setting atom values ...
+  1 settings made for type
+group            pka id 1
+1 atoms in group pka
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100
+Neighbor list info ...
+  update every 1 steps, delay 10 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 8.6825
+  ghost atom cutoff = 8.6825
+  binsize = 4.34125, bins = 19 19 19
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair eam/alloy, perpetual
+      attributes: half, newton on
+      pair build: half/bin/atomonly/newton
+      stencil: half/bin/3d/newton
+      bin: standard
+Per MPI rank memory allocation (min/avg/max) = 9.014 | 9.014 | 9.014 Mbytes
+Step Dt Time Temp PotEng KinEng f_3 
+       0 2.4879625e-05            0    53029.167   -106186.96       219339            0 
+       5 2.4881895e-05 0.00012440247    53019.542    -106184.2    219299.18    36.968257 
+      10 1.0341742e-05 0.00021830123    53006.803   -106159.67    219246.49    64.866388 
+      15 5.6752732e-06 0.00025836298     52996.09   -106127.26    219202.18     76.76618 
+      20 4.0862174e-06 0.00028301112    52987.566   -106099.31    219166.93    84.086114 
+      25 3.3676848e-06 0.00030179899     52980.99   -106077.67    219139.73    89.664821 
+      30 3.021773e-06 0.00031783944    52976.302   -106063.02    219120.33    94.427181 
+      35 2.8935472e-06 0.00033261879    52973.489   -106055.77     219108.7    98.814784 
+      40 2.9393606e-06 0.00034710883    52972.541   -106056.15    219104.78    103.11632 
+      45 3.1821803e-06 0.00036219854    52973.425   -106064.29    219108.43    107.59586 
+      50 3.7436309e-06 0.00037905755    52976.071   -106080.26    219119.38    112.60079 
+      55 5.0681667e-06 0.0003999252    52980.343   -106104.15    219137.05    118.79618 
+      60 1.0187808e-05 0.00043197649    52985.861   -106136.51    219159.87     128.3128 
+      65 1.8643099e-05 0.00052944037    52985.278   -106162.53    219157.46    157.25436 
+      70 1.8445045e-05 0.00060999223    52977.928   -106155.89    219127.06    181.17146 
+      75 2.4893021e-05 0.00072688076    52972.393   -106168.08    219104.17     215.8731 
+      80 7.3916674e-06 0.0008114874    52959.382    -106139.9    219050.35    240.98764 
+      85 4.1550998e-06 0.00084037284     52948.08   -106101.75     219003.6    249.55971 
+      90 2.976545e-06 0.00085843108    52938.032   -106065.55    218962.04    254.91754 
+      95 2.3728646e-06 0.00087196913    52929.045   -106032.38    218924.87    258.93348 
+     100 2.0139362e-06 0.00088304819    52921.106   -106002.82    218892.03    262.21943 
+Loop time of 2.45676 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 0.007 ns/day, 3388.559 hours/ns, 40.704 timesteps/s
+99.8% CPU use with 4 MPI tasks x 1 OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 2.2127     | 2.2257     | 2.2399     |   0.8 | 90.59
+Neigh   | 0.095856   | 0.097842   | 0.10197    |   0.8 |  3.98
+Comm    | 0.03626    | 0.054908   | 0.069787   |   6.3 |  2.23
+Output  | 0.00088538 | 0.0011005  | 0.0017236  |   1.1 |  0.04
+Modify  | 0.072449   | 0.072553   | 0.072611   |   0.0 |  2.95
+Other   |            | 0.004684   |            |       |  0.19
+
+Nlocal:        8000.00 ave        8033 max        7977 min
+Histogram: 1 0 1 1 0 0 0 0 0 1
+Nghost:        12605.0 ave       12628 max       12572 min
+Histogram: 1 0 0 0 0 0 1 1 0 1
+Neighs:       703998.0 ave      706570 max      702282 min
+Histogram: 1 1 0 0 1 0 0 0 0 1
+
+Total # of neighbors = 2815992
+Ave neighs/atom = 87.999750
+Neighbor list builds = 5
+Dangerous builds = 3
+
+Please see the log.cite file for references relevant to this simulation
+
+Total wall time: 0:00:02

examples/USER/misc/electron_stopping/log.18Sep2020.cascade_SiSi.intel.1

@@ -0,0 +1,113 @@
+LAMMPS (18 Sep 2020)
+OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
+  using 1 OpenMP thread(s) per MPI task
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Si lattice with one primary knock-on atom (PKA) - single species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          diamond 5.431
+Lattice spacing in x,y,z = 5.4310000 5.4310000 5.4310000
+
+region           box block -10 10 -10 10 -10 10
+create_box       1 box
+Created orthogonal box = (-54.310000 -54.310000 -54.310000) to (54.310000 54.310000 54.310000)
+  1 by 1 by 1 MPI processor grid
+create_atoms     1 box
+Created 64000 atoms
+  create_atoms CPU = 0.008 seconds
+
+pair_style       tersoff/zbl
+pair_coeff       * * ../../../../potentials/SiC.tersoff.zbl Si
+Reading tersoff/zbl potential file ../../../../potentials/SiC.tersoff.zbl with DATE: 2009-04-15
+
+mass             1 28.0855
+
+velocity         all create 300 42534 mom yes rot yes
+
+group            pka id 1
+1 atoms in group pka
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100
+Neighbor list info ...
+  update every 1 steps, delay 10 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5
+  ghost atom cutoff = 5
+  binsize = 2.5, bins = 44 44 44
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair tersoff/zbl, perpetual
+      attributes: full, newton on
+      pair build: full/bin/atomonly
+      stencil: full/bin/3d
+      bin: standard
+Per MPI rank memory allocation (min/avg/max) = 23.91 | 23.91 | 23.91 Mbytes
+Step Dt Time Temp PotEng KinEng f_3 
+       0 2.4879625e-05            0    21258.724   -296293.96    175863.22            0 
+       5 9.2462185e-06 9.0354398e-05    21252.059   -296277.65    175808.08    38.834393 
+      10 6.1558479e-06 0.00013003059    21246.736   -296250.63    175764.05    55.881868 
+      15 4.9002335e-06 0.00015681379    21242.649   -296228.27    175730.24    67.386915 
+      20 5.853687e-06 0.00018286317    21239.571   -296213.99    175704.78    78.574676 
+      25 7.0182823e-06 0.00021483214    21237.286   -296208.81    175685.87    92.303028 
+      30 8.2570048e-06 0.00025083646    21236.034   -296213.99    175675.52    107.76296 
+      35 6.4734302e-06 0.00029194185    21233.473   -296210.33    175654.33    125.41212 
+      40 7.3445302e-06 0.00032561085    21231.196   -296205.94     175635.5    139.86641 
+      45 6.9480705e-06 0.00036268325     21230.21   -296213.68    175627.33    155.78046 
+      50 7.2224188e-06 0.00039655436    21230.512   -296230.74    175629.84    170.32001 
+      55 1.0773409e-05 0.00044221823    21230.023   -296246.37    175625.79    189.92217 
+      60 5.7527075e-06 0.00048339879    21226.064   -296231.33    175593.04     207.5982 
+      65 5.8568503e-06 0.0005110075    21222.544   -296213.97    175563.92    219.44643 
+      70 6.7430644e-06 0.00054252027    21220.179   -296207.92    175544.35    232.96808 
+      75 7.0523029e-06 0.00057648256    21219.781   -296219.19    175541.06    247.53974 
+      80 1.784394e-05 0.00062210154    21221.276   -296251.35    175553.43    267.11364 
+      85 2.1885193e-05 0.0007395532    21218.037   -296274.94    175526.64    317.50995 
+      90 8.233509e-06 0.00081518257    21211.247   -296251.53    175470.47    349.95382 
+      95 5.1490725e-06 0.00084789415     21205.33   -296216.55    175421.52      363.982 
+     100 5.7628664e-06 0.0008764946    21200.168   -296186.27    175378.81    376.24357 
+Loop time of 20.4868 on 1 procs for 100 steps with 64000 atoms
+
+Performance: 0.002 ns/day, 9874.909 hours/ns, 4.881 timesteps/s
+99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 19.397     | 19.397     | 19.397     |   0.0 | 94.68
+Neigh   | 0.45332    | 0.45332    | 0.45332    |   0.0 |  2.21
+Comm    | 0.035144   | 0.035144   | 0.035144   |   0.0 |  0.17
+Output  | 0.0040397  | 0.0040397  | 0.0040397  |   0.0 |  0.02
+Modify  | 0.5739     | 0.5739     | 0.5739     |   0.0 |  2.80
+Other   |            | 0.0229     |            |       |  0.11
+
+Nlocal:        64000.0 ave       64000 max       64000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:        18341.0 ave       18341 max       18341 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:        0.00000 ave           0 max           0 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+FullNghs:  1.79199e+06 ave 1.79199e+06 max 1.79199e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 1791990
+Ave neighs/atom = 27.999844
+Neighbor list builds = 7
+Dangerous builds = 2
+
+Please see the log.cite file for references relevant to this simulation
+
+Total wall time: 0:00:20

examples/USER/misc/electron_stopping/log.18Sep2020.cascade_SiSi.intel.4

@@ -0,0 +1,113 @@
+LAMMPS (18 Sep 2020)
+OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
+  using 1 OpenMP thread(s) per MPI task
+# ***
+# Example input for including electronic stopping effects using fix electron/stopping/fit
+# Si lattice with one primary knock-on atom (PKA) - single species simulation
+# ***
+
+units            metal
+boundary         p p p
+
+lattice          diamond 5.431
+Lattice spacing in x,y,z = 5.4310000 5.4310000 5.4310000
+
+region           box block -10 10 -10 10 -10 10
+create_box       1 box
+Created orthogonal box = (-54.310000 -54.310000 -54.310000) to (54.310000 54.310000 54.310000)
+  1 by 2 by 2 MPI processor grid
+create_atoms     1 box
+Created 64000 atoms
+  create_atoms CPU = 0.003 seconds
+
+pair_style       tersoff/zbl
+pair_coeff       * * ../../../../potentials/SiC.tersoff.zbl Si
+Reading tersoff/zbl potential file ../../../../potentials/SiC.tersoff.zbl with DATE: 2009-04-15
+
+mass             1 28.0855
+
+velocity         all create 300 42534 mom yes rot yes
+
+group            pka id 1
+1 atoms in group pka
+velocity         pka set 1120 1620 400
+
+fix              1 all nve
+fix              2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
+fix              3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
+
+thermo           5
+thermo_style     custom step dt time temp pe ke f_3
+thermo_modify    lost warn flush yes
+
+#dump             0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
+#dump_modify      0 first yes
+
+run              100
+Neighbor list info ...
+  update every 1 steps, delay 10 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5
+  ghost atom cutoff = 5
+  binsize = 2.5, bins = 44 44 44
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair tersoff/zbl, perpetual
+      attributes: full, newton on
+      pair build: full/bin/atomonly
+      stencil: full/bin/3d
+      bin: standard
+Per MPI rank memory allocation (min/avg/max) = 7.777 | 7.777 | 7.777 Mbytes
+Step Dt Time Temp PotEng KinEng f_3 
+       0 2.4879625e-05            0    21258.724   -296293.96    175863.22            0 
+       5 9.2462211e-06 9.0354422e-05    21252.059   -296277.66    175808.08    38.834403 
+      10 6.1568847e-06 0.00013003069    21246.736   -296250.63    175764.05    55.881913 
+      15 4.8997821e-06 0.00015681555    21242.649   -296228.27    175730.24    67.387669 
+      20 5.8536714e-06 0.00018286203    21239.571   -296213.99    175704.78    78.574187 
+      25 7.0160073e-06 0.00021483347    21237.285    -296208.8    175685.86    92.303599 
+      30 8.2556386e-06 0.00025082046    21236.035   -296213.99    175675.53    107.75609 
+      35 6.4735852e-06 0.00029193023    21233.474   -296210.34    175654.34    125.40713 
+      40 7.3441556e-06 0.00032559783    21231.197   -296205.94     175635.5    139.86082 
+      45 6.9483099e-06 0.00036267022     21230.21   -296213.68    175627.34    155.77487 
+      50 7.2213562e-06 0.0003965413    21230.513   -296230.74    175629.84    170.31441 
+      55 1.0776037e-05 0.00044219672    21230.024   -296246.38     175625.8    189.91293 
+      60 5.7538246e-06 0.0004833796    21226.067   -296231.34    175593.06    207.58996 
+      65 5.856213e-06 0.00051099409    21222.546   -296213.98    175563.94    219.44067 
+      70 6.7431217e-06 0.00054250526     21220.18   -296207.92    175544.37    232.96164 
+      75 7.0518411e-06 0.00057646788    21219.781   -296219.18    175541.07    247.53344 
+      80 1.7829072e-05 0.00062207162    21221.276   -296251.34    175553.43     267.1008 
+      85 2.1894958e-05 0.0007395084     21218.04   -296274.95    175526.66    317.49073 
+      90 8.2365472e-06 0.00081516502     21211.25   -296251.55    175470.49    349.94629 
+      95 5.1493496e-06 0.00084788428    21205.333   -296216.57    175421.54    363.97777 
+     100 5.7652664e-06 0.00087648406    21200.171    -296186.3    175378.84    376.23905 
+Loop time of 5.23182 on 4 procs for 100 steps with 64000 atoms
+
+Performance: 0.010 ns/day, 2520.759 hours/ns, 19.114 timesteps/s
+99.7% CPU use with 4 MPI tasks x 1 OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 4.8069     | 4.8618     | 4.9229     |   2.0 | 92.93
+Neigh   | 0.11442    | 0.11856    | 0.12948    |   1.8 |  2.27
+Comm    | 0.040943   | 0.098988   | 0.15807    |  14.7 |  1.89
+Output  | 0.0013075  | 0.0014801  | 0.0019936  |   0.8 |  0.03
+Modify  | 0.14496    | 0.14502    | 0.1451     |   0.0 |  2.77
+Other   |            | 0.005981   |            |       |  0.11
+
+Nlocal:        16000.0 ave       16017 max       15987 min
+Histogram: 1 0 1 0 0 1 0 0 0 1
+Nghost:        8044.00 ave        8058 max        8026 min
+Histogram: 1 0 0 0 1 0 0 0 1 1
+Neighs:        0.00000 ave           0 max           0 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+FullNghs:     447998.0 ave      448471 max      447634 min
+Histogram: 1 0 1 0 0 1 0 0 0 1
+
+Total # of neighbors = 1791990
+Ave neighs/atom = 27.999844
+Neighbor list builds = 7
+Dangerous builds = 2
+
+Please see the log.cite file for references relevant to this simulation
+
+Total wall time: 0:00:05

examples/USER/reaction/nylon,6-6_melt/rxn1_stp1_map

@@ -3,7 +3,7 @@ this is a nominal superimpose file
 2 edgeIDs
 18 equivalences
 
-BondingIDs
+InitiatorIDs
 
 10
 1

examples/USER/reaction/nylon,6-6_melt/rxn1_stp2_map

@@ -3,7 +3,7 @@ this is a nominal superimpose file
 2 edgeIDs
 15 equivalences
 
-BondingIDs
+InitiatorIDs
 
 4
 12

examples/USER/reaction/tiny_epoxy/rxn1_stp1.map

@@ -3,7 +3,7 @@ this is a map file
 1 edgeIDs
 31 equivalences
 
-BondingIDs
+InitiatorIDs
 
 15
 1

examples/USER/reaction/tiny_epoxy/rxn1_stp2.map

@@ -3,7 +3,7 @@ this is a map file
 1 edgeIDs
 31 equivalences
 
-BondingIDs
+InitiatorIDs
 
 4
 25

examples/USER/reaction/tiny_epoxy/rxn2_stp1.map

@@ -3,7 +3,7 @@ this is a map file
 2 edgeIDs
 42 equivalences
 
-BondingIDs
+InitiatorIDs
 
 15
 32

examples/USER/reaction/tiny_epoxy/rxn2_stp2.map

@@ -3,7 +3,7 @@ this is a map file
 2 edgeIDs
 42 equivalences
 
-BondingIDs
+InitiatorIDs
 
 35
 24

examples/USER/reaction/tiny_nylon/rxn1_stp1_map

@@ -3,7 +3,7 @@ this is a nominal superimpose file
 2 edgeIDs
 18 equivalences
 
-BondingIDs
+InitiatorIDs
 
 10
 1

examples/USER/reaction/tiny_nylon/rxn1_stp2_map

@@ -3,7 +3,7 @@ this is a nominal superimpose file
 2 edgeIDs
 15 equivalences
 
-BondingIDs
+InitiatorIDs
 
 4
 12

examples/USER/reaction/tiny_polystyrene/2styrene_map

@@ -3,7 +3,7 @@ this is a map file
 0 edgeIDs
 32 equivalences
 
-BondingIDs
+InitiatorIDs
 
 4
 30

examples/USER/reaction/tiny_polystyrene/chain_chain_map

@@ -8,7 +8,7 @@ EdgeIDs
 17
 34
 
-BondingIDs
+InitiatorIDs
 
 14
 38

examples/USER/reaction/tiny_polystyrene/chain_plus_styrene_map

@@ -7,7 +7,7 @@ EdgeIDs
 
 30
 
-BondingIDs
+InitiatorIDs
 
 14
 34

examples/granular/in.pour.drum

@@ -2,99 +2,98 @@
 # 'turn' cylinder by changing direction of gravity, then rotate it.
 # This simulates a rotating drum powder characterization experiment.
 
-variable	name string rotating_drum_two_types
+variable        name string rotating_drum_two_types
 
-atom_style	sphere
-units		lj
+atom_style      sphere
+units           lj
 
 ###############################################
 # Geometry-related parameters
 ###############################################
 
-variable	boxx equal 30
-variable	boxy equal 30
-variable	boxz equal 50
+variable        boxx equal 30
+variable        boxy equal 30
+variable        boxz equal 50
 
-variable	drum_rad equal ${boxx}*0.5
-variable	drum_height equal 20
+variable        drum_rad equal ${boxx}*0.5
+variable        drum_height equal 20
 
-variable	xc equal 0.5*${boxx}
-variable	yc equal 0.5*${boxx}
-variable	zc equal 0.5*${boxz}
+variable        xc equal 0.5*${boxx}
+variable        yc equal 0.5*${boxx}
+variable        zc equal 0.5*${boxz}
 
 ###############################################
 # Particle-related parameters
 ###############################################
-variable	rlo equal 0.25
-variable	rhi equal 0.5
-variable	dlo equal 2.0*${rlo}
-variable	dhi equal 2.0*${rhi}
+variable        rlo equal 0.25
+variable        rhi equal 0.5
+variable        dlo equal 2.0*${rlo}
+variable        dhi equal 2.0*${rhi}
 
-variable	cyl_rad_inner equal ${drum_rad}-1.1*${rhi}
+variable        cyl_rad_inner equal ${drum_rad}-1.1*${rhi}
 
-variable	dens equal 1.0
+variable        dens equal 1.0
 
 variable skin equal 0.4*${rhi}
 
 #############
 processors * * 1
-region		boxreg block 0 ${boxx} 0 ${boxy} 0 ${boxz}
-create_box	2 boxreg
-change_box	all boundary p p f
-comm_modify	vel yes
+region          boxreg block 0 ${boxx} 0 ${boxy} 0 ${boxz}
+create_box      2 boxreg
+change_box      all boundary p p f
 
-variable	theta equal 0
+pair_style      granular
+pair_coeff      1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
+pair_coeff      2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
 
-region		curved_wall cylinder z ${xc} ${yc} ${drum_rad} 0 ${drum_height} side in rotate v_theta ${xc} ${yc} 0 0 0 1
-region		bottom_wall plane ${xc} ${yc} 0 0 0 1 side in rotate v_theta ${xc} ${yc} 0 0 0 1
+variable        theta equal 0
 
-region		insreg cylinder z ${xc} ${yc} ${cyl_rad_inner} ${drum_height} ${boxz}
+region          curved_wall cylinder z ${xc} ${yc} ${drum_rad} 0 ${drum_height} side in rotate v_theta ${xc} ${yc} 0 0 0 1
+region          bottom_wall plane ${xc} ${yc} 0 0 0 1 side in rotate v_theta ${xc} ${yc} 0 0 0 1
 
-fix		0 all balance 100 1.0 shift xy 5 1.1
-fix		1 all nve/sphere
-fix		grav all gravity 10 vector 0 0 -1
-fix		ins1 all pour 2000 1 1234 region insreg diam range ${dlo} ${dhi} dens ${dens} ${dens}
-fix		ins2 all pour 2000 2 1234 region insreg diam range ${dlo} ${dhi} dens ${dens} ${dens}
+region          insreg cylinder z ${xc} ${yc} ${cyl_rad_inner} ${drum_height} ${boxz}
 
-comm_modify	vel yes
+fix             0 all balance 100 1.0 shift xy 5 1.1
+fix             1 all nve/sphere
+fix             grav all gravity 10 vector 0 0 -1
+fix             ins1 all pour 2000 1 1234 region insreg diam range ${dlo} ${dhi} dens ${dens} ${dens}
+fix             ins2 all pour 2000 2 1234 region insreg diam range ${dlo} ${dhi} dens ${dens} ${dens}
 
-neighbor	${skin} bin
-neigh_modify	delay 0 every 1 check yes
+comm_modify     vel yes
 
-pair_style	granular 
-pair_coeff	1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
-pair_coeff	2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
+neighbor        ${skin} bin
+neigh_modify    delay 0 every 1 check yes
 
-fix		3 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region curved_wall 
-fix		4 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region bottom_wall
+fix             3 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region curved_wall
+fix             4 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region bottom_wall
 
-thermo_style	custom step atoms ke v_theta
-thermo_modify	lost warn
-thermo		100
+thermo_style    custom step atoms ke v_theta
+thermo_modify   lost warn
+thermo          100
 
-timestep	0.001
+timestep        0.001
 
-#dump		1 all custom 100 ${name}.dump id type radius mass x y z 
+#dump           1 all custom 100 ${name}.dump id type radius mass x y z
 
 #For removal later
-compute		1 all property/atom radius
-variable	zmax atom z+c_1>0.5*${drum_height}
-group		delgroup dynamic all var zmax every 10000
+compute         1 all property/atom radius
+variable        zmax atom z+c_1>0.5*${drum_height}
+group           delgroup dynamic all var zmax every 10000
 
-run		2000
+run             2000
 
 #Remove any particles that are above z > 0.5*drum_height
-delete_atoms	group delgroup
+delete_atoms    group delgroup
 
 #Add top lid
-region		top_wall plane ${xc} ${yc} ${drum_height} 0 0 -1 side in rotate v_theta ${xc} ${yc} 0 0 0 1
-fix		5 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region top_wall
+region          top_wall plane ${xc} ${yc} ${drum_height} 0 0 -1 side in rotate v_theta ${xc} ${yc} 0 0 0 1
+fix             5 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region top_wall
 
 # 'Turn' drum by switching the direction of gravity
-unfix		grav
-unfix		ins1
-unfix		ins2
-fix		grav all gravity 10 vector 0 -1 0
+unfix           grav
+unfix           ins1
+unfix           ins2
+fix             grav all gravity 10 vector 0 -1 0
 
-variable	theta equal 2*PI*elapsed/20000.0
-run		3000
+variable        theta equal 2*PI*elapsed/20000.0
+run             3000

examples/granular/in.pour.flatwall

@@ -1,67 +1,65 @@
 # pour two types of particles (cohesive and non-cohesive) on flat wall
 
-variable   	name string pour_two_types
+variable        name string pour_two_types
 
-atom_style	sphere
-units		lj
+atom_style      sphere
+units           lj
 
 ###############################################
 # Geometry-related parameters
 ###############################################
 
-variable	boxx equal 20
-variable	boxy equal 20
-variable	boxz equal 30
+variable        boxx equal 20
+variable        boxy equal 20
+variable        boxz equal 30
 
-variable	xc1 equal 0.3*${boxx}
-variable	xc2 equal 0.7*${boxx}
-variable	yc equal 0.5*${boxy}
+variable        xc1 equal 0.3*${boxx}
+variable        xc2 equal 0.7*${boxx}
+variable        yc equal 0.5*${boxy}
 
 ###############################################
 # Particle-related parameters
 ###############################################
-variable	rlo equal 0.25
-variable	rhi equal 0.5
-variable	dlo equal 2.0*${rlo}
-variable	dhi equal 2.0*${rhi}
+variable        rlo equal 0.25
+variable        rhi equal 0.5
+variable        dlo equal 2.0*${rlo}
+variable        dhi equal 2.0*${rhi}
 
-variable	dens equal 1.0
+variable        dens equal 1.0
 
 variable skin equal 0.3*${rhi}
 
 #############
-processors	* * 1
-region 		boxreg block 0 ${boxx} 0 ${boxy} 0 ${boxz}
-create_box	2 boxreg
-change_box	all boundary p p f
+processors      * * 1
+region          boxreg block 0 ${boxx} 0 ${boxy} 0 ${boxz}
+create_box      2 boxreg
+change_box      all boundary p p f
 
-comm_modify 	vel yes
+pair_style      granular
+pair_coeff      1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
+pair_coeff      2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall
 
-region		insreg1 cylinder z ${xc1} ${yc} 5 15 ${boxz}
-region		insreg2 cylinder z ${xc2} ${yc} 5 15 ${boxz}
+comm_modify     vel yes
 
-fix		1 all nve/sphere
-fix		grav all gravity 10.0 vector 0 0 -1
-fix		ins1 all pour 1500 1 3123 region insreg1 diam range ${dlo} ${dhi} dens ${dens} ${dens}
-fix		ins2 all pour 1500 2 3123 region insreg2 diam range ${dlo} ${dhi} dens ${dens} ${dens}
+region          insreg1 cylinder z ${xc1} ${yc} 5 15 ${boxz}
+region          insreg2 cylinder z ${xc2} ${yc} 5 15 ${boxz}
 
-comm_modify	vel yes
+fix             1 all nve/sphere
+fix             grav all gravity 10.0 vector 0 0 -1
+fix             ins1 all pour 1500 1 3123 region insreg1 diam range ${dlo} ${dhi} dens ${dens} ${dens}
+fix             ins2 all pour 1500 2 3123 region insreg2 diam range ${dlo} ${dhi} dens ${dens} ${dens}
 
-neighbor	${skin} bin
-neigh_modify	delay 0 every 1 check yes
+neighbor        ${skin} bin
+neigh_modify    delay 0 every 1 check yes
 
-pair_style	granular 
-pair_coeff 	1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
-pair_coeff 	2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall 
+fix             3 all wall/gran granular hertz/material 1e5 1e3 0.3 tangential mindlin NULL 1.0 0.5 zplane 0 NULL
 
-fix		3 all wall/gran granular hertz/material 1e5 1e3 0.3 tangential mindlin NULL 1.0 0.5 zplane 0 NULL 
+thermo_style    custom step atoms ke
+thermo_modify   lost warn
+thermo          100
 
-thermo_style	custom step cpu atoms ke
-thermo_modify	lost warn
-thermo		100
+timestep        0.001
 
-timestep	0.001
+#dump           1 all custom 100 ${name}.dump id type radius mass x y z
 
-#dump		1 all custom 100 ${name}.dump id type radius mass x y z 
-
-run		5000
+run             5000

examples/granular/log.29Oct20.pour.drum.g++.1

@@ -1,5 +1,4 @@
-LAMMPS (29 Mar 2019)
-OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:88)
+LAMMPS (29 Oct 2020)
   using 1 OpenMP thread(s) per MPI task
 # pour two types of particles (cohesive and non-cohesive) into cylinder
 # 'turn' cylinder by changing direction of gravity, then rotate it.
@@ -55,10 +54,14 @@ region		boxreg block 0 30 0 ${boxy} 0 ${boxz}
 region		boxreg block 0 30 0 30 0 ${boxz}
 region		boxreg block 0 30 0 30 0 50
 create_box	2 boxreg
-Created orthogonal box = (0 0 0) to (30 30 50)
+Created orthogonal box = (0.0000000 0.0000000 0.0000000) to (30.000000 30.000000 50.000000)
   1 by 1 by 1 MPI processor grid
 change_box	all boundary p p f
-comm_modify	vel yes
+Changing box ...
+
+pair_style	granular
+pair_coeff	1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
+pair_coeff	2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
 
 variable	theta equal 0
 
@@ -104,10 +107,6 @@ neighbor	${skin} bin
 neighbor	0.2 bin
 neigh_modify	delay 0 every 1 check yes
 
-pair_style	granular
-pair_coeff	1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
-pair_coeff	2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
-
 fix		3 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region curved_wall
 fix		4 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region bottom_wall
 
@@ -117,8 +116,7 @@ thermo		100
 
 timestep	0.001
 
-dump		1 all custom 100 ${name}.dump id type radius mass x y z
-dump		1 all custom 100 rotating_drum_two_types.dump id type radius mass x y z
+#dump		1 all custom 100 ${name}.dump id type radius mass x y z
 
 #For removal later
 compute		1 all property/atom radius
@@ -140,7 +138,7 @@ Neighbor list info ...
       pair build: half/size/bin/newton
       stencil: half/bin/3d/newton
       bin: standard
-Per MPI rank memory allocation (min/avg/max) = 13.02 | 13.02 | 13.02 Mbytes
+Per MPI rank memory allocation (min/avg/max) = 13.03 | 13.03 | 13.03 Mbytes
 Step Atoms KinEng v_theta 
        0        0           -0            0 
      100     4000           -0            0 
@@ -163,32 +161,32 @@ Step Atoms KinEng v_theta
     1800     4000           -0            0 
     1900     4000           -0            0 
     2000     4000           -0            0 
-Loop time of 3.54461 on 1 procs for 2000 steps with 4000 atoms
+Loop time of 10.5178 on 1 procs for 2000 steps with 4000 atoms
 
-Performance: 48750.057 tau/day, 564.237 timesteps/s
-99.5% CPU use with 1 MPI tasks x 1 OpenMP threads
+Performance: 16429.309 tau/day, 190.154 timesteps/s
+99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.61949    | 0.61949    | 0.61949    |   0.0 | 17.48
-Neigh   | 1.2492     | 1.2492     | 1.2492     |   0.0 | 35.24
-Comm    | 0.046404   | 0.046404   | 0.046404   |   0.0 |  1.31
-Output  | 0.15901    | 0.15901    | 0.15901    |   0.0 |  4.49
-Modify  | 1.4165     | 1.4165     | 1.4165     |   0.0 | 39.96
-Other   |            | 0.05391    |            |       |  1.52
+Pair    | 1.0701     | 1.0701     | 1.0701     |   0.0 | 10.17
+Neigh   | 4.2135     | 4.2135     | 4.2135     |   0.0 | 40.06
+Comm    | 0.38276    | 0.38276    | 0.38276    |   0.0 |  3.64
+Output  | 0.0013647  | 0.0013647  | 0.0013647  |   0.0 |  0.01
+Modify  | 4.7076     | 4.7076     | 4.7076     |   0.0 | 44.76
+Other   |            | 0.1424     |            |       |  1.35
 
-Nlocal:    4000 ave 4000 max 4000 min
+Nlocal:        4000.00 ave        4000 max        4000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    166 ave 166 max 166 min
+Nghost:        171.000 ave         171 max         171 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    8195 ave 8195 max 8195 min
+Neighs:        8093.00 ave        8093 max        8093 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
 
-Total # of neighbors = 8195
-Ave neighs/atom = 2.04875
+Total # of neighbors = 8093
+Ave neighs/atom = 2.0232500
 Neighbor list builds = 1004
-Dangerous builds = 3
+Dangerous builds = 4
 
 #Remove any particles that are above z > 0.5*drum_height
 delete_atoms	group delgroup
@@ -205,67 +203,69 @@ fix		5 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindl
 
 # 'Turn' drum by switching the direction of gravity
 unfix		grav
+unfix		ins1
+unfix		ins2
 fix		grav all gravity 10 vector 0 -1 0
 
 variable	theta equal 2*PI*elapsed/20000.0
 run		3000
-Per MPI rank memory allocation (min/avg/max) = 24.81 | 24.81 | 24.81 Mbytes
+Per MPI rank memory allocation (min/avg/max) = 19.37 | 19.37 | 19.37 Mbytes
 Step Atoms KinEng v_theta 
-    2000     4000    64.333531            0 
-    2100     4000    106.69182  0.031415927 
-    2200     4000     121.8461  0.062831853 
-    2300     4000    88.767952   0.09424778 
-    2400     4000    82.850721   0.12566371 
-    2500     4000    91.683284   0.15707963 
-    2600     4000     31.56344   0.18849556 
-    2700     4000    4.5697672   0.21991149 
-    2800     4000    3.9879051   0.25132741 
-    2900     4000    4.4394235   0.28274334 
-    3000     4000    5.1212931   0.31415927 
-    3100     4000    5.8608892   0.34557519 
-    3200     4000     6.600714   0.37699112 
-    3300     4000    7.3497851   0.40840704 
-    3400     4000    8.0490988   0.43982297 
-    3500     4000    8.6712396    0.4712389 
-    3600     4000    9.1328667   0.50265482 
-    3700     4000    9.4683561   0.53407075 
-    3800     4000    9.5878145   0.56548668 
-    3900     4000     9.387745    0.5969026 
-    4000     4000    8.9117631   0.62831853 
-    4100     4000    8.2344368   0.65973446 
-    4200     4000    7.5335088   0.69115038 
-    4300     4000    6.8426179   0.72256631 
-    4400     4000    6.0567247   0.75398224 
-    4500     4000    5.4166132   0.78539816 
-    4600     4000    4.6012409   0.81681409 
-    4700     4000    3.8314982   0.84823002 
-    4800     4000    3.1916415   0.87964594 
-    4900     4000    2.7833964   0.91106187 
-    5000     4000    2.5051362    0.9424778 
-Loop time of 11.9545 on 1 procs for 3000 steps with 4000 atoms
+    2000     4000    65.647582            0 
+    2100     4000    105.60001  0.031415927 
+    2200     4000    112.27573  0.062831853 
+    2300     4000    92.758671   0.09424778 
+    2400     4000    88.925835   0.12566371 
+    2500     4000    81.369163   0.15707963 
+    2600     4000    32.046943   0.18849556 
+    2700     4000    4.1926368   0.21991149 
+    2800     4000    3.9933453   0.25132741 
+    2900     4000    4.5062193   0.28274334 
+    3000     4000    5.3409521   0.31415927 
+    3100     4000    6.0165991   0.34557519 
+    3200     4000     6.606767   0.37699112 
+    3300     4000    7.3997751   0.40840704 
+    3400     4000    8.1098807   0.43982297 
+    3500     4000    8.6552424    0.4712389 
+    3600     4000    9.8445204   0.50265482 
+    3700     4000    10.098753   0.53407075 
+    3800     4000    10.039489   0.56548668 
+    3900     4000    9.6376278    0.5969026 
+    4000     4000    9.2598836   0.62831853 
+    4100     4000    8.7116037   0.65973446 
+    4200     4000    8.1274117   0.69115038 
+    4300     4000    7.1487627   0.72256631 
+    4400     4000    6.2253778   0.75398224 
+    4500     4000    5.3061398   0.78539816 
+    4600     4000    4.4319316   0.81681409 
+    4700     4000     4.205607   0.84823002 
+    4800     4000    3.2112987   0.87964594 
+    4900     4000    2.6449777   0.91106187 
+    5000     4000    2.3475497    0.9424778 
+Loop time of 32.4926 on 1 procs for 3000 steps with 4000 atoms
 
-Performance: 21682.142 tau/day, 250.951 timesteps/s
-99.7% CPU use with 1 MPI tasks x 1 OpenMP threads
+Performance: 7977.205 tau/day, 92.329 timesteps/s
+99.9% CPU use with 1 MPI tasks x 1 OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 4.8291     | 4.8291     | 4.8291     |   0.0 | 40.40
-Neigh   | 2.7489     | 2.7489     | 2.7489     |   0.0 | 22.99
-Comm    | 0.071249   | 0.071249   | 0.071249   |   0.0 |  0.60
-Output  | 0.20547    | 0.20547    | 0.20547    |   0.0 |  1.72
-Modify  | 4.0179     | 4.0179     | 4.0179     |   0.0 | 33.61
-Other   |            | 0.0819     |            |       |  0.69
+Pair    | 8.0124     | 8.0124     | 8.0124     |   0.0 | 24.66
+Neigh   | 10.993     | 10.993     | 10.993     |   0.0 | 33.83
+Comm    | 0.86697    | 0.86697    | 0.86697    |   0.0 |  2.67
+Output  | 0.0021827  | 0.0021827  | 0.0021827  |   0.0 |  0.01
+Modify  | 12.367     | 12.367     | 12.367     |   0.0 | 38.06
+Other   |            | 0.2515     |            |       |  0.77
 
-Nlocal:    4000 ave 4000 max 4000 min
+Nlocal:        4000.00 ave        4000 max        4000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    322 ave 322 max 322 min
+Nghost:        318.000 ave         318 max         318 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    14849 ave 14849 max 14849 min
+Neighs:        14807.0 ave       14807 max       14807 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
 
-Total # of neighbors = 14849
-Ave neighs/atom = 3.71225
-Neighbor list builds = 1290
-Dangerous builds = 672
-Total wall time: 0:00:15
+Total # of neighbors = 14807
+Ave neighs/atom = 3.7017500
+Neighbor list builds = 2189
+Dangerous builds = 1536
+Total wall time: 0:00:43

examples/granular/log.29Oct20.pour.drum.g++.4

@@ -1,5 +1,4 @@
-LAMMPS (29 Mar 2019)
-OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:88)
+LAMMPS (29 Oct 2020)
   using 1 OpenMP thread(s) per MPI task
 # pour two types of particles (cohesive and non-cohesive) into cylinder
 # 'turn' cylinder by changing direction of gravity, then rotate it.
@@ -55,10 +54,14 @@ region		boxreg block 0 30 0 ${boxy} 0 ${boxz}
 region		boxreg block 0 30 0 30 0 ${boxz}
 region		boxreg block 0 30 0 30 0 50
 create_box	2 boxreg
-Created orthogonal box = (0 0 0) to (30 30 50)
+Created orthogonal box = (0.0000000 0.0000000 0.0000000) to (30.000000 30.000000 50.000000)
   2 by 2 by 1 MPI processor grid
 change_box	all boundary p p f
-comm_modify	vel yes
+Changing box ...
+
+pair_style	granular
+pair_coeff	1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
+pair_coeff	2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
 
 variable	theta equal 0
 
@@ -104,10 +107,6 @@ neighbor	${skin} bin
 neighbor	0.2 bin
 neigh_modify	delay 0 every 1 check yes
 
-pair_style	granular
-pair_coeff	1 * hertz/material 1e5 0.2 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji
-pair_coeff	2 2 jkr 1e5 0.1 0.3 50 tangential mindlin NULL 1.0 0.5 rolling sds 1e3 1e3 0.1 twisting marshall damping tsuji
-
 fix		3 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region curved_wall
 fix		4 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindlin NULL 1.0 0.5 damping tsuji region bottom_wall
 
@@ -117,8 +116,7 @@ thermo		100
 
 timestep	0.001
 
-dump		1 all custom 100 ${name}.dump id type radius mass x y z
-dump		1 all custom 100 rotating_drum_two_types.dump id type radius mass x y z
+#dump		1 all custom 100 ${name}.dump id type radius mass x y z
 
 #For removal later
 compute		1 all property/atom radius
@@ -163,32 +161,32 @@ Step Atoms KinEng v_theta
     1800     4000           -0            0 
     1900     4000           -0            0 
     2000     4000           -0            0 
-Loop time of 2.0709 on 4 procs for 2000 steps with 4000 atoms
+Loop time of 3.86825 on 4 procs for 2000 steps with 4000 atoms
 
-Performance: 83442.024 tau/day, 965.764 timesteps/s
-97.7% CPU use with 4 MPI tasks x 1 OpenMP threads
+Performance: 44671.398 tau/day, 517.030 timesteps/s
+96.7% CPU use with 4 MPI tasks x 1 OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.24679    | 0.26336    | 0.28853    |   3.0 | 12.72
-Neigh   | 0.52279    | 0.5332     | 0.53858    |   0.9 | 25.75
-Comm    | 0.17418    | 0.20253    | 0.23266    |   4.7 |  9.78
-Output  | 0.092897   | 0.093531   | 0.09515    |   0.3 |  4.52
-Modify  | 0.88151    | 0.89571    | 0.90582    |   0.9 | 43.25
-Other   |            | 0.08257    |            |       |  3.99
+Pair    | 0.26114    | 0.27918    | 0.28728    |   2.0 |  7.22
+Neigh   | 1.2044     | 1.2414     | 1.3105     |   3.7 | 32.09
+Comm    | 0.38592    | 0.47065    | 0.51052    |   7.4 | 12.17
+Output  | 0.0007236  | 0.0013456  | 0.0024846  |   1.8 |  0.03
+Modify  | 1.6217     | 1.6723     | 1.7801     |   5.0 | 43.23
+Other   |            | 0.2034     |            |       |  5.26
 
-Nlocal:    1000 ave 1001 max 999 min
+Nlocal:        1000.00 ave        1012 max         988 min
 Histogram: 2 0 0 0 0 0 0 0 0 2
-Nghost:    267.75 ave 276 max 262 min
-Histogram: 1 0 1 0 1 0 0 0 0 1
-Neighs:    2031.5 ave 2091 max 1958 min
-Histogram: 1 0 0 0 1 0 0 1 0 1
+Nghost:        269.250 ave         278 max         256 min
+Histogram: 1 0 0 0 0 0 1 1 0 1
+Neighs:        2060.50 ave        2156 max        1921 min
+Histogram: 1 0 0 1 0 0 0 0 0 2
 
-Total # of neighbors = 8126
-Ave neighs/atom = 2.0315
+Total # of neighbors = 8242
+Ave neighs/atom = 2.0605000
 Neighbor list builds = 1004
-Dangerous builds = 3
+Dangerous builds = 4
 
 #Remove any particles that are above z > 0.5*drum_height
 delete_atoms	group delgroup
@@ -205,67 +203,69 @@ fix		5 all wall/gran/region granular hertz/material 1e5 0.1 0.3 tangential mindl
 
 # 'Turn' drum by switching the direction of gravity
 unfix		grav
+unfix		ins1
+unfix		ins2
 fix		grav all gravity 10 vector 0 -1 0
 
 variable	theta equal 2*PI*elapsed/20000.0
 run		3000
-Per MPI rank memory allocation (min/avg/max) = 21.6 | 22.6 | 23.82 Mbytes
+Per MPI rank memory allocation (min/avg/max) = 18.55 | 18.55 | 18.55 Mbytes
 Step Atoms KinEng v_theta 
-    2000     4000    64.255821            0 
-    2100     4000    106.47082  0.031415927 
-    2200     4000    121.52634  0.062831853 
-    2300     4000    87.748818   0.09424778 
-    2400     4000    82.712784   0.12566371 
-    2500     4000    90.618713   0.15707963 
-    2600     4000    30.096031   0.18849556 
-    2700     4000    4.0838611   0.21991149 
-    2800     4000    3.7485959   0.25132741 
-    2900     4000    4.2159774   0.28274334 
-    3000     4000    4.8730048   0.31415927 
-    3100     4000    5.6109465   0.34557519 
-    3200     4000    6.4290528   0.37699112 
-    3300     4000    7.2699677   0.40840704 
-    3400     4000    8.0895944   0.43982297 
-    3500     4000    8.7222781    0.4712389 
-    3600     4000     9.133205   0.50265482 
-    3700     4000    9.3404584   0.53407075 
-    3800     4000    9.3359844   0.56548668 
-    3900     4000    9.0916854    0.5969026 
-    4000     4000    8.5596424   0.62831853 
-    4100     4000    7.9734883   0.65973446 
-    4200     4000    7.2154383   0.69115038 
-    4300     4000    6.7039232   0.72256631 
-    4400     4000    6.1542738   0.75398224 
-    4500     4000    5.4049454   0.78539816 
-    4600     4000    4.4603192   0.81681409 
-    4700     4000    3.6197985   0.84823002 
-    4800     4000    2.9895571   0.87964594 
-    4900     4000    2.5314553   0.91106187 
-    5000     4000    2.2645533    0.9424778 
-Loop time of 6.64209 on 4 procs for 3000 steps with 4000 atoms
+    2000     4000    65.819213            0 
+    2100     4000    105.02389  0.031415927 
+    2200     4000    112.02469  0.062831853 
+    2300     4000    92.271262   0.09424778 
+    2400     4000    89.369506   0.12566371 
+    2500     4000    80.910925   0.15707963 
+    2600     4000    31.620722   0.18849556 
+    2700     4000    4.3019937   0.21991149 
+    2800     4000    3.9913967   0.25132741 
+    2900     4000    4.5203726   0.28274334 
+    3000     4000     5.484886   0.31415927 
+    3100     4000    6.1085958   0.34557519 
+    3200     4000    6.7085635   0.37699112 
+    3300     4000    7.4787777   0.40840704 
+    3400     4000    8.2116413   0.43982297 
+    3500     4000    8.7979302    0.4712389 
+    3600     4000     9.871649   0.50265482 
+    3700     4000    10.012426   0.53407075 
+    3800     4000    9.9067754   0.56548668 
+    3900     4000     9.725458    0.5969026 
+    4000     4000    9.3350056   0.62831853 
+    4100     4000    8.8337295   0.65973446 
+    4200     4000    8.2712493   0.69115038 
+    4300     4000    6.9609934   0.72256631 
+    4400     4000    6.0120294   0.75398224 
+    4500     4000    5.0490036   0.78539816 
+    4600     4000    4.2796544   0.81681409 
+    4700     4000    4.1736483   0.84823002 
+    4800     4000    3.0860106   0.87964594 
+    4900     4000    2.6670909   0.91106187 
+    5000     4000    2.2901814    0.9424778 
+Loop time of 10.7627 on 4 procs for 3000 steps with 4000 atoms
 
-Performance: 39023.861 tau/day, 451.665 timesteps/s
-96.6% CPU use with 4 MPI tasks x 1 OpenMP threads
+Performance: 24083.252 tau/day, 278.741 timesteps/s
+97.9% CPU use with 4 MPI tasks x 1 OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 1.8376     | 2.126      | 2.3131     |  12.6 | 32.01
-Neigh   | 0.97762    | 1.0518     | 1.1337     |   5.4 | 15.84
-Comm    | 0.53699    | 0.84265    | 1.2325     |  27.6 | 12.69
-Output  | 0.13922    | 0.14159    | 0.14388    |   0.4 |  2.13
-Modify  | 1.8815     | 2.1026     | 2.3368     |  11.2 | 31.66
-Other   |            | 0.3774     |            |       |  5.68
+Pair    | 1.6731     | 2.0701     | 2.3327     |  18.9 | 19.23
+Neigh   | 2.7389     | 3.1706     | 3.5146     |  15.7 | 29.46
+Comm    | 0.93507    | 1.5441     | 2.1182     |  39.1 | 14.35
+Output  | 0.0021682  | 0.0044412  | 0.006026   |   2.2 |  0.04
+Modify  | 3.0031     | 3.4223     | 3.9262     |  18.3 | 31.80
+Other   |            | 0.5511     |            |       |  5.12
 
-Nlocal:    1000 ave 1256 max 744 min
+Nlocal:        1000.00 ave        1277 max         723 min
 Histogram: 2 0 0 0 0 0 0 0 0 2
-Nghost:    579.5 ave 789 max 498 min
-Histogram: 2 1 0 0 0 0 0 0 0 1
-Neighs:    3696.25 ave 4853 max 2590 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
+Nghost:        569.750 ave         809 max         454 min
+Histogram: 1 2 0 0 0 0 0 0 0 1
+Neighs:        3690.50 ave        4937 max        2426 min
+Histogram: 1 1 0 0 0 0 0 0 0 2
 
-Total # of neighbors = 14785
-Ave neighs/atom = 3.69625
-Neighbor list builds = 1230
-Dangerous builds = 676
-Total wall time: 0:00:08
+Total # of neighbors = 14762
+Ave neighs/atom = 3.6905000
+Neighbor list builds = 2187
+Dangerous builds = 1610
+Total wall time: 0:00:14

examples/granular/log.29Oct20.pour.flatwall.g++.1

@@ -1,5 +1,4 @@
-LAMMPS (29 Mar 2019)
-OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:88)
+LAMMPS (29 Oct 2020)
   using 1 OpenMP thread(s) per MPI task
 # pour two types of particles (cohesive and non-cohesive) on flat wall
 
@@ -45,9 +44,14 @@ region 		boxreg block 0 20 0 ${boxy} 0 ${boxz}
 region 		boxreg block 0 20 0 20 0 ${boxz}
 region 		boxreg block 0 20 0 20 0 30
 create_box	2 boxreg
-Created orthogonal box = (0 0 0) to (20 20 30)
+Created orthogonal box = (0.0000000 0.0000000 0.0000000) to (20.000000 20.000000 30.000000)
   1 by 1 by 1 MPI processor grid
 change_box	all boundary p p f
+Changing box ...
+
+pair_style	granular
+pair_coeff 	1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
+pair_coeff 	2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall
 
 comm_modify 	vel yes
 
@@ -75,19 +79,13 @@ fix		ins2 all pour 1500 2 3123 region insreg2 diam range 0.5 1 dens 1 ${dens}
 fix		ins2 all pour 1500 2 3123 region insreg2 diam range 0.5 1 dens 1 1
 Particle insertion: 562 every 346 steps, 1500 by step 693
 
-comm_modify	vel yes
-
 neighbor	${skin} bin
 neighbor	0.15 bin
 neigh_modify	delay 0 every 1 check yes
 
-pair_style	granular
-pair_coeff 	1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
-pair_coeff 	2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall
-
 fix		3 all wall/gran granular hertz/material 1e5 1e3 0.3 tangential mindlin NULL 1.0 0.5 zplane 0 NULL
 
-thermo_style	custom step cpu atoms ke
+thermo_style	custom step atoms ke
 thermo_modify	lost warn
 thermo		100
 
@@ -109,26 +107,82 @@ Neighbor list info ...
       stencil: half/bin/3d/newton
       bin: standard
 Per MPI rank memory allocation (min/avg/max) = 12.22 | 12.22 | 12.22 Mbytes
-Step CPU Atoms KinEng 
-       0            0        0           -0 
-     100    3.8153191      855           -0 
-     200     4.195287      855           -0 
-     300    4.5890362      855           -0 
-     400    10.636087     1500           -0 
-     500    11.306909     1500           -0 
-     600    11.968198     1500           -0 
-     700    22.631892     2288           -0 
-     800    23.711387     2288           -0 
-     900    24.754344     2288           -0 
-    1000    25.811778     2288           -0 
-    1100    35.368869     2845           -0 
-    1200    37.149843     2845           -0 
-    1300    39.026458     2845           -0 
-    1400    41.757583     3000           -0 
-    1500    45.155503     3000           -0 
-    1600    48.570241     3000           -0 
-    1700    52.839322     3000           -0 
-    1800    59.772697     3000           -0 
-    1900    69.493305     3000           -0 
-    2000    114.61886     3000           -0 
-    2100    152.89232     3000           -0 
+Step Atoms KinEng 
+       0        0           -0 
+     100      926           -0 
+     200      926           -0 
+     300      926           -0 
+     400     1498           -0 
+     500     1498           -0 
+     600     1498           -0 
+     700     2275           -0 
+     800     2275           -0 
+     900     2275           -0 
+    1000     2275           -0 
+    1100     2954           -0 
+    1200     2954           -0 
+    1300     2954           -0 
+    1400     3000           -0 
+    1500     3000           -0 
+    1600     3000           -0 
+    1700     3000           -0 
+    1800     3000           -0 
+    1900     3000           -0 
+    2000     3000           -0 
+    2100     3000           -0 
+    2200     3000           -0 
+    2300     3000           -0 
+    2400     3000           -0 
+    2500     3000           -0 
+    2600     3000           -0 
+    2700     3000           -0 
+    2800     3000           -0 
+    2900     3000           -0 
+    3000     3000           -0 
+    3100     3000           -0 
+    3200     3000           -0 
+    3300     3000           -0 
+    3400     3000           -0 
+    3500     3000           -0 
+    3600     3000           -0 
+    3700     3000           -0 
+    3800     3000           -0 
+    3900     3000           -0 
+    4000     3000           -0 
+    4100     3000           -0 
+    4200     3000           -0 
+    4300     3000           -0 
+    4400     3000           -0 
+    4500     3000           -0 
+    4600     3000           -0 
+    4700     3000           -0 
+    4800     3000           -0 
+    4900     3000           -0 
+    5000     3000           -0 
+Loop time of 24.3889 on 1 procs for 5000 steps with 3000 atoms
+
+Performance: 17713.003 tau/day, 205.012 timesteps/s
+99.9% CPU use with 1 MPI tasks x 1 OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 14.362     | 14.362     | 14.362     |   0.0 | 58.89
+Neigh   | 3.3483     | 3.3483     | 3.3483     |   0.0 | 13.73
+Comm    | 0.42893    | 0.42893    | 0.42893    |   0.0 |  1.76
+Output  | 0.0025065  | 0.0025065  | 0.0025065  |   0.0 |  0.01
+Modify  | 6.059      | 6.059      | 6.059      |   0.0 | 24.84
+Other   |            | 0.1876     |            |       |  0.77
+
+Nlocal:        3000.00 ave        3000 max        3000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:        462.000 ave         462 max         462 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:        17694.0 ave       17694 max       17694 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 17694
+Ave neighs/atom = 5.8980000
+Neighbor list builds = 1133
+Dangerous builds = 0
+Total wall time: 0:00:24

examples/granular/log.29Oct20.pour.flatwall.g++.4

@@ -1,5 +1,4 @@
-LAMMPS (29 Mar 2019)
-OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:88)
+LAMMPS (29 Oct 2020)
   using 1 OpenMP thread(s) per MPI task
 # pour two types of particles (cohesive and non-cohesive) on flat wall
 
@@ -45,9 +44,14 @@ region 		boxreg block 0 20 0 ${boxy} 0 ${boxz}
 region 		boxreg block 0 20 0 20 0 ${boxz}
 region 		boxreg block 0 20 0 20 0 30
 create_box	2 boxreg
-Created orthogonal box = (0 0 0) to (20 20 30)
+Created orthogonal box = (0.0000000 0.0000000 0.0000000) to (20.000000 20.000000 30.000000)
   2 by 2 by 1 MPI processor grid
 change_box	all boundary p p f
+Changing box ...
+
+pair_style	granular
+pair_coeff 	1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
+pair_coeff 	2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall
 
 comm_modify 	vel yes
 
@@ -75,26 +79,19 @@ fix		ins2 all pour 1500 2 3123 region insreg2 diam range 0.5 1 dens 1 ${dens}
 fix		ins2 all pour 1500 2 3123 region insreg2 diam range 0.5 1 dens 1 1
 Particle insertion: 562 every 346 steps, 1500 by step 693
 
-comm_modify	vel yes
-
 neighbor	${skin} bin
 neighbor	0.15 bin
 neigh_modify	delay 0 every 1 check yes
 
-pair_style	granular
-pair_coeff 	1 * jkr 1000.0 50.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
-pair_coeff 	2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall
-
 fix		3 all wall/gran granular hertz/material 1e5 1e3 0.3 tangential mindlin NULL 1.0 0.5 zplane 0 NULL
 
-thermo_style	custom step cpu atoms ke
+thermo_style	custom step atoms ke
 thermo_modify	lost warn
 thermo		100
 
 timestep	0.001
 
-dump		1 all custom 100 ${name}.dump id type radius mass x y z
-dump		1 all custom 100 pour_two_types.dump id type radius mass x y z
+#dump		1 all custom 100 ${name}.dump id type radius mass x y z
 
 run		5000
 Neighbor list info ...
@@ -110,82 +107,82 @@ Neighbor list info ...
       stencil: half/bin/3d/newton
       bin: standard
 Per MPI rank memory allocation (min/avg/max) = 11.98 | 11.98 | 11.98 Mbytes
-Step CPU Atoms KinEng 
-       0            0        0           -0 
-     100   0.11584234      855           -0 
-     200   0.12743592      855           -0 
-     300   0.13925815      855           -0 
-     400   0.35203671     1500           -0 
-     500   0.37055922     1500           -0 
-     600   0.38671875     1500           -0 
-     700   0.71736908     2288           -0 
-     800   0.74506783     2288           -0 
-     900   0.77112222     2288           -0 
-    1000   0.79632139     2288           -0 
-    1100    1.0384252     2845           -0 
-    1200      1.08093     2845           -0 
-    1300    1.1224561     2845           -0 
-    1400    1.1811485     3000           -0 
-    1500    1.2414908     3000           -0 
-    1600    1.3105879     3000           -0 
-    1700     1.390928     3000           -0 
-    1800    1.4869275     3000           -0 
-    1900    1.5958266     3000           -0 
-    2000    1.7172487     3000           -0 
-    2100     1.851155     3000           -0 
-    2200    1.9957182     3000           -0 
-    2300    2.1593764     3000           -0 
-    2400    2.3433132     3000           -0 
-    2500     2.532742     3000           -0 
-    2600    2.7376895     3000           -0 
-    2700    2.9463468     3000           -0 
-    2800    3.1645725     3000           -0 
-    2900    3.3879526     3000           -0 
-    3000    3.6152103     3000           -0 
-    3100    3.8467371     3000           -0 
-    3200    4.0787683     3000           -0 
-    3300    4.3097105     3000           -0 
-    3400    4.5423617     3000           -0 
-    3500    4.7773693     3000           -0 
-    3600    5.0127218     3000           -0 
-    3700    5.2519271     3000           -0 
-    3800    5.4951298     3000           -0 
-    3900    5.7210469     3000           -0 
-    4000    5.9432652     3000           -0 
-    4100    6.1687591     3000           -0 
-    4200    6.3942792     3000           -0 
-    4300    6.6331475     3000           -0 
-    4400    6.8632154     3000           -0 
-    4500    7.0979366     3000           -0 
-    4600    7.3305347     3000           -0 
-    4700    7.5670528     3000           -0 
-    4800    7.8086057     3000           -0 
-    4900    8.0407174     3000           -0 
-    5000    8.2765219     3000           -0 
-Loop time of 8.27669 on 4 procs for 5000 steps with 3000 atoms
+Step Atoms KinEng 
+       0        0           -0 
+     100      926           -0 
+     200      926           -0 
+     300      926           -0 
+     400     1498           -0 
+     500     1498           -0 
+     600     1498           -0 
+     700     2275           -0 
+     800     2275           -0 
+     900     2275           -0 
+    1000     2275           -0 
+    1100     2954           -0 
+    1200     2954           -0 
+    1300     2954           -0 
+    1400     3000           -0 
+    1500     3000           -0 
+    1600     3000           -0 
+    1700     3000           -0 
+    1800     3000           -0 
+    1900     3000           -0 
+    2000     3000           -0 
+    2100     3000           -0 
+    2200     3000           -0 
+    2300     3000           -0 
+    2400     3000           -0 
+    2500     3000           -0 
+    2600     3000           -0 
+    2700     3000           -0 
+    2800     3000           -0 
+    2900     3000           -0 
+    3000     3000           -0 
+    3100     3000           -0 
+    3200     3000           -0 
+    3300     3000           -0 
+    3400     3000           -0 
+    3500     3000           -0 
+    3600     3000           -0 
+    3700     3000           -0 
+    3800     3000           -0 
+    3900     3000           -0 
+    4000     3000           -0 
+    4100     3000           -0 
+    4200     3000           -0 
+    4300     3000           -0 
+    4400     3000           -0 
+    4500     3000           -0 
+    4600     3000           -0 
+    4700     3000           -0 
+    4800     3000           -0 
+    4900     3000           -0 
+    5000     3000           -0 
+Loop time of 12.1982 on 4 procs for 5000 steps with 3000 atoms
 
-Performance: 52194.788 tau/day, 604.106 timesteps/s
-97.7% CPU use with 4 MPI tasks x 1 OpenMP threads
+Performance: 35414.923 tau/day, 409.895 timesteps/s
+97.0% CPU use with 4 MPI tasks x 1 OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 1.6106     | 3.4073     | 5.4191     |  95.7 | 41.17
-Neigh   | 0.51456    | 0.64572    | 0.81542    |  16.6 |  7.80
-Comm    | 0.2808     | 2.5222     | 4.4998     | 121.9 | 30.47
-Output  | 0.15695    | 0.15919    | 0.16502    |   0.8 |  1.92
-Modify  | 1.3517     | 1.4192     | 1.4904     |   4.9 | 17.15
-Other   |            | 0.123      |            |       |  1.49
+Pair    | 1.7141     | 3.8131     | 6.2143     | 107.3 | 31.26
+Neigh   | 0.77648    | 0.96585    | 1.1892     |  18.3 |  7.92
+Comm    | 0.7427     | 3.5566     | 5.9731     | 128.4 | 29.16
+Output  | 0.0067544  | 0.0086352  | 0.011408   |   1.8 |  0.07
+Modify  | 3.3476     | 3.5826     | 3.8235     |  11.5 | 29.37
+Other   |            | 0.2715     |            |       |  2.23
 
-Nlocal:    750 ave 1036 max 482 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
-Nghost:    429.75 ave 475 max 386 min
+Nlocal:        750.000 ave        1033 max         463 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Nghost:        435.000 ave         492 max         378 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Neighs:        4434.50 ave        7028 max        1967 min
 Histogram: 2 0 0 0 0 0 0 0 0 2
-Neighs:    4051.75 ave 6274 max 2057 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
 
-Total # of neighbors = 16207
-Ave neighs/atom = 5.40233
-Neighbor list builds = 1165
+Total # of neighbors = 17738
+Ave neighs/atom = 5.9126667
+Neighbor list builds = 1139
 Dangerous builds = 0
-Total wall time: 0:00:08
+Total wall time: 0:00:12

lib/kim/Install.py

@@ -18,12 +18,13 @@ parser = ArgumentParser(prog='Install.py',
 # settings
 
 thisdir = fullpath('.')
-version = "2.1.3"
+version = "2.2.0"
 
 # known checksums for different KIM-API versions. used to validate the download.
 checksums = { \
         '2.1.2' : '6ac52e14ef52967fc7858220b208cba5', \
         '2.1.3' : '6ee829a1bbba5f8b9874c88c4c4ebff8', \
+        '2.2.0' : 'e7f944e1593cffd7444679a660607f6c', \
         }
 
 

lib/kokkos/BUILD.md

@@ -52,13 +52,17 @@ There are numerous device backends, options, and architecture-specific optimizat
 ````
 which activates the OpenMP backend. All of the options controlling device backends, options, architectures, and third-party libraries (TPLs) are given below.
 
-## Platform-specific Problems
+## Known Issues<a name="KnownIssues"></a>
 
 ### Cray
 
 * The Cray compiler wrappers do static linking by default. This seems to break the Kokkos build. You will likely need to set the environment variable `CRAYPE_LINK_TYPE=dynamic` in order to link correctly. Kokkos warns during configure if this is missing.
 * The Cray compiler identifies to CMake as Clang, but it sometimes has its own flags that differ from Clang. We try to include all exceptions, but flag errors may occur in which a Clang-specific flag is passed that the Cray compiler does not recognize.
 
+### Fortran
+
+* In a mixed C++/Fortran code, CMake will use the C++ linker by default. If you override this behavior and use Fortran as the link language, the link may break because Kokkos adds linker flags expecting the linker to be C++. Prior to CMake 3.18, Kokkos has no way of detecting in downstream projects that the linker was changed to Fortran.  From CMake 3.18, Kokkos can use generator expressions to avoid adding flags when the linker is not C++. Note: Kokkos will not add any linker flags in this Fortran case. The user will be entirely on their own to add the appropriate linker flags.
+
 ## Spack
 An alternative to manually building with the CMake is to use the Spack package manager.
 To do so, download the `kokkos-spack` git repo and add to the package list:

lib/kokkos/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Change Log
 
+## [3.2.01](https://github.com/kokkos/kokkos/tree/3.2.01) (2020-11-17)
+[Full Changelog](https://github.com/kokkos/kokkos/compare/3.2.00...3.2.01)
+
+**Fixed bugs:**
+- Disallow KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE in shared library builds [\#3332](https://github.com/kokkos/kokkos/pull/3332)
+- Do not install libprinter-tool when testing is enabled [\#3313](https://github.com/kokkos/kokkos/pull/3313)
+- Fix restrict/alignment following refactor [\#3373](https://github.com/kokkos/kokkos/pull/3373)
+  - Intel fix: workaround compiler issue with using statement [\#3383](https://github.com/kokkos/kokkos/pull/3383)
+- Fix zero-length reductions [#\3364](https://github.com/kokkos/kokkos/pull/3364)
+  - Pthread zero-length reduction fix [\#3452](https://github.com/kokkos/kokkos/pull/3452)
+  - HPX zero-length reduction fix [\#3470](https://github.com/kokkos/kokkos/pull/3470)
+  - cuda/9.2 zero-length reduction fix [\#3580](https://github.com/kokkos/kokkos/pull/3580)
+- Fix multi-stream scratch [#\3269](https://github.com/kokkos/kokkos/pull/3269)
+- Guard KOKKOS_ALL_COMPILE_OPTIONS if Cuda is not enabled [\#3387](https://github.com/kokkos/kokkos/pull/3387)
+- Do not include link flags for Fortran linkage [\#3384](https://github.com/kokkos/kokkos/pull/3384)
+- Fix NVIDIA GPU arch macro with autodetection [\#3473](https://github.com/kokkos/kokkos/pull/3473)
+- Fix libdl/test issues with Trilinos [\#3543](https://github.com/kokkos/kokkos/pull/3543)
+  - Register Pthread as Tribits option to be enabled with Trilinos [\#3558](https://github.com/kokkos/kokkos/pull/3558)
+
+**Implemented enhancements:**
+- Separate Cuda timing-based tests into their own executable [\#3407](https://github.com/kokkos/kokkos/pull/3407)
+
 ## [3.2.00](https://github.com/kokkos/kokkos/tree/3.2.00) (2020-08-19)
 [Full Changelog](https://github.com/kokkos/kokkos/compare/3.1.01...3.2.00)
 

lib/kokkos/CMakeLists.txt

@@ -112,7 +112,7 @@ ENDIF()
 
 set(Kokkos_VERSION_MAJOR 3)
 set(Kokkos_VERSION_MINOR 2)
-set(Kokkos_VERSION_PATCH 0)
+set(Kokkos_VERSION_PATCH 1)
 set(Kokkos_VERSION "${Kokkos_VERSION_MAJOR}.${Kokkos_VERSION_MINOR}.${Kokkos_VERSION_PATCH}")
 math(EXPR KOKKOS_VERSION "${Kokkos_VERSION_MAJOR} * 10000 + ${Kokkos_VERSION_MINOR} * 100 + ${Kokkos_VERSION_PATCH}")
 
@@ -207,7 +207,9 @@ IF (KOKKOS_HAS_TRILINOS)
   # we have to match the annoying behavior
   STRING(REPLACE ";" " " KOKKOSCORE_COMPILE_OPTIONS "${KOKKOS_COMPILE_OPTIONS}")
   LIST(APPEND KOKKOS_ALL_COMPILE_OPTIONS ${KOKKOS_COMPILE_OPTIONS})
-  LIST(APPEND KOKKOS_ALL_COMPILE_OPTIONS ${KOKKOS_CUDA_OPTIONS})
+  IF (KOKKOS_ENABLE_CUDA)
+    LIST(APPEND KOKKOS_ALL_COMPILE_OPTIONS ${KOKKOS_CUDA_OPTIONS})
+  ENDIF()
   FOREACH(XCOMP_FLAG ${KOKKOS_XCOMPILER_OPTIONS})
     SET(KOKKOSCORE_XCOMPILER_OPTIONS "${KOKKOSCORE_XCOMPILER_OPTIONS} -Xcompiler ${XCOMP_FLAG}")
     LIST(APPEND KOKKOS_ALL_COMPILE_OPTIONS -Xcompiler ${XCOMP_FLAG})

lib/kokkos/Makefile.kokkos

@@ -12,7 +12,7 @@ endif
 
 KOKKOS_VERSION_MAJOR = 3
 KOKKOS_VERSION_MINOR = 2
-KOKKOS_VERSION_PATCH = 0
+KOKKOS_VERSION_PATCH = 1
 KOKKOS_VERSION = $(shell echo $(KOKKOS_VERSION_MAJOR)*10000+$(KOKKOS_VERSION_MINOR)*100+$(KOKKOS_VERSION_PATCH) | bc)
 
 # Options: Cuda,HIP,ROCm,OpenMP,Pthread,Serial

lib/kokkos/README.md

@@ -108,6 +108,10 @@ For specifics see the LICENSE file contained in the repository or distribution.
 * ARM
     * Pthreads backend
 
+### Build system:
+* CMake >= 3.10: required
+* CMake >= 3.13: recommended
+* CMake >= 3.18: Fortran linkage. This does not affect most mixed Fortran/Kokkos builds. See [build issues](BUILD.md#KnownIssues).
 
 Primary tested compiler are passing in release mode
 with warnings as errors. They also are tested with a comprehensive set of

lib/kokkos/cmake/fake_tribits.cmake

@@ -103,11 +103,18 @@ FUNCTION(KOKKOS_ADD_TEST)
       COMM serial mpi
       NUM_MPI_PROCS 1
       ${TEST_UNPARSED_ARGUMENTS}
+      ADDED_TESTS_NAMES_OUT ALL_TESTS_ADDED
     )
 
+    # We will get prepended package name here
+    SET(TEST_NAME ${PACKAGE_NAME}_${TEST_NAME})
+    SET(EXE ${PACKAGE_NAME}_${EXE_ROOT})
+
     if(TEST_TOOL)
       add_dependencies(${EXE} ${TEST_TOOL}) #make sure the exe has to build the tool
-      set_property(TEST ${TEST_NAME} APPEND_STRING PROPERTY ENVIRONMENT "KOKKOS_PROFILE_LIBRARY=$<TARGET_FILE:${TEST_TOOL}>")
+      foreach(TEST_ADDED ${ALL_TESTS_ADDED})
+        set_property(TEST ${TEST_ADDED} APPEND PROPERTY ENVIRONMENT "KOKKOS_PROFILE_LIBRARY=$<TARGET_FILE:${TEST_TOOL}>")
+      endforeach()
     endif()
   else()
     CMAKE_PARSE_ARGUMENTS(TEST
@@ -263,9 +270,7 @@ ENDFUNCTION()
 
 FUNCTION(KOKKOS_ADD_TEST_LIBRARY NAME)
 IF (KOKKOS_HAS_TRILINOS)
-  TRIBITS_ADD_LIBRARY(${NAME} ${ARGN} TESTONLY
-   ADDED_LIB_TARGET_NAME_OUT ${NAME}
-  )
+  TRIBITS_ADD_LIBRARY(${NAME} ${ARGN} TESTONLY)
 ELSE()
   SET(oneValueArgs)
   SET(multiValueArgs HEADERS SOURCES)
@@ -273,16 +278,26 @@ ELSE()
   CMAKE_PARSE_ARGUMENTS(PARSE
     "STATIC;SHARED"
     ""
-    "HEADERS;SOURCES"
+    "HEADERS;SOURCES;DEPLIBS"
     ${ARGN})
 
+  SET(LIB_TYPE)
+  IF (PARSE_STATIC)
+    SET(LIB_TYPE STATIC)
+  ELSEIF (PARSE_SHARED)
+    SET(LIB_TYPE SHARED)
+  ENDIF()
+
   IF(PARSE_HEADERS)
     LIST(REMOVE_DUPLICATES PARSE_HEADERS)
   ENDIF()
   IF(PARSE_SOURCES)
     LIST(REMOVE_DUPLICATES PARSE_SOURCES)
   ENDIF()
-  ADD_LIBRARY(${NAME} ${PARSE_SOURCES})
+  ADD_LIBRARY(${NAME} ${LIB_TYPE} ${PARSE_SOURCES})
+  IF (PARSE_DEPLIBS)
+    TARGET_LINK_LIBRARIES(${NAME} PRIVATE ${PARSE_DEPLIBS})
+  ENDIF()
 ENDIF()
 ENDFUNCTION()
 

lib/kokkos/cmake/kokkos_arch.cmake

@@ -65,32 +65,6 @@ KOKKOS_ARCH_OPTION(VEGA900         GPU  "AMD GPU MI25 GFX900")
 KOKKOS_ARCH_OPTION(VEGA906         GPU  "AMD GPU MI50/MI60 GFX906")
 KOKKOS_ARCH_OPTION(INTEL_GEN       GPU  "Intel GPUs Gen9+")
 
-IF (KOKKOS_ENABLE_CUDA)
- #Regardless of version, make sure we define the general architecture name
- IF (KOKKOS_ARCH_KEPLER30 OR KOKKOS_ARCH_KEPLER32 OR KOKKOS_ARCH_KEPLER35 OR KOKKOS_ARCH_KEPLER37)
-   SET(KOKKOS_ARCH_KEPLER ON)
- ENDIF()
-
- #Regardless of version, make sure we define the general architecture name
- IF (KOKKOS_ARCH_MAXWELL50 OR KOKKOS_ARCH_MAXWELL52 OR KOKKOS_ARCH_MAXWELL53)
-   SET(KOKKOS_ARCH_MAXWELL ON)
- ENDIF()
-
- #Regardless of version, make sure we define the general architecture name
- IF (KOKKOS_ARCH_PASCAL60 OR KOKKOS_ARCH_PASCAL61)
-   SET(KOKKOS_ARCH_PASCAL ON)
- ENDIF()
-
-  #Regardless of version, make sure we define the general architecture name
-  IF (KOKKOS_ARCH_VOLTA70 OR KOKKOS_ARCH_VOLTA72)
-    SET(KOKKOS_ARCH_VOLTA ON)
-  ENDIF()
-
-  IF (KOKKOS_ARCH_AMPERE80)
-    SET(KOKKOS_ARCH_AMPERE ON)
-  ENDIF()
-ENDIF()
-
 
 
 IF(KOKKOS_ENABLE_COMPILER_WARNINGS)
@@ -475,6 +449,32 @@ IF(KOKKOS_ENABLE_CUDA AND NOT CUDA_ARCH_ALREADY_SPECIFIED)
   ENDIF()
 ENDIF()
 
+IF (KOKKOS_ENABLE_CUDA)
+ #Regardless of version, make sure we define the general architecture name
+ IF (KOKKOS_ARCH_KEPLER30 OR KOKKOS_ARCH_KEPLER32 OR KOKKOS_ARCH_KEPLER35 OR KOKKOS_ARCH_KEPLER37)
+   SET(KOKKOS_ARCH_KEPLER ON)
+ ENDIF()
+
+ #Regardless of version, make sure we define the general architecture name
+ IF (KOKKOS_ARCH_MAXWELL50 OR KOKKOS_ARCH_MAXWELL52 OR KOKKOS_ARCH_MAXWELL53)
+   SET(KOKKOS_ARCH_MAXWELL ON)
+ ENDIF()
+
+ #Regardless of version, make sure we define the general architecture name
+ IF (KOKKOS_ARCH_PASCAL60 OR KOKKOS_ARCH_PASCAL61)
+   SET(KOKKOS_ARCH_PASCAL ON)
+ ENDIF()
+
+  #Regardless of version, make sure we define the general architecture name
+  IF (KOKKOS_ARCH_VOLTA70 OR KOKKOS_ARCH_VOLTA72)
+    SET(KOKKOS_ARCH_VOLTA ON)
+  ENDIF()
+
+  IF (KOKKOS_ARCH_AMPERE80)
+    SET(KOKKOS_ARCH_AMPERE ON)
+  ENDIF()
+ENDIF()
+
 #CMake verbose is kind of pointless
 #Let's just always print things
 MESSAGE(STATUS "Execution Spaces:")

lib/kokkos/cmake/kokkos_enable_options.cmake

@@ -109,3 +109,7 @@ ENDIF()
 IF (KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE AND KOKKOS_CXX_COMPILER_ID STREQUAL Clang)
   MESSAGE(FATAL_ERROR "Relocatable device code is currently not supported with Clang - must use nvcc_wrapper or turn off RDC")
 ENDIF()
+
+IF (KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE AND BUILD_SHARED_LIBS)
+  MESSAGE(FATAL_ERROR "Relocatable device code requires static libraries.")
+ENDIF()

lib/kokkos/cmake/kokkos_functions.cmake

@@ -209,6 +209,11 @@ ENDMACRO()
 #
 #     If specified, this TPL will build an INTERFACE library rather than an
 #     IMPORTED target
+IF (KOKKOS_HAS_TRILINOS)
+MACRO(kokkos_import_tpl NAME)
+  #do nothing
+ENDMACRO()
+ELSE()
 MACRO(kokkos_import_tpl NAME)
   CMAKE_PARSE_ARGUMENTS(TPL
    "NO_EXPORT;INTERFACE"
@@ -241,6 +246,7 @@ MACRO(kokkos_import_tpl NAME)
     LIST(APPEND KOKKOS_ENABLED_TPLS ${NAME})
   ENDIF()
 ENDMACRO(kokkos_import_tpl)
+ENDIF()
 
 MACRO(kokkos_import_cmake_tpl MODULE_NAME)
   kokkos_import_tpl(${MODULE_NAME} ${ARGN} NO_EXPORT)