recognize STL files starting with "solid binary" as binary files

used in multiple runs (for custom/adios dump style)

.github/CODEOWNERS

@@ -67,6 +67,7 @@ src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
+src/REPLICA/fix_pimd_langevin.*     @Yi-FanLi
 
 # core LAMMPS classes
 src/lammps.*              @sjplimp

.github/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contributing to LAMMPS via GitHub
 
-Thank your for considering to contribute to the LAMMPS software project.
+Thank you for considering to contribute to the LAMMPS software project.
 
 The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
 

.gitignore

@@ -57,3 +57,6 @@ out/x86
 out/x64
 src/Makefile.package-e
 src/Makefile.package.settings-e
+/cmake/build/x64-Debug-Clang
+/install/x64-GUI-MSVC
+/install

bench/in.chain

@@ -1,25 +1,25 @@
 # FENE beadspring benchmark
 
-units		lj
-atom_style	bond
+units           lj
+atom_style      bond
 special_bonds   fene
 
-read_data	data.chain
+read_data       data.chain
 
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1
 
 bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
+bond_coeff      1 30.0 1.5 1.0 1.0
 
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
+pair_style      lj/cut 1.12
+pair_modify     shift yes
+pair_coeff      1 1 1.0 1.0 1.12
 
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297
 
 thermo          100
-timestep	0.012
+timestep        0.012
 
-run		100
+run             100

bench/in.chain.scaled

@@ -1,32 +1,32 @@
 # FENE beadspring benchmark
 
-variable	x index 1
-variable	y index 1
-variable	z index 1
+variable        x index 1
+variable        y index 1
+variable        z index 1
 
-units		lj
-atom_style	bond
-atom_modify	map hash
+units           lj
+atom_style      bond
+atom_modify     map hash
 special_bonds   fene
 
-read_data	data.chain
+read_data       data.chain
 
-replicate	$x $y $z
+replicate       $x $y $z
 
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1
 
 bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
+bond_coeff      1 30.0 1.5 1.0 1.0
 
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
+pair_style      lj/cut 1.12
+pair_modify     shift yes
+pair_coeff      1 1 1.0 1.0 1.12
 
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297
 
 thermo          100
-timestep	0.012
+timestep        0.012
 
-run		100
+run             100

bench/in.chute

@@ -1,33 +1,33 @@
 # LAMMPS benchmark of granular flow
 # chute flow of 32000 atoms with frozen base at 26 degrees
 
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
+units           lj
+atom_style      sphere
+boundary        p p fs
+newton          off
+comm_modify     vel yes
 
-read_data	data.chute
+read_data       data.chute
 
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
+pair_style      gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff      * *
 
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
+neighbor        0.1 bin
+neigh_modify    every 1 delay 0
 
-timestep	0.0001
+timestep        0.0001
 
-group		bottom type 2
-group		active subtract all bottom
-neigh_modify	exclude group bottom bottom
+group           bottom type 2
+group           active subtract all bottom
+neigh_modify    exclude group bottom bottom
 
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
+fix             1 all gravity 1.0 chute 26.0
+fix             2 bottom freeze
+fix             3 active nve/sphere
 
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
+compute         1 all erotate/sphere
+thermo_style    custom step atoms ke c_1 vol
+thermo_modify   norm no
+thermo          100
 
-run		100
+run             100

bench/in.chute.scaled

@@ -1,38 +1,38 @@
 # LAMMPS benchmark of granular flow
 # chute flow of 32000 atoms with frozen base at 26 degrees
 
-variable	x index 1
-variable	y index 1
+variable        x index 1
+variable        y index 1
 
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
+units           lj
+atom_style      sphere
+boundary        p p fs
+newton          off
+comm_modify     vel yes
 
-read_data	data.chute
+read_data       data.chute
 
-replicate	$x $y 1
+replicate       $x $y 1
 
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
+pair_style      gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff      * *
 
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
+neighbor        0.1 bin
+neigh_modify    every 1 delay 0
 
-timestep	0.0001
+timestep        0.0001
 
-group		bottom type 2
-group		active subtract all bottom
-neigh_modify	exclude group bottom bottom
+group           bottom type 2
+group           active subtract all bottom
+neigh_modify    exclude group bottom bottom
 
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
+fix             1 all gravity 1.0 chute 26.0
+fix             2 bottom freeze
+fix             3 active nve/sphere
 
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
+compute         1 all erotate/sphere
+thermo_style    custom step atoms ke c_1 vol
+thermo_modify   norm no
+thermo          100
 
-run		100
+run             100

bench/in.eam

@@ -1,32 +1,32 @@
 # bulk Cu lattice
 
-variable	x index 1
-variable	y index 1
-variable	z index 1
+variable        x index 1
+variable        y index 1
+variable        z index 1
 
-variable	xx equal 20*$x
-variable	yy equal 20*$y
-variable	zz equal 20*$z
+variable        xx equal 20*$x
+variable        yy equal 20*$y
+variable        zz equal 20*$z
 
-units		metal
-atom_style	atomic
+units           metal
+atom_style      atomic
 
-lattice		fcc 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-create_box	1 box
-create_atoms	1 box
+lattice         fcc 3.615
+region          box block 0 ${xx} 0 ${yy} 0 ${zz}
+create_box      1 box
+create_atoms    1 box
 
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
+pair_style      eam
+pair_coeff      1 1 Cu_u3.eam
 
-velocity	all create 1600.0 376847 loop geom
+velocity        all create 1600.0 376847 loop geom
 
-neighbor	1.0 bin
+neighbor        1.0 bin
 neigh_modify    every 1 delay 5 check yes
 
-fix		1 all nve
+fix             1 all nve
 
-timestep	0.005
-thermo		50
+timestep        0.005
+thermo          50
 
-run		100
+run             100

bench/in.lj

@@ -1,30 +1,30 @@
 # 3d Lennard-Jones melt
 
-variable	x index 1
-variable	y index 1
-variable	z index 1
+variable        x index 1
+variable        y index 1
+variable        z index 1
 
-variable	xx equal 20*$x
-variable	yy equal 20*$y
-variable	zz equal 20*$z
+variable        xx equal 20*$x
+variable        yy equal 20*$y
+variable        zz equal 20*$z
 
-units		lj
-atom_style	atomic
+units           lj
+atom_style      atomic
 
-lattice		fcc 0.8442
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-create_box	1 box
-create_atoms	1 box
-mass		1 1.0
+lattice         fcc 0.8442
+region          box block 0 ${xx} 0 ${yy} 0 ${zz}
+create_box      1 box
+create_atoms    1 box
+mass            1 1.0
 
-velocity	all create 1.44 87287 loop geom
+velocity        all create 1.44 87287 loop geom
 
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
+pair_style      lj/cut 2.5
+pair_coeff      1 1 1.0 1.0 2.5
 
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
+neighbor        0.3 bin
+neigh_modify    delay 0 every 20 check no
 
-fix		1 all nve
+fix             1 all nve
 
-run		100
+run             100

bench/in.rhodo

@@ -1,27 +1,27 @@
 # Rhodopsin model
 
-units           real  
-neigh_modify    delay 5 every 1   
+units           real
+neigh_modify    delay 5 every 1
 
-atom_style      full  
-bond_style      harmonic 
-angle_style     charmm 
-dihedral_style  charmm 
-improper_style  harmonic 
-pair_style      lj/charmm/coul/long 8.0 10.0 
-pair_modify     mix arithmetic 
-kspace_style    pppm 1e-4 
+atom_style      full
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
 
 read_data       data.rhodo
 
 fix             1 all shake 0.0001 5 0 m 1.0 a 232
 fix             2 all npt temp 300.0 300.0 100.0 &
-		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+                z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
 
 special_bonds   charmm
- 
+
 thermo          50
-thermo_style    multi 
+thermo_style    multi
 timestep        2.0
 
-run		100
+run             100

bench/in.rhodo.scaled

@@ -1,34 +1,34 @@
 # Rhodopsin model
 
-variable	x index 1
-variable	y index 1
-variable	z index 1
+variable        x index 1
+variable        y index 1
+variable        z index 1
 
-units           real  
-neigh_modify    delay 5 every 1   
+units           real
+neigh_modify    delay 5 every 1
 
-atom_style      full  
-atom_modify	map hash
-bond_style      harmonic 
-angle_style     charmm 
-dihedral_style  charmm 
-improper_style  harmonic 
-pair_style      lj/charmm/coul/long 8.0 10.0 
-pair_modify     mix arithmetic 
-kspace_style    pppm 1e-4 
+atom_style      full
+atom_modify     map hash
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
 
 read_data       data.rhodo
 
-replicate	$x $y $z
+replicate       $x $y $z
 
 fix             1 all shake 0.0001 5 0 m 1.0 a 232
 fix             2 all npt temp 300.0 300.0 100.0 &
-		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+                z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
 
 special_bonds   charmm
- 
+
 thermo          50
-thermo_style    multi 
+thermo_style    multi
 timestep        2.0
 
-run		100
+run             100

cmake/CMakeLists.jpeg

@@ -1,615 +0,0 @@
-cmake_minimum_required(VERSION 3.10)
-# When using CMake 3.4 and later, don't export symbols from executables unless
-# the CMAKE_ENABLE_EXPORTS variable is set.
-if(POLICY CMP0065)
-  cmake_policy(SET CMP0065 NEW)
-endif()
-if (POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-if(CMAKE_EXECUTABLE_SUFFIX)
-  set(CMAKE_EXECUTABLE_SUFFIX_TMP ${CMAKE_EXECUTABLE_SUFFIX})
-endif()
-
-project(libjpeg-turbo C)
-set(VERSION 2.1.3)
-set(COPYRIGHT_YEAR "1991-2022")
-string(REPLACE "." ";" VERSION_TRIPLET ${VERSION})
-list(GET VERSION_TRIPLET 0 VERSION_MAJOR)
-list(GET VERSION_TRIPLET 1 VERSION_MINOR)
-list(GET VERSION_TRIPLET 2 VERSION_REVISION)
-function(pad_number NUMBER OUTPUT_LEN)
-  string(LENGTH "${${NUMBER}}" INPUT_LEN)
-  if(INPUT_LEN LESS OUTPUT_LEN)
-    math(EXPR ZEROES "${OUTPUT_LEN} - ${INPUT_LEN} - 1")
-    set(NUM ${${NUMBER}})
-    foreach(C RANGE ${ZEROES})
-      set(NUM "0${NUM}")
-    endforeach()
-    set(${NUMBER} ${NUM} PARENT_SCOPE)
-  endif()
-endfunction()
-pad_number(VERSION_MINOR 3)
-pad_number(VERSION_REVISION 3)
-set(LIBJPEG_TURBO_VERSION_NUMBER ${VERSION_MAJOR}${VERSION_MINOR}${VERSION_REVISION})
-
-# CMake 3.14 and later sets CMAKE_MACOSX_BUNDLE to TRUE by default when
-# CMAKE_SYSTEM_NAME is iOS, tvOS, or watchOS, which breaks the libjpeg-turbo
-# build.  (Specifically, when CMAKE_MACOSX_BUNDLE is TRUE, executables for
-# Apple platforms are built as application bundles, which causes CMake to
-# complain that our install() directives for executables do not specify a
-# BUNDLE DESTINATION.  Even if CMake did not complain, building executables as
-# application bundles would break our iOS packages.)
-set(CMAKE_MACOSX_BUNDLE FALSE)
-
-string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")
-set(BUILD ${DEFAULT_BUILD} CACHE STRING "Build string (default: ${DEFAULT_BUILD})")
-
-# NOTE: On Windows, this does nothing except when using MinGW or Cygwin.
-# CMAKE_BUILD_TYPE has no meaning in Visual Studio, and it always defaults to
-# Debug when using NMake.
-if(NOT CMAKE_BUILD_TYPE)
-  set(CMAKE_BUILD_TYPE Release)
-endif()
-message(STATUS "CMAKE_BUILD_TYPE = ${CMAKE_BUILD_TYPE}")
-
-message(STATUS "VERSION = ${VERSION}, BUILD = ${BUILD}")
-
-include(cmakescripts/PackageInfo.cmake)
-
-# Detect CPU type and whether we're building 64-bit or 32-bit code
-math(EXPR BITS "${CMAKE_SIZEOF_VOID_P} * 8")
-string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} CMAKE_SYSTEM_PROCESSOR_LC)
-set(COUNT 1)
-foreach(ARCH ${CMAKE_OSX_ARCHITECTURES})
-  if(COUNT GREATER 1)
-    message(FATAL_ERROR "The libjpeg-turbo build system does not support multiple values in CMAKE_OSX_ARCHITECTURES.")
-  endif()
-  math(EXPR COUNT "${COUNT}+1")
-endforeach()
-if(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86_64" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "amd64" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "i[0-9]86" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "ia32")
-  if(BITS EQUAL 64 OR CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
-    set(CPU_TYPE x86_64)
-  else()
-    set(CPU_TYPE i386)
-  endif()
-  if(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL ${CPU_TYPE})
-    set(CMAKE_SYSTEM_PROCESSOR ${CPU_TYPE})
-  endif()
-elseif(CMAKE_SYSTEM_PROCESSOR_LC STREQUAL "aarch64" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^arm")
-  if(BITS EQUAL 64)
-    set(CPU_TYPE arm64)
-  else()
-    set(CPU_TYPE arm)
-  endif()
-elseif(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^ppc" OR
-  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^powerpc")
-  set(CPU_TYPE powerpc)
-else()
-  set(CPU_TYPE ${CMAKE_SYSTEM_PROCESSOR_LC})
-endif()
-if(CMAKE_OSX_ARCHITECTURES MATCHES "x86_64" OR
-  CMAKE_OSX_ARCHITECTURES MATCHES "arm64" OR
-  CMAKE_OSX_ARCHITECTURES MATCHES "i386")
-  set(CPU_TYPE ${CMAKE_OSX_ARCHITECTURES})
-endif()
-if(CMAKE_OSX_ARCHITECTURES MATCHES "ppc")
-  set(CPU_TYPE powerpc)
-endif()
-if(MSVC_IDE AND CMAKE_GENERATOR_PLATFORM MATCHES "arm64")
-  set(CPU_TYPE arm64)
-endif()
-
-message(STATUS "${BITS}-bit build (${CPU_TYPE})")
-
-macro(report_directory var)
-  if(CMAKE_INSTALL_${var} STREQUAL CMAKE_INSTALL_FULL_${var})
-    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}}")
-  else()
-    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}} (${CMAKE_INSTALL_FULL_${var}})")
-  endif()
-  mark_as_advanced(CLEAR CMAKE_INSTALL_${var})
-endmacro()
-
-set(DIRLIST "BINDIR;DATAROOTDIR;DOCDIR;INCLUDEDIR;LIBDIR")
-if(UNIX)
-  list(APPEND DIRLIST "MANDIR")
-endif()
-foreach(dir ${DIRLIST})
-  report_directory(${dir})
-endforeach()
-
-
-###############################################################################
-# CONFIGURATION OPTIONS
-###############################################################################
-
-macro(boolean_number var)
-  if(${var})
-    set(${var} 1 ${ARGN})
-  else()
-    set(${var} 0 ${ARGN})
-  endif()
-endmacro()
-
-option(ENABLE_SHARED "Build shared libraries" FALSE)
-boolean_number(ENABLE_SHARED)
-option(ENABLE_STATIC "Build static libraries" TRUE)
-boolean_number(ENABLE_STATIC)
-option(REQUIRE_SIMD "Generate a fatal error if SIMD extensions are not available for this platform (default is to fall back to a non-SIMD build)" FALSE)
-boolean_number(REQUIRE_SIMD)
-option(WITH_12BIT "Encode/decode JPEG images with 12-bit samples (implies WITH_ARITH_DEC=0 WITH_ARITH_ENC=0 WITH_JAVA=0 WITH_SIMD=0 WITH_TURBOJPEG=0 )" FALSE)
-boolean_number(WITH_12BIT)
-option(WITH_ARITH_DEC "Include arithmetic decoding support when emulating the libjpeg v6b API/ABI" TRUE)
-boolean_number(WITH_ARITH_DEC)
-option(WITH_ARITH_ENC "Include arithmetic encoding support when emulating the libjpeg v6b API/ABI" TRUE)
-boolean_number(WITH_ARITH_ENC)
-if(CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
-  set(WITH_JAVA 0)
-else()
-  option(WITH_JAVA "Build Java wrapper for the TurboJPEG API library (implies ENABLE_SHARED=1)" FALSE)
-  boolean_number(WITH_JAVA)
-endif()
-option(WITH_JPEG7 "Emulate libjpeg v7 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
-boolean_number(WITH_JPEG7)
-option(WITH_JPEG8 "Emulate libjpeg v8 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
-boolean_number(WITH_JPEG8)
-option(WITH_MEM_SRCDST "Include in-memory source/destination manager functions when emulating the libjpeg v6b or v7 API/ABI" TRUE)
-boolean_number(WITH_MEM_SRCDST)
-option(WITH_SIMD "Include SIMD extensions, if available for this platform" FALSE)
-boolean_number(WITH_SIMD)
-option(WITH_TURBOJPEG "Include the TurboJPEG API library and associated test programs" FALSE)
-boolean_number(WITH_TURBOJPEG)
-option(WITH_FUZZ "Build fuzz targets" FALSE)
-
-macro(report_option var desc)
-  if(${var})
-    message(STATUS "${desc} enabled (${var} = ${${var}})")
-  else()
-    message(STATUS "${desc} disabled (${var} = ${${var}})")
-  endif()
-endmacro()
-
-if(WITH_JAVA)
-  set(ENABLE_SHARED 1)
-endif()
-
-# Explicitly setting CMAKE_POSITION_INDEPENDENT_CODE=FALSE disables PIC for all
-# targets, which will cause the shared library builds to fail.  Thus, if shared
-# libraries are enabled and CMAKE_POSITION_INDEPENDENT_CODE is explicitly set
-# to FALSE, we need to unset it, thus restoring the default behavior
-# (automatically using PIC for shared library targets.)
-if(DEFINED CMAKE_POSITION_INDEPENDENT_CODE AND
-  NOT CMAKE_POSITION_INDEPENDENT_CODE AND ENABLE_SHARED)
-  unset(CMAKE_POSITION_INDEPENDENT_CODE CACHE)
-endif()
-
-report_option(ENABLE_SHARED "Shared libraries")
-report_option(ENABLE_STATIC "Static libraries")
-
-if(ENABLE_SHARED)
-  set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_FULL_LIBDIR})
-endif()
-
-if(WITH_JPEG8 OR WITH_JPEG7)
-  set(WITH_ARITH_ENC 1)
-  set(WITH_ARITH_DEC 1)
-endif()
-if(WITH_JPEG8)
-  set(WITH_MEM_SRCDST 0)
-endif()
-
-if(WITH_12BIT)
-  set(WITH_ARITH_DEC 0)
-  set(WITH_ARITH_ENC 0)
-  set(WITH_JAVA 0)
-  set(WITH_SIMD 0)
-  set(WITH_TURBOJPEG 0)
-  set(BITS_IN_JSAMPLE 12)
-else()
-  set(BITS_IN_JSAMPLE 8)
-endif()
-report_option(WITH_12BIT "12-bit JPEG support")
-
-if(WITH_ARITH_DEC)
-  set(D_ARITH_CODING_SUPPORTED 1)
-endif()
-if(NOT WITH_12BIT)
-  report_option(WITH_ARITH_DEC "Arithmetic decoding support")
-endif()
-
-if(WITH_ARITH_ENC)
-  set(C_ARITH_CODING_SUPPORTED 1)
-endif()
-if(NOT WITH_12BIT)
-  report_option(WITH_ARITH_ENC "Arithmetic encoding support")
-endif()
-
-if(NOT WITH_12BIT)
-  report_option(WITH_TURBOJPEG "TurboJPEG API library")
-  report_option(WITH_JAVA "TurboJPEG Java wrapper")
-endif()
-
-if(WITH_MEM_SRCDST)
-  set(MEM_SRCDST_SUPPORTED 1)
-  set(MEM_SRCDST_FUNCTIONS "global:  jpeg_mem_dest;  jpeg_mem_src;")
-endif()
-if(NOT WITH_JPEG8)
-  report_option(WITH_MEM_SRCDST "In-memory source/destination managers")
-endif()
-
-set(SO_AGE 2)
-if(WITH_MEM_SRCDST)
-  set(SO_AGE 3)
-endif()
-
-if(WITH_JPEG8)
-  set(JPEG_LIB_VERSION 80)
-elseif(WITH_JPEG7)
-  set(JPEG_LIB_VERSION 70)
-else()
-  set(JPEG_LIB_VERSION 62)
-endif()
-
-math(EXPR JPEG_LIB_VERSION_DIV10 "${JPEG_LIB_VERSION} / 10")
-math(EXPR JPEG_LIB_VERSION_MOD10 "${JPEG_LIB_VERSION} % 10")
-if(JPEG_LIB_VERSION STREQUAL "62")
-  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION})
-else()
-  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION_DIV10})
-endif()
-if(JPEG_LIB_VERSION STREQUAL "80")
-  set(DEFAULT_SO_MINOR_VERSION 2)
-else()
-  set(DEFAULT_SO_MINOR_VERSION 0)
-endif()
-
-# This causes SO_MAJOR_VERSION/SO_MINOR_VERSION to reset to defaults if
-# WITH_JPEG7 or WITH_JPEG8 has changed.
-if((DEFINED WITH_JPEG7_INT AND NOT WITH_JPEG7 EQUAL WITH_JPEG7_INT) OR
-  (DEFINED WITH_JPEG8_INT AND NOT WITH_JPEG8 EQUAL WITH_JPEG8_INT))
-  set(FORCE_SO_VERSION "FORCE")
-endif()
-set(WITH_JPEG7_INT ${WITH_JPEG7} CACHE INTERNAL "")
-set(WITH_JPEG8_INT ${WITH_JPEG8} CACHE INTERNAL "")
-
-set(SO_MAJOR_VERSION ${DEFAULT_SO_MAJOR_VERSION} CACHE STRING
-  "Major version of the libjpeg API shared library (default: ${DEFAULT_SO_MAJOR_VERSION})"
-  ${FORCE_SO_VERSION})
-set(SO_MINOR_VERSION ${DEFAULT_SO_MINOR_VERSION} CACHE STRING
-  "Minor version of the libjpeg API shared library (default: ${DEFAULT_SO_MINOR_VERSION})"
-  ${FORCE_SO_VERSION})
-
-set(JPEG_LIB_VERSION_DECIMAL "${JPEG_LIB_VERSION_DIV10}.${JPEG_LIB_VERSION_MOD10}")
-message(STATUS "Emulating libjpeg API/ABI v${JPEG_LIB_VERSION_DECIMAL} (WITH_JPEG7 = ${WITH_JPEG7}, WITH_JPEG8 = ${WITH_JPEG8})")
-message(STATUS "libjpeg API shared library version = ${SO_MAJOR_VERSION}.${SO_AGE}.${SO_MINOR_VERSION}")
-
-# Because the TurboJPEG API library uses versioned symbols and changes the
-# names of functions whenever they are modified in a backward-incompatible
-# manner, it is always backward-ABI-compatible with itself, so the major and
-# minor SO versions don't change.  However, we increase the middle number (the
-# SO "age") whenever functions are added to the API.
-set(TURBOJPEG_SO_MAJOR_VERSION 0)
-set(TURBOJPEG_SO_AGE 2)
-set(TURBOJPEG_SO_VERSION 0.${TURBOJPEG_SO_AGE}.0)
-
-
-###############################################################################
-# COMPILER SETTINGS
-###############################################################################
-
-if(MSVC)
-  option(WITH_CRT_DLL
-    "Link all ${CMAKE_PROJECT_NAME} libraries and executables with the C run-time DLL (msvcr*.dll) instead of the static C run-time library (libcmt*.lib.)  The default is to use the C run-time DLL only with the libraries and executables that need it."
-    FALSE)
-  if(NOT WITH_CRT_DLL)
-    # Use the static C library for all build types
-    foreach(var CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
-      CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO)
-      if(${var} MATCHES "/MD")
-        string(REGEX REPLACE "/MD" "/MT" ${var} "${${var}}")
-      endif()
-    endforeach()
-  endif()
-  add_definitions(-D_CRT_NONSTDC_NO_WARNINGS)
-endif()
-
-if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID STREQUAL "Clang")
-  # Use the maximum optimization level for release builds
-  foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
-    if(${var} MATCHES "-O2")
-      string(REGEX REPLACE "-O2" "-O3" ${var} "${${var}}")
-    endif()
-  endforeach()
-endif()
-
-if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
-  if(CMAKE_C_COMPILER_ID MATCHES "SunPro")
-    # Use the maximum optimization level for release builds
-    foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
-      if(${var} MATCHES "-xO3")
-        string(REGEX REPLACE "-xO3" "-xO5" ${var} "${${var}}")
-      endif()
-      if(${var} MATCHES "-xO2")
-        string(REGEX REPLACE "-xO2" "-xO5" ${var} "${${var}}")
-      endif()
-    endforeach()
-  endif()
-endif()
-
-string(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE_UC)
-
-set(EFFECTIVE_C_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
-message(STATUS "Compiler flags = ${EFFECTIVE_C_FLAGS}")
-
-set(EFFECTIVE_LD_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${CMAKE_EXE_LINKER_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
-message(STATUS "Linker flags = ${EFFECTIVE_LD_FLAGS}")
-
-include(CheckCSourceCompiles)
-include(CheckIncludeFiles)
-include(CheckTypeSize)
-
-check_type_size("size_t" SIZE_T)
-check_type_size("unsigned long" UNSIGNED_LONG)
-
-if(SIZE_T EQUAL UNSIGNED_LONG)
-  check_c_source_compiles("int main(int argc, char **argv) { unsigned long a = argc;  return __builtin_ctzl(a); }"
-    HAVE_BUILTIN_CTZL)
-endif()
-if(MSVC)
-  check_include_files("intrin.h" HAVE_INTRIN_H)
-endif()
-
-if(UNIX)
-  if(CMAKE_CROSSCOMPILING)
-    set(RIGHT_SHIFT_IS_UNSIGNED 0)
-  else()
-    include(CheckCSourceRuns)
-    check_c_source_runs("
-      #include <stdio.h>
-      #include <stdlib.h>
-      int is_shifting_signed (long arg) {
-        long res = arg >> 4;
-        if (res == -0x7F7E80CL)
-          return 1; /* right shift is signed */
-        /* see if unsigned-shift hack will fix it. */
-        /* we can't just test exact value since it depends on width of long... */
-        res |= (~0L) << (32-4);
-        if (res == -0x7F7E80CL)
-          return 0; /* right shift is unsigned */
-        printf(\"Right shift isn't acting as I expect it to.\\\\n\");
-        printf(\"I fear the JPEG software will not work at all.\\\\n\\\\n\");
-        return 0; /* try it with unsigned anyway */
-      }
-      int main (void) {
-        exit(is_shifting_signed(-0x7F7E80B1L));
-      }" RIGHT_SHIFT_IS_UNSIGNED)
-  endif()
-endif()
-
-if(MSVC)
-  set(INLINE_OPTIONS "__inline;inline")
-else()
-  set(INLINE_OPTIONS "__inline__;inline")
-endif()
-option(FORCE_INLINE "Force function inlining" TRUE)
-boolean_number(FORCE_INLINE)
-if(FORCE_INLINE)
-  if(MSVC)
-    list(INSERT INLINE_OPTIONS 0 "__forceinline")
-  else()
-    list(INSERT INLINE_OPTIONS 0 "inline __attribute__((always_inline))")
-    list(INSERT INLINE_OPTIONS 0 "__inline__ __attribute__((always_inline))")
-  endif()
-endif()
-foreach(inline ${INLINE_OPTIONS})
-  check_c_source_compiles("${inline} static int foo(void) { return 0; } int main(void) { return foo(); }"
-    INLINE_WORKS)
-  if(INLINE_WORKS)
-    set(INLINE ${inline})
-    break()
-  endif()
-endforeach()
-if(NOT INLINE_WORKS)
-  message(FATAL_ERROR "Could not determine how to inline functions.")
-endif()
-message(STATUS "INLINE = ${INLINE} (FORCE_INLINE = ${FORCE_INLINE})")
-
-if(WITH_TURBOJPEG)
-  if(MSVC)
-    set(THREAD_LOCAL "__declspec(thread)")
-  else()
-    set(THREAD_LOCAL "__thread")
-  endif()
-  check_c_source_compiles("${THREAD_LOCAL} int i;  int main(void) { i = 0;  return i; }" HAVE_THREAD_LOCAL)
-  if(HAVE_THREAD_LOCAL)
-    message(STATUS "THREAD_LOCAL = ${THREAD_LOCAL}")
-  else()
-    message(WARNING "Thread-local storage is not available.  The TurboJPEG API library's global error handler will not be thread-safe.")
-    unset(THREAD_LOCAL)
-  endif()
-endif()
-
-if(UNIX AND NOT APPLE)
-  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map "VERS_1 { global: *; };")
-  set(CMAKE_REQUIRED_FLAGS
-    "-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
-  check_c_source_compiles("int main(void) { return 0; }" HAVE_VERSION_SCRIPT)
-  set(CMAKE_REQUIRED_FLAGS)
-  file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
-  if(HAVE_VERSION_SCRIPT)
-    message(STATUS "Linker supports GNU-style version scripts")
-    set(MAPFLAG "-Wl,--version-script,")
-    set(TJMAPFLAG "-Wl,--version-script,")
-  else()
-    message(STATUS "Linker does not support GNU-style version scripts")
-    if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
-      # The Solaris linker doesn't like our version script for the libjpeg API
-      # library, but the version script for the TurboJPEG API library should
-      # still work.
-      file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map
-        "VERS_1 { global: foo;  local: *; }; VERS_2 { global: foo2; } VERS_1;")
-      set(CMAKE_REQUIRED_FLAGS "-Wl,-M,${CMAKE_CURRENT_BINARY_DIR}/conftest.map -shared")
-      check_c_source_compiles("int foo() { return 0; } int foo2() { return 2; }"
-        HAVE_MAPFILE)
-      set(CMAKE_REQUIRED_FLAGS)
-      file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
-      if(HAVE_MAPFILE)
-        message(STATUS "Linker supports mapfiles")
-        set(TJMAPFLAG "-Wl,-M,")
-      else()
-        message(STATUS "Linker does not support mapfiles")
-      endif()
-    endif()
-  endif()
-endif()
-
-# Generate files
-if(WIN32)
-  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/win/jconfig.h.in jconfig.h)
-else()
-  configure_file(jconfig.h.in jconfig.h)
-endif()
-configure_file(jconfigint.h.in jconfigint.h)
-configure_file(jversion.h.in jversion.h)
-if(UNIX)
-  configure_file(libjpeg.map.in libjpeg.map)
-endif()
-
-# Include directories and compiler definitions
-include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
-
-
-###############################################################################
-# TARGETS
-###############################################################################
-
-if(CMAKE_EXECUTABLE_SUFFIX_TMP)
-  set(CMAKE_EXECUTABLE_SUFFIX ${CMAKE_EXECUTABLE_SUFFIX_TMP})
-endif()
-message(STATUS "CMAKE_EXECUTABLE_SUFFIX = ${CMAKE_EXECUTABLE_SUFFIX}")
-
-set(JPEG_SOURCES jcapimin.c jcapistd.c jccoefct.c jccolor.c jcdctmgr.c jchuff.c
-  jcicc.c jcinit.c jcmainct.c jcmarker.c jcmaster.c jcomapi.c jcparam.c
-  jcphuff.c jcprepct.c jcsample.c jctrans.c jdapimin.c jdapistd.c jdatadst.c
-  jdatasrc.c jdcoefct.c jdcolor.c jddctmgr.c jdhuff.c jdicc.c jdinput.c
-  jdmainct.c jdmarker.c jdmaster.c jdmerge.c jdphuff.c jdpostct.c jdsample.c
-  jdtrans.c jerror.c jfdctflt.c jfdctfst.c jfdctint.c jidctflt.c jidctfst.c
-  jidctint.c jidctred.c jquant1.c jquant2.c jutils.c jmemmgr.c jmemnobs.c)
-
-if(WITH_ARITH_ENC OR WITH_ARITH_DEC)
-  set(JPEG_SOURCES ${JPEG_SOURCES} jaricom.c)
-endif()
-
-if(WITH_ARITH_ENC)
-  set(JPEG_SOURCES ${JPEG_SOURCES} jcarith.c)
-endif()
-
-if(WITH_ARITH_DEC)
-  set(JPEG_SOURCES ${JPEG_SOURCES} jdarith.c)
-endif()
-
-if(WITH_SIMD)
-  add_subdirectory(simd)
-  if(NEON_INTRINSICS)
-    add_definitions(-DNEON_INTRINSICS)
-  endif()
-elseif(NOT WITH_12BIT)
-  message(STATUS "SIMD extensions: None (WITH_SIMD = ${WITH_SIMD})")
-endif()
-if(WITH_SIMD)
-  message(STATUS "SIMD extensions: ${CPU_TYPE} (WITH_SIMD = ${WITH_SIMD})")
-  if(MSVC_IDE OR XCODE)
-    set_source_files_properties(${SIMD_OBJS} PROPERTIES GENERATED 1)
-  endif()
-else()
-  add_library(simd OBJECT jsimd_none.c)
-  if(NOT WIN32 AND (CMAKE_POSITION_INDEPENDENT_CODE OR ENABLE_SHARED))
-    set_target_properties(simd PROPERTIES POSITION_INDEPENDENT_CODE 1)
-  endif()
-endif()
-
-if(WITH_JAVA)
-  add_subdirectory(java)
-endif()
-
-if(ENABLE_SHARED)
-  add_subdirectory(sharedlib)
-endif()
-
-if(ENABLE_STATIC)
-  add_library(jpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
-    ${SIMD_OBJS})
-  if(NOT MSVC)
-    set_target_properties(jpeg-static PROPERTIES OUTPUT_NAME jpeg)
-  endif()
-endif()
-
-if(WITH_TURBOJPEG)
-  if(ENABLE_SHARED)
-    set(TURBOJPEG_SOURCES ${JPEG_SOURCES} $<TARGET_OBJECTS:simd> ${SIMD_OBJS}
-      turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c rdppm.c
-      wrbmp.c wrppm.c)
-    set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile)
-    if(WITH_JAVA)
-      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES} turbojpeg-jni.c)
-      include_directories(${JAVA_INCLUDE_PATH} ${JAVA_INCLUDE_PATH2})
-      set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile.jni)
-    endif()
-    if(MSVC)
-      configure_file(${CMAKE_SOURCE_DIR}/win/turbojpeg.rc.in
-        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
-      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES}
-        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
-    endif()
-    add_library(turbojpeg SHARED ${TURBOJPEG_SOURCES})
-    set_property(TARGET turbojpeg PROPERTY COMPILE_FLAGS
-      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
-    if(WIN32)
-      set_target_properties(turbojpeg PROPERTIES DEFINE_SYMBOL DLLDEFINE)
-    endif()
-    if(MINGW)
-      set_target_properties(turbojpeg PROPERTIES LINK_FLAGS -Wl,--kill-at)
-    endif()
-    if(APPLE AND (NOT CMAKE_OSX_DEPLOYMENT_TARGET OR
-                  CMAKE_OSX_DEPLOYMENT_TARGET VERSION_GREATER 10.4))
-      if(NOT CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG)
-        set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
-      endif()
-      set_target_properties(turbojpeg PROPERTIES MACOSX_RPATH 1)
-    endif()
-    set_target_properties(turbojpeg PROPERTIES
-      SOVERSION ${TURBOJPEG_SO_MAJOR_VERSION} VERSION ${TURBOJPEG_SO_VERSION})
-    if(TJMAPFLAG)
-      set_target_properties(turbojpeg PROPERTIES
-        LINK_FLAGS "${TJMAPFLAG}${TJMAPFILE}")
-    endif()
-  endif()
-
-  if(ENABLE_STATIC)
-    add_library(turbojpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
-      ${SIMD_OBJS} turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c
-      rdppm.c wrbmp.c wrppm.c)
-    set_property(TARGET turbojpeg-static PROPERTY COMPILE_FLAGS
-      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
-    if(NOT MSVC)
-      set_target_properties(turbojpeg-static PROPERTIES OUTPUT_NAME turbojpeg)
-    endif()
-  endif()
-endif()
-
-if(WIN32)
-  set(USE_SETMODE "-DUSE_SETMODE")
-endif()
-if(WITH_12BIT)
-  set(COMPILE_FLAGS "-DGIF_SUPPORTED -DPPM_SUPPORTED ${USE_SETMODE}")
-else()
-  set(COMPILE_FLAGS "-DBMP_SUPPORTED -DGIF_SUPPORTED -DPPM_SUPPORTED -DTARGA_SUPPORTED ${USE_SETMODE}")
-  set(CJPEG_BMP_SOURCES rdbmp.c rdtarga.c)
-  set(DJPEG_BMP_SOURCES wrbmp.c wrtarga.c)
-endif()

cmake/CMakeLists.png

@@ -1,741 +0,0 @@
-# CMakeLists.txt
-
-# Copyright (C) 2018 Cosmin Truta
-# Copyright (C) 2007,2009-2018 Glenn Randers-Pehrson
-# Written by Christian Ehrlicher, 2007
-# Revised by Roger Lowman, 2009-2010
-# Revised by Clifford Yapp, 2011-2012,2017
-# Revised by Roger Leigh, 2016
-# Revised by Andreas Franek, 2016
-# Revised by Sam Serrels, 2017
-# Revised by Vadim Barkov, 2017
-# Revised by Vicky Pfau, 2018
-# Revised by Cameron Cawley, 2018
-# Revised by Cosmin Truta, 2018
-# Revised by Kyle Bentley, 2018
-
-# This code is released under the libpng license.
-# For conditions of distribution and use, see the disclaimer
-# and license in png.h
-
-cmake_minimum_required(VERSION 3.10)
-cmake_policy(VERSION 3.1)
-# When using CMake 3.4 and later, don't export symbols from executables unless
-# the CMAKE_ENABLE_EXPORTS variable is set.
-if(POLICY CMP0065)
-  cmake_policy(SET CMP0065 NEW)
-endif()
-if (POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
-
-project(libpng C ASM)
-enable_testing()
-
-set(PNGLIB_MAJOR 1)
-set(PNGLIB_MINOR 6)
-set(PNGLIB_RELEASE 37)
-set(PNGLIB_NAME libpng${PNGLIB_MAJOR}${PNGLIB_MINOR})
-set(PNGLIB_VERSION ${PNGLIB_MAJOR}.${PNGLIB_MINOR}.${PNGLIB_RELEASE})
-
-include(GNUInstallDirs)
-
-# needed packages
-
-# Allow users to specify location of Zlib.
-# Useful if zlib is being built alongside this as a sub-project.
-option(PNG_BUILD_ZLIB "Custom zlib Location, else find_package is used" ON)
-
-if(NOT PNG_BUILD_ZLIB)
-  find_package(ZLIB REQUIRED)
-  include_directories(${ZLIB_INCLUDE_DIR})
-endif()
-
-if(UNIX AND NOT APPLE AND NOT BEOS AND NOT HAIKU)
-  find_library(M_LIBRARY m)
-else()
-  # libm is not needed and/or not available
-  set(M_LIBRARY "")
-endif()
-
-# COMMAND LINE OPTIONS
-option(PNG_SHARED "Build shared lib" OFF)
-option(PNG_STATIC "Build static lib" ON)
-option(PNG_TESTS  "Build libpng tests" OFF)
-
-# Many more configuration options could be added here
-option(PNG_FRAMEWORK "Build OS X framework" OFF)
-option(PNG_DEBUG "Build with debug output" OFF)
-option(PNG_HARDWARE_OPTIMIZATIONS "Enable hardware optimizations" OFF)
-
-set(PNG_PREFIX "" CACHE STRING "Prefix to add to the API function names")
-set(DFA_XTRA "" CACHE FILEPATH "File containing extra configuration settings")
-
-if(PNG_HARDWARE_OPTIMIZATIONS)
-
-# set definitions and sources for arm
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
-  CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
-  set(PNG_ARM_NEON_POSSIBLE_VALUES check on off)
-  set(PNG_ARM_NEON "check" CACHE STRING "Enable ARM NEON optimizations:
-     check: (default) use internal checking code;
-     off: disable the optimizations;
-     on: turn on unconditionally.")
-  set_property(CACHE PNG_ARM_NEON PROPERTY STRINGS
-     ${PNG_ARM_NEON_POSSIBLE_VALUES})
-  list(FIND PNG_ARM_NEON_POSSIBLE_VALUES ${PNG_ARM_NEON} index)
-  if(index EQUAL -1)
-    message(FATAL_ERROR
-            "PNG_ARM_NEON must be one of [${PNG_ARM_NEON_POSSIBLE_VALUES}]")
-  elseif(NOT ${PNG_ARM_NEON} STREQUAL "off")
-    set(libpng_arm_sources
-      arm/arm_init.c
-      arm/filter_neon.S
-      arm/filter_neon_intrinsics.c
-      arm/palette_neon_intrinsics.c)
-
-    if(${PNG_ARM_NEON} STREQUAL "on")
-      add_definitions(-DPNG_ARM_NEON_OPT=2)
-    elseif(${PNG_ARM_NEON} STREQUAL "check")
-      add_definitions(-DPNG_ARM_NEON_CHECK_SUPPORTED)
-    endif()
-  else()
-    add_definitions(-DPNG_ARM_NEON_OPT=0)
-  endif()
-endif()
-
-# set definitions and sources for powerpc
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
-  set(PNG_POWERPC_VSX_POSSIBLE_VALUES on off)
-  set(PNG_POWERPC_VSX "on" CACHE STRING "Enable POWERPC VSX optimizations:
-     off: disable the optimizations.")
-  set_property(CACHE PNG_POWERPC_VSX PROPERTY STRINGS
-     ${PNG_POWERPC_VSX_POSSIBLE_VALUES})
-  list(FIND PNG_POWERPC_VSX_POSSIBLE_VALUES ${PNG_POWERPC_VSX} index)
-  if(index EQUAL -1)
-    message(FATAL_ERROR
-            "PNG_POWERPC_VSX must be one of [${PNG_POWERPC_VSX_POSSIBLE_VALUES}]")
-  elseif(NOT ${PNG_POWERPC_VSX} STREQUAL "off")
-    set(libpng_powerpc_sources
-      powerpc/powerpc_init.c
-      powerpc/filter_vsx_intrinsics.c)
-    if(${PNG_POWERPC_VSX} STREQUAL "on")
-      add_definitions(-DPNG_POWERPC_VSX_OPT=2)
-    endif()
-  else()
-    add_definitions(-DPNG_POWERPC_VSX_OPT=0)
-  endif()
-endif()
-
-# set definitions and sources for intel
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
-  set(PNG_INTEL_SSE_POSSIBLE_VALUES on off)
-  set(PNG_INTEL_SSE "on" CACHE STRING "Enable INTEL_SSE optimizations:
-     off: disable the optimizations")
-  set_property(CACHE PNG_INTEL_SSE PROPERTY STRINGS
-     ${PNG_INTEL_SSE_POSSIBLE_VALUES})
-  list(FIND PNG_INTEL_SSE_POSSIBLE_VALUES ${PNG_INTEL_SSE} index)
-  if(index EQUAL -1)
-    message(FATAL_ERROR
-            "PNG_INTEL_SSE must be one of [${PNG_INTEL_SSE_POSSIBLE_VALUES}]")
-  elseif(NOT ${PNG_INTEL_SSE} STREQUAL "off")
-    set(libpng_intel_sources
-      intel/intel_init.c
-      intel/filter_sse2_intrinsics.c)
-    if(${PNG_INTEL_SSE} STREQUAL "on")
-      add_definitions(-DPNG_INTEL_SSE_OPT=1)
-    endif()
-  else()
-    add_definitions(-DPNG_INTEL_SSE_OPT=0)
-  endif()
-endif()
-
-# set definitions and sources for MIPS
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
-  set(PNG_MIPS_MSA_POSSIBLE_VALUES on off)
-  set(PNG_MIPS_MSA "on" CACHE STRING "Enable MIPS_MSA optimizations:
-     off: disable the optimizations")
-  set_property(CACHE PNG_MIPS_MSA PROPERTY STRINGS
-     ${PNG_MIPS_MSA_POSSIBLE_VALUES})
-  list(FIND PNG_MIPS_MSA_POSSIBLE_VALUES ${PNG_MIPS_MSA} index)
-  if(index EQUAL -1)
-    message(FATAL_ERROR
-            "PNG_MIPS_MSA must be one of [${PNG_MIPS_MSA_POSSIBLE_VALUES}]")
-  elseif(NOT ${PNG_MIPS_MSA} STREQUAL "off")
-    set(libpng_mips_sources
-      mips/mips_init.c
-      mips/filter_msa_intrinsics.c)
-    if(${PNG_MIPS_MSA} STREQUAL "on")
-      add_definitions(-DPNG_MIPS_MSA_OPT=2)
-    endif()
-  else()
-    add_definitions(-DPNG_MIPS_MSA_OPT=0)
-  endif()
-endif()
-
-else(PNG_HARDWARE_OPTIMIZATIONS)
-
-# set definitions and sources for arm
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
-  add_definitions(-DPNG_ARM_NEON_OPT=0)
-endif()
-
-# set definitions and sources for powerpc
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
-  add_definitions(-DPNG_POWERPC_VSX_OPT=0)
-endif()
-
-# set definitions and sources for intel
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
-  add_definitions(-DPNG_INTEL_SSE_OPT=0)
-endif()
-
-# set definitions and sources for MIPS
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
-   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
-  add_definitions(-DPNG_MIPS_MSA_OPT=0)
-endif()
-
-endif(PNG_HARDWARE_OPTIMIZATIONS)
-
-# SET LIBNAME
-set(PNG_LIB_NAME png${PNGLIB_MAJOR}${PNGLIB_MINOR})
-
-# to distinguish between debug and release lib
-set(CMAKE_DEBUG_POSTFIX "d")
-
-include(CheckCSourceCompiles)
-option(ld-version-script "Enable linker version script" ON)
-if(ld-version-script AND NOT APPLE)
-  # Check if LD supports linker scripts.
-  file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map" "VERS_1 {
-        global: sym;
-        local: *;
-};
-
-VERS_2 {
-        global: sym2;
-                main;
-} VERS_1;
-")
-  set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS})
-  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS} "-Wl,--version-script='${CMAKE_CURRENT_BINARY_DIR}/conftest.map'")
-  check_c_source_compiles("void sym(void) {}
-void sym2(void) {}
-int main(void) {return 0;}
-" HAVE_LD_VERSION_SCRIPT)
-  if(NOT HAVE_LD_VERSION_SCRIPT)
-    set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE} "-Wl,-M -Wl,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
-  check_c_source_compiles("void sym(void) {}
-void sym2(void) {}
-int main(void) {return 0;}
-" HAVE_SOLARIS_LD_VERSION_SCRIPT)
-  endif()
-  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE})
-  file(REMOVE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
-endif()
-
-# Find symbol prefix.  Likely obsolete and unnecessary with recent
-# toolchains (it's not done in many other projects).
-function(symbol_prefix)
-  set(SYMBOL_PREFIX)
-
-  execute_process(COMMAND "${CMAKE_C_COMPILER}" "-E" "-"
-                  INPUT_FILE /dev/null
-                  OUTPUT_VARIABLE OUT
-                  RESULT_VARIABLE STATUS)
-
-  if(CPP_FAIL)
-    message(WARNING "Failed to run the C preprocessor")
-  endif()
-
-  string(REPLACE "\n" ";" OUT "${OUT}")
-  foreach(line ${OUT})
-    string(REGEX MATCH "^PREFIX=" found_match "${line}")
-    if(found_match)
-      string(REGEX REPLACE "^PREFIX=(.*\)" "\\1" prefix "${line}")
-      string(REGEX MATCH "__USER_LABEL_PREFIX__" found_match "${prefix}")
-      if(found_match)
-        string(REGEX REPLACE "(.*)__USER_LABEL_PREFIX__(.*)" "\\1\\2" prefix "${prefix}")
-      endif()
-      set(SYMBOL_PREFIX "${prefix}")
-    endif()
-  endforeach()
-
-  message(STATUS "Symbol prefix: ${SYMBOL_PREFIX}")
-  set(SYMBOL_PREFIX "${SYMBOL_PREFIX}" PARENT_SCOPE)
-endfunction()
-
-if(UNIX)
-  symbol_prefix()
-endif()
-
-find_program(AWK NAMES gawk awk)
-
-include_directories(${CMAKE_CURRENT_BINARY_DIR})
-
-if(NOT AWK OR ANDROID)
-  # No awk available to generate sources; use pre-built pnglibconf.h
-  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt
-                 ${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h)
-  add_custom_target(genfiles) # Dummy
-else()
-  include(CMakeParseArguments)
-  # Generate .chk from .out with awk
-  # generate_chk(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
-  function(generate_chk)
-    set(options)
-    set(oneValueArgs INPUT OUTPUT)
-    set(multiValueArgs DEPENDS)
-    cmake_parse_arguments(_GC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
-    if(NOT _GC_INPUT)
-      message(FATAL_ERROR "generate_chk: Missing INPUT argument")
-    endif()
-    if(NOT _GC_OUTPUT)
-      message(FATAL_ERROR "generate_chk: Missing OUTPUT argument")
-    endif()
-
-    add_custom_command(OUTPUT "${_GC_OUTPUT}"
-                       COMMAND "${CMAKE_COMMAND}"
-                               "-DINPUT=${_GC_INPUT}"
-                               "-DOUTPUT=${_GC_OUTPUT}"
-                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake"
-                       DEPENDS "${_GC_INPUT}" ${_GC_DEPENDS}
-                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-  endfunction()
-
-  # Generate .out from .c with awk
-  # generate_out(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
-  function(generate_out)
-    set(options)
-    set(oneValueArgs INPUT OUTPUT)
-    set(multiValueArgs DEPENDS)
-    cmake_parse_arguments(_GO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
-    if(NOT _GO_INPUT)
-      message(FATAL_ERROR "generate_out: Missing INPUT argument")
-    endif()
-    if(NOT _GO_OUTPUT)
-      message(FATAL_ERROR "generate_out: Missing OUTPUT argument")
-    endif()
-
-    add_custom_command(OUTPUT "${_GO_OUTPUT}"
-                       COMMAND "${CMAKE_COMMAND}"
-                               "-DINPUT=${_GO_INPUT}"
-                               "-DOUTPUT=${_GO_OUTPUT}"
-                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake"
-                       DEPENDS "${_GO_INPUT}" ${_GO_DEPENDS}
-                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-  endfunction()
-
-  # Generate specific source file with awk
-  # generate_source(OUTPUT outputfile [DEPENDS dep1 [dep2...]])
-  function(generate_source)
-    set(options)
-    set(oneValueArgs OUTPUT)
-    set(multiValueArgs DEPENDS)
-    cmake_parse_arguments(_GSO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
-    if(NOT _GSO_OUTPUT)
-      message(FATAL_ERROR "generate_source: Missing OUTPUT argument")
-    endif()
-
-    add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${_GSO_OUTPUT}"
-                       COMMAND "${CMAKE_COMMAND}"
-                               "-DOUTPUT=${_GSO_OUTPUT}"
-                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
-                       DEPENDS ${_GSO_DEPENDS}
-                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-  endfunction()
-
-  # Copy file
-  function(generate_copy source destination)
-    add_custom_command(OUTPUT "${destination}"
-                       COMMAND "${CMAKE_COMMAND}" -E remove "${destination}"
-                       COMMAND "${CMAKE_COMMAND}" -E copy "${source}"
-                                                          "${destination}"
-                       DEPENDS "${source}")
-  endfunction()
-
-  # Generate scripts/pnglibconf.h
-  generate_source(OUTPUT "scripts/pnglibconf.c"
-                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
-                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
-                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
-
-  # Generate pnglibconf.c
-  generate_source(OUTPUT "pnglibconf.c"
-                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
-                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
-                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
-
-  if(PNG_PREFIX)
-    set(PNGLIBCONF_H_EXTRA_DEPENDS
-        "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
-        "${CMAKE_CURRENT_SOURCE_DIR}/scripts/macro.lst")
-    set(PNGPREFIX_H_EXTRA_DEPENDS
-        "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out")
-  endif()
-
-  generate_out(INPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
-
-  # Generate pnglibconf.h
-  generate_source(OUTPUT "pnglibconf.h"
-                  DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
-                          ${PNGLIBCONF_H_EXTRA_DEPENDS})
-
-  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/intprefix.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
-               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
-
-  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/prefix.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
-               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
-                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
-                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
-
-  # Generate pngprefix.h
-  generate_source(OUTPUT "pngprefix.h"
-                  DEPENDS ${PNGPREFIX_H_EXTRA_DEPENDS})
-
-  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/sym.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
-               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
-
-  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
-               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
-                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
-                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt")
-
-  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/vers.c"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
-               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
-                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
-                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
-
-  generate_chk(INPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
-               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
-               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/checksym.awk"
-                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.def")
-
-  add_custom_target(symbol-check DEPENDS
-                    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk")
-
-  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
-                "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
-  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
-                "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
-
-  add_custom_target(genvers DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
-  add_custom_target(gensym DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
-
-  add_custom_target("genprebuilt"
-                    COMMAND "${CMAKE_COMMAND}"
-                            "-DOUTPUT=scripts/pnglibconf.h.prebuilt"
-                            -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
-                    WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-
-  # A single target handles generation of all generated files.  If
-  # they are depended upon separately by multiple targets, this
-  # confuses parallel make (it would require a separate top-level
-  # target for each file to track the dependencies properly).
-  add_custom_target(genfiles DEPENDS
-    "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym"
-    "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers"
-    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
-    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
-    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
-    "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/pnglibconf.c"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
-    "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out")
-endif(NOT AWK OR ANDROID)
-
-# OUR SOURCES
-set(libpng_public_hdrs
-  png.h
-  pngconf.h
-  "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
-)
-set(libpng_private_hdrs
-  pngpriv.h
-  pngdebug.h
-  pnginfo.h
-  pngstruct.h
-)
-if(AWK AND NOT ANDROID)
-  list(APPEND libpng_private_hdrs "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h")
-endif()
-set(libpng_sources
-  ${libpng_public_hdrs}
-  ${libpng_private_hdrs}
-  png.c
-  pngerror.c
-  pngget.c
-  pngmem.c
-  pngpread.c
-  pngread.c
-  pngrio.c
-  pngrtran.c
-  pngrutil.c
-  pngset.c
-  pngtrans.c
-  pngwio.c
-  pngwrite.c
-  pngwtran.c
-  pngwutil.c
-  ${libpng_arm_sources}
-  ${libpng_intel_sources}
-  ${libpng_mips_sources}
-  ${libpng_powerpc_sources}
-)
-set(pngtest_sources
-  pngtest.c
-)
-set(pngvalid_sources
-  contrib/libtests/pngvalid.c
-)
-set(pngstest_sources
-  contrib/libtests/pngstest.c
-)
-set(pngunknown_sources
-  contrib/libtests/pngunknown.c
-)
-set(pngimage_sources
-  contrib/libtests/pngimage.c
-)
-set(pngfix_sources
-  contrib/tools/pngfix.c
-)
-set(png_fix_itxt_sources
-  contrib/tools/png-fix-itxt.c
-)
-
-if(MSVC)
-  add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
-endif()
-
-if(PNG_DEBUG)
-  add_definitions(-DPNG_DEBUG)
-endif()
-
-# NOW BUILD OUR TARGET
-include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${ZLIB_INCLUDE_DIR})
-
-unset(PNG_LIB_TARGETS)
-
-if(PNG_STATIC)
-  # does not work without changing name
-  set(PNG_LIB_NAME_STATIC png_static)
-  add_library(png_static STATIC ${libpng_sources})
-  add_dependencies(png_static genfiles)
-  # MSVC doesn't use a different file extension for shared vs. static
-  # libs.  We are able to change OUTPUT_NAME to remove the _static
-  # for all other platforms.
-  if(NOT MSVC)
-    set_target_properties(png_static PROPERTIES
-      OUTPUT_NAME "${PNG_LIB_NAME}"
-      CLEAN_DIRECT_OUTPUT 1)
-  else()
-    set_target_properties(png_static PROPERTIES
-      OUTPUT_NAME "${PNG_LIB_NAME}_static"
-      CLEAN_DIRECT_OUTPUT 1)
-  endif()
-  list(APPEND PNG_LIB_TARGETS png_static)
-  if(MSVC)
-    # msvc does not append 'lib' - do it here to have consistent name
-    set_target_properties(png_static PROPERTIES PREFIX "lib")
-  endif()
-  target_link_libraries(png_static ${M_LIBRARY})
-endif()
-
-if(NOT PNG_LIB_TARGETS)
-  message(SEND_ERROR
-    "No library variant selected to build. "
-    "Please enable at least one of the following options: "
-    "PNG_STATIC, PNG_SHARED, PNG_FRAMEWORK")
-endif()
-
-# Set a variable with CMake code which:
-# Creates a symlink from src to dest (if possible) or alternatively
-# copies if different.
-include(CMakeParseArguments)
-
-function(create_symlink DEST_FILE)
-
-  cmake_parse_arguments(S "" "FILE;TARGET" "" ${ARGN})
-
-  if(NOT S_TARGET AND NOT S_FILE)
-    message(FATAL_ERROR "create_symlink: Missing TARGET or FILE argument")
-  endif()
-
-  if(S_TARGET AND S_FILE)
-    message(FATAL_ERROR "create_symlink: Both source file ${S_FILE} and build target ${S_TARGET} arguments are present; can only have one.")
-  endif()
-
-  if(S_FILE)
-    # If we don't need to symlink something that's coming from a build target,
-    # we can go ahead and symlink/copy at configure time.
-    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
-      execute_process(
-        COMMAND "${CMAKE_COMMAND}" -E copy_if_different ${S_FILE} ${DEST_FILE}
-        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-    else()
-      execute_process(
-        COMMAND ${CMAKE_COMMAND} -E create_symlink ${S_FILE} ${DEST_FILE}
-        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
-    endif()
-  endif()
-
-  if(S_TARGET)
-    # We need to use generator expressions, which can be a bit tricky, so for
-    # simplicity make the symlink a POST_BUILD step and use the TARGET
-    # signature of add_custom_command.
-    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
-      add_custom_command(TARGET ${S_TARGET} POST_BUILD
-        COMMAND "${CMAKE_COMMAND}" -E copy_if_different $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
-    else()
-      add_custom_command(TARGET ${S_TARGET} POST_BUILD
-        COMMAND "${CMAKE_COMMAND}" -E create_symlink $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
-    endif()
-  endif()
-
-endfunction()
-
-# Create source generation scripts.
-configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genchk.cmake.in
-               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake @ONLY)
-configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genout.cmake.in
-               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake @ONLY)
-configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/gensrc.cmake.in
-               ${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake @ONLY)
-
-# libpng is a library so default to 'lib'
-if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
-  set(CMAKE_INSTALL_LIBDIR lib)
-endif()
-
-# CREATE PKGCONFIG FILES
-# We use the same files like ./configure, so we have to set its vars.
-# Only do this on Windows for Cygwin - the files don't make much sense outside
-# of a UNIX look-alike.
-if(NOT WIN32 OR CYGWIN OR MINGW)
-  set(prefix      ${CMAKE_INSTALL_PREFIX})
-  set(exec_prefix ${CMAKE_INSTALL_PREFIX})
-  set(libdir      ${CMAKE_INSTALL_FULL_LIBDIR})
-  set(includedir  ${CMAKE_INSTALL_FULL_INCLUDEDIR})
-  set(LIBS        "-lz -lm")
-  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng.pc.in
-    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc @ONLY)
-  create_symlink(libpng.pc FILE ${PNGLIB_NAME}.pc)
-
-  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng-config.in
-    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config @ONLY)
-  create_symlink(libpng-config FILE ${PNGLIB_NAME}-config)
-endif()
-
-# SET UP LINKS
-if(PNG_SHARED)
-  set_target_properties(png PROPERTIES
-#   VERSION 16.${PNGLIB_RELEASE}.1.6.37
-    VERSION 16.${PNGLIB_RELEASE}.0
-    SOVERSION 16
-    CLEAN_DIRECT_OUTPUT 1)
-endif()
-
-# INSTALL
-if(NOT SKIP_INSTALL_LIBRARIES AND NOT SKIP_INSTALL_ALL)
-  install(TARGETS ${PNG_LIB_TARGETS}
-          EXPORT libpng
-          RUNTIME DESTINATION bin
-          LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
-          ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
-          FRAMEWORK DESTINATION ${CMAKE_INSTALL_LIBDIR})
-
-  if(PNG_SHARED)
-    # Create a symlink for libpng.dll.a => libpng16.dll.a on Cygwin
-    if(CYGWIN OR MINGW)
-      create_symlink(libpng${CMAKE_IMPORT_LIBRARY_SUFFIX} TARGET png)
-      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_IMPORT_LIBRARY_SUFFIX}
-              DESTINATION ${CMAKE_INSTALL_LIBDIR})
-    endif()
-
-    if(NOT WIN32)
-      create_symlink(libpng${CMAKE_SHARED_LIBRARY_SUFFIX} TARGET png)
-      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_SHARED_LIBRARY_SUFFIX}
-              DESTINATION ${CMAKE_INSTALL_LIBDIR})
-    endif()
-  endif()
-
-  if(PNG_STATIC)
-    if(NOT WIN32 OR CYGWIN OR MINGW)
-      create_symlink(libpng${CMAKE_STATIC_LIBRARY_SUFFIX} TARGET png_static)
-      install(FILES $<TARGET_LINKER_FILE_DIR:png_static>/libpng${CMAKE_STATIC_LIBRARY_SUFFIX}
-              DESTINATION ${CMAKE_INSTALL_LIBDIR})
-    endif()
-  endif()
-endif()
-
-if(NOT SKIP_INSTALL_HEADERS AND NOT SKIP_INSTALL_ALL)
-  install(FILES ${libpng_public_hdrs} DESTINATION include)
-  install(FILES ${libpng_public_hdrs} DESTINATION include/${PNGLIB_NAME})
-endif()
-if(NOT SKIP_INSTALL_EXECUTABLES AND NOT SKIP_INSTALL_ALL)
-  if(NOT WIN32 OR CYGWIN OR MINGW)
-    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config DESTINATION bin)
-    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config DESTINATION bin)
-  endif()
-endif()
-
-if(NOT SKIP_INSTALL_PROGRAMS AND NOT SKIP_INSTALL_ALL)
-  install(TARGETS ${PNG_BIN_TARGETS}
-          RUNTIME DESTINATION bin)
-endif()
-
-if(NOT SKIP_INSTALL_FILES AND NOT SKIP_INSTALL_ALL)
-  # Install man pages
-  if(NOT PNG_MAN_DIR)
-    set(PNG_MAN_DIR "share/man")
-  endif()
-  install(FILES libpng.3 libpngpf.3 DESTINATION ${PNG_MAN_DIR}/man3)
-  install(FILES png.5 DESTINATION ${PNG_MAN_DIR}/man5)
-  # Install pkg-config files
-  if(NOT CMAKE_HOST_WIN32 OR CYGWIN OR MINGW)
-    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libpng.pc
-            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
-    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config
-            DESTINATION bin)
-    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc
-            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
-    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config
-            DESTINATION bin)
-  endif()
-endif()
-
-# Create an export file that CMake users can include() to import our targets.
-if(NOT SKIP_INSTALL_EXPORT AND NOT SKIP_INSTALL_ALL)
-  install(EXPORT libpng DESTINATION lib/libpng FILE lib${PNG_LIB_NAME}.cmake)
-endif()
-
-# what's with libpng-manual.txt and all the extra files?
-
-# UNINSTALL
-# do we need this?
-
-# DIST
-# do we need this?
-
-# to create msvc import lib for mingw compiled shared lib
-# pexports libpng.dll > libpng.def
-# lib /def:libpng.def /machine:x86

cmake/CMakeLists.txt

@@ -1,3 +1,4 @@
+# -*- CMake -*- master configuration file for building LAMMPS
 ########################################
 # CMake build system
 # This file is part of LAMMPS
@@ -12,11 +13,6 @@ endif()
 if(POLICY CMP0075)
   cmake_policy(SET CMP0075 NEW)
 endif()
-# set policy to silence warnings about missing executable permissions in
-# pythonx.y-config when cross-compiling. review occasionally if it may be set to NEW
-if(POLICY CMP0109)
-  cmake_policy(SET CMP0109 OLD)
-endif()
 # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
 if(POLICY CMP0135)
   cmake_policy(SET CMP0135 OLD)
@@ -192,6 +188,7 @@ option(BUILD_SHARED_LIBS "Build shared library" OFF)
 option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON)
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
+option(BUILD_LAMMPS_GUI "Build and install the LAMMPS GUI" OFF)
 
 # Support using clang-tidy for C++ files with selected options
 set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling")
@@ -257,7 +254,6 @@ set(STANDARD_PACKAGES
   KIM
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD
@@ -404,6 +400,7 @@ pkg_depends(CG-DNA MOLECULE)
 pkg_depends(CG-DNA ASPHERE)
 pkg_depends(ELECTRODE KSPACE)
 pkg_depends(EXTRA-MOLECULE MOLECULE)
+pkg_depends(MESONT MOLECULE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -441,7 +438,7 @@ if(BUILD_OMP)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_LATTE OR PKG_ELECTRODE)
+if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
   enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
@@ -521,7 +518,7 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MSCG COMPRESS ML-PACE LEPTON)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM MSCG COMPRESS ML-PACE LEPTON)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -796,9 +793,11 @@ include(Tools)
 include(Documentation)
 
 ###############################################################################
-# Install potential and force field files in data directory
+# Install bench, potential and force field files in data directory
 ###############################################################################
-set(LAMMPS_INSTALL_DATADIR ${CMAKE_INSTALL_FULL_DATADIR}/lammps)
+set(LAMMPS_INSTALL_DATADIR ${CMAKE_INSTALL_DATADIR}/lammps)
+
+install(DIRECTORY ${LAMMPS_DIR}/bench DESTINATION ${LAMMPS_INSTALL_DATADIR})
 install(DIRECTORY ${LAMMPS_POTENTIALS_DIR} DESTINATION ${LAMMPS_INSTALL_DATADIR})
 if(BUILD_TOOLS)
   install(DIRECTORY ${LAMMPS_TOOLS_DIR}/msi2lmp/frc_files DESTINATION ${LAMMPS_INSTALL_DATADIR})
@@ -891,13 +890,23 @@ else()
 endif()
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
+if(GIT_FOUND AND EXISTS ${LAMMPS_DIR}/.git)
+  execute_process(COMMAND ${GIT_EXECUTABLE} describe --dirty=-modified --always
+    OUTPUT_VARIABLE GIT_DESCRIBE
+    ERROR_QUIET
+    WORKING_DIRECTORY ${LAMMPS_DIR}
+    OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
 message(STATUS "<<< Build configuration >>>
-   LAMMPS Version:   ${PROJECT_VERSION}
+   LAMMPS Version:   ${PROJECT_VERSION} ${GIT_DESCRIBE}
    Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
    CMake Version:    ${CMAKE_VERSION}
    Build type:       ${LAMMPS_BUILD_TYPE}
    Install path:     ${CMAKE_INSTALL_PREFIX}
    Generator:        ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}")
+if(CMAKE_CROSSCOMPILING)
+  message(STATUS "Cross compiling on ${CMAKE_HOST_SYSTEM}")
+endif()
 ###############################################################################
 # Print package summary
 ###############################################################################
@@ -1026,6 +1035,14 @@ endif()
 if(BUILD_LAMMPS_SHELL)
   message(STATUS "<<< Building LAMMPS Shell >>>")
 endif()
+if(BUILD_LAMMPS_GUI)
+  message(STATUS "<<< Building LAMMPS GUI >>>")
+  if(LAMMPS_GUI_USE_PLUGIN)
+    message(STATUS "Loading LAMMPS library as plugin at run time")
+  else()
+    message(STATUS "Linking LAMMPS library at compile time")
+  endif()
+endif()
 if(ENABLE_TESTING)
   message(STATUS "<<< Building Unit Tests >>>")
   if(ENABLE_COVERAGE)

cmake/CMakeLists.zlib

@@ -1,195 +0,0 @@
-cmake_minimum_required(VERSION 3.10)
-# When using CMake 3.4 and later, don't export symbols from executables unless
-# the CMAKE_ENABLE_EXPORTS variable is set.
-if(POLICY CMP0065)
-  cmake_policy(SET CMP0065 NEW)
-endif()
-if (POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
-
-project(zlib C)
-
-set(VERSION "1.2.11")
-
-option(ASM686 "Enable building i686 assembly implementation" OFF)
-option(AMD64 "Enable building amd64 assembly implementation" OFF)
-
-set(INSTALL_BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin" CACHE PATH "Installation directory for executables")
-set(INSTALL_LIB_DIR "${CMAKE_INSTALL_PREFIX}/lib" CACHE PATH "Installation directory for libraries")
-set(INSTALL_INC_DIR "${CMAKE_INSTALL_PREFIX}/include" CACHE PATH "Installation directory for headers")
-set(INSTALL_MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man" CACHE PATH "Installation directory for manual pages")
-set(INSTALL_PKGCONFIG_DIR "${CMAKE_INSTALL_PREFIX}/share/pkgconfig" CACHE PATH "Installation directory for pkgconfig (.pc) files")
-
-include(CheckTypeSize)
-include(CheckFunctionExists)
-include(CheckIncludeFile)
-include(CheckCSourceCompiles)
-
-check_include_file(sys/types.h HAVE_SYS_TYPES_H)
-check_include_file(stdint.h    HAVE_STDINT_H)
-check_include_file(stddef.h    HAVE_STDDEF_H)
-
-#
-# Check to see if we have large file support
-#
-set(CMAKE_REQUIRED_DEFINITIONS -D_LARGEFILE64_SOURCE=1)
-# We add these other definitions here because CheckTypeSize.cmake
-# in CMake 2.4.x does not automatically do so and we want
-# compatibility with CMake 2.4.x.
-if(HAVE_SYS_TYPES_H)
-    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_SYS_TYPES_H)
-endif()
-if(HAVE_STDINT_H)
-    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDINT_H)
-endif()
-if(HAVE_STDDEF_H)
-    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDDEF_H)
-endif()
-check_type_size(off64_t OFF64_T)
-check_type_size(off64_t OFF64_T)
-if(HAVE_OFF64_T)
-   add_definitions(-D_LARGEFILE64_SOURCE=1)
-endif()
-set(CMAKE_REQUIRED_DEFINITIONS) # clear variable
-
-#
-# Check for fseeko
-#
-check_function_exists(fseeko HAVE_FSEEKO)
-if(NOT HAVE_FSEEKO)
-    add_definitions(-DNO_FSEEKO)
-endif()
-
-#
-# Check for unistd.h
-#
-check_include_file(unistd.h Z_HAVE_UNISTD_H)
-
-if(MSVC)
-    set(CMAKE_DEBUG_POSTFIX "d")
-    add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
-    add_definitions(-D_CRT_NONSTDC_NO_DEPRECATE)
-    include_directories(${CMAKE_CURRENT_SOURCE_DIR})
-endif()
-
-if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
-    # If we're doing an out of source build and the user has a zconf.h
-    # in their source tree...
-    if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h)
-        file(RENAME ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.included)
-  endif()
-endif()
-
-set(ZLIB_PC ${CMAKE_CURRENT_BINARY_DIR}/zlib.pc)
-configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/zlib.pc.cmakein
-		${ZLIB_PC} @ONLY)
-configure_file(	${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.cmakein
-		${CMAKE_CURRENT_BINARY_DIR}/zconf.h @ONLY)
-include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_SOURCE_DIR})
-
-
-#============================================================================
-# zlib
-#============================================================================
-
-set(ZLIB_PUBLIC_HDRS
-    ${CMAKE_CURRENT_BINARY_DIR}/zconf.h
-    zlib.h
-)
-set(ZLIB_PRIVATE_HDRS
-    crc32.h
-    deflate.h
-    gzguts.h
-    inffast.h
-    inffixed.h
-    inflate.h
-    inftrees.h
-    trees.h
-    zutil.h
-)
-set(ZLIB_SRCS
-    adler32.c
-    compress.c
-    crc32.c
-    deflate.c
-    gzclose.c
-    gzlib.c
-    gzread.c
-    gzwrite.c
-    inflate.c
-    infback.c
-    inftrees.c
-    inffast.c
-    trees.c
-    uncompr.c
-    zutil.c
-)
-
-if(NOT MINGW)
-    set(ZLIB_DLL_SRCS
-        win32/zlib1.rc # If present will override custom build rule below.
-    )
-endif()
-
-if(CMAKE_COMPILER_IS_GNUCC)
-    if(ASM686)
-        set(ZLIB_ASMS contrib/asm686/match.S)
-    elseif (AMD64)
-        set(ZLIB_ASMS contrib/amd64/amd64-match.S)
-    endif ()
-
-	if(ZLIB_ASMS)
-		add_definitions(-DASMV)
-		set_source_files_properties(${ZLIB_ASMS} PROPERTIES LANGUAGE C COMPILE_FLAGS -DNO_UNDERLINE)
-	endif()
-endif()
-
-if(MSVC)
-    if(ASM686)
-		ENABLE_LANGUAGE(ASM_MASM)
-        set(ZLIB_ASMS
-			contrib/masmx86/inffas32.asm
-			contrib/masmx86/match686.asm
-		)
-    elseif (AMD64)
-		ENABLE_LANGUAGE(ASM_MASM)
-        set(ZLIB_ASMS
-			contrib/masmx64/gvmat64.asm
-			contrib/masmx64/inffasx64.asm
-		)
-    endif()
-
-	if(ZLIB_ASMS)
-		add_definitions(-DASMV -DASMINF)
-	endif()
-endif()
-
-# parse the full version number from zlib.h and include in ZLIB_FULL_VERSION
-file(READ ${CMAKE_CURRENT_SOURCE_DIR}/zlib.h _zlib_h_contents)
-string(REGEX REPLACE ".*#define[ \t]+ZLIB_VERSION[ \t]+\"([-0-9A-Za-z.]+)\".*"
-    "\\1" ZLIB_FULL_VERSION ${_zlib_h_contents})
-
-if(MINGW)
-    # This gets us DLL resource information when compiling on MinGW.
-    if(NOT CMAKE_RC_COMPILER)
-        set(CMAKE_RC_COMPILER windres.exe)
-    endif()
-
-    add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
-                       COMMAND ${CMAKE_RC_COMPILER}
-                            -D GCC_WINDRES
-                            -I ${CMAKE_CURRENT_SOURCE_DIR}
-                            -I ${CMAKE_CURRENT_BINARY_DIR}
-                            -o ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
-                            -i ${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc)
-    set(ZLIB_DLL_SRCS ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj)
-endif(MINGW)
-
-add_library(zlibstatic STATIC ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
-
-if(UNIX)
-    # On unix-like platforms the library is almost always called libz
-   set_target_properties(zlibstatic PROPERTIES OUTPUT_NAME z)
-endif()

cmake/CMakeSettings.json

@@ -63,6 +63,11 @@
           "name": "ENABLE_TESTING",
           "value": "True",
           "type": "BOOL"
+        },
+        {
+          "name": "BUILD_LAMMPS_GUI",
+          "value": "False",
+          "type": "BOOL"
         }
       ]
     },
@@ -303,6 +308,54 @@
           "type": "STRING"
         }
       ]
+    },
+    {
+      "name": "x64-GUI-MSVC",
+      "generator": "Ninja",
+      "configurationType": "Release",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -D QT_DIR=C:\\Qt\\5.15.2\\msvc2019_64\\lib\\cmake\\Qt5  -D Qt5_DIR=C:\\Qt\\5.15.2\\msvc2019_64\\lib\\cmake\\Qt5",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [ "msvc_x64_x64" ],
+      "variables": [
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "False",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_MPI",
+          "value": "False",
+          "type": "BOOL"
+        },
+        {
+          "name": "WITH_PNG",
+          "value": "False",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_LAMMPS_GUI",
+          "value": "True",
+          "type": "BOOL"
+        }
+      ]
     }
   ]
 }

cmake/Modules/CodingStandard.cmake

@@ -5,6 +5,10 @@ if(CMAKE_VERSION VERSION_LESS 3.12)
         set(Python3_VERSION ${PYTHON_VERSION_STRING})
     endif()
 else()
+    # use default (or custom) Python executable, if version is sufficient
+    if(Python_VERSION VERSION_GREATER_EQUAL 3.5)
+      set(Python3_EXECUTABLE ${Python_EXECUTABLE})
+    endif()
     find_package(Python3 COMPONENTS Interpreter QUIET)
 endif()
 

cmake/Modules/DetectHIPInstallation.cmake

@@ -0,0 +1,16 @@
+if(NOT DEFINED HIP_PATH)
+    if(NOT DEFINED ENV{HIP_PATH})
+        message(FATAL_ERROR "HIP support requires HIP_PATH to be defined.\n"
+        "Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
+    else()
+        set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
+    endif()
+endif()
+if(NOT DEFINED ROCM_PATH)
+    if(NOT DEFINED ENV{ROCM_PATH})
+        set(ROCM_PATH "/opt/rocm" CACHE PATH "Path to ROCm installation")
+    else()
+        set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
+    endif()
+endif()
+list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})

cmake/Modules/Documentation.cmake

@@ -4,14 +4,18 @@
 option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
 
 if(BUILD_DOC)
-  # Sphinx 3.x requires at least Python 3.5
+  # Current Sphinx versions require at least Python 3.8
   if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.5 REQUIRED)
+    find_package(PythonInterp 3.8 REQUIRED)
     set(VIRTUALENV ${PYTHON_EXECUTABLE} -m venv)
   else()
+    # use default (or custom) Python executable, if version is sufficient
+    if(Python_VERSION VERSION_GREATER_EQUAL 3.8)
+      set(Python3_EXECUTABLE ${Python_EXECUTABLE})
+    endif()
     find_package(Python3 REQUIRED COMPONENTS Interpreter)
-    if(Python3_VERSION VERSION_LESS 3.5)
-      message(FATAL_ERROR "Python 3.5 and up is required to build the HTML documentation")
+    if(Python3_VERSION VERSION_LESS 3.8)
+      message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
     endif()
     set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
   endif()

cmake/Modules/FindClangFormat.cmake

@@ -1,5 +1,7 @@
 # Find clang-format
 find_program(ClangFormat_EXECUTABLE NAMES clang-format
+                                          clang-format-17.0
+                                          clang-format-16.0
                                           clang-format-15.0
                                           clang-format-14.0
                                           clang-format-13.0
@@ -19,7 +21,7 @@ if(ClangFormat_EXECUTABLE)
                   OUTPUT_VARIABLE clang_format_version
                   ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
 
-  if(clang_format_version MATCHES "^(Ubuntu |)clang-format version .*")
+  if(clang_format_version MATCHES "^(Ubuntu |Debian |)clang-format version .*")
     # Arch Linux output:
     # clang-format version 10.0.0
     #
@@ -32,9 +34,15 @@ if(ClangFormat_EXECUTABLE)
     # Ubuntu 22.04 LTS output:
     # Ubuntu clang-format version 14.0.0-1ubuntu1
     #
+    # Debian 11 output:
+    # Debian clang-format version 11.0.1-2
+    #
+    # Debian 12 output:
+    # Debian clang-format version 14.0.6
+    #
     # Fedora 36 output:
     # clang-format version 14.0.5 (Fedora 14.0.5-1.fc36)
-    string(REGEX REPLACE "^(Ubuntu |)clang-format version ([0-9.]+).*"
+    string(REGEX REPLACE "^(Ubuntu |Debian |)clang-format version ([0-9.]+).*"
                          "\\2"
                          ClangFormat_VERSION
                          "${clang_format_version}")

cmake/Modules/LAMMPSUtils.cmake

@@ -152,7 +152,7 @@ endfunction(FetchPotentials)
 # set CMAKE_LINUX_DISTRO and CMAKE_DISTRO_VERSION on Linux
 if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (EXISTS /etc/os-release))
   file(STRINGS /etc/os-release distro REGEX "^NAME=")
-  string(REGEX REPLACE "NAME=\"?([^\"]*)\"?" "\\1" distro "${distro}")
+  string(REGEX REPLACE "NAME=\"?([^ ]+).*\"?" "\\1" distro "${distro}")
   file(STRINGS /etc/os-release disversion REGEX "^VERSION_ID=")
   string(REGEX REPLACE "VERSION_ID=\"?([^\"]*)\"?" "\\1" disversion "${disversion}")
   set(CMAKE_LINUX_DISTRO ${distro})

cmake/Modules/Packages/GPU.cmake

@@ -64,6 +64,8 @@ if(GPU_API STREQUAL "CUDA")
     endif()
     set(GPU_CUDA_MPS_FLAGS "-DCUDA_MPS_SUPPORT")
   endif()
+  option(CUDA_BUILD_MULTIARCH "Enable building CUDA kernels for all supported GPU architectures" ON)
+  mark_as_advanced(GPU_BUILD_MULTIARCH)
 
   set(GPU_ARCH "sm_50" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
 
@@ -93,56 +95,58 @@ if(GPU_API STREQUAL "CUDA")
   # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
   set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH}")
 
-  # apply the following to build "fat" CUDA binaries only for known CUDA toolkits since version 8.0
-  # only the Kepler achitecture and beyond is supported
-  # comparison chart according to: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
-  if(CUDA_VERSION VERSION_LESS 8.0)
-    message(FATAL_ERROR "CUDA Toolkit version 8.0 or later is required")
-  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "13.0")
-    message(WARNING "Untested CUDA Toolkit version ${CUDA_VERSION}. Use at your own risk")
-    set(GPU_CUDA_GENCODE "-arch=all")
-  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
-    set(GPU_CUDA_GENCODE "-arch=all")
-  else()
-    # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
-    endif()
-    # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
-    endif()
-    # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
-    endif()
-    # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
-    endif()
-    # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
-    endif()
-    # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
-    endif()
-    # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
-    endif()
-    # Ampere (GPU Arch 8.6) is supported by CUDA 11.1 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_86,code=[sm_86,compute_86]")
-    endif()
-    # Lovelace (GPU Arch 8.9) is supported by CUDA 11.8 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.8")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
-    endif()
-    # Hopper (GPU Arch 9.0) is supported by CUDA 12.0 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
+  if(CUDA_BUILD_MULTIARCH)
+    # apply the following to build "fat" CUDA binaries only for known CUDA toolkits since version 8.0
+    # only the Kepler achitecture and beyond is supported
+    # comparison chart according to: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
+    if(CUDA_VERSION VERSION_LESS 8.0)
+      message(FATAL_ERROR "CUDA Toolkit version 8.0 or later is required")
+    elseif(CUDA_VERSION VERSION_GREATER_EQUAL "13.0")
+      message(WARNING "Untested CUDA Toolkit version ${CUDA_VERSION}. Use at your own risk")
+      set(GPU_CUDA_GENCODE "-arch=all")
+    elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+      set(GPU_CUDA_GENCODE "-arch=all")
+    else()
+      # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
+      if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
+      endif()
+      # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11
+      if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
+      endif()
+      # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
+      endif()
+      # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
+      endif()
+      # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
+      endif()
+      # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
+      endif()
+      # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
+      endif()
+      # Ampere (GPU Arch 8.6) is supported by CUDA 11.1 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_86,code=[sm_86,compute_86]")
+      endif()
+      # Lovelace (GPU Arch 8.9) is supported by CUDA 11.8 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "11.8")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
+      endif()
+      # Hopper (GPU Arch 9.0) is supported by CUDA 12.0 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
+      endif()
     endif()
   endif()
 
@@ -256,22 +260,7 @@ elseif(GPU_API STREQUAL "OPENCL")
   add_dependencies(ocl_get_devices OpenCL::OpenCL)
 
 elseif(GPU_API STREQUAL "HIP")
-  if(NOT DEFINED HIP_PATH)
-      if(NOT DEFINED ENV{HIP_PATH})
-          message(FATAL_ERROR "GPU_API=HIP requires HIP_PATH to be defined.\n"
-          "Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
-      else()
-          set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
-      endif()
-  endif()
-  if(NOT DEFINED ROCM_PATH)
-      if(NOT DEFINED ENV{ROCM_PATH})
-          set(ROCM_PATH "/opt/rocm" CACHE PATH "Path to ROCm installation")
-      else()
-          set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
-      endif()
-  endif()
-  list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})
+  include(DetectHIPInstallation)
   find_package(hip REQUIRED)
   option(HIP_USE_DEVICE_SORT "Use GPU sorting" ON)
 

cmake/Modules/Packages/KOKKOS.cmake

@@ -16,8 +16,8 @@ if(Kokkos_ENABLE_OPENMP)
   if(NOT BUILD_OMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
   else()
-    # NVHPC does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
-    if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC"))
+    # NVHPC/(AMD)Clang does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
+    if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
       message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
     endif()
   endif()
@@ -49,8 +49,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "f140e02b826223b1045207d9bc10d404" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.02.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "34d7860d548c06a4040236d959c9f99a" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -75,7 +75,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.7.01 REQUIRED CONFIG)
+  find_package(Kokkos 3.7.02 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -88,7 +88,7 @@ else()
   if(CMAKE_REQUEST_PIC)
     set(CMAKE_POSITION_INDEPENDENT_CODE ON)
   endif()
-  add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR})
+  add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR} EXCLUDE_FROM_ALL)
 
   set(Kokkos_INCLUDE_DIRS ${LAMMPS_LIB_KOKKOS_SRC_DIR}/core/src
                           ${LAMMPS_LIB_KOKKOS_SRC_DIR}/containers/src
@@ -121,6 +121,11 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/domain_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/modify_kokkos.cpp)
 
+# fix wall/gran has been refactored in an incompatible way. Use old version of base class for now
+if(PKG_GRANULAR)
+  list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fix_wall_gran_old.cpp)
+endif()
+
 if(PKG_KSPACE)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fft3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
@@ -132,8 +137,10 @@ if(PKG_KSPACE)
     endif()
   elseif(Kokkos_ENABLE_HIP)
     if(NOT (FFT STREQUAL "KISS"))
+      include(DetectHIPInstallation)
+      find_package(hipfft REQUIRED)
       target_compile_definitions(lammps PRIVATE -DFFT_HIPFFT)
-      target_link_libraries(lammps PRIVATE hipfft)
+      target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
   endif()
 endif()

cmake/Modules/Packages/LATTE.cmake

@@ -1,54 +0,0 @@
-enable_language(Fortran)
-
-# using lammps in a super-build setting
-if(TARGET LATTE::latte)
-  target_link_libraries(lammps PRIVATE LATTE::latte)
-  return()
-endif()
-
-find_package(LATTE 1.2.2 CONFIG)
-if(LATTE_FOUND)
-  set(DOWNLOAD_LATTE_DEFAULT OFF)
-else()
-  set(DOWNLOAD_LATTE_DEFAULT ON)
-endif()
-option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" ${DOWNLOAD_LATTE_DEFAULT})
-if(DOWNLOAD_LATTE)
-  message(STATUS "LATTE download requested - we will build our own")
-  set(LATTE_URL "https://github.com/lanl/LATTE/archive/v1.2.2.tar.gz" CACHE STRING "URL for LATTE tarball")
-  set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball")
-  mark_as_advanced(LATTE_URL)
-  mark_as_advanced(LATTE_MD5)
-  GetFallbackURL(LATTE_URL LATTE_FALLBACK)
-
-  # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
-  list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
-  list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
-  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1) AND NOT USE_INTERNAL_LINALG)
-    message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation. "
-                        "Try to configure LAMMPS with '-D USE_INTERNAL_LINALG=on' added as a workaround.")
-  endif()
-
-  include(ExternalProject)
-  ExternalProject_Add(latte_build
-    URL     ${LATTE_URL} ${LATTE_FALLBACK}
-    URL_MD5 ${LATTE_MD5}
-    SOURCE_SUBDIR cmake
-    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} -DCMAKE_INSTALL_LIBDIR=lib
-    -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
-    -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER} -DCMAKE_Fortran_FLAGS=${CMAKE_Fortran_FLAGS}
-    -DCMAKE_Fortran_FLAGS_${BTYPE}=${CMAKE_Fortran_FLAGS_${BTYPE}} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-    BUILD_BYPRODUCTS <INSTALL_DIR>/lib/liblatte.a
-  )
-  ExternalProject_get_property(latte_build INSTALL_DIR)
-  add_library(LAMMPS::LATTE UNKNOWN IMPORTED)
-  set_target_properties(LAMMPS::LATTE PROPERTIES
-    IMPORTED_LOCATION "${INSTALL_DIR}/lib/liblatte.a"
-    INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
-  target_link_libraries(lammps PRIVATE LAMMPS::LATTE)
-  add_dependencies(LAMMPS::LATTE latte_build)
-else()
-  find_package(LATTE 1.2.2 REQUIRED CONFIG)
-  target_link_libraries(lammps PRIVATE LATTE::latte)
-endif()

cmake/Modules/Packages/PLUMED.cmake

@@ -1,106 +1,169 @@
-set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
-set(PLUMED_MODE_VALUES static shared runtime)
-set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
-validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
-string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+# Plumed2 support for PLUMED package
 
-set(PLUMED_LINK_LIBS)
-if(PLUMED_MODE STREQUAL "STATIC")
-  find_package(LAPACK REQUIRED)
-  find_package(BLAS REQUIRED)
-  find_package(GSL REQUIRED)
-  list(APPEND PLUMED_LINK_LIBS ${LAPACK_LIBRARIES} ${BLAS_LIBRARIES} GSL::gsl)
-  find_package(ZLIB QUIET)
-  if(ZLIB_FOUND)
-    list(APPEND PLUMED_LINK_LIBS ZLIB::ZLIB)
-  endif()
-  find_package(FFTW3 QUIET)
-  if(FFTW3_FOUND)
-    list(APPEND PLUMED_LINK_LIBS FFTW3::FFTW3)
-  endif()
+if(BUILD_MPI)
+  set(PLUMED_CONFIG_MPI "--enable-mpi")
+  set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
+  set(PLUMED_CONFIG_CXX  ${CMAKE_MPI_CXX_COMPILER})
+  set(PLUMED_CONFIG_CPP "-I ${MPI_CXX_INCLUDE_PATH}")
+  set(PLUMED_CONFIG_LIB "${MPI_CXX_LIBRARIES}")
+  set(PLUMED_CONFIG_DEP "mpi4win_build")
+else()
+  set(PLUMED_CONFIG_MPI "--disable-mpi")
+  set(PLUMED_CONFIG_CC  ${CMAKE_C_COMPILER})
+  set(PLUMED_CONFIG_CXX  ${CMAKE_CXX_COMPILER})
+  set(PLUMED_CONFIG_CPP "")
+  set(PLUMED_CONFIG_LIB "")
+  set(PLUMED_CONFIG_DEP "")
+endif()
+if(BUILD_OMP)
+  set(PLUMED_CONFIG_OMP "--enable-openmp")
+else()
+  set(PLUMED_CONFIG_OMP "--disable-openmp")
 endif()
 
-find_package(PkgConfig QUIET)
-set(DOWNLOAD_PLUMED_DEFAULT ON)
-if(PKG_CONFIG_FOUND)
-  pkg_check_modules(PLUMED QUIET plumed)
-  if(PLUMED_FOUND)
-    set(DOWNLOAD_PLUMED_DEFAULT OFF)
-  endif()
-endif()
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.2/plumed-src-2.8.2.tgz"
+  CACHE STRING "URL for PLUMED tarball")
+set(PLUMED_MD5 "599092b6a0aa6fff992612537ad98994" CACHE STRING "MD5 checksum of PLUMED tarball")
 
-option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
-if(DOWNLOAD_PLUMED)
-  if(BUILD_MPI)
-    set(PLUMED_CONFIG_MPI "--enable-mpi")
-    set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
-    set(PLUMED_CONFIG_CXX  ${CMAKE_MPI_CXX_COMPILER})
+mark_as_advanced(PLUMED_URL)
+mark_as_advanced(PLUMED_MD5)
+GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
+
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+    set(CROSS_CONFIGURE mingw64-configure)
+  elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86")
+    set(CROSS_CONFIGURE mingw32-configure)
   else()
-    set(PLUMED_CONFIG_MPI "--disable-mpi")
-    set(PLUMED_CONFIG_CC  ${CMAKE_C_COMPILER})
-    set(PLUMED_CONFIG_CXX  ${CMAKE_CXX_COMPILER})
+    message(FATAL_ERROR "Unsupported target system: ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR}")
   endif()
-  if(BUILD_OMP)
-    set(PLUMED_CONFIG_OMP "--enable-openmp")
-  else()
-    set(PLUMED_CONFIG_OMP "--disable-openmp")
-  endif()
-  message(STATUS "PLUMED download requested - we will build our own")
-  if(PLUMED_MODE STREQUAL "STATIC")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX}")
-  elseif(PLUMED_MODE STREQUAL "SHARED")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
-  elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_PREFIX}")
-  endif()
-
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.2/plumed-src-2.8.2.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "599092b6a0aa6fff992612537ad98994" CACHE STRING "MD5 checksum of PLUMED tarball")
-
-  mark_as_advanced(PLUMED_URL)
-  mark_as_advanced(PLUMED_MD5)
-  GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
-
+  message(STATUS "Downloading and cross-compiling Plumed2 for ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR} with ${CROSS_CONFIGURE}")
   include(ExternalProject)
   ExternalProject_Add(plumed_build
     URL     ${PLUMED_URL} ${PLUMED_FALLBACK}
     URL_MD5 ${PLUMED_MD5}
     BUILD_IN_SOURCE 1
-    CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
+    CONFIGURE_COMMAND ${CROSS_CONFIGURE} --disable-shared --disable-bsymbolic
+                                         --disable-python --enable-cxx=11
+                                         --enable-modules=-adjmat:+crystallization:-dimred:+drr:+eds:-fisst:+funnel:+logmfd:+manyrestraints:+maze:+opes:+multicolvar:-pamm:-piv:+s2cm:-sasa:-ves
+                                         ${PLUMED_CONFIG_OMP}
+                                         ${PLUMED_CONFIG_MPI}
+                                         CXX=${PLUMED_CONFIG_CXX}
+                                         CC=${PLUMED_CONFIG_CC}
+                                         CPPFLAGS=${PLUMED_CONFIG_CPP}
+                                         LIBS=${PLUMED_CONFIG_LIB}
+    INSTALL_COMMAND ""
+    BUILD_BYPRODUCTS "<SOURCE_DIR>/src/lib/install/libplumed.a" "<SOURCE_DIR>/src/lib/install/plumed.exe"
+    DEPENDS "${PLUMED_MPI_CONFIG_DEP}"
+  )
+  ExternalProject_Get_Property(plumed_build SOURCE_DIR)
+  set(PLUMED_BUILD_DIR ${SOURCE_DIR})
+  set(PLUMED_INSTALL_DIR ${PLUMED_BUILD_DIR}/src/lib/install)
+  file(MAKE_DIRECTORY ${PLUMED_BUILD_DIR}/src/include)
+
+  add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
+  add_dependencies(LAMMPS::PLUMED plumed_build)
+  set_target_properties(LAMMPS::PLUMED PROPERTIES
+    IMPORTED_LOCATION "${PLUMED_INSTALL_DIR}/libplumed.a"
+    INTERFACE_LINK_LIBRARIES "-Wl,--image-base -Wl,0x10000000 -lfftw3 -lz  -fstack-protector -lssp -fopenmp"
+    INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_BUILD_DIR}/src/include")
+
+  add_custom_target(plumed_copy ALL ${CMAKE_COMMAND} -E rm -rf ${CMAKE_BINARY_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/plumed_patches
+    COMMAND ${CMAKE_COMMAND} -E copy ${PLUMED_INSTALL_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/plumed.exe
+    COMMAND ${CMAKE_COMMAND} -E copy_directory ${PLUMED_BUILD_DIR}/patches ${CMAKE_BINARY_DIR}/patches
+    BYPRODUCTS ${CMAKE_BINARY_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/patches
+    DEPENDS plumed_build
+    COMMENT "Copying Plumed files"
+  )
+
+else()
+
+  set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
+  set(PLUMED_MODE_VALUES static shared runtime)
+  set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
+  validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
+  string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+
+  set(PLUMED_LINK_LIBS)
+  if(PLUMED_MODE STREQUAL "STATIC")
+    find_package(LAPACK REQUIRED)
+    find_package(BLAS REQUIRED)
+    find_package(GSL REQUIRED)
+    list(APPEND PLUMED_LINK_LIBS ${LAPACK_LIBRARIES} ${BLAS_LIBRARIES} GSL::gsl)
+    find_package(ZLIB QUIET)
+    if(ZLIB_FOUND)
+      list(APPEND PLUMED_LINK_LIBS ZLIB::ZLIB)
+    endif()
+    find_package(FFTW3 QUIET)
+    if(FFTW3_FOUND)
+      list(APPEND PLUMED_LINK_LIBS FFTW3::FFTW3)
+    endif()
+  endif()
+
+  find_package(PkgConfig QUIET)
+  set(DOWNLOAD_PLUMED_DEFAULT ON)
+  if(PKG_CONFIG_FOUND)
+    pkg_check_modules(PLUMED QUIET plumed)
+    if(PLUMED_FOUND)
+      set(DOWNLOAD_PLUMED_DEFAULT OFF)
+    endif()
+  endif()
+
+  option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
+  if(DOWNLOAD_PLUMED)
+    message(STATUS "PLUMED download requested - we will build our own")
+    if(PLUMED_MODE STREQUAL "STATIC")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX}")
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_PREFIX}")
+    endif()
+
+    include(ExternalProject)
+    ExternalProject_Add(plumed_build
+      URL     ${PLUMED_URL} ${PLUMED_FALLBACK}
+      URL_MD5 ${PLUMED_MD5}
+      BUILD_IN_SOURCE 1
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
                                              ${CONFIGURE_REQUEST_PIC}
                                              --enable-modules=all
+                                             --enable-cxx=11
+                                             --disable-python
                                              ${PLUMED_CONFIG_MPI}
                                              ${PLUMED_CONFIG_OMP}
                                              CXX=${PLUMED_CONFIG_CXX}
                                              CC=${PLUMED_CONFIG_CC}
-    BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS}
-  )
-  ExternalProject_get_property(plumed_build INSTALL_DIR)
-  add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
-  add_dependencies(LAMMPS::PLUMED plumed_build)
-  if(PLUMED_MODE STREQUAL "STATIC")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
-  elseif(PLUMED_MODE STREQUAL "SHARED")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
-  elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+      BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS}
+    )
+    ExternalProject_get_property(plumed_build INSTALL_DIR)
+    add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
+    add_dependencies(LAMMPS::PLUMED plumed_build)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+      set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+    endif()
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
+    file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
+  else()
+    find_package(PkgConfig REQUIRED)
+    pkg_check_modules(PLUMED REQUIRED plumed)
+    add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
+    endif()
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")
   endif()
-  set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
-  file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
-else()
-  find_package(PkgConfig REQUIRED)
-  pkg_check_modules(PLUMED REQUIRED plumed)
-  add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
-  if(PLUMED_MODE STREQUAL "STATIC")
-    include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
-  elseif(PLUMED_MODE STREQUAL "SHARED")
-    include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
-  elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
-    include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
-  endif()
-  set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
-  set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")
 endif()
+
 target_link_libraries(lammps PRIVATE LAMMPS::PLUMED)

cmake/Modules/Testing.cmake

@@ -18,29 +18,33 @@ if(ENABLE_TESTING)
 
   # we need to build and link a LOT of tester executables, so it is worth checking if
   # a faster linker is available. requires GNU or Clang compiler, newer CMake.
-  # also only verified with Fedora Linux > 30 and Ubuntu <= 18.04 (Ubuntu 20.04 fails)
+  # also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
   if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (CMAKE_VERSION VERSION_GREATER_EQUAL 3.13)
-      AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
-        OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
-    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND (CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04))
+      AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
+    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
+          ((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
         OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
       include(CheckCXXCompilerFlag)
       set(CMAKE_CUSTOM_LINKER_DEFAULT default)
+      check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=bfd HAVE_BFD_LINKER_FLAG)
+      find_program(HAVE_MOLD_LINKER_BIN ld.mold)
       find_program(HAVE_LLD_LINKER_BIN lld ld.lld)
       find_program(HAVE_GOLD_LINKER_BIN ld.gold)
       find_program(HAVE_BFD_LINKER_BIN ld.bfd)
-      if(HAVE_LLD_LINKER_FLAG AND HAVE_LLD_LINKER_BIN)
+      if(HAVE_MOLD_LINKER_FLAG AND HAVE_MOLD_LINKER_BIN)
+        set(CMAKE_CUSTOM_LINKER_DEFAULT mold)
+      elseif(HAVE_LLD_LINKER_FLAG AND HAVE_LLD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT lld)
       elseif(HAVE_GOLD_LINKER_FLAG AND HAVE_GOLD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT gold)
       elseif(HAVE_BFD_LINKER_FLAG AND HAVE_BFD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT bfd)
       endif()
-      set(CMAKE_CUSTOM_LINKER_VALUES lld gold bfd default)
-      set(CMAKE_CUSTOM_LINKER ${CMAKE_CUSTOM_LINKER_DEFAULT} CACHE STRING "Choose a custom linker for faster linking (lld, gold, bfd, default)")
+      set(CMAKE_CUSTOM_LINKER_VALUES mold lld gold bfd default)
+      set(CMAKE_CUSTOM_LINKER ${CMAKE_CUSTOM_LINKER_DEFAULT} CACHE STRING "Choose a custom linker for faster linking (mold, lld, gold, bfd, default)")
       validate_option(CMAKE_CUSTOM_LINKER CMAKE_CUSTOM_LINKER_VALUES)
       mark_as_advanced(CMAKE_CUSTOM_LINKER)
       if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")

cmake/Modules/Tools.cmake

@@ -33,9 +33,15 @@ if(BUILD_TOOLS)
   endif()
   install(TARGETS msi2lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
   install(FILES ${LAMMPS_DOC_DIR}/msi2lmp.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
+
+  add_subdirectory(${LAMMPS_TOOLS_DIR}/phonon ${CMAKE_BINARY_DIR}/phana_build)
 endif()
 
+find_package(PkgConfig QUIET)
 if(BUILD_LAMMPS_SHELL)
+  if(NOT PkgConfig_FOUND)
+    message(FATAL_ERROR "Must have pkg-config installed for building LAMMPS shell")
+  endif()
   find_package(PkgConfig REQUIRED)
   pkg_check_modules(READLINE IMPORTED_TARGET REQUIRED readline)
   if(NOT LAMMPS_EXCEPTIONS)
@@ -65,4 +71,8 @@ if(BUILD_LAMMPS_SHELL)
   install(FILES ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.desktop DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications/)
 endif()
 
-
+if(BUILD_LAMMPS_GUI)
+  get_filename_component(LAMMPS_GUI_DIR ${LAMMPS_SOURCE_DIR}/../tools/lammps-gui ABSOLUTE)
+  get_filename_component(LAMMPS_GUI_BIN ${CMAKE_BINARY_DIR}/lammps-gui-build ABSOLUTE)
+  add_subdirectory(${LAMMPS_GUI_DIR} ${LAMMPS_GUI_BIN})
+endif()

cmake/packaging/MacOSXBundleInfo.plist.in

@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+	<key>CFBundleDevelopmentRegion</key>
+	<string>en-US</string>
+	<key>CFBundleExecutable</key>
+	<string>${MACOSX_BUNDLE_EXECUTABLE_NAME}</string>
+        <key>CFBundleDisplayName</key>
+        <string>The LAMMPS Molecular Dynamics Software</string>
+	<key>CFBundleIconFile</key>
+	<string>lammps</string>
+	<key>CFBundleIdentifier</key>
+	<string>org.lammps.gui</string>
+	<key>CFBundleInfoDictionaryVersion</key>
+	<string>6.0</string>
+	<key>CFBundleLongVersionString</key>
+	<string>${MACOSX_BUNDLE_LONG_VERSION_STRING}</string>
+	<key>CFBundleName</key>
+	<string>LAMMPS</string>
+	<key>CFBundlePackageType</key>
+	<string>APPL</string>
+	<key>CFBundleShortVersionString</key>
+	<string>${MACOSX_BUNDLE_SHORT_VERSION_STRING}</string>
+	<key>CFBundleSignature</key>
+	<string>????</string>
+	<key>CFBundleVersion</key>
+	<string>${MACOSX_BUNDLE_BUNDLE_VERSION}</string>
+	<key>CSResourcesFileMapped</key>
+	<true/>
+	<key>NSHumanReadableCopyright</key>
+	<string>${MACOSX_BUNDLE_COPYRIGHT}</string>
+</dict>
+</plist>

cmake/packaging/README.macos

@@ -0,0 +1,69 @@
+LAMMPS and LAMMPS GUI universal binaries for macOS (arm64/x86_64)
+=================================================================
+
+This package provides universal binaries of LAMMPS and LAMMPS GUI that should
+run on macOS systems running running macOS version 11 (Big Sur) or newer.  Note
+the binaries are compiled without MPI support and contain a compatible subset
+of the available packages.
+
+The following individual commands are included:
+binary2txt lammps-gui lmp msi2lmp phana stl_bin2txt
+
+After copying the lammps-gui folder into your Applications folder, please follow
+these steps:
+
+1. Open the Terminal app
+
+2. Type the following command and press ENTER:
+
+   open ~/.zprofile
+
+   This will open a text editor for modifying the .zprofile file in your home
+   directory.
+
+3. Add the following lines to the end of the file, save it, and close the editor
+
+   LAMMPS_INSTALL_DIR=/Applications/LAMMPS.app/Contents
+   LAMMPS_POTENTIALS=${LAMMPS_INSTALL_DIR}/share/lammps/potentials
+   LAMMPS_BENCH_DIR=${LAMMPS_INSTALL_DIR}/share/lammps/bench
+   MSI2LMP_LIBRARY=${LAMMPS_INSTALL_DIR}/share/lammps/frc_files
+   PATH=${LAMMPS_INSTALL_DIR}/bin:$PATH
+   export LAMMPS_POTENTIALS LAMMPS_BENCH_DIR PATH
+
+4. In your existing terminal, type the following command make the settings active
+
+   source ~/.zprofile
+
+   Note, you don't have to type this in new terminals, since they will apply
+   the changes from .zprofile automatically.
+
+   Note: the above assumes you use the default shell (zsh) that comes with
+   MacOS. If you customized MacOS to use a different shell, you'll need to modify
+   that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
+   to modify the same environment variables.
+
+5. Try running LAMMPS (which might fail, see step 7)
+
+   lmp -in ${LAMMPS_BENCH_DIR}/in.lj
+
+6. Try running the LAMMPS GUI
+
+   lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
+
+   Depending on the size and resolution of your screen, the fonts may
+   be too small to read. This can be adjusted by setting the environment
+   variable QT_FONT_DPI. The default value would be 72, so to increase
+   the fonts by a third one can add to the .zprofile file the line
+
+   export QT_FONT_DPI=96
+
+   and reload as shown above.
+
+7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
+
+   MacOS will likely block the initial run of the executables, since they
+   were downloaded from the internet and are missing a known signature from an
+   identified developer. Go to "Settings" and search for "Security settings". It
+   should display a message that an executable like "lmp" was blocked. Press
+   "Open anyway", which might prompt you for your admin credentials. Afterwards
+   "lmp" and the other executables should work as expected.

cmake/packaging/build_linux_tgz.sh

@@ -0,0 +1,77 @@
+#!/bin/bash
+
+APP_NAME=lammps-gui
+DESTDIR=${PWD}/../LAMMPS_GUI
+
+echo "Delete old files, if they exist"
+rm -rf ${DESTDIR} ../LAMMPS-Linux-amd64.tar.gz
+
+echo "Create staging area for deployment and populate"
+DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
+
+echo "Remove debug info"
+for s in ${DESTDIR}/bin/* ${DESTDIR}/lib/liblammps*
+do \
+        test -f $s && strip --strip-debug $s
+done
+
+echo "Remove libc, gcc, and X11 related shared libs"
+rm -f ${DESTDIR}/lib/ld*.so ${DESTDIR}/lib/ld*.so.[0-9]
+rm -f ${DESTDIR}/lib/lib{c,dl,rt,m,pthread}.so.?
+rm -f ${DESTDIR}/lib/lib{c,dl,rt,m,pthread}-[0-9].[0-9]*.so
+rm -f ${DESTDIR}/lib/libX* ${DESTDIR}/lib/libxcb*
+rm -f ${DESTDIR}/lib/libgcc_s*
+rm -f ${DESTDIR}/lib/libstdc++*
+
+# get qt dir
+QTDIR=$(ldd ${DESTDIR}/bin/lammps-gui | grep libQt5Core | sed -e 's/^.*=> *//' -e 's/libQt5Core.so.*$/qt5/')
+cat > ${DESTDIR}/bin/qt.conf <<EOF
+[Paths]
+Plugins = ../qt5plugins
+EOF
+
+# platform plugin
+mkdir -p ${DESTDIR}/qt5plugins/platforms
+cp ${QTDIR}/plugins/platforms/libqxcb.so ${DESTDIR}/qt5plugins/platforms
+
+# get platform plugin dependencies
+QTDEPS=$(LD_LIBRARY_PATH=${DESTDIR}/lib ldd ${QTDIR}/plugins/platforms/libqxcb.so | grep -v ${DESTDIR} | grep libQt5 | sed -e 's/^.*=> *//' -e 's/\(libQt5.*.so.*\) .*$/\1/')
+for dep in ${QTDEPS}
+do \
+    cp ${dep} ${DESTDIR}/lib
+done
+
+echo "Add additional plugins for Qt"
+for dir in styles imageformats
+do \
+    cp -r  ${QTDIR}/plugins/${dir} ${DESTDIR}/qt5plugins/
+done
+
+# get imageplugin dependencies
+for s in ${DESTDIR}/qt5plugins/imageformats/*.so
+do \
+    QTDEPS=$(LD_LIBRARY_PATH=${DESTDIR}/lib ldd $s | grep -v ${DESTDIR} | grep -E '(libQt5|jpeg)' | sed -e 's/^.*=> *//' -e 's/\(lib.*.so.*\) .*$/\1/')
+    for dep in ${QTDEPS}
+    do \
+        cp ${dep} ${DESTDIR}/lib
+    done
+done
+
+echo "Set up wrapper script"
+MYDIR=$(dirname "$0")
+cp ${MYDIR}/linux_wrapper.sh ${DESTDIR}/bin
+for s in ${DESTDIR}/bin/*
+do \
+        EXE=$(basename $s)
+        test ${EXE} = linux_wrapper.sh && continue
+        test ${EXE} = qt.conf && continue
+        ln -s bin/linux_wrapper.sh ${DESTDIR}/${EXE}
+done
+
+pushd ..
+tar -czvvf LAMMPS-Linux-amd64.tar.gz LAMMPS_GUI
+popd
+
+echo "Cleanup dir"
+rm -r ${DESTDIR}
+exit 0

cmake/packaging/build_macos_dmg.sh

@@ -0,0 +1,111 @@
+#!/bin/bash
+
+APP_NAME=lammps-gui
+
+echo "Delete old files, if they exist"
+rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS-macOS-multiarch.dmg
+
+echo "Create initial dmg file with macdeployqt"
+macdeployqt  lammps-gui.app -dmg
+echo "Create writable dmg file"
+hdiutil convert ${APP_NAME}.dmg -format UDRW -o ${APP_NAME}-rw.dmg
+
+echo "Mount writeable DMG file in read-write mode. Keep track of device and volume names"
+DEVICE=$(hdiutil attach -readwrite -noverify ${APP_NAME}-rw.dmg | grep '^/dev/' | sed 1q | awk '{print $1}')
+VOLUME=$(df | grep ${DEVICE} | sed -e 's/^.*\(\/Volumes\/\)/\1/')
+sleep 2
+
+echo "Create link to Application folder and move README and background image files"
+
+pushd "${VOLUME}"
+ln -s /Applications .
+mv  ${APP_NAME}.app/Contents/Resources/README.txt .
+mkdir  .background
+mv ${APP_NAME}.app/Contents/Resources/LAMMPS_DMG_Background.png .background/background.png
+mv ${APP_NAME}.app LAMMPS.app
+cd LAMMPS.app/Contents
+
+echo "Attach icons to LAMMPS console and GUI executables"
+echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
+Rez -a icon.rsrc -o bin/lmp
+SetFile -a C bin/lmp
+Rez -a icon.rsrc -o MacOS/lammps-gui
+SetFile -a C MacOS/lammps-gui
+rm icon.rsrc
+popd
+
+echo 'Tell the Finder to resize the window, set the background,'
+echo 'change the icon size, place the icons in the right position, etc.'
+echo '
+    tell application "Finder"
+    tell disk "'${APP_NAME}'"
+
+      -- wait for the image to finish mounting
+      set open_attempts to 0
+      repeat while open_attempts < 4
+        try
+          open
+            delay 1
+            set open_attempts to 5
+          close
+        on error errStr number errorNumber
+          set open_attempts to open_attempts + 1
+          delay 10
+        end try
+      end repeat
+      delay 5
+
+      -- open the image the first time and save a .DS_Store
+      -- just the background and icon setup
+      open
+        set current view of container window to icon view
+        set theViewOptions to the icon view options of container window
+        set background picture of theViewOptions to file ".background:background.png"
+        set arrangement of theViewOptions to not arranged
+        set icon size of theViewOptions to 64
+        delay 5
+      close
+
+      -- next set up the position of the app and Applications symlink
+      -- plus hide all window decorations
+      open
+        update without registering applications
+        tell container window
+          set sidebar width to 0
+          set statusbar visible to false
+          set toolbar visible to false
+          set the bounds to { 100, 40, 868, 640 }
+          set position of item "'LAMMPS'.app" to { 190, 216 }
+          set position of item "Applications" to { 576, 216 }
+          set position of item "README.txt" to { 190, 400 }
+        end tell
+        update without registering applications
+        delay 5
+      close
+
+      -- one last open and close to check the results
+      open
+        delay 5
+      close
+    end tell
+    delay 1
+  end tell
+' | osascript
+
+sync
+
+echo "Unmount modified disk image and convert to compressed read-only image"
+hdiutil detach "${DEVICE}"
+hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
+
+echo "Attach icon to .dmg file"
+echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
+Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
+SetFile -a C LAMMPS-macOS-multiarch.dmg
+rm icon.rsrc
+
+echo "Delete temporary disk images"
+rm -f "${APP_NAME}-rw.dmg"
+rm -f "${APP_NAME}.dmg"
+
+exit 0

cmake/packaging/build_windows_cross_zip.sh

@@ -0,0 +1,64 @@
+#!/bin/bash
+
+APP_NAME=lammps-gui
+DESTDIR=${PWD}/LAMMPS_GUI
+SYSROOT="$1"
+
+echo "Delete old files, if they exist"
+rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64.zip
+
+echo "Create staging area for deployment and populate"
+DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
+
+# no static libs needed
+rm -rvf ${DESTDIR}/lib
+# but the LAMMPS lib
+
+echo "Copying required DLL files"
+for dll in $(objdump -p *.exe *.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
+do \
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
+done
+
+echo "Copy required Qt plugins"
+mkdir -p ${DESTDIR}/qt5plugins
+for plugin in imageformats platforms styles
+do \
+    cp -r ${SYSROOT}/lib/qt5/plugins/${plugin} ${DESTDIR}/qt5plugins/
+done
+
+echo "Check dependencies of DLL files"
+for dll in $(objdump -p ${DESTDIR}/bin/*.dll ${DESTDIR}/qt5plugins/*/*.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
+do \
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
+done
+
+for dll in $(objdump -p ${DESTDIR}/bin/*.dll ${DESTDIR}/qt5plugins/*/*.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
+do \
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
+done
+
+cat > ${DESTDIR}/bin/qt.conf <<EOF
+[Paths]
+Plugins = ../qt5plugins
+EOF
+zip -9rvD LAMMPS-Win10-amd64.zip LAMMPS_GUI
+

cmake/packaging/build_windows_vs.cmake

@@ -0,0 +1,28 @@
+# CMake script to be run post installation to build zipped package
+
+# clean up old zipfile and deployment tree
+file(REMOVE LAMMPS-Win10-amd64.zip)
+file(REMOVE_RECURSE LAMMPS_GUI)
+file(RENAME ${INSTNAME} LAMMPS_GUI)
+
+# move all executables and dlls to main folder and delete bin folder
+file(GLOB BINFILES LIST_DIRECTORIES FALSE LAMMPS_GUI/bin/*.exe LAMMPS_GUI/bin/*.dll)
+foreach(bin ${BINFILES})
+  get_filename_component(exe ${bin} NAME)
+  file(RENAME ${bin} LAMMPS_GUI/${exe})
+endforeach()
+file(REMOVE_RECURSE LAMMPS_GUI/bin)
+
+# create qt.conf so Qt will find its plugins
+file(WRITE LAMMPS_GUI/qt.conf "[Paths]\r\nPlugins = qt5plugins\r\n")
+
+# initialize environment and then run windeployqt to populate folder with missing dependencies and Qt plugins
+file(WRITE qtdeploy.bat "@ECHO OFF\r\nset VSCMD_DEBUG=0\r\nCALL ${VC_INIT} x64\r\nset PATH=${QT5_BIN_DIR};%PATH%\r\nwindeployqt --plugindir LAMMPS_GUI/qt5plugins --release  LAMMPS_GUI/lammps-gui.exe --no-quick-import --no-webkit2 --no-translations --no-system-d3d-compiler --no-angle --no-opengl-sw\r\n")
+execute_process(COMMAND cmd.exe /c qtdeploy.bat COMMAND_ECHO STDERR)
+file(REMOVE qtdeploy.bat)
+
+# create zip archive
+file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS-Win10-amd64.zip")
+execute_process(COMMAND powershell -ExecutionPolicy Bypass -File makearchive.ps1)
+file(REMOVE makearchive.ps1)
+file(REMOVE_RECURSE LAMMPS_GUI)

cmake/packaging/linux_wrapper.sh

@@ -0,0 +1,18 @@
+#!/bin/sh
+# wrapper for bundled executables
+
+# reset locale to avoid problems with decimal numbers
+export LC_ALL=C
+
+BASEDIR=$(dirname "$0")
+EXENAME=$(basename "$0")
+
+# append to LD_LIBRARY_PATH to prefer local (newer) libs
+LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASEDIR}/lib
+
+# set some environment variables for LAMMPS etc.
+LAMMPS_POTENTIALS=${BASEDIR}/share/lammps/potentials
+MSI2LMP_LIBRARY=${BASEDIR}/share/lammps/frc_files
+export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY
+
+exec "${BASEDIR}/bin/${EXENAME}" "$@"

cmake/packaging/png2iconset.sh

@@ -0,0 +1,30 @@
+#!/bin/sh
+
+if [ $# != 2 ]
+then
+   echo "usage: $0 <pngfile> <iconset name>"
+   exit 1
+fi
+
+png="$1"
+ico="$2"
+
+if [ ! -f ${png} ]
+then
+   echo "PNG Image $1 not found"
+fi
+
+rm -rf ${ico}.iconset
+mkdir ${ico}.iconset
+sips -z   16   16 ${png} --out ${ico}.iconset/icon_16x16.png
+sips -z   32   32 ${png} --out ${ico}.iconset/icon_16x16@2x.png
+sips -z   32   32 ${png} --out ${ico}.iconset/icon_32x32.png
+sips -z   64   64 ${png} --out ${ico}.iconset/icon_32x32@2x.png
+sips -z  128  128 ${png} --out ${ico}.iconset/icon_128x128.png
+sips -z  256  256 ${png} --out ${ico}.iconset/icon_128x128@2x.png
+sips -z  256  256 ${png} --out ${ico}.iconset/icon_256x256.png
+sips -z  512  512 ${png} --out ${ico}.iconset/icon_256x256@2x.png
+sips -z  512  512 ${png} --out ${ico}.iconset/icon_512x512.png
+sips -z 1024 1024 ${png} --out ${ico}.iconset/icon_512x512@2x.png
+iconutil -c icns ${ico}.iconset
+rm -rf ${ico}.iconset

cmake/presets/all_off.cmake

@@ -43,7 +43,6 @@ set(ALL_PACKAGES
   KOKKOS
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/all_on.cmake

@@ -45,7 +45,6 @@ set(ALL_PACKAGES
   KOKKOS
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/download.cmake

@@ -1,14 +1,13 @@
 # Preset that turns on packages with automatic downloads of sources or potentials.
 # Compilation of libraries like Plumed or ScaFaCoS can take a considerable amount of time.
 
-set(ALL_PACKAGES KIM LATTE MSCG VORONOI PLUMED SCAFACOS MACHDYN MESONT MDI ML-PACE)
+set(ALL_PACKAGES KIM MSCG VORONOI PLUMED SCAFACOS MACHDYN MESONT MDI ML-PACE)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)
 endforeach()
 
 set(DOWNLOAD_KIM ON CACHE BOOL "" FORCE)
-set(DOWNLOAD_LATTE ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_MDI ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_MSCG ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)

cmake/presets/macos-multiarch.cmake

@@ -0,0 +1,14 @@
+# preset that will build portable multi-arch binaries on macOS without MPI
+
+set(CMAKE_OSX_ARCHITECTURES "arm64;x86_64" CACHE STRING "" FORCE)
+set(CMAKE_OSX_DEPLOYMENT_TARGET 11.0 CACHE STRING "" FORCE)
+set(CMAKE_BUILD_TYPE Release CACHE STRING "" FORCE)
+
+set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+
+set(BUILD_MPI FALSE CACHE BOOL "" FORCE)
+set(BUILD_SHARED_LIBS FALSE CACHE BOOL "" FORCE)
+set(LAMMPS_EXCEPTIONS TRUE CACHE BOOL "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -35,7 +35,6 @@ set(WIN_PACKAGES
   INTEL
   INTERLAYER
   KSPACE
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/nolib.cmake

@@ -12,7 +12,6 @@ set(PACKAGES_WITH_LIB
   KIM
   KOKKOS
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MDI

cmake/presets/windows.cmake

@@ -32,6 +32,7 @@ set(WIN_PACKAGES
   INTERLAYER
   KSPACE
   LEPTON
+  MACHDYN
   MANIFOLD
   MANYBODY
   MC
@@ -45,6 +46,7 @@ set(WIN_PACKAGES
   MOLECULE
   MOLFILE
   OPENMP
+  OPT
   ORIENT
   PERI
   PHONON

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "28 March 2023" "2023-03-28"
+.TH LAMMPS "1" "2 August 2023" "2023-08-2"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 28 March 2023
+\- Molecular Dynamics Simulator.  Version 2 August 2023
 
 .SH SYNOPSIS
 .B lmp

doc/src/Bibliography.rst

@@ -203,7 +203,7 @@ Bibliography
    A Caro, DA Crowson, M Caro; Phys Rev Lett, 95, 075702 (2005)
 
 **(CasP)**
-   CasP webpage: https://www.helmholtz-berlin.de/people/gregor-schiwietz/casp_en.html
+   CasP webpage: http://www.casp-program.org/
 
 **(Cawkwell2012)**
    A.\  M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86 (17), 174308 (2012).

doc/src/Build_basics.rst

@@ -128,14 +128,14 @@ and adds vectorization support when compiled with compatible compilers,
 in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
 package can be compiled to include OpenMP threading.
 
-In addition, there are a few commands in LAMMPS that have native OpenMP
-support included as well.  These are commands in the ``MPIIO``,
-``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.  Furthermore,
-some packages support OpenMP threading indirectly through the libraries
-they interface to: e.g. ``LATTE``, ``KSPACE``, and ``COLVARS``.  See the
-:doc:`Packages details <Packages_details>` page for more info on these
-packages, and the pages for their respective commands for OpenMP
-threading info.
+In addition, there are a few commands in LAMMPS that have native
+OpenMP support included as well.  These are commands in the ``MPIIO``,
+``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.
+Furthermore, some packages support OpenMP threading indirectly through
+the libraries they interface to: e.g. ``KSPACE``, and ``COLVARS``.
+See the :doc:`Packages details <Packages_details>` page for more info
+on these packages, and the pages for their respective commands for
+OpenMP threading info.
 
 For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
 and turn on their native OpenMP support and turn on their native OpenMP
@@ -489,8 +489,9 @@ using CMake or Make.
 
       .. code-block:: bash
 
-         -D BUILD_TOOLS=value         # yes or no (default)
-         -D BUILD_LAMMPS_SHELL=value  # yes or no (default)
+         -D BUILD_TOOLS=value         # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
+         -D BUILD_LAMMPS_SHELL=value  # yes or no (default). Build lammps-shell
+         -D BUILD_LAMMPS_GUI=value    # yes or no (default). Build lammps-gui
 
       The generated binaries will also become part of the LAMMPS installation
       (see below).
@@ -504,7 +505,6 @@ using CMake or Make.
          make binary2txt       # build only binary2txt tool
          make chain            # build only chain tool
          make micelle2d        # build only micelle2d tool
-         make thermo_extract   # build only thermo_extract tool
 
          cd lammps/tools/lammps-shell
          make                  # build LAMMPS shell

doc/src/Build_extras.rst

@@ -43,7 +43,6 @@ This is the list of packages that may require additional steps.
    * :ref:`INTEL <intel>`
    * :ref:`KIM <kim>`
    * :ref:`KOKKOS <kokkos>`
-   * :ref:`LATTE <latte>`
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
@@ -141,6 +140,8 @@ CMake build
                                 # value = yes or no (default)
    -D CUDA_MPS_SUPPORT=value    # enables some tweaks required to run with active nvidia-cuda-mps daemon
                                 # value = yes or no (default)
+   -D CUDA_BUILD_MULTIARCH=value  # enables building CUDA kernels for all supported GPU architectures
+                                  # value = yes (default) or no
    -D USE_STATIC_OPENCL_LOADER=value  # downloads/includes OpenCL ICD loader library, no local OpenCL headers/libs needed
                                       # value = yes (default) or no
 
@@ -159,41 +160,49 @@ CMake build
 A more detailed list can be found, for example,
 at `Wikipedia's CUDA article <https://en.wikipedia.org/wiki/CUDA#GPUs_supported>`_
 
-CMake can detect which version of the CUDA toolkit is used and thus will try
-to include support for **all** major GPU architectures supported by this toolkit.
-Thus the GPU_ARCH setting is merely an optimization, to have code for
-the preferred GPU architecture directly included rather than having to wait
-for the JIT compiler of the CUDA driver to translate it.
+CMake can detect which version of the CUDA toolkit is used and thus will
+try to include support for **all** major GPU architectures supported by
+this toolkit.  Thus the GPU_ARCH setting is merely an optimization, to
+have code for the preferred GPU architecture directly included rather
+than having to wait for the JIT compiler of the CUDA driver to translate
+it.  This behavior can be turned off (e.g. to speed up compilation) by
+setting :code:`CUDA_ENABLE_MULTIARCH` to :code:`no`.
 
-When compiling for CUDA or HIP with CUDA, version 8.0 or later of the CUDA toolkit
-is required and a GPU architecture of Kepler or later, which must *also* be
-supported by the CUDA toolkit in use **and** the CUDA driver in use.
-When compiling for OpenCL, OpenCL version 1.2 or later is required and the
-GPU must be supported by the GPU driver and OpenCL runtime bundled with the driver.
+When compiling for CUDA or HIP with CUDA, version 8.0 or later of the
+CUDA toolkit is required and a GPU architecture of Kepler or later,
+which must *also* be supported by the CUDA toolkit in use **and** the
+CUDA driver in use.  When compiling for OpenCL, OpenCL version 1.2 or
+later is required and the GPU must be supported by the GPU driver and
+OpenCL runtime bundled with the driver.
 
-When building with CMake, you **must NOT** build the GPU library in ``lib/gpu``
-using the traditional build procedure. CMake will detect files generated by that
-process and will terminate with an error and a suggestion for how to remove them.
+When building with CMake, you **must NOT** build the GPU library in
+``lib/gpu`` using the traditional build procedure. CMake will detect
+files generated by that process and will terminate with an error and a
+suggestion for how to remove them.
 
-If you are compiling for OpenCL, the default setting is to download, build, and
-link with a static OpenCL ICD loader library and standard OpenCL headers.  This
-way no local OpenCL development headers or library needs to be present and only
-OpenCL compatible drivers need to be installed to use OpenCL.  If this is not
-desired, you can set :code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
+If you are compiling for OpenCL, the default setting is to download,
+build, and link with a static OpenCL ICD loader library and standard
+OpenCL headers.  This way no local OpenCL development headers or library
+needs to be present and only OpenCL compatible drivers need to be
+installed to use OpenCL.  If this is not desired, you can set
+:code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
 
-The GPU library has some multi-thread support using OpenMP.  If LAMMPS is built
-with ``-D BUILD_OMP=on`` this will also be enabled.
+The GPU library has some multi-thread support using OpenMP.  If LAMMPS
+is built with ``-D BUILD_OMP=on`` this will also be enabled.
 
-If you are compiling with HIP, note that before running CMake you will have to
-set appropriate environment variables. Some variables such as
-:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
-and the linker to work correctly.
+If you are compiling with HIP, note that before running CMake you will
+have to set appropriate environment variables. Some variables such as
+:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are
+necessary for :code:`hipcc` and the linker to work correctly.
 
-Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
-code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
-set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
-yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
-should only use this option in preparations to run on Aurora system at ANL.
+.. versionadded:: 3Aug2022
+
+Using the CHIP-SPV implementation of HIP is supported. It allows one to
+run HIP code on Intel GPUs via the OpenCL or Level Zero backends. To use
+CHIP-SPV, you must set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake
+command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
+the use of HIP for Intel GPUs is experimental. You should only use this
+option in preparations to run on Aurora system at Argonne.
 
 .. code:: bash
 
@@ -684,20 +693,11 @@ This list was last updated for version 3.7.1 of the Kokkos library.
          -D Kokkos_ARCH_GPUARCH=yes    # GPUARCH = GPU from list above
          -D Kokkos_ENABLE_CUDA=yes
          -D Kokkos_ENABLE_OPENMP=yes
-         -D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper
 
       This will also enable executing FFTs on the GPU, either via the
       internal KISSFFT library, or - by preference - with the cuFFT
       library bundled with the CUDA toolkit, depending on whether CMake
-      can identify its location.  The *wrapper* value for
-      ``CMAKE_CXX_COMPILER`` variable is the path to the CUDA nvcc
-      compiler wrapper provided in the Kokkos library:
-      ``lib/kokkos/bin/nvcc_wrapper``\ .  The setting should include the
-      full path name to the wrapper, e.g.
-
-      .. code-block:: bash
-
-         -D CMAKE_CXX_COMPILER=${HOME}/lammps/lib/kokkos/bin/nvcc_wrapper
+      can identify its location.
 
       For AMD or NVIDIA GPUs using HIP, set these variables:
 
@@ -832,63 +832,6 @@ will thus always enable it.
 
 ----------
 
-.. _latte:
-
-LATTE package
--------------------------
-
-To build with this package, you must download and build the LATTE
-library.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_LATTE=value      # download LATTE for build, value = no (default) or yes
-         -D LATTE_LIBRARY=path        # LATTE library file (only needed if a custom location)
-         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
-                                      #   value = no (default) or yes
-
-      If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
-      and built inside the CMake build directory.  If the LATTE library
-      is already on your system (in a location CMake cannot find it),
-      ``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
-      file, not the directory the library file is in.
-
-      The LATTE library requires LAPACK (and BLAS) and CMake can identify
-      their locations and pass that info to the LATTE build script. But
-      on some systems this triggers a (current) limitation of CMake and
-      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
-      those cases to use the bundled linear algebra library and work around
-      the limitation.
-
-   .. tab:: Traditional make
-
-      You can download and build the LATTE library manually if you
-      prefer; follow the instructions in ``lib/latte/README``\ .  You
-      can also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invokes the
-      ``lib/latte/Install.py`` script with the specified args:
-
-      .. code-block:: bash
-
-         make lib-latte                        # print help message
-         make lib-latte args="-b"              # download and build in lib/latte/LATTE-master
-         make lib-latte args="-p $HOME/latte"  # use existing LATTE installation in $HOME/latte
-         make lib-latte args="-b -m gfortran"  # download and build in lib/latte and
-                                               #   copy Makefile.lammps.gfortran to Makefile.lammps
-
-      Note that 3 symbolic (soft) links, ``includelink`` and ``liblink``
-      and ``filelink.o``, are created in ``lib/latte`` to point to
-      required folders and files in the LATTE home directory.  When
-      LAMMPS itself is built it will use these links.  You should also
-      check that the ``Makefile.lammps`` file you create is appropriate
-      for the compiler you use on your system to build LATTE.
-
-----------
-
 .. _lepton:
 
 LEPTON package
@@ -938,6 +881,50 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
 
 ----------
 
+.. _machdyn:
+
+MACHDYN package
+-------------------------------
+
+To build with this package, you must download the Eigen3 library.
+Eigen3 is a template library, so you do not need to build it.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D DOWNLOAD_EIGEN3            # download Eigen3, value = no (default) or yes
+         -D EIGEN3_INCLUDE_DIR=path    # path to Eigen library (only needed if a custom location)
+
+      If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
+      downloaded and inside the CMake build directory.  If the Eigen3
+      library is already on your system (in a location where CMake
+      cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
+      ``Eigen3`` include file is in.
+
+   .. tab:: Traditional make
+
+      You can download the Eigen3 library manually if you prefer; follow
+      the instructions in ``lib/machdyn/README``.  You can also do it in one
+      step from the ``lammps/src`` dir, using a command like these,
+      which simply invokes the ``lib/machdyn/Install.py`` script with the
+      specified args:
+
+      .. code-block:: bash
+
+         make lib-machdyn                         # print help message
+         make lib-machdyn args="-b"               # download to lib/machdyn/eigen3
+         make lib-machdyn args="-p /usr/include/eigen3"    # use existing Eigen installation in /usr/include/eigen3
+
+      Note that a symbolic (soft) link named ``includelink`` is created
+      in ``lib/machdyn`` to point to the Eigen dir.  When LAMMPS builds it
+      will use this link.  You should not need to edit the
+      ``lib/machdyn/Makefile.lammps`` file.
+
+----------
+
 .. _mliap:
 
 ML-IAP package
@@ -1413,9 +1400,9 @@ This package depends on the KSPACE package.
       KSPACE package so the latter one *must* be enabled.
 
       The ELECTRODE package also requires LAPACK (and BLAS) and CMake
-      can identify their locations and pass that info to the LATTE build
-      script.  But on some systems this may cause problems when linking
-      or the dependency is not desired.  Try enabling
+      can identify their locations and pass that info to the ELECTRODE
+      build script.  But on some systems this may cause problems when
+      linking or the dependency is not desired.  Try enabling
       ``USE_INTERNAL_LINALG`` in those cases to use the bundled linear
       algebra library and work around the limitation.
 
@@ -1536,6 +1523,55 @@ ML-POD package
 
 ----------
 
+.. _ml-quip:
+
+ML-QUIP package
+---------------------------------
+
+To build with this package, you must download and build the QUIP
+library.  It can be obtained from GitHub.  For support of GAP
+potentials, additional files with specific licensing conditions need
+to be downloaded and configured.  The automatic download will from
+within CMake will download the non-commercial use version.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D DOWNLOAD_QUIP=value       # download QUIP library for build, value = no (default) or yes
+         -D QUIP_LIBRARY=path         # path to libquip.a (only needed if a custom location)
+         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+                                      #   value = no (default) or yes
+
+      CMake will try to download and build the QUIP library from GitHub,
+      if it is not found on the local machine. This requires to have git
+      installed. It will use the same compilers and flags as used for
+      compiling LAMMPS.  Currently this is only supported for the GNU
+      and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
+      want to use a previously compiled and installed QUIP library and
+      CMake cannot find it.
+
+      The QUIP library requires LAPACK (and BLAS) and CMake can identify
+      their locations and pass that info to the QUIP build script. But
+      on some systems this triggers a (current) limitation of CMake and
+      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+      those cases to use the bundled linear algebra library and work around
+      the limitation.
+
+   .. tab:: Traditional make
+
+      The download/build procedure for the QUIP library, described in
+      ``lib/quip/README`` file requires setting two environment
+      variables, ``QUIP_ROOT`` and ``QUIP_ARCH``.  These are accessed by
+      the ``lib/quip/Makefile.lammps`` file which is used when you
+      compile and link LAMMPS with this package.  You should only need
+      to edit ``Makefile.lammps`` if the LAMMPS build can not use its
+      settings to successfully build on your system.
+
+----------
+
 .. _plumed:
 
 PLUMED package
@@ -2057,55 +2093,6 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
 
 ----------
 
-.. _ml-quip:
-
-ML-QUIP package
----------------------------------
-
-To build with this package, you must download and build the QUIP
-library.  It can be obtained from GitHub.  For support of GAP
-potentials, additional files with specific licensing conditions need
-to be downloaded and configured.  The automatic download will from
-within CMake will download the non-commercial use version.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_QUIP=value       # download QUIP library for build, value = no (default) or yes
-         -D QUIP_LIBRARY=path         # path to libquip.a (only needed if a custom location)
-         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
-                                      #   value = no (default) or yes
-
-      CMake will try to download and build the QUIP library from GitHub,
-      if it is not found on the local machine. This requires to have git
-      installed. It will use the same compilers and flags as used for
-      compiling LAMMPS.  Currently this is only supported for the GNU
-      and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
-      want to use a previously compiled and installed QUIP library and
-      CMake cannot find it.
-
-      The QUIP library requires LAPACK (and BLAS) and CMake can identify
-      their locations and pass that info to the QUIP build script. But
-      on some systems this triggers a (current) limitation of CMake and
-      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
-      those cases to use the bundled linear algebra library and work around
-      the limitation.
-
-   .. tab:: Traditional make
-
-      The download/build procedure for the QUIP library, described in
-      ``lib/quip/README`` file requires setting two environment
-      variables, ``QUIP_ROOT`` and ``QUIP_ARCH``.  These are accessed by
-      the ``lib/quip/Makefile.lammps`` file which is used when you
-      compile and link LAMMPS with this package.  You should only need
-      to edit ``Makefile.lammps`` if the LAMMPS build can not use its
-      settings to successfully build on your system.
-
-----------
-
 .. _scafacos:
 
 SCAFACOS package
@@ -2153,50 +2140,6 @@ To build with this package, you must download and build the
 
 ----------
 
-.. _machdyn:
-
-MACHDYN package
--------------------------------
-
-To build with this package, you must download the Eigen3 library.
-Eigen3 is a template library, so you do not need to build it.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_EIGEN3            # download Eigen3, value = no (default) or yes
-         -D EIGEN3_INCLUDE_DIR=path    # path to Eigen library (only needed if a custom location)
-
-      If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
-      downloaded and inside the CMake build directory.  If the Eigen3
-      library is already on your system (in a location where CMake
-      cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
-      ``Eigen3`` include file is in.
-
-   .. tab:: Traditional make
-
-      You can download the Eigen3 library manually if you prefer; follow
-      the instructions in ``lib/smd/README``.  You can also do it in one
-      step from the ``lammps/src`` dir, using a command like these,
-      which simply invokes the ``lib/smd/Install.py`` script with the
-      specified args:
-
-      .. code-block:: bash
-
-         make lib-smd                         # print help message
-         make lib-smd args="-b"               # download to lib/smd/eigen3
-         make lib-smd args="-p /usr/include/eigen3"    # use existing Eigen installation in /usr/include/eigen3
-
-      Note that a symbolic (soft) link named ``includelink`` is created
-      in ``lib/smd`` to point to the Eigen dir.  When LAMMPS builds it
-      will use this link.  You should not need to edit the
-      ``lib/smd/Makefile.lammps`` file.
-
-----------
-
 .. _vtk:
 
 VTK package

doc/src/Build_make.rst

@@ -117,8 +117,8 @@ their settings may become outdated, too:
 
 .. code-block:: bash
 
-   make mac             # build serial LAMMPS on a Mac
-   make mac_mpi         # build parallel LAMMPS on a Mac
+   make mac             # build serial LAMMPS on macOS
+   make mac_mpi         # build parallel LAMMPS on macOS
    make intel_cpu       # build with the INTEL package optimized for CPUs
    make knl             # build with the INTEL package optimized for KNLs
    make opt             # build with the OPT package optimized for CPUs

doc/src/Build_manual.rst

@@ -53,10 +53,10 @@ incorporates programmer documentation extracted from the LAMMPS C++
 sources through the `Doxygen <https://doxygen.nl/>`_ program.  Currently
 the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
 and MOBI (for Amazon Kindle readers) are supported.  For that to work a
-Python 3 interpreter, the ``doxygen`` tools and internet access to
-download additional files and tools are required.  This download is
-usually only required once or after the documentation folder is returned
-to a pristine state with ``make clean-all``.
+Python interpreter version 3.8 or later, the ``doxygen`` tools and
+internet access to download additional files and tools are required.
+This download is usually only required once or after the documentation
+folder is returned to a pristine state with ``make clean-all``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into

doc/src/Build_package.rst

@@ -46,7 +46,6 @@ packages:
    * :ref:`INTEL <intel>`
    * :ref:`KIM <kim>`
    * :ref:`KOKKOS <kokkos>`
-   * :ref:`LATTE <latte>`
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`

doc/src/Commands_compute.rst

@@ -46,6 +46,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`com/chunk <compute_com_chunk>`
    * :doc:`contact/atom <compute_contact_atom>`
    * :doc:`coord/atom (k) <compute_coord_atom>`
+   * :doc:`count/type <compute_count_type>`
    * :doc:`damage/atom <compute_damage_atom>`
    * :doc:`dihedral <compute_dihedral>`
    * :doc:`dihedral/local <compute_dihedral_local>`
@@ -63,7 +64,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`entropy/atom <compute_entropy_atom>`
    * :doc:`erotate/asphere <compute_erotate_asphere>`
    * :doc:`erotate/rigid <compute_erotate_rigid>`
-   * :doc:`erotate/sphere <compute_erotate_sphere>`
+   * :doc:`erotate/sphere (k) <compute_erotate_sphere>`
    * :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>`
    * :doc:`event/displace <compute_event_displace>`
    * :doc:`fabric <compute_fabric>`
@@ -152,11 +153,11 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`sph/t/atom <compute_sph_t_atom>`
    * :doc:`spin <compute_spin>`
    * :doc:`stress/atom <compute_stress_atom>`
-   * :doc:`stress/cartesian <compute_stress_profile>`
-   * :doc:`stress/cylinder <compute_stress_profile>`
+   * :doc:`stress/cartesian <compute_stress_cartesian>`
+   * :doc:`stress/cylinder <compute_stress_curvilinear>`
    * :doc:`stress/mop <compute_stress_mop>`
    * :doc:`stress/mop/profile <compute_stress_mop>`
-   * :doc:`stress/spherical <compute_stress_profile>`
+   * :doc:`stress/spherical <compute_stress_curvilinear>`
    * :doc:`stress/tally <compute_tally>`
    * :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>`
    * :doc:`temp (k) <compute_temp>`

doc/src/Commands_fix.rst

@@ -104,7 +104,6 @@ OPT.
    * :doc:`langevin/drude <fix_langevin_drude>`
    * :doc:`langevin/eff <fix_langevin_eff>`
    * :doc:`langevin/spin <fix_langevin_spin>`
-   * :doc:`latte <fix_latte>`
    * :doc:`lb/fluid <fix_lb_fluid>`
    * :doc:`lb/momentum <fix_lb_momentum>`
    * :doc:`lb/viscous <fix_lb_viscous>`
@@ -172,6 +171,7 @@ OPT.
    * :doc:`pafi <fix_pafi>`
    * :doc:`pair <fix_pair>`
    * :doc:`phonon <fix_phonon>`
+   * :doc:`pimd/langevin <fix_pimd>`
    * :doc:`pimd/nvt <fix_pimd>`
    * :doc:`planeforce <fix_planeforce>`
    * :doc:`plumed <fix_plumed>`
@@ -261,7 +261,7 @@ OPT.
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`
    * :doc:`wall/ees <fix_wall_ees>`
-   * :doc:`wall/gran <fix_wall_gran>`
+   * :doc:`wall/gran (k) <fix_wall_gran>`
    * :doc:`wall/gran/region <fix_wall_gran_region>`
    * :doc:`wall/harmonic <fix_wall>`
    * :doc:`wall/lj1043 <fix_wall>`

doc/src/Commands_pair.rst

@@ -37,6 +37,7 @@ OPT.
    *
    * :doc:`adp (ko) <pair_adp>`
    * :doc:`agni (o) <pair_agni>`
+   * :doc:`aip/water/2dm (t) <pair_aip_water_2dm>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
    * :doc:`amoeba (g) <pair_amoeba>`
@@ -137,6 +138,7 @@ OPT.
    * :doc:`lennard/mdf <pair_mdf>`
    * :doc:`lepton (o) <pair_lepton>`
    * :doc:`lepton/coul (o) <pair_lepton>`
+   * :doc:`lepton/sphere (o) <pair_lepton>`
    * :doc:`line/lj <pair_line_lj>`
    * :doc:`lj/charmm/coul/charmm (giko) <pair_charmm>`
    * :doc:`lj/charmm/coul/charmm/implicit (ko) <pair_charmm>`
@@ -171,12 +173,14 @@ OPT.
    * :doc:`lj/cut/dipole/long (g) <pair_dipole>`
    * :doc:`lj/cut/dipole/sf (go) <pair_dipole>`
    * :doc:`lj/cut/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/sphere (o) <pair_lj_cut_sphere>`
    * :doc:`lj/cut/thole/long (o) <pair_thole>`
    * :doc:`lj/cut/tip4p/cut (o) <pair_lj_cut_tip4p>`
    * :doc:`lj/cut/tip4p/long (got) <pair_lj_cut_tip4p>`
    * :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
    * :doc:`lj/expand (gko) <pair_lj_expand>`
    * :doc:`lj/expand/coul/long (gk) <pair_lj_expand>`
+   * :doc:`lj/expand/sphere (o) <pair_lj_expand_sphere>`
    * :doc:`lj/gromacs (gko) <pair_gromacs>`
    * :doc:`lj/gromacs/coul/gromacs (ko) <pair_gromacs>`
    * :doc:`lj/long/coul/long (iot) <pair_lj_long>`

doc/src/Commands_removed.rst

@@ -38,6 +38,20 @@ been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
 present, LAMMPS will replace the commands accordingly and print a
 warning.
 
+LATTE package
+-------------
+
+.. deprecated:: 15Jun2023
+
+The LATTE package with the fix latte command was removed from LAMMPS.
+This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
+and :doc:`fix mdi/qmmm <fix_mdi_qmmm>` from the :ref:`MDI package
+<PKG-MDI>`.  These fixes are compatible with several quantum software
+packages, including LATTE.  See the ``examples/QUANTUM`` dir and the
+:doc:`MDI coupling HOWTO <Howto_mdi>` page.  MDI supports running LAMMPS
+with LATTE as a plugin library (similar to the way fix latte worked), as
+well as on a different set of MPI processors.
+
 MEAM package
 ------------
 

doc/src/Developer.rst

@@ -13,6 +13,7 @@ of time and requests from the LAMMPS user community.
    Developer_org
    Developer_code_design
    Developer_parallel
+   Developer_atom
    Developer_comm_ops
    Developer_flow
    Developer_write

doc/src/Developer_atom.rst

@@ -0,0 +1,88 @@
+Accessing per-atom data
+-----------------------
+
+This page discusses how per-atom data is managed in LAMMPS, how it can
+be accessed, what communication patters apply, and some of the utility
+functions that exist for a variety of purposes.
+
+
+Owned and ghost atoms
+^^^^^^^^^^^^^^^^^^^^^
+
+As described on the :doc:`parallel partitioning algorithms
+<Developer_par_part>` page, LAMMPS uses a domain decomposition of the
+simulation domain, either in a *brick* or *tiled* manner.  Each MPI
+process *owns* exactly one subdomain and the atoms within it. To compute
+forces for tuples of atoms that are spread across sub-domain boundaries,
+also a "halo" of *ghost* atoms are maintained within a the communication
+cutoff distance of its subdomain.
+
+The total number of atoms is stored in `Atom::natoms` (within any
+typical class this can be referred to at `atom->natoms`. The number of
+*owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of
+*ghost* atoms is stored in `Atom::nghost`.  The sum of `Atom::nlocal`
+over all MPI processes should be `Atom::natoms`. This is by default
+regularly checked by the Thermo class, and if the sum does not match,
+LAMMPS stops with a "lost atoms" error.  For convenience also the
+property `Atom::nmax` is available, this is the maximum of
+`Atom::nlocal + Atom::nghost` across all MPI processes.
+
+Per-atom properties are either managed by the atom style, or individual
+classes.  or as custom arrays by the individual classes. If only access
+to *owned* atoms is needed, they are usually allocated to be of size
+`Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all
+per-atom properties are available or updated on *ghost* atoms. For
+example, per-atom velocities are only updated with :doc:`comm_modify vel
+yes <comm_modify>`.
+
+
+Atom indexing
+^^^^^^^^^^^^^
+
+When referring to individual atoms, they may be indexed by their local
+*index*, their index in their `Atom::x` array. This is densely populated
+containing first all *owned* atoms (index < `Atom::nlocal`) and then all
+*ghost* atoms.  The order of atoms in these arrays can change due to
+atoms migrating between between subdomains, atoms being added or
+deleted, or atoms being sorted for better cache efficiency.  Atoms are
+globally uniquely identified by their *atom ID*. There may be multiple
+atoms with the same atom ID present, but only one of them may be an
+*owned* atom.
+
+To find the local *index* of an atom, when the *atom ID* is known, the
+`Atom::map()` function may be used. It will return the local atom index
+or -1. If the returned value is between 0 (inclusive) and `Atom::nlocal`
+(exclusive) it is an *owned* or "local" atom; for larger values the atom
+is present as a ghost atom; for a value of -1, the atom is not present
+on the current subdomain at all.
+
+If multiple atoms with the same tag exist in the same subdomain, they
+can be found via the `Atom::sametag` array. It points to the next atom
+index with the same tag or -1 if there are no more atoms with the same
+tag.  The list will be exhaustive when starting with an index of an
+*owned* atom, since the atom IDs are unique, so there can only be one
+such atom.  Example code to count atoms with same atom ID in subdomain:
+
+.. code-block:: c++
+
+   for (int i = 0; i < atom->nlocal; ++i) {
+     int count = 0;
+     while (sametag[i] >= 0) {
+       i = sametag[i];
+       ++count;
+     }
+     printf("Atom ID: %ld is present %d times\n", atom->tag[i], count);
+   }
+
+Atom class versus AtomVec classes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The `Atom` class contains all kinds of flags and counters about atoms in
+the system and that includes pointers to **all** per-atom properties
+available for atoms.  However, only a subset of these pointers are
+non-NULL and which those are depends on the atom style.  For each atom
+style there is a corresponding `AtomVecXXX` class derived from the
+`AtomVec` base class, where the XXX indicates the atom style.  This
+`AtomVecXXX` class will update the counters and per-atom pointers if
+atoms are added or removed to the system or migrate between subdomains.
+

doc/src/Developer_grid.rst

@@ -92,8 +92,8 @@ Arguments for these methods can be values returned by the
 *setup_grid()* method (described below), which define the extent of
 the grid cells (owned+ghost) the processor owns.  These 4 methods
 allocate memory for 2d (first two) and 3d (second two) grid data.  The
-two methods that end in "_one" allocate an array which stores a single
-value per grid cell.  The two that end in "_multi" allocate an array
+two methods that end in "_offset" allocate an array which stores a single
+value per grid cell.  The two that end in "_last" allocate an array
 which stores *Nvalues* per grid cell.
 
 .. code-block:: c++

doc/src/Examples.rst

@@ -94,8 +94,6 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | kim         | use of potentials from the `OpenKIM Repository <openkim_>`_      |
 +-------------+------------------------------------------------------------------+
-| latte       | examples for using fix latte for DFTB via the LATTE library      |
-+-------------+------------------------------------------------------------------+
 | mdi         | use of the MDI package and MolSSI MDI code coupling library      |
 +-------------+------------------------------------------------------------------+
 | meam        | MEAM test for SiC and shear (same as shear examples)             |

doc/src/Fortran.rst

@@ -56,17 +56,6 @@ C++ in the ``examples/COUPLE/simple`` folder of the LAMMPS distribution.
    and Ubuntu 18.04 LTS and not compatible.  Either newer compilers
    need to be installed or the Linux updated.
 
-.. versionchanged:: 8Feb2023
-
-.. note::
-
-   A contributed Fortran interface is available in the
-   ``examples/COUPLE/fortran2`` folder.  However, since the completion
-   of the :f:mod:`LIBLAMMPS` module, this interface is now deprecated,
-   no longer actively maintained and will likely be removed in the
-   future.  Please see the ``README`` file in that folder for more
-   information about it and how to contact its author and maintainer.
-
 ----------
 
 Creating or deleting a LAMMPS object
@@ -203,40 +192,62 @@ Below is an example demonstrating some of the possible uses.
 
 .. code-block:: fortran
 
-  PROGRAM testprop
-    USE LIBLAMMPS
-    USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t
-    USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : OUTPUT_UNIT
-    TYPE(lammps) :: lmp
-    INTEGER(KIND=c_int64_t), POINTER :: natoms
-    REAL(KIND=c_double), POINTER :: dt
-    INTEGER(KIND=c_int64_t), POINTER :: ntimestep
-    REAL(KIND=c_double) :: pe, ke
+   PROGRAM testprop
+     USE LIBLAMMPS
+     USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
+     USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : OUTPUT_UNIT
+     TYPE(lammps) :: lmp
+     INTEGER(KIND=c_int64_t), POINTER :: natoms, ntimestep, bval
+     REAL(KIND=c_double), POINTER :: dt, dval
+     INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
+     INTEGER(KIND=c_int) :: i
+     CHARACTER(LEN=11) :: key
+     REAL(KIND=c_double) :: pe, ke
 
-    lmp = lammps()
-    CALL lmp%file('in.sysinit')
-    natoms = lmp%extract_global('natoms')
-    WRITE(OUTPUT_UNIT,'(A,I0,A)') 'Running a simulation with ', natoms, ' atoms'
-    WRITE(OUTPUT_UNIT,'(I0,A,I0,A,I0,A)') lmp%extract_setting('nlocal'), &
-        ' local and ', lmp%extract_setting('nghost'), ' ghost atoms. ', &
-        lmp%extract_setting('ntypes'), ' atom types'
+     lmp = lammps()
+     CALL lmp%file('in.sysinit')
+     natoms = lmp%extract_global('natoms')
+     WRITE(OUTPUT_UNIT,'(A,I0,A)') 'Running a simulation with ', natoms, ' atoms'
+     WRITE(OUTPUT_UNIT,'(I0,A,I0,A,I0,A)') lmp%extract_setting('nlocal'), &
+         ' local and ', lmp%extract_setting('nghost'), ' ghost atoms. ', &
+         lmp%extract_setting('ntypes'), ' atom types'
 
-    CALL lmp%command('run 2 post no')
-    dt = lmp%extract_global('dt')
-    ntimestep = lmp%extract_global('ntimestep')
-    WRITE(OUTPUT_UNIT,'(A,I0,A,F4.1,A)') 'At step: ', ntimestep, &
-        '  Changing timestep from', dt, ' to 0.5'
-    dt = 0.5_c_double
-    CALL lmp%command('run 2 post no')
+     CALL lmp%command('run 2 post no')
 
-    WRITE(OUTPUT_UNIT,'(A,I0)') 'At step: ', ntimestep
-    pe = lmp%get_thermo('pe')
-    ke = lmp%get_thermo('ke')
-    PRINT*, 'PE = ', pe
-    PRINT*, 'KE = ', ke
+     ntimestep = lmp%last_thermo('step', 0)
+     nfield = lmp%last_thermo('num', 0)
+     WRITE(OUTPUT_UNIT,'(A,I0,A,I0)') 'Last thermo output on step: ', ntimestep, &
+         ',  number of fields: ', nfield
+     DO i=1, nfield
+         key = lmp%last_thermo('keyword',i)
+         typ = lmp%last_thermo('type',i)
+         IF (typ == lmp%dtype%i32) THEN
+             ival = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', ival
+         ELSE IF (typ == lmp%dtype%i64) THEN
+             bval = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', bval
+         ELSE IF (typ == lmp%dtype%r64) THEN
+             dval = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', dval
+         END IF
+     END DO
 
-    CALL lmp%close(.TRUE.)
-  END PROGRAM testprop
+     dt = lmp%extract_global('dt')
+     ntimestep = lmp%extract_global('ntimestep')
+     WRITE(OUTPUT_UNIT,'(A,I0,A,F4.1,A)') 'At step: ', ntimestep, &
+         '  Changing timestep from', dt, ' to 0.5'
+     dt = 0.5_c_double
+     CALL lmp%command('run 2 post no')
+
+     WRITE(OUTPUT_UNIT,'(A,I0)') 'At step: ', ntimestep
+     pe = lmp%get_thermo('pe')
+     ke = lmp%get_thermo('ke')
+     WRITE(OUTPUT_UNIT,*) 'PE = ', pe
+     WRITE(OUTPUT_UNIT,*) 'KE = ', ke
+
+     CALL lmp%close(.TRUE.)
+   END PROGRAM testprop
 
 ---------------
 
@@ -262,6 +273,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype style: type(lammps_style)
    :f type: derived type to access lammps type constants
    :ftype type: type(lammps_type)
+   :f dtype: derived type to access lammps data type constants
+   :ftype dtype: type(lammps_dtype)
    :f close: :f:subr:`close`
    :ftype close: subroutine
    :f subroutine error: :f:subr:`error`
@@ -278,6 +291,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype get_natoms: function
    :f get_thermo: :f:func:`get_thermo`
    :ftype get_thermo: function
+   :f last_thermo: :f:func:`last_thermo`
+   :ftype last_thermo: function
    :f extract_box: :f:subr:`extract_box`
    :ftype extract_box: subroutine
    :f reset_box: :f:subr:`reset_box`
@@ -587,6 +602,96 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
+.. f:function:: last_thermo(what, index)
+
+   This function will call :cpp:func:`lammps_last_thermo` and returns
+   either a string or a pointer to a cached copy of LAMMPS last thermodynamic
+   output, depending on the data requested through *what*.  Note that *index*
+   uses 1-based indexing to access thermo output columns.
+
+   .. versionadded:: 15Jun2023
+
+   Note that this function actually does not return a value, but rather
+   associates the pointer on the left side of the assignment to point to
+   internal LAMMPS data (with the exception of string data, which are
+   copied and returned as ordinary Fortran strings).  Pointers must be
+   of the correct data type to point to said data (typically
+   ``INTEGER(c_int)``, ``INTEGER(c_int64_t)``, or ``REAL(c_double)``).
+   The pointer being associated with LAMMPS data is type-checked at
+   run-time via an overloaded assignment operator.  The pointers
+   returned by this function point to temporary, read-only data that may
+   be overwritten at any time, so their target values need to be copied
+   to local storage if they are supposed to persist.
+
+   For example,
+
+   .. code-block:: fortran
+
+      PROGRAM thermo
+        USE LIBLAMMPS
+        USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
+        TYPE(lammps) :: lmp
+        INTEGER(KIND=c_int64_t), POINTER :: ntimestep, bval
+        REAL(KIND=c_double), POINTER :: dval
+        INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
+        INTEGER(KIND=c_int) :: i
+        CHARACTER(LEN=11) :: key
+
+        lmp = lammps()
+        CALL lmp%file('in.sysinit')
+
+        ntimestep = lmp%last_thermo('step', 0)
+        nfield = lmp%last_thermo('num', 0)
+        PRINT*, 'Last thermo output on step: ', ntimestep, '  Number of fields: ', nfield
+        DO i=1, nfield
+            key = lmp%last_thermo('keyword',i)
+            typ = lmp%last_thermo('type',i)
+            IF (typ == lmp%dtype%i32) THEN
+                ival = lmp%last_thermo('data',i)
+                PRINT*, key, ':', ival
+            ELSE IF (typ == lmp%dtype%i64) THEN
+                bval = lmp%last_thermo('data',i)
+                PRINT*, key, ':', bval
+            ELSE IF (typ == lmp%dtype%r64) THEN
+                dval = lmp%last_thermo('data',i)
+                PRINT*, key, ':', dval
+            END IF
+        END DO
+        CALL lmp%close(.TRUE.)
+      END PROGRAM thermo
+
+   would extract the last timestep where thermo output was done and the number
+   of columns it printed.  Then it loops over the columns to print out column
+   header keywords and the corresponding data.
+
+   .. note::
+
+      If :f:func:`last_thermo` returns a string, the string must have a length
+      greater than or equal to the length of the string (not including the
+      terminal ``NULL`` character) that LAMMPS returns. If the variable's
+      length is too short, the string will be truncated.  As usual in Fortran,
+      strings are padded with spaces at the end.  If you use an allocatable
+      string, the string **must be allocated** prior to calling this function.
+
+   :p character(len=\*) what: string with the name of the thermo keyword
+   :p integer(c_int) index: 1-based column index
+   :to: :cpp:func:`lammps_last_thermo`
+   :r pointer [polymorphic]: pointer to LAMMPS data. The left-hand side of the
+    assignment should be either a string (if expecting string data) or a
+    C-compatible pointer (e.g., ``INTEGER(c_int), POINTER :: nlocal``) to the
+    extracted property.
+
+   .. warning::
+
+       Modifying the data in the location pointed to by the returned pointer
+       may lead to inconsistent internal data and thus may cause failures,
+       crashes, or bogus simulations.  In general, it is much better
+       to use a LAMMPS input command that sets or changes these parameters.
+       Using an input command will take care of all side effects and necessary
+       updates of settings derived from such settings.
+
+--------
+
 .. f:subroutine:: extract_box([boxlo][, boxhi][, xy][, yz][, xz][, pflags][, boxflag])
 
    This subroutine will call :cpp:func:`lammps_extract_box`. All
@@ -764,13 +869,14 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    .. note::
 
-      If :f:func:`extract_global` returns a string, the string must have length
-      greater than or equal to the length of the string (not including the
-      terminal ``NULL`` character) that LAMMPS returns. If the variable's
-      length is too short, the string will be truncated. As usual in Fortran,
-      strings are padded with spaces at the end. If you use an allocatable
-      string, the string **must be allocated** prior to calling this function,
-      but you can automatically reallocate it to the correct length after the
+      If :f:func:`extract_global` returns a string, the string must have
+      a length greater than or equal to the length of the string (not
+      including the terminal ``NULL`` character) that LAMMPS returns. If
+      the variable's length is too short, the string will be
+      truncated. As usual in Fortran, strings are padded with spaces at
+      the end. If you use an allocatable string, the string **must be
+      allocated** prior to calling this function, but you can
+      automatically reallocate it to the correct length after the
       function returns, viz.,
 
       .. code-block :: fortran

doc/src/Howto.rst

@@ -23,7 +23,6 @@ General howto
    Howto_library
    Howto_couple
    Howto_mdi
-   Howto_bpm
    Howto_broken_bonds
 
 Settings howto
@@ -83,6 +82,7 @@ Packages howto
    Howto_spherical
    Howto_granular
    Howto_body
+   Howto_bpm
    Howto_polarizable
    Howto_coreshell
    Howto_drude
@@ -100,6 +100,7 @@ Tutorials howto
 
    Howto_cmake
    Howto_github
+   Howto_lammps_gui
    Howto_pylammps
    Howto_wsl
 

doc/src/Howto_2d.rst

@@ -13,9 +13,9 @@ box with a single z plane of atoms - e.g.
 
 .. code-block:: LAMMPS
 
-   create box 1 -10 10 -10 10 -0.25 0.25
+   create_box 1 -10 10 -10 10 -0.25 0.25
 
-If using the :doc:`read data <read_data>` command to read in a file of
+If using the :doc:`read_data <read_data>` command to read in a file of
 atom coordinates, set the "zlo zhi" values to be finite but narrow,
 similar to the create_box command settings just described.  For each
 atom in the file, assign a z coordinate so it falls inside the

doc/src/Howto_bpm.rst

@@ -79,9 +79,9 @@ As bonds can be broken between neighbor list builds, the
 bond styles. There are two possible settings which determine how pair
 interactions work between bonded particles.  First, one can overlay
 pair forces with bond forces such that all bonded particles also
-feel pair interactions. This can be accomplished by using the *overlay/pair*
-keyword present in all bpm bond styles and by using the following special
-bond settings
+feel pair interactions. This can be accomplished by setting the *overlay/pair*
+keyword present in all bpm bond styles to *yes* and requires using the
+following special bond settings
 
    .. code-block:: LAMMPS
 
@@ -107,7 +107,17 @@ bond lists is expensive.  By setting the lj weight for 1-2 bonds to
 zero, this turns off pairwise interactions.  Even though there are no
 charges in BPM models, setting a nonzero coul weight for 1-2 bonds
 ensures all bonded neighbors are still included in the neighbor list
-in case bonds break between neighbor list builds.
+in case bonds break between neighbor list builds. If bond breakage is
+disabled during a simulation run by setting the *break* keyword to *no*,
+a zero coul weight for 1-2 bonds can be used to exclude bonded atoms
+from the neighbor list builds
+
+   .. code-block:: LAMMPS
+
+      special_bonds lj 0 1 1 coul 0 1 1
+
+This can be useful for post-processing, or to determine pair interaction
+properties between distinct bonded particles.
 
 To monitor the fracture of bonds in the system, all BPM bond styles
 have the ability to record instances of bond breakage to output using

doc/src/Howto_broken_bonds.rst

@@ -1,48 +1,56 @@
 Broken Bonds
 ============
 
-Typically, bond interactions persist for the duration of a simulation in
-LAMMPS. However, there are some exceptions that allow for bonds to
-break, including the :doc:`quartic bond style <bond_quartic>` and the
-bond styles in the :doc:`BPM package <Howto_bpm>` which contains the
-:doc:`bpm/spring <bond_bpm_spring>` and :doc:`bpm/rotational
-<bond_bpm_rotational>` bond styles. In these cases, a bond can be broken
-if it is stretched beyond a user-defined threshold.  LAMMPS accomplishes
-this by setting the bond type to 0, such that the bond force is no
-longer computed.
+Typically, molecular bond interactions persist for the duration of a
+simulation in LAMMPS.  However, some commands break bonds dynamically,
+including the following:
 
-Users are normally able to weight the contribution of pair forces to atoms
-that are bonded using the :doc:`special_bonds command <special_bonds>`.
-When bonds break, this is not always the case. For the quartic bond style,
-pair forces are always turned off between bonded particles. LAMMPS does
-this via a computational sleight-of-hand. It subtracts the pairwise
-interaction as part of the bond computation. When the bond breaks, the
-subtraction stops.  For this to work, the pairwise interaction must always
-be computed by the :doc:`pair_style <pair_style>` command, whether the bond
-is broken or not.  This means that :doc:`special_bonds <special_bonds>` must
-be set to 1,1,1. After the bond breaks, the pairwise interaction between the
-two atoms is turned on, since they are no longer bonded.
+* :doc:`bond_style quartic <bond_quartic>`
+* :doc:`fix bond/break <fix_bond_break>`
+* :doc:`fix bond/react <fix_bond_react>`
+* :doc:`BPM package <Howto_bpm>` bond styles
 
-In the BPM package, one can either turn off all pair interactions between
-bonded particles or leave them on, overlaying pair forces on top of bond
-forces. To remove pair forces, the special bond list is dynamically
-updated. More details can be found on the :doc:`Howto BPM <Howto_bpm>`
-page.
+A bond can break if it is stretched beyond a user-defined threshold or
+more generally if other criteria are met.
 
-Bonds can also be broken by fixes which change bond topology, including
-:doc:`fix bond/break <fix_bond_break>` and
-:doc:`fix bond/react <fix_bond_react>`. These fixes will automatically
-trigger a rebuild of the neighbor list and update special bond data structures
-when bonds are broken.
+For the quartic bond style, when a bond is broken its bond type is set
+to 0 to effectively break it and pairwise forces between the two atoms
+in the broken bond are "turned on".  Angles, dihedrals, etc cannot be
+defined for a system when :doc:`bond_style quartic <bond_quartic>` is
+used.
 
-Note that when bonds are dumped to a file via the :doc:`dump local <dump>` command, bonds with type 0 are not included.  The
-:doc:`delete_bonds <delete_bonds>` command can also be used to query the
-status of broken bonds or permanently delete them, e.g.:
+Similarly, bond styles in the BPM package are also incompatible with
+angles, dihedrals, etc. and when a bond breaks its type is set to zero.
+However, in the BPM package one can either turn off all pair interactions
+between bonded particles or leave them on, overlaying pair forces on
+top of bond forces. To remove pair forces, the special bond list is
+dynamically updated.  More details can be found on the :doc:`Howto BPM
+<Howto_bpm>` page.
+
+The :doc:`fix bond/break <fix_bond_break>` and :doc:`fix bond/react
+<fix_bond_react>` commands allow breaking of bonds within a molecular
+topology with may also define angles, dihedrals, etc.  These commands
+update internal topology data structures to remove broken bonds, as
+well as the appropriate angle, dihedral, etc interactions which
+include the bond.  They also trigger a rebuild of the neighbor list
+when this occurs, to turn on the appropriate pairwise forces.
+
+Note that when bonds are dumped to a file via the :doc:`dump local
+<dump>` command, bonds with type 0 are not included.
+
+The :doc:`delete_bonds <delete_bonds>` command can be used to query
+the status of broken bonds with type = 0 or permanently delete them,
+e.g.:
 
 .. code-block:: LAMMPS
 
    delete_bonds all stats
    delete_bonds all bond 0 remove
 
-The compute :doc:`nbond/atom <compute_nbond_atom>` can also be used
-to tally the current number of bonds per atom, excluding broken bonds.
+The compute :doc:`count/type <compute_count_type>` command tallies the
+current number of bonds (or angles, etc) for each bond (angle, etc)
+type.  It also tallies broken bonds with type = 0.
+
+The compute :doc:`nbond/atom <compute_nbond_atom>` command tallies the
+current number of bonds each atom is part of, excluding broken bonds
+with type = 0.

doc/src/Howto_couple.rst

@@ -12,16 +12,16 @@ LAMMPS can be coupled to other codes in at least 4 different ways.  Each
 has advantages and disadvantages, which you will have to think about in
 the context of your application.
 
-1. Define a new :doc:`fix <fix>` command that calls the other code.  In
-   this scenario, LAMMPS is the driver code.  During timestepping, the
-   fix is invoked, and can make library calls to the other code, which
-   has been linked to LAMMPS as a library.  This is the way the
-   :ref:`LATTE <PKG-LATTE>` package, which performs density-functional
-   tight-binding calculations using the `LATTE software
-   <https://github.com/lanl/LATTE>`_ to compute forces, is interfaced to
-   LAMMPS.  See the :doc:`fix latte <fix_latte>` command for more
+1. Define a new :doc:`fix <fix>` or :doc:`compute <compute>` command
+   that calls the other code.  In this scenario, LAMMPS is the driver
+   code.  During timestepping, the fix or compute is invoked, and can
+   make library calls to the other code, which has been linked to LAMMPS
+   as a library.  This is the way the :ref:`VORONOI <PKG-VORONOI>`
+   package, which computes Voronoi tesselations using the `Voro++
+   library <http://math.lbl.gov/voro++>`_, is interfaced to LAMMPS.  See
+   the :doc:`compute voronoi <compute_voronoi_atom>` command for more
    details.  Also see the :doc:`Modify <Modify>` pages for information
-   on how to add a new fix to LAMMPS.
+   on how to add a new fix or compute to LAMMPS.
 
 .. spacer
 

doc/src/Howto_lammps_gui.rst

@@ -0,0 +1,402 @@
+Using the LAMMPS GUI
+====================
+
+LAMMPS GUI is a simple graphical text editor that is linked to the
+:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
+directly using the contents of the editor's text buffer as input.
+
+This is similar to what people traditionally would do to run LAMMPS:
+using a regular text editor to edit the input and run the necessary
+commands, possibly including the text editor, too, from a command line
+terminal window.  That is quite effective when running LAMMPS on
+high-performance computing facilities and when you are very proficient
+in using the command line.  The main benefit of a GUI application is
+that this integrates well with graphical desktop environments and many
+basic tasks can be done directly from within the GUI without switching
+to a text console or requiring external programs or scripts to extract
+data from the generated output.  This makes it easier for beginners to
+get started running simple LAMMPS simulations and thus very suitable for
+tutorials on LAMMPS.  But also makes it easier to switch to a full
+featured text editor and more sophisticated visualization and analysis
+tools.
+
+-----
+
+The following text provides a detailed tour of the features and
+functionality of the LAMMPS GUI.  This document describes LAMMPS GUI
+version 1.2.
+
+Main window
+-----------
+
+When LAMMPS GUI starts, it will show the main window with either an
+empty buffer, or have a file loaded. In the latter case it may look like
+the following:
+
+.. image:: JPG/lammps-gui-main.png
+   :align: center
+   :scale: 50%
+
+There is the menu bar at the top, then the main editor buffer with the
+input file contents in the center with line numbers on the left and the
+input colored according to the LAMMPS input file syntax.  At the bottom
+is the status bar, which shows the status of LAMMPS execution on the
+left ("Ready." when idle) and the current working directory on the
+right.  The size of the main window will be stored when exiting and
+restored when starting again.  The name of the current file in the
+buffer is shown in the window title and the text `*modified*` is added
+in case the buffer has modifications that are not yet saved to a file.
+
+Opening Files
+^^^^^^^^^^^^^
+
+The LAMMPS GUI application will try to open the first command line
+argument as input file, further arguments are ignored.  When no
+argument is given LAMMPS GUI will start with an empty buffer.
+Files can also be opened via the ``File`` menu or by drag-and-drop
+of a file from a file manager to the editor window.  Only one
+file can be open at a time, so opening a new file with a filled
+buffer will close this buffer and in case the buffer has unsaved
+modifications will ask to either cancel the load, discard the
+changes or save them.
+
+
+Running LAMMPS
+^^^^^^^^^^^^^^
+
+From within the LAMMPS GUI main window LAMMPS can be started either from
+the ``Run`` menu, by the hotkey `Ctrl-Enter` (`Command-Enter` on macOS),
+or by clicking on the green button in the status bar.  LAMMPS runs in a
+separate thread, so the GUI stays responsive and thus it is able to
+interact with the calculation and access its data.  It is important to
+note, that LAMMPS is using the contents of the input buffer for the run,
+**not** the file it was read from. If there are unsaved changes in the
+buffer, they *will* be used.
+
+.. image:: JPG/lammps-gui-running.png
+   :align: center
+   :scale: 75%
+
+While LAMMPS is running, the contents of the status bar change: on the
+left side there is a text indicating that LAMMPS is running, which will
+contain the selected number of threads, if thread-parallel acceleration
+was selected in the ``Preferences`` dialog.  On the right side, a
+progress bar is shown that displays the estimated progress on the
+current :doc:`run command <run>`.  Additionally, two windows will open:
+the log window with the captured screen output and the chart window with
+a line graph created from the thermodynamic output of the run.
+
+The run can be stopped cleanly by using either the ``Stop LAMMPS`` entry
+in the ``Run`` menu, the hotkey `Ctrl-/` (`Command-/` on macOS), or
+clicking on the red button in the status bar.  This will cause that the
+running LAMMPS process will complete the current iteration and then
+stop.  This is equivalent to the command `timer timeout 0 <timer>` and
+implemented by calling the :cpp:func:`lammps_force_timeout()` function
+of the LAMMPS C-library interface.
+
+
+Viewing Snapshot Images
+^^^^^^^^^^^^^^^^^^^^^^^
+
+By selecting the ``View Image`` entry in the ``Run`` menu, by hitting
+the `Ctrl-I` (`Command-I` on macOS) hotkey or by clicking on the
+"palette" button in the status bar, LAMMPS GUI will issue a
+:doc:`write_dump image <dump_image>` command and read the resulting
+snapshot image into an image viewer window.  When possible, LAMMPS
+GUI will try to detect which elements the atoms correspond to (via
+their mass) and then colorize them accordingly. Otherwise just some
+predefined sequence of colors are assigned to different atom types.
+
+.. image:: JPG/lammps-gui-image.png
+   :align: center
+   :scale: 50%
+
+The default image size, some default image quality settings, the view
+style and some colors can be changed in the ``Preferences`` dialog
+window.  From the image viewer window further adjustments can be made:
+actual image size, high-quality rendering, anti-aliasing, view style,
+display of box or axes, zoom factor. The the image can be rotated
+horizontally and vertically and it is possible to only display the atoms
+within a predefined group (default is "all").  After each change, the
+image is rendered again and the display updated.  The small palette icon
+on the top left will be colored while LAMMPS is running to render the
+image and it will be grayed out again, when it is done.  When there are
+many items to show and high quality images with anti-aliasing are
+requested, re-rendering can take several seconds.  From the ``File``
+menu, the shown image can be saved to a file permanently or copied into
+the cut-n-paste buffer for pasting into another application.
+
+
+Editor Functions
+^^^^^^^^^^^^^^^^
+
+The editor has most the usual functionality that similar programs have:
+text selection via mouse or with cursor moves while holding the Shift
+key, Cut, Copy, Paste, Undo, Redo.  All of these editing functions are
+available via hotkeys.  When trying to exit the editor with a modified
+buffer, a dialog will pop up asking whether to cancel the quit, or don't
+save or save the buffer's contents to a file.
+
+Context Specific Help
+^^^^^^^^^^^^^^^^^^^^^
+
+.. image:: JPG/lammps-gui-popup-help.png
+   :align: center
+   :scale: 50%
+
+A unique feature of the LAMMPS GUI is the option to look up the
+documentation for the command in the current line.  This can be achieved
+by either clicking the right mouse button or by using the `Ctrl-?`
+hotkey.  When clicking the mouse there are additional entries in the
+context menu that will open the corresponding documentation page in the
+online LAMMPS documentation.  When using the hotkey, the first of those
+entries will be chosen directly.
+
+Menu
+----
+
+The menu bar the entries ``File``, ``Edit``, ``Run``, ``View``, and ``About``.
+Instead of using the mouse to click on them, the individual menus can also
+be activated by hitting the `Alt` key together with the corresponding underlined
+letter, that is `Alt-f` will activate the ``File`` menu.  For the corresponding
+activated sub-menus, also the underlined letter, together with the `Alt` key can
+be used to select instead of the mouse.
+
+File
+^^^^
+
+The ``File`` menu offers the usual options:
+
+- ``New`` will clear the current buffer and reset the file name to ``*unknown*``
+- ``Open`` will open a dialog to select a new file
+- ``Save`` will save the current file; if the file name is ``*unknown*``
+  a dialog will open to select a new file name
+- ``Save As`` will open a dialog to select and new file name and save
+  the buffer to it
+- ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
+  will appear to either cancel the quit, save or don't save the file.
+
+In addition, up to 5 recent file names will be listed after the ``Open``
+entry that allows to re-open recent files. This list is stored when
+quitting and recovered when starting again.
+
+Edit
+^^^^
+
+The ``Edit`` menu offers the usual editor functions like ``Undo``,
+``Redo``, ``Cut``, ``Copy``, ``Paste``, but also offers to open the
+``Preferences`` dialog and to delete all stored preferences so they
+will be reset to their defaults.
+
+Run
+^^^
+
+The ``Run`` menu allows to start and stop a LAMMPS process.  Rather than
+calling the LAMMPS executable as a separate executable, the LAMMPS GUI
+is linked to the LAMMPS library and thus can run LAMMPS internally
+through the :ref:`LAMMPS C-library interface <lammps_c_api>`.
+Specifically, a LAMMPS instance will be created by calling
+:cpp:func:`lammps_open_no_mpi` and then the buffer contents run by
+calling :cpp:func:`lammps_commands_string`.  Certain commands and
+features are only available, after a LAMMPS instance is created.  Its
+presence is indicated by a small LAMMPS ``L`` logo in the status bar at
+the bottom left of the main window.
+
+The LAMMPS calculation will be run in a concurrent thread so that the
+GUI will stay responsive and will be updated during the run.  This can
+be used to tell the running LAMMPS instance to stop at the next
+timestep.  The ``Stop LAMMPS`` entry will do this by calling
+:cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
+timeout 0 <timer>` command.
+
+The ``Set Variables`` entry will open a dialog box where :doc:`index style variables <variable>`
+can be set. Those variables will be passed to the LAMMPS instance when
+it is created and are thus set *before* a run is started.
+
+.. image:: JPG/lammps-gui-variables.png
+   :align: center
+   :scale: 75%
+
+The ``Set Variables`` dialog will be pre-populated with entries that are
+set as index variables in the input and any variables that are used but
+not defined as far as the built-in parser can detect them.  New rows for
+additional variables can be added through the ``Add Row`` button and
+existing rows deleted by clicking on the ``X`` icons on the right.
+
+The ``View Image`` entry will send a :doc:`dump image <dump_image>`
+command to the LAMMPS instance, read the resulting file, and show it in
+an ``Image Viewer`` window.
+
+The ``View in OVITO`` entry will launch `OVITO <https://ovito.org>`_
+with a :doc:`data file <write_data>` of the current state of the system.
+This option is only available, if the LAMMPS GUI can find the OVITO
+executable in the system path.
+
+The ``View in VMD`` entry will instead launch VMD, also to load a
+:doc:`data file <write_data>` of the current state of the system.  This
+option is only available, if the LAMMPS GUI can find the VMD executable
+in the system path.
+
+View
+^^^^
+
+The ``View`` menu offers to show or hide the three optional windows
+with log output, graphs, or images.  The default settings for those
+can be changed in the ``Preferences dialog``.
+
+About
+^^^^^
+
+The ``About`` menu finally offers a couple of dialog windows and an
+option to launch the LAMMPS online documentation in a web browser.  The
+``About LAMMPS GUI`` entry displays a dialog with a summary of the
+configuration settings of the LAMMPS library in use and the version
+number of LAMMPS GUI itself.  The ``Quick Help`` displays a dialog with
+a minimal description of LAMMPS GUI.  And ``LAMMPS Manual`` will open
+the main page of this LAMMPS documentation at https://docs.lammps.org/.
+
+Preferences
+-----------
+
+The ``Preferences`` dialog allows to customize some of the behavior
+and looks of the LAMMPS GUI application.  The settings are grouped
+and each group is displayed within a tab.
+
+.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
+   :width: 25%
+
+.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
+   :width: 25%
+
+.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
+   :width: 25%
+
+|guiprefs1|  |guiprefs2|  |guiprefs3|
+
+General Settings:
+^^^^^^^^^^^^^^^^^
+
+- *Echo input to log:* when checked, all input commands, including
+  variable expansions, will be echoed to the log window. This is
+  equivalent to using `-echo screen` at the command line.  There is no
+  log *file* produced since it always uses `-log none`.
+- *Include citation details:* when checked full citation info will be
+  included to the log window.  This is equivalent to using `-cite
+  screen` on the command line.
+- *Show log window by default:* when checked, the screen output of a
+  LAMMPS run will be collected in a log window during the run
+- *Show chart window by default:* when checked, the thermodynamic
+  output of a LAMMPS run will be collected and displayed in a chart
+  window as line graphs.
+- *Replace log window on new run:* when checked, an existing log
+  window will be replaced on a new LAMMPS run, otherwise each run will
+  create a new log window.
+- *Replace chart window on new run:* when checked, an existing chart
+  window will be replaced on a new LAMMPS run, otherwise each run will
+  create a new chart window.
+- *Replace image window on new render:* when checked, an existing
+  chart window will be replaced when a new snapshot image is requested,
+  otherwise each command will create a new image window.
+- *Path to LAMMPS Shared Library File:* this options is only available
+  when LAMMPS GUI was compiled to load the LAMMPS library at run time
+  instead of being linked to it directly.  With the ``Browse..`` button
+  or by changing the text, a different shared library file with a
+  different compilation of LAMMPS with different settings or from a
+  different version can be loaded.  After this setting was changed,
+  LAMMPS GUI needs to be re-launched.
+- *Select Default Font:* Opens a font selection dialog where the type
+  and size for the default font (used for everything but the editor and
+  log) of the application can be set.
+- *Select Text Font:* Opens a font selection dialog where the type and
+  size for the text editor and log font of the application can be set.
+
+Accelerators:
+^^^^^^^^^^^^^
+
+This tab enables to select which accelerator package is used and is
+equivalent to using the `-suffix` and `-package` flags on the command
+line.  Only settings supported by the LAMMPS library and local hardware
+are available.  The `Number of threads` field allows to set the maximum
+number of threads for the accelerator packages that use threads.
+
+Snapshot Image:
+^^^^^^^^^^^^^^^
+
+This tab allows to set some defaults for the snapshot images displayed
+in the ``Image Viewer`` window, like its dimensions and the zoom factor
+applied.  The *Antialias* switch requests to render images with twice
+the number of pixels for width and height and then smoothly scales the
+image back to the requested size.  This produces higher quality images
+with smoother edges at the expense of requiring more CPU time to render
+the image.  The *HQ Image mode* option turns on using a screen space
+ambient occlusion mode (SSAO) when rendering images.  This is also more
+time consuming, but produces a more 'spatial' representation of the
+system.  The *VDW Style* checkbox selects whether atoms are represented
+by space filling spheres when checked or by smaller spheres and stick.
+Finally there are a couple of drop down lists to select the background
+and box color.
+
+
+Hotkeys
+-------
+
+Almost all functionality is accessible from the menu or via hotkeys.
+The following hotkeys are available (On macOS use the Command key
+instead of Ctrl/Control).
+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+
+   * - Hotkey
+     - Function
+     - Hotkey
+     - Function
+     - Hotkey
+     - Function
+     - Hotkey
+     - Function
+   * - Ctrl+N
+     - New File
+     - Ctrl+Z
+     - Undo edit
+     - Ctrl+Enter
+     - Run LAMMPS
+     - Ctrl+Shift+A
+     - About LAMMPS GUI
+   * - Ctrl+O
+     - Open File
+     - Ctrl+Shift+Z
+     - Redo edit
+     - Ctrl+/
+     - Stop Active Run
+     - Ctrl+Shift+H
+     - Quick Help
+   * - CTRL+S
+     - Save File
+     - Ctrl+C
+     - Copy text
+     - Ctrl+Shift+V
+     - Set Variables
+     - Ctrl+Shift+G
+     - LAMMPS GUI Howto
+   * - Ctrl+Shift+S
+     - Save File As
+     - Ctrl+X
+     - Cut text
+     - Ctrl+I
+     - Create Snapshot Image
+     - Ctrl+Shift+M
+     - LAMMPS Manual
+   * - Ctrl+Q
+     - Quit
+     - Ctrl+V
+     - Paste text
+     - Ctrl+P
+     - Preferences
+     - Ctrl+?
+     - Context Help
+
+Further editing keybindings `are documented with the Qt documentation
+<https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_.  In
+case of conflicts the list above takes precedence.

doc/src/Howto_spc.rst

@@ -69,15 +69,13 @@ SPC/E with rigid bonds.
    timestep 1.0
    fix rigid     all shake 0.0001 10 10000 b 1 a 1
    minimize 0.0 0.0 1000 10000
-   run 0 post no
-   reset_timestep 0
    velocity all create 300.0 5463576
-   fix integrate all nvt temp 300.0 300.0 1.0
+   fix integrate all nvt temp 300.0 300.0 100.0
 
    thermo_style custom step temp press etotal density pe ke
    thermo 1000
    run 20000 upto
-   write_data tip4p.data nocoeff
+   write_data spce.data nocoeff
 
 .. _spce_molecule:
 .. code-block::

doc/src/Howto_tip3p.rst

@@ -128,11 +128,11 @@ TIP3P with rigid bonds.
 
     fix rigid all shake 0.001 10 10000 b 1 a 1
     minimize 0.0 0.0 1000 10000
-    run 0 post no
 
     reset_timestep 0
+    timestep 1.0
     velocity all create 300.0 5463576
-    fix integrate all nvt temp 300 300 1.0
+    fix integrate all nvt temp 300 300 100.0
 
     thermo_style custom step temp press etotal pe
 

doc/src/Howto_tip4p.rst

@@ -101,7 +101,7 @@ not as part of the pair coefficients.
         - 0.52422
       * - LJ :math:`\epsilon` of OO (kcal/mole)
         - 0.1550
-        - 0.1577
+        - 0.21084
         - 0.1852
         - 0.16275
       * - LJ :math:`\sigma` of OO (:math:`\AA`)
@@ -180,17 +180,17 @@ file changed):
 
     fix rigid all shake 0.001 10 10000 b 1 a 1
     minimize 0.0 0.0 1000 10000
-    run 0 post no
 
     reset_timestep 0
+    timestep 1.0
     velocity all create 300.0 5463576
-    fix integrate all nvt temp 300 300 1.0
+    fix integrate all nvt temp 300 300 100.0
 
     thermo_style custom step temp press etotal pe
 
     thermo 1000
     run 20000
-    write_data tip3p.data nocoeff
+    write_data tip4p-implicit.data nocoeff
 
 Below is the code for a LAMMPS input file using the explicit method and
 a TIP4P molecule file.  Because of using :doc:`fix rigid/nvt/small
@@ -203,6 +203,7 @@ rigid/nvt/small can identify rigid bodies by their molecule ID:
 
     units real
     atom_style charge
+    atom_modify map array
     region box block -5 5 -5 5 -5 5
     create_box 3 box
 
@@ -219,14 +220,14 @@ rigid/nvt/small can identify rigid bodies by their molecule ID:
     molecule water tip4p.mol
     create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
 
-    timestep 0.1
-    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 1.0
+    timestep 0.5
+    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
     velocity all create 300.0 5463576
 
     thermo_style custom step temp press etotal density pe ke
     thermo 1000
     run 20000
-    write_data tip4p.data nocoeff
+    write_data tip4p-explicit.data nocoeff
 
 .. _tip4p_molecule:
 .. code-block::

doc/src/Howto_tip5p.rst

@@ -91,6 +91,7 @@ ID:
 
     units real
     atom_style charge
+    atom_modify map array
     region box block -5 5 -5 5 -5 5
     create_box 3 box
 
@@ -107,8 +108,8 @@ ID:
     molecule water tip5p.mol
     create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
 
-    timestep 0.20
-    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 1.0
+    timestep 0.5
+    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
     reset_timestep 0
     velocity all create 300.0 5463576
 

doc/src/Install_conda.rst

@@ -1,13 +1,13 @@
-Download an executable for Linux or Mac via Conda
--------------------------------------------------
+Download an executable for Linux or macOS via Conda
+---------------------------------------------------
 
 Pre-compiled LAMMPS binaries are available for macOS and Linux via the
 `Conda <conda_>`_ package management system.
 
-First, one must set up the Conda package manager on your system.  Follow the
-instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
-environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
-install:
+First, one must set up the Conda package manager on your system.  Follow
+the instructions to install `Miniconda <mini_conda_install_>`_, then
+create a conda environment (named `my-lammps-env` or whatever you
+prefer) for your LAMMPS install:
 
 .. code-block:: bash
 

doc/src/Install_mac.rst

@@ -1,12 +1,12 @@
-Download an executable for Mac
-------------------------------
+Download an executable for macOS
+--------------------------------
 
-LAMMPS can be downloaded, built, and configured for OS X on a Mac with
-`Homebrew <homebrew_>`_.  (Alternatively, see the installation
-instructions for :doc:`downloading an executable via Conda
-<Install_conda>`.)  The following LAMMPS packages are unavailable at
-this time because of additional requirements not yet met: GPU, KOKKOS,
-LATTE, MSCG, MPIIO, POEMS, VORONOI.
+LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
+<homebrew_>`_.  (Alternatively, see the installation instructions for
+:doc:`downloading an executable via Conda <Install_conda>`.)  The
+following LAMMPS packages are unavailable at this time because of
+additional requirements not yet met: GPU, KOKKOS, MSCG, MPIIO, POEMS,
+VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
@@ -15,8 +15,9 @@ the following commands:
 
    brew install lammps
 
-This will install the executables "lammps_serial" and "lammps_mpi", as well as
-the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
+This will install the executables "lammps_serial" and "lammps_mpi", as
+well as the LAMMPS "doc", "potentials", "tools", "bench", and "examples"
+directories.
 
 Once LAMMPS is installed, you can test the installation with the
 Lennard-Jones benchmark file:

doc/src/Install_tarball.rst

@@ -2,7 +2,7 @@ Download source and documentation as a tarball
 ----------------------------------------------
 
 You can download a current LAMMPS tarball from the `download page <download_>`_
-of the `LAMMPS website <lws_>`_.
+of the `LAMMPS website <lws_>`_ or from GitHub (see below).
 
 .. _download: https://www.lammps.org/download.html
 .. _bug: https://www.lammps.org/bug.html
@@ -17,21 +17,21 @@ tarball occasionally updated.  Feature releases occur every 4 to 8
 weeks.  The new contents in all feature releases are listed on the `bug
 and feature page <bug_>`_ of the LAMMPS homepage.
 
-Both tarballs include LAMMPS documentation (HTML and PDF files)
-corresponding to that version.
-
 Tarballs of older LAMMPS versions can also be downloaded from `this page
 <older_>`_.
 
-Once you have a tarball, unzip and untar it with the following
+Tarballs downloaded from the LAMMPS homepage include the pre-translated
+LAMMPS documentation (HTML and PDF files) corresponding to that version.
+
+Once you have a tarball, uncompress and untar it with the following
 command:
 
 .. code-block:: bash
 
    tar -xzvf lammps*.tar.gz
 
-This will create a LAMMPS directory with the version date
-in its name, e.g. lammps-23Jun18.
+This will create a LAMMPS directory with the version date in its name,
+e.g. lammps-28Mar23.
 
 ----------
 
@@ -45,7 +45,8 @@ with the following command, to create a lammps-<version> directory:
    unzip lammps*.zip
 
 This version corresponds to the selected LAMMPS feature or stable
-release.
+release (as indicated by the matching git tag) and will only contain the
+source code and no pre-built documentation.
 
 .. _git: https://github.com/lammps/lammps/releases
 

doc/src/Intro_features.rst

@@ -88,7 +88,7 @@ commands)
 * charge equilibration (QEq via dynamic, point, shielded, Slater methods)
 * coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO, oxDNA / oxRNA, SPICA
 * mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
-* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
+* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q)
 * electron force field (eFF, AWPMD)
 * bond potentials: harmonic, FENE, Morse, nonlinear, Class II (COMPASS), quartic (breakable), tabulated, scripted
 * angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, Class II (COMPASS), tabulated, scripted

doc/src/Library_properties.rst

@@ -5,6 +5,7 @@ This section documents the following functions:
 
 - :cpp:func:`lammps_get_natoms`
 - :cpp:func:`lammps_get_thermo`
+- :cpp:func:`lammps_last_thermo`
 - :cpp:func:`lammps_extract_box`
 - :cpp:func:`lammps_reset_box`
 - :cpp:func:`lammps_memory_usage`
@@ -81,6 +82,11 @@ subdomains and processors.
 
 -----------------------
 
+.. doxygenfunction:: lammps_last_thermo
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_extract_box
    :project: progguide
 

doc/src/Manual.rst

@@ -23,10 +23,23 @@ coordinated.
 
 ----------
 
-The content for this manual is part of the LAMMPS distribution.  The
-online version always corresponds to the latest feature release version.
-If needed, you can build a local copy of the manual as HTML pages or a
-PDF file by following the steps on the :doc:`Build_manual` page.  If you
+The content for this manual is part of the LAMMPS distribution in its
+doc directory.
+
+* The version of the manual on the LAMMPS website corresponds to the
+  latest LAMMPS feature release.  It is available at:
+  `https://docs.lammps.org/ <https://docs.lammps.org/>`_.
+* A version of the manual corresponding to the latest LAMMPS stable
+  release (state of the *stable* branch on GitHub) is available online
+  at: `https://docs.lammps.org/stable/
+  <https://docs.lammps.org/stable/>`_
+* A version of the manual with the features most recently added to
+  LAMMPS (state of the *develop* branch on GitHub) is available at:
+  `https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
+
+If needed, you can build a copy on your local machine of the manual
+(HTML pages or PDF file) for the version of LAMMPS you have
+downloaded.  Follow the steps on the :doc:`Build_manual` page.  If you
 have difficulties viewing the pages, please :ref:`see this note
 <webbrowser>`.
 
@@ -136,10 +149,21 @@ Indices and tables
    :class: note
 
    The HTML version of the manual makes use of advanced features present
-   in "modern" web browsers.  This can lead to incompatibilities with older
-   web browsers (released more than 4 years ago) and specific vendor browsers
-   (e.g. Internet Explorer on Windows; Microsoft Edge works well though)
+   in "modern" web browsers.  This leads to incompatibilities with older
+   web browsers and specific vendor browsers (e.g. Internet Explorer on Windows)
    where parts of the pages are not rendered as expected (e.g. the layout is
    broken or mathematical expressions not typeset).  In that case we
    recommend to install/use a different/newer web browser or use
    the `PDF version of the manual <https://docs.lammps.org/Manual.pdf>`_.
+
+   The following web browser versions have been verified to work as
+   expected on Linux, macOS, and Windows where available:
+
+   - Safari version 11.1 and later
+   - Firefox version 54 and later
+   - Chrome version 54 and later
+   - Opera version 41 and later
+   - Edge version 80 and later
+
+   Also Android version 7.1 and later and iOS version 11 and later have
+   been verified to render this website as expected.

doc/src/Modify.rst

@@ -1,23 +1,30 @@
 Modifying & extending LAMMPS
 ****************************
 
-LAMMPS is designed in a modular fashion and to be easy to modify or
-extend with new functionality.  In fact, about 95% of its source code
-are optional.  The following pages give basic instructions on what
-is required when adding new styles of different kinds to LAMMPS.
+LAMMPS has a modular design, so that it is easy to modify or extend with
+new functionality.  In fact, about 95% of its source code is optional.
+The following pages give basic instructions on adding new features to
+LAMMPS.  More in-depth explanations and documentation of individual
+functions and classes are given in :doc:`Developer`.
 
 If you add a new feature to LAMMPS and think it will be of general
 interest to other users, we encourage you to submit it for inclusion in
-LAMMPS as a pull request on our `GitHub site
-<https://github.com/lammps/lammps>`_, after reading about :doc:`how to
-prepare your code for submission <Modify_contribute>` and :doc:`the
-style requirements and recommendations <Modify_style>`.
+LAMMPS. This process is explained in the following three pages:
+
+* :doc:`how to prepare and submit your code <Modify_contribute>`
+* :doc:`requirements for submissions <Modify_requirements>`
+* :doc:`style guidelines <Modify_style>`
+
+A summary description of various types of styles in LAMMPS follows.
+A discussion of implementing specific styles from scratch is given
+in :doc:`writing new styles <Developer_write>`.
 
 .. toctree::
    :maxdepth: 1
 
    Modify_overview
    Modify_contribute
+   Modify_requirements
    Modify_style
 
 .. toctree::

doc/src/Modify_contribute.rst

@@ -2,74 +2,59 @@ Submitting new features for inclusion in LAMMPS
 ===============================================
 
 We encourage LAMMPS users to submit new features they wrote for LAMMPS
-to be included into the LAMMPS distribution and thus become easily
-accessible to all LAMMPS users.  The LAMMPS source code is managed with
-git and public development is hosted on `GitHub
-<https://github.com/lammps/lammps>`_.  You can monitor the repository to
-be notified of releases, follow the ongoing development, and comment on
-topics of interest to you.
+to be included in the LAMMPS distribution and thus become easily
+accessible to all LAMMPS users.  The LAMMPS source code is managed
+with git and public development is hosted on `GitHub
+<https://github.com/lammps/lammps>`_.  You can monitor the repository
+to be notified of releases, follow the ongoing development, and
+comment on topics of interest to you.
+
+This section contains general information regarding the preparation
+and submission of new features to LAMMPS. If you are new to
+development in LAMMPS, we recommend you read one of the tutorials on
+developing a new :doc:`pair style <Developer_write_pair>` or :doc:`fix
+style <Developer_write_fix>` which provide a friendly introduction to
+what LAMMPS development entails and common vocabulary used on this
+section.
+
 
 Communication with the LAMMPS developers
 ----------------------------------------
 
-For any larger modifications or programming project, you are encouraged
-to contact the LAMMPS developers ahead of time in order to discuss
-implementation strategies and coding guidelines.  That will make it
-easier to integrate your contribution and results in less work for
-everybody involved.  You are also encouraged to search through the list
-of `open issues on GitHub <https://github.com/lammps/lammps/issues>`_
-and submit a new issue for a planned feature, so you would not duplicate
-the work of others (and possibly get scooped by them) or have your work
-duplicated by others.
+For any larger modifications or programming project, you are
+encouraged to contact the LAMMPS developers ahead of time to discuss
+implementation strategies. That will make it easier to integrate your
+contribution and typically results in less work for everyone involved.
+You are also encouraged to search through the list of `open issues on
+GitHub <https://github.com/lammps/lammps/issues>`_ and submit a new
+issue for a planned feature, to avoid duplicating work (and possibly
+being scooped).
 
-For informal communication with the LAMMPS developers you may ask to
-join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.  This
-slack work space is by invitation only.  Thus for access, please send an
-e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you are
-working on.  Only discussions related to LAMMPS development are
-tolerated in that work space, so this is **NOT** for people that look
+For informal communication with the LAMMPS developers, you may ask to
+join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.
+This slack work space is by invitation only.  For access, please send
+an e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you
+are working on.  Only discussions related to LAMMPS development are
+tolerated in that work space, so this is **NOT** for people looking
 for help with compiling, installing, or using LAMMPS.  Please post a
 message to the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for
 those purposes.
 
-Packages versus individual files
---------------------------------
-
-The remainder of this chapter describes how to add new "style" files of
-various kinds to LAMMPS.  Packages are simply collections of one or more
-such new class files which are invoked as a new style within a LAMMPS
-input script.  In some cases also collections of supporting functions or
-classes are included as separate files in a package, especially when
-they can be shared between multiple styles. If designed correctly, these
-additions typically do not require any changes to the core code of
-LAMMPS; they are simply add-on files that are compiled with the rest of
-LAMMPS.  To make those styles work, you may need some trivial changes to
-the core code; an example of a trivial change is making a parent-class
-method "virtual" when you derive a new child class from it.
-
-If you think your new feature or package requires some non-trivial
-changes in core LAMMPS files, you should communicate with the LAMMPS
-developers `on Slack <https://lammps.org/slack.html>`_, `on GitHub
-<https://github.com/lammps/lammps/issues>`_, or `via email
-<https://www.lammps.org/authors.html>`_, since we may have
-recommendations about what changes to do where, or may not want to
-include certain changes for some reason and thus you would need to look
-for alternatives.
 
 Time and effort required
 ------------------------
 
-How quickly your contribution will be integrated can vary a lot.  It
-depends largely on how much effort it will cause the LAMMPS developers
-to integrate and test it, how many and what kind of changes to the core
-code are required, how quickly you can address them and of how much
-interest it is to the larger LAMMPS community.  Please see the section
-on :doc:`LAMMPS programming style and requirements <Modify_style>` for
-instructions, recommendations, and formal requirements.  A small,
-modular, well written contribution may be integrated within hours, but a
-complex change that will require a redesign of some core functionality
-in LAMMPS for a clean integration can take many months until it is
-considered ready for inclusion (though this is rare).
+How quickly your contribution will be integrated can vary widely.  It
+depends largely on how much effort is required by the LAMMPS
+developers to integrate and test it, if any and what kind of changes
+to the core code are required, how quickly you can address them, and
+how much interest the contribution is to the larger LAMMPS
+community. This process can be streamlined by following the
+:doc:`requirements <Modify_requirements>` and :doc:`style
+guidelines<Modify_style>`.  A small, modular, well written
+contribution may be integrated within hours, but a complex change that
+requires a re-design of a core functionality in LAMMPS can take months
+before inclusion (though this is rare).
 
 
 Submission procedure
@@ -78,36 +63,24 @@ Submission procedure
 All changes to LAMMPS (including those from LAMMPS developers) are
 integrated via pull requests on GitHub and cannot be merged without
 passing the automated testing and an approving review by a LAMMPS core
-developer.  Thus before submitting your contribution, you should first
-make certain, that your added or modified code compiles and works
-correctly with the latest development version of LAMMPS and contains all
-bug fixes from it.
+developer.  Before submitting your contribution, you should therefore
+first ensure that your added or modified code compiles and works
+correctly with the latest development version of LAMMPS and contains
+all bug fixes from it.
 
-Once you have prepared everything, see the :doc:`LAMMPS GitHub Tutorial
-<Howto_github>` page for instructions on how to submit your changes or
-new files through a GitHub pull request yourself.  If you are unable or
-unwilling to submit via GitHub yourself, you may also submit patch files
-or full files to the LAMMPS developers and ask them to submit a pull
-request on GitHub on your behalf.  Then create a gzipped tar file of
-all  changed or added files or a corresponding patch file using
-'diff -u' or 'diff -c' format and compress it with gzip.  Please only
-use gzip compression, as this works well and is available on all platforms.
+Once you have prepared everything, see the :doc:`LAMMPS GitHub
+Tutorial <Howto_github>` page for instructions on how to submit your
+changes or new files through a GitHub pull request.  If you are unable
+or unwilling to submit via GitHub yourself, you may also send patch
+files or full files to the `LAMMPS developers
+<https://www.lammps.org/authors.html>`_ and ask them to submit a pull
+request on GitHub on your behalf.  If this is the case, create a
+gzipped tar file of all new or changed files or a corresponding patch
+file using 'diff -u' or 'diff -c' format and compress it with gzip.
+Please only use gzip compression, as this works well and is available
+on all platforms.  This mode of submission may delay the integration
+as it depends more on the LAMMPS developers.
 
-If the new features/files are broadly useful we may add them as core
-files to LAMMPS or as part of a :doc:`package <Packages_list>`.  All
-packages are listed and described on the :doc:`Packages details
-<Packages_details>` doc page.
-
-Licensing
----------
-
-Note that by providing us files to release, you agree to make them
-open-source, i.e. we can release them under the terms of the GPL
-(version 2) with the rest of LAMMPS.  And similarly as part of a LGPL
-(version 2.1) distribution of LAMMPS that we make available to
-developers on request only and with files that are not authorized for
-that kind of distribution removed (e.g. interface to FFTW).  See the
-:doc:`LAMMPS license <Intro_opensource>` page for details.
 
 External contributions
 ----------------------
@@ -115,11 +88,42 @@ External contributions
 If you prefer to do so, you can also develop and support your add-on
 feature **without** having it included in the LAMMPS distribution, for
 example as a download from a website of your own.  See the `External
-LAMMPS packages and tools <https://www.lammps.org/external.html>`_ page
-of the LAMMPS website for examples of groups that do this.  We are happy
-to advertise your package and website from that page.  Simply email the
-`developers <https://www.lammps.org/authors.html>`_ with info about your
-package and we will post it there.  We recommend to name external
-packages USER-\<name\> so they can be easily distinguished from bundled
-packages that do not have the USER- prefix.
+LAMMPS packages and tools <https://www.lammps.org/external.html>`_
+page of the LAMMPS website for examples of groups that do this.  We
+are happy to advertise your package and website from that page.
+Simply email the `developers <https://www.lammps.org/authors.html>`_
+with info about your package, and we will post it there.  We recommend
+naming external packages USER-\<name\> so they can be easily
+distinguished from packages in the LAMMPS distribution which do not
+have the USER- prefix.
 
+
+Location of files: individual files and packages
+------------------------------------------------
+
+We rarely accept new styles in the core src folder.  Thus, please
+review the list of :doc:`available Packages <Packages_details>` to see
+if your contribution should be added to one of them.  It should fit
+into the general purpose of that package.  If it does not fit well, it
+may be added to one of the EXTRA- packages or the MISC package.
+
+However, if your project includes many related features that are not
+covered by one of the existing packages or is dependent on a library
+(bundled or external), it is best to create a new package with its own
+directory (with a name like FOO).  In addition to your new files, the
+directory should contain a README text file containing your name and
+contact information and a brief description of what your new package
+does.
+
+
+Changes to core LAMMPS files
+--------------------------------
+
+If designed correctly, most additions do not require any changes to
+the core code of LAMMPS; they are simply add-on files that are
+compiled with the rest of LAMMPS.  To make those styles work, you may
+need some trivial changes to the core code.  An example of a trivial
+change is making a parent-class method "virtual" when you derive a new
+child class from it.  If your features involve more substantive
+changes to the core LAMMPS files, it is particularly encouraged that
+you communicate with the LAMMPS developers early in development.

doc/src/Modify_gran_sub_mod.rst

@@ -80,8 +80,8 @@ There are also several type-specific methods
      - Optional method to test when particles are in contact. By default, this is when particles overlap.
    * - ``GranSubModNormal->pulloff_distance()``
      - Optional method to return the distance at which particles stop interacting. By default, this is when particles no longer overlap.
-   * - ``GranSubModNormal->calculate_area()``
-     - Optional method to return the surface area of the contact. By default, this returns the geometric cross section.
+   * - ``GranSubModNormal->calculate_radius()``
+     - Optional method to return the radius of the contact. By default, this returns the radius of the geometric cross section.
    * - ``GranSubModNormal->set_fncrit()``
      - Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, this is the current total normal force including damping.
    * - ``GranSubModNormal->calculate_forces()``
@@ -105,9 +105,7 @@ set of files ``gran_sub_mod_custom.h``:
 
    #ifdef GranSubMod_CLASS
    // clang-format off
-   GranSubModStyle(hooke/piecewise,
-            GranSubModNormalHookePiecewise,
-            NORMAL);
+   GranSubModStyle(hooke/piecewise,GranSubModNormalHookePiecewise,NORMAL);
    // clang-format on
    #else
 
@@ -119,15 +117,14 @@ set of files ``gran_sub_mod_custom.h``:
 
    namespace LAMMPS_NS {
    namespace Granular_NS {
-
-   class GranSubModNormalHookePiecewise : public GranSubModNormal {
-    public:
-     GranSubModNormalHookePiecewise(class GranularModel *, class LAMMPS *);
-     void coeffs_to_local() override;
-     double calculate_forces();
-    protected:
-     double k1, k2, delta_switch;
-   };
+     class GranSubModNormalHookePiecewise : public GranSubModNormal {
+      public:
+       GranSubModNormalHookePiecewise(class GranularModel *, class LAMMPS *);
+       void coeffs_to_local() override;
+       double calculate_forces() override;
+      protected:
+       double k1, k2, delta_switch;
+     };
 
    }    // namespace Granular_NS
    }    // namespace LAMMPS_NS
@@ -147,7 +144,8 @@ and ``gran_sub_mod_custom.cpp``
    using namespace LAMMPS_NS;
    using namespace Granular_NS;
 
-   GranSubModNormalHookePiecewise::GranSubModNormalHookePiecewise(GranularModel *gm, LAMMPS *lmp) :  GranSubModNormal(gm, lmp)
+   GranSubModNormalHookePiecewise::GranSubModNormalHookePiecewise(GranularModel *gm, LAMMPS *lmp) :
+       GranSubModNormal(gm, lmp)
    {
      num_coeffs = 4;
    }

doc/src/Modify_overview.rst

@@ -1,42 +1,44 @@
 Overview
 ========
 
-The best way to add a new feature to LAMMPS is to find a similar feature
-and look at the corresponding source and header files to figure out what
-it does.  You will need some knowledge of C++ to be able to understand
-the high-level structure of LAMMPS and its class organization, but
-functions (class methods) that do actual computations are mostly written
-in C-style code and operate on simple C-style data structures (vectors
-and arrays).  A high-level overview of the programming style choices in
-LAMMPS is :doc:`given elsewhere <Developer_code_design>`.
+The best way to add a new feature to LAMMPS is to find a similar
+feature and look at the corresponding source and header files to
+figure out what it does.  You will need some knowledge of C++ to
+understand the high-level structure of LAMMPS and its class
+organization.  Functions (class methods) that do actual computations
+are mostly written in C-style code and operate on simple C-style data
+structures (vectors and arrays).  A high-level overview of the
+programming style choices in LAMMPS is :doc:`given elsewhere
+<Developer_code_design>`.
 
 Most of the new features described on the :doc:`Modify <Modify>` doc
-page require you to write a new C++ derived class (except for exceptions
-described below, where you can make small edits to existing files).
-Creating a new class requires 2 files, a source code file (\*.cpp) and a
-header file (\*.h).  The derived class must provide certain methods to
-work as a new option.  Depending on how different your new feature is
-compared to existing features, you can either derive from the base class
-itself, or from a derived class that already exists.  Enabling LAMMPS to
-invoke the new class is as simple as putting the two source files in the
-src directory and re-building LAMMPS.
+page require you to write a new C++ derived class (except for
+exceptions described below, where you can make small edits to existing
+files).  Creating a new class requires 2 files, a source code file
+(\*.cpp) and a header file (\*.h).  The derived class must provide
+certain methods to work as a new option.  Depending on how different
+your new feature is compared to existing features, you can either
+derive from the base class itself, or from a derived class that
+already exists.  Enabling LAMMPS to invoke the new class is as simple
+as putting the two source files in the src directory and re-building
+LAMMPS.
 
 The advantage of C++ and its object-orientation is that all the code
 and variables needed to define the new feature are in the 2 files you
-write, and thus should not make the rest of LAMMPS more complex or
-cause side-effect bugs.
+write.  Thus, it should not make the rest of LAMMPS more complex or
+cause bugs through unwanted side effects.
 
-Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
-and pair_foo.h that define a new class PairFoo that computes pairwise
-potentials described in the classic 1997 :ref:`paper <Foo>` by Foo, et al.
-If you wish to invoke those potentials in a LAMMPS input script with a
-command like
+Here is a concrete example.  Suppose you write 2 files
+``pair_foo.cpp`` and ``pair_foo.h`` that define a new class
+``PairFoo`` which computes pairwise potentials described in the
+classic 1997 :ref:`paper <Foo>` by Foo, *et al.* If you wish to invoke
+those potentials in a LAMMPS input script with a command like:
 
 .. code-block:: LAMMPS
 
    pair_style foo 0.1 3.5
 
-then your pair_foo.h file should be structured as follows:
+then your ``pair_foo.h`` file should be structured as follows:
 
 .. code-block:: c++
 
@@ -51,28 +53,27 @@ then your pair_foo.h file should be structured as follows:
    #endif
 
 where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
-files.
+``PairFoo`` is the class name defined in your ``pair_foo.cpp`` and
+``pair_foo.h`` files.
 
 When you re-build LAMMPS, your new pairwise potential becomes part of
 the executable and can be invoked with a pair_style command like the
 example above.  Arguments like 0.1 and 3.5 can be defined and
 processed by your new class.
 
-As illustrated by this example pair style, many kinds of options are
-referred to in the LAMMPS documentation as the "style" of a particular
-command.
+As illustrated by this example, many features referred to in the
+LAMMPS documentation are called a "style" of a particular command.
 
 The :doc:`Modify page <Modify>` lists all the common styles in LAMMPS,
-and discusses the header file for the base class that these styles are
-derived from.  Public variables in that file are ones used and set by
-the derived classes which are also used by the base class.  Sometimes
-they are also used by the rest of LAMMPS.  Pure functions, which means
-functions declared as virtual in the base class header file which are
-also set to 0, are functions you **must** implement in your new derived
-class to give it the functionality LAMMPS expects. Virtual functions
-that are not set to 0 are functions you may override or not.  Those
-are usually defined with an empty function body.
+and discusses the header file for the base class that these styles
+derive from.  Public variables in that file can be used and set by the
+derived classes, and may also be used by the base class.  Sometimes
+they are also accessed by the rest of LAMMPS.  Pure functions, which
+means functions declared as virtual in the base class header file and
+which are also set to 0, are functions you **must** implement in your
+new derived class to give it the functionality LAMMPS expects. Virtual
+functions that are not set to 0 are functions you may override or not.
+Those are usually defined with an empty function body.
 
 Additionally, new output options can be added directly to the
 thermo.cpp, dump_custom.cpp, and variable.cpp files.  These are also
@@ -85,9 +86,9 @@ functionality:
   post-processing step.  Many computations are more easily and more
   quickly done that way.
 * Do not try to do anything within the timestepping of a run that is not
-  parallel.  For example do not accumulate a bunch of data on a single
-  processor and analyze it.  You run the risk of seriously degrading
-  the parallel efficiency this way.
+  parallel.  For example, do not accumulate a bunch of data on a single
+  processor and analyze it.  That would run the risk of seriously degrading
+  the parallel efficiency.
 * If your new feature reads arguments or writes output, make sure you
   follow the unit conventions discussed by the :doc:`units <units>`
   command.

doc/src/Modify_requirements.rst

@@ -0,0 +1,384 @@
+Requirements for contributions to LAMMPS
+========================================
+
+The following is a summary of the current requirements and
+recommendations for including contributed source code or documentation
+into the LAMMPS software distribution.
+
+Motivation
+----------
+
+The LAMMPS developers are committed to provide a software package that
+is versatile, reliable, high-quality, efficient, portable, and easy to
+maintain and modify.  Achieving all of these goals is challenging
+since a large part of LAMMPS consists of contributed code from many
+different authors who may not be professionally trained programmers or
+familiar with the idiosyncrasies of maintaining a large software
+package.  In addition, changes that interfere with the parallel
+efficiency of the core code must be avoided.  As LAMMPS continues to
+grow and more features and functionality are added, it is necessary to
+follow established guidelines when accepting new contributions while
+also working at the same time to improve the existing code.
+
+The following requirements and recommendations are provided as a
+guide.  They indicate which individual requirements are strict, and
+which represent a preference and thus are negotiable or optional.
+Please feel free to contact the LAMMPS core developers in case you
+need additional explanations or clarifications, or you need assistance
+in implementing the (strict) requirements for your contributions.
+Requirements include:
+
+* :ref:`Licensing requirements <ReqLicense>` (strict)
+* :ref:`Integration testing <ReqIntegrationTesting>` (strict)
+* :ref:`Documentation <ReqDocumentation>` (strict)
+* :ref:`Programming language standards <ReqProgrammingStandards>` (strict)
+* :ref:`Build system <ReqBuildSystem>` (strict)
+* :ref:`Command or style names <ReqNaming>` (strict)
+* :ref:`Programming style requirements <ReqProgrammingStyle>` (varied)
+* :ref:`Examples <ReqExamples>` (preferred)
+* :ref:`Error or warning messages and explanations <ReqErrorMessages>` (preferred)
+* :ref:`Citation reminder <ReqCitation>` (optional)
+* :ref:`Testing <ReqUnitTesting>` (optional)
+
+.. _ReqLicense:
+
+Licensing requirements (strict)
+-------------------------------
+
+Contributing authors agree when submitting a pull request that their
+contributions can be distributed under the LAMMPS license conditions.
+This is the GNU public license in version 2 (not 3 or later) for the
+publicly distributed versions, e.g. on the LAMMPS homepage or on
+GitHub.  We also have a version of LAMMPS under LGPL 2.1 terms which
+is available on request; this will usually be the latest available or
+a previous stable version with a few LGPL 2.1 incompatible files
+removed.  More details are found on the :doc:`LAMMPS open-source
+license page <Intro_opensource>`.
+
+Your new source files should have the LAMMPS copyright and GPL notice,
+followed by your name and email address at the top, like other
+user-contributed LAMMPS source files.
+
+Contributions may be under a different license as long as that license
+does not conflict with the aforementioned terms.  Contributions that
+use code with a conflicting license can be split into two parts:
+
+1. the core parts (i.e. parts that must be in the `src` tree) that are
+   licensed under compatible terms and bundled with the LAMMPS sources
+2. an external library that must be downloaded and compiled (either
+   separately or as part of the LAMMPS compilation)
+
+Please note, that this split licensing mode may complicate including
+the contribution in binary packages.
+
+.. _ReqIntegrationTesting:
+
+Integration testing (strict)
+----------------------------
+
+Where possible we use available continuous integration tools to search
+for common programming mistakes, portability limitations, incompatible
+formatting, and undesired side effects. Contributed code must pass the
+automated tests on GitHub before it can be merged with the LAMMPS
+distribution. These tests compile LAMMPS in a variety of environments
+and settings and run the bundled unit tests.  At the discretion of the
+LAMMPS developer managing the pull request, additional tests may be
+activated that test for "side effects" on running a collection of
+input decks and create consistent results.  The translation of the
+documentation to HTML and PDF is also tested.
+
+This means that contributed source code **must** compile with the most
+current version of LAMMPS with ``-DLAMMPS_BIGBIG`` in addition to the
+default setting of ``-DLAMMPS_SMALLBIG``.  The code needs to work
+correctly in both cases, and also in serial and parallel using MPI.
+
+Some "disruptive" changes may break tests and require updates to the
+testing tools or scripts or tests themselves.  This is rare.  If in
+doubt, contact the LAMMPS developer that is assigned to the pull
+request.
+
+.. _ReqDocumentation:
+
+Documentation (strict)
+----------------------
+
+Contributions that add new styles or commands or augment existing ones
+must include the corresponding new or modified documentation in
+`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
+folder). The documentation should be written in American English and the
+.rst file must only use ASCII characters, so it can be cleanly
+translated to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and
+PDFLaTeX).  Special characters may be included via embedded math
+expression typeset in a LaTeX subset.
+
+.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
+
+When adding new commands, they need to be integrated into the sphinx
+documentation system, and the corresponding command tables and lists
+updated. When translating the documentation into html files there
+should be no warnings. When adding a new package, some lists
+describing packages must also be updated as well as a package specific
+description added.  Likewise, if necessary, some package specific
+build instructions should be included.
+
+As appropriate, the text files with the documentation can include
+inline mathematical expressions or figures (see ``doc/JPG`` for
+examples).  Additional PDF files with further details may also be
+included; see ``doc/PDF`` for examples.  The page should also include
+literature citations as appropriate; see the bottom of
+``doc/fix_nh.rst`` for examples and the earlier part of the same file
+for how to format the cite itself.  Citation labels must be unique
+across **all** .rst files.  The "Restrictions" section of the page
+should indicate if your command is only available if LAMMPS is built
+with the appropriate package.  See other command doc files for
+examples of how to do this.
+
+Please run at least "make html" and "make spelling" from within the
+doc/src directory, and carefully inspect and proofread the resulting
+HTML format doc page before submitting your code.  Upon submission of
+a pull request, checks for error free completion of the HTML and PDF
+build will be performed and also a spell check, a check for correct
+anchors and labels, and a check for completeness of references to all
+styles in their corresponding tables and lists is run.  In case the
+spell check reports false positives, they can be added to the file
+``doc/utils/sphinx-config/false_positives.txt``
+
+Contributions that add or modify the library interface or "public"
+APIs from the C++ code or the Fortran module must include suitable
+doxygen comments in the source and corresponding changes to the
+documentation sources for the "Programmer Guide" guide section of the
+LAMMPS manual.
+
+If your feature requires some more complex steps and explanations to
+be used correctly or some external or bundled tools or scripts, we
+recommend that you also contribute a :doc:`Howto document <Howto>`
+providing some more background information and some tutorial material.
+This can also be used to provide more in-depth explanations of models
+that require use of multiple commands.
+
+As a rule-of-thumb, the more clear and self-explanatory you make your
+documentation, README files and examples, and the easier you make it
+for people to get started, the more likely it is that users will try
+out your new feature.
+
+.. _ReqProgrammingStandards:
+
+Programming language standards (strict)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The core of LAMMPS is written in C++11 in a style that can be mostly
+described as "C with classes".  Advanced C++ features like operator
+overloading or excessive use of templates are avoided with the intent to
+keep the code readable to programmers that have limited C++ programming
+experience.  C++ constructs are acceptable when they help improve the
+readability and reliability of the code, e.g. when using the
+`std::string` class instead of manipulating pointers and calling the
+string functions of the C library.  In addition, a collection of
+convenient :doc:`utility functions and classes <Developer_utils>` for
+recurring tasks and a collection of :doc:`platform neutral functions
+<Developer_platform>` for improved portability are provided.
+Contributions with code requiring more recent C++ standards are only
+accepted as packages with the post C++11 standard code confined to the
+package so that it is optional.
+
+Included Fortran code has to be compatible with the Fortran 2003
+standard.  Since not all platforms supported by LAMMPS provide good
+support for compiling Fortran files, it should be considered to rewrite
+these parts as C++ code, if possible and thus allow for a wider adoption
+of the contribution.  As of January 2023, all previously included
+Fortran code for the LAMMPS executable has been replaced by equivalent
+C++ code.
+
+Python code must be compatible with Python 3.5 and later.  Large parts
+of LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
+compatible with Python 2.7.  Compatibility with Python 2.7 is desirable,
+but compatibility with Python 3.5 is **required**.
+
+Compatibility with older programming language standards is very
+important to maintain portability and availability of LAMMPS on many
+platforms.  This applies especially to HPC cluster environments, which
+tend to be running older software stacks and where LAMMPS users may be
+required to use those older tools for access to advanced hardware
+features or not have the option to install newer compilers or libraries.
+
+.. _ReqBuildSystem:
+
+Build system (strict)
+---------------------
+
+LAMMPS currently supports two build systems: one that is based on
+:doc:`traditional Makefiles <Build_make>` and one that is based on
+:doc:`CMake <Build_cmake>`.  Therefore, your contribution must be
+compatible with and support both build systems.
+
+For a single pair of header and implementation files that are an
+independent feature, it is usually only required to add them to
+``src/.gitignore``.
+
+For traditional make, if your contributed files or package depend on
+other LAMMPS style files or packages also being installed
+(e.g. because your file is a derived class from the other LAMMPS
+class), then an ``Install.sh`` file is also needed to check for those
+dependencies and modifications to ``src/Depend.sh`` to trigger the checks.
+See other README and Install.sh files in other directories as
+examples.
+
+Similarly, for CMake support, changes may need to be made to
+``cmake/CMakeLists.txt``, some of the files in ``cmake/presets``, and
+possibly a file with specific instructions needs to be added to
+``cmake/Modules/Packages/``.  Please check out how this is handled for
+existing packages and ask the LAMMPS developers if you need assistance.
+
+.. _ReqNaming:
+
+Command or style names, file names, and keywords (strict)
+---------------------------------------------------------
+
+All user-visible command or style names should be all lower case and
+should only use letters, numbers, or forward slashes.  They should be
+descriptive and initialisms should be avoided unless they are well
+established (e.g. lj for Lennard-Jones).  For a compute style
+"some/name" the source files must be called ``compute_some_name.h`` and
+``compute_some_name.cpp``. The "include guard" in the header file would
+then be ``LMP_COMPUTE_SOME_NAME_H`` and the class name
+``ComputeSomeName``.
+
+.. _ReqProgrammingStyle:
+
+Programming style requirements (varied)
+---------------------------------------
+
+To maintain source code consistency across contributions from many
+people, there are various programming style requirements for
+contributions to LAMMPS.  Some of these requirements are strict and
+must be followed, while others are only preferred and thus may be
+skipped.  An in-depth discussion of the style guidelines is provided
+in the :doc:`programming style doc page <Modify_style>`.
+
+.. _ReqExamples:
+
+Examples (preferred)
+--------------------
+
+For many new features, it is preferred that example scripts (simple,
+small, fast to complete on 1 CPU) are included that demonstrate the
+use of new or extended functionality. These are typically include
+under the examples or examples/PACKAGES directory and are further
+described on the :doc:`examples page <Examples>`.  Guidelines for
+input scripts include:
+
+- commands that generate output should be commented out (except when the
+  output is the sole purpose or the feature, e.g. for a new compute)
+
+- commands like :doc:`log <log>`, :doc:`echo <echo>`, :doc:`package
+  <package>`, :doc:`processors <processors>`, :doc:`suffix <suffix>` may
+  **not** be used in the input file (exception: "processors * * 1" or
+  similar is acceptable when used to avoid unwanted domain decomposition
+  of empty volumes)
+
+- outside of the log files, no generated output should be included
+
+- custom thermo_style settings may not include output measuring CPU or other
+  time as it complicates comparisons between different runs
+
+- input files should be named ``in.name``, data files should be named
+  ``data.name`` and log files should be named ``log.version.name.<compiler>.<ncpu>``
+
+- the total file size of all the inputs and outputs should be small
+
+- where possible, potential files from the "potentials" folder or data
+  file from other folders should be re-used through symbolic links
+
+.. _ReqErrorMessages:
+
+Error or warning messages and explanations (preferred)
+------------------------------------------------------
+
+.. versionchanged:: 4May2022
+
+Starting with LAMMPS version 4 May 2022, the LAMMPS developers have
+agreed on a new policy for error and warning messages.
+
+Previously, all error and warning strings were supposed to be listed in
+the class header files with an explanation.  Those would then be
+regularly "harvested" and transferred to alphabetically sorted lists in
+the manual.  To avoid excessively long lists and to reduce effort, this
+came with a requirement to have rather generic error messages (e.g.
+"Illegal ... command").  To identify the specific cause, the name of the
+source file and the line number of the error location would be printed,
+so that one could look up the cause by reading the source code.
+
+The new policy encourages more specific error messages that ideally
+indicate the cause directly, and requiring no further lookup. This is
+aided by the `{fmt} library <https://fmt.dev>`_ enabling Error class
+methods that take a variable number of arguments and an error text that
+will be treated like a {fmt} syntax format string. Error messages should
+still preferably be kept to a single line or two lines at most.
+
+For more complex explanations or errors that have multiple possible
+reasons, a paragraph should be added to the `Error_details` page with an
+error code reference (e.g. ``.. _err0001:``) then the utility function
+:cpp:func:`utils::errorurl() <LAMMPS_NS::utils::errorurl>` can be used
+to generate a URL that will directly lead to that paragraph.  An error
+for missing arguments can be easily generated using the
+:cpp:func:`utils::missing_cmd_args()
+<LAMMPS_NS::utils::missing_cmd_args>` convenience function.
+An example for this approach would be the
+``src/read_data.cpp`` and ``src/atom.cpp`` files that implement the
+:doc:`read_data <read_data>` and :doc:`atom_modify <atom_modify>`
+commands and that may create :ref:`"Unknown identifier in data file" <err0001>`
+errors that may have multiple possible reasons which complicates debugging,
+and thus require some additional explanation.
+
+The transformation of existing LAMMPS code to this new scheme is
+ongoing.  Given the size of the LAMMPS code base, it will take a
+significant amount of time to complete.  For new code, however,
+following the new approach is strongly preferred.  The expectation is
+that the new scheme will make understanding errors easier for LAMMPS
+users, developers, and maintainers.
+
+.. _ReqCitation:
+
+Citation reminder (optional)
+-----------------------------
+
+If there is a paper of yours describing your feature (either the
+algorithm/science behind the feature itself, or its initial usage, or
+its implementation in LAMMPS), you can add the citation to the \*.cpp
+source file.  See ``src/DIFFRACTION/compute_saed.cpp`` for an example.
+A BibTeX format citation is stored in a string variable at the top of
+the file, and a single line of code registering this variable is added
+to the constructor of the class.  When your feature is used, then
+LAMMPS (by default) will print the brief info and the DOI in the first
+line to the screen and the full citation to the log file.
+
+If there is additional functionality (which may have been added later)
+described in a different publication, additional citation descriptions
+may be added so long as they are only registered when the
+corresponding keyword activating this functionality is used.
+
+With these options, it is possible to have LAMMPS output a specific
+citation reminder whenever a user invokes your feature from their
+input script.  Please note that you should *only* use this for the
+*most* relevant paper for a feature and a publication that you or your
+group authored.  E.g. adding a citation in the source code for a paper
+by Nose and Hoover if you write a fix that implements their integrator
+is not the intended usage.  That kind of citation should just be
+included in the documentation page you provide describing your
+contribution.  If you are not sure what the best option would be,
+please contact the LAMMPS developers for advice.
+
+.. _ReqUnitTesting:
+
+Testing (optional)
+------------------
+
+If your contribution contains new utility functions or a supporting
+class (i.e. anything that does not depend on a LAMMPS object), new
+unit tests should be added to a suitable folder in the ``unittest``
+tree.  When adding a new LAMMPS style computing forces or selected
+fixes, a ``.yaml`` file with a test configuration and reference data
+should be added for the styles where a suitable tester program already
+exists (e.g. pair styles, bond styles, etc.). Please see :ref:`this
+section in the manual <testing>` for more information on how to
+enable, run, and expand testing.

doc/src/Modify_style.rst

@@ -1,350 +1,72 @@
-LAMMPS programming style and requirements for contributions
-===========================================================
-
-The following is a summary of the current requirements and
-recommendations for including contributed source code or documentation
-into the LAMMPS software distribution.
-
-Motivation
-----------
-
-The LAMMPS developers are committed to providing a software package that
-is versatile, reliable, high-quality, efficient, portable, and easy to
-maintain and modify.  Achieving all of these goals is challenging since
-a large part of LAMMPS consists of contributed code from many different
-authors and not many of them are professionally trained programmers and
-familiar with the idiosyncrasies of maintaining a large software
-package.  In addition, changes that interfere with the parallel
-efficiency of the core code must be avoided.  As LAMMPS continues to
-grow and more features and functionality are added, it becomes a
-necessity to be more discriminating with new contributions while also
-working at the same time to improve the existing code.
-
-The following requirements and recommendations are provided to help
-maintaining or improving that status.  Where possible we utilize
-available continuous integration tools to search for common programming
-mistakes, portability limitations, incompatible formatting, and
-undesired side effects.  It is indicated which requirements are strict,
-and which represent a preference and thus are negotiable or optional.
-
-Please feel free to contact the LAMMPS core developers in case you need
-additional explanations or clarifications or in case you need assistance
-in realizing the (strict) requirements for your contributions.
-
-Licensing requirements (strict)
--------------------------------
-
-Contributing authors agree when submitting a pull request that their
-contributions can be distributed under the LAMMPS license
-conditions. This is the GNU public license in version 2 (not 3 or later)
-for the publicly distributed versions, e.g. on the LAMMPS homepage or on
-GitHub.  On request we also make a version of LAMMPS available under
-LGPL 2.1 terms; this will usually be the latest available or a previous
-stable version with a few LGPL 2.1 incompatible files removed.
-
-Your new source files should have the LAMMPS copyright, GPL notice, and
-your name and email address at the top, like other user-contributed
-LAMMPS source files.
-
-Contributions may be under a different license for long as that
-license does not conflict with the aforementioned terms.  Contributions
-that use code with a conflicting license can be split into two parts:
-
-1. the core parts (i.e. parts that must be in the `src` tree) that are
-   licensed under compatible terms and bundled with the LAMMPS sources
-2. an external library that must be downloaded and compiled (either
-   separately or as part of the LAMMPS compilation)
-
-Please note, that this split licensed mode may complicate including the
-contribution in binary packages.
-
-Using Pull Requests on GitHub (preferred)
------------------------------------------
-
-All contributions to LAMMPS are processed as pull requests on GitHub
-(this also applies to the work of the core LAMMPS developers).  A
-:doc:`tutorial for submitting pull requests on GitHub <Howto_github>` is
-provided.  If this is still problematic, contributors may contact any of
-the core LAMMPS developers for help or to create a pull request on their
-behalf.  This latter way of submission may delay the integration as it
-depends on the amount of time required to prepare the pull request and
-free time available by the LAMMPS developer in question to spend on this
-task.
-
-Integration Testing (strict)
-----------------------------
-
-Contributed code, like all pull requests, must pass the automated
-tests on GitHub before it can be merged with the LAMMPS distribution.
-These tests compile LAMMPS in a variety of environments and settings and
-run the bundled unit tests.  At the discretion of the LAMMPS developer
-managing the pull request, additional tests may be activated that test
-for "side effects" on running a collection of input decks and create
-consistent results.  Also, the translation of the documentation to HTML
-and PDF is tested for.
-
-More specifically, this means that contributed source code **must**
-compile with the most current version of LAMMPS with ``-DLAMMPS_BIGBIG``
-in addition to the default setting of ``-DLAMMPS_SMALLBIG``.  The code
-needs to work correctly in both cases and also in serial and parallel
-using MPI.
-
-Some "disruptive" changes may break tests and require updates to the
-testing tools or scripts or tests themselves.  This is rare.  If in
-doubt, contact the LAMMPS developer that is assigned to the pull request
-for further details and explanations and suggestions of what needs to be
-done.
-
-Documentation (strict)
-----------------------
-
-Contributions that add new styles or commands or augment existing ones
-must include the corresponding new or modified documentation in
-`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
-folder). The documentation shall be written in American English and the
-.rst file must use only ASCII characters so it can be cleanly translated
-to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
-Special characters may be included via embedded math expression typeset
-in a LaTeX subset.
-
-.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
-
-When adding new commands, they need to be integrated into the sphinx
-documentation system, and the corresponding command tables and lists
-updated. When translating the documentation into html files there should
-be no warnings. When adding a new package also some lists describing
-packages must be updated as well as a package specific description added
-and, if necessary, some package specific build instructions included.
-
-As appropriate, the text files with the documentation can include inline
-mathematical expression or figures (see ``doc/JPG`` for examples).
-Additional PDF files with further details (see ``doc/PDF`` for examples) may
-also be included.  The page should also include literature citations as
-appropriate; see the bottom of ``doc/fix_nh.rst`` for examples and the
-earlier part of the same file for how to format the cite itself.
-Citation labels must be unique across **all** .rst files.  The
-"Restrictions" section of the page should indicate if your command is
-only available if LAMMPS is built with the appropriate FOO package.  See
-other package doc files for examples of how to do this.
-
-Please run at least "make html" and "make spelling" and carefully
-inspect and proofread the resulting HTML format doc page before
-submitting your code.  Upon submission of a pull request, checks for
-error free completion of the HTML and PDF build will be performed and
-also a spell check, a check for correct anchors and labels, and a check
-for completeness of references all styles in their corresponding tables
-and lists is run.  In case the spell check reports false positives they
-can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
-
-Contributions that add or modify the library interface or "public" APIs
-from the C++ code or the Fortran module must include suitable doxygen
-comments in the source and corresponding changes to the documentation
-sources for the "Programmer Guide" guide section of the LAMMPS manual.
-
-Examples (preferred)
---------------------
-
-In most cases, it is preferred that example scripts (simple, small, fast
-to complete on 1 CPU) are included that demonstrate the use of new or
-extended functionality. These are typically under the examples or
-examples/PACKAGES directory.  A few guidelines for such example input
-decks.
-
-- commands that generate output should be commented out (except when the
-  output is the sole purpose or the feature, e.g. for a new compute).
-
-- commands like :doc:`log <log>`, :doc:`echo <echo>`, :doc:`package
-  <package>`, :doc:`processors <processors>`, :doc:`suffix <suffix>` may
-  **not** be used in the input file (exception: "processors * * 1" or
-  similar is acceptable when used to avoid unwanted domain decomposition
-  of empty volumes).
-
-- outside of the log files no generated output should be included
-
-- custom thermo_style settings may not include output measuring CPU or other time
-  as that makes comparing the thermo output between different runs more complicated.
-
-- input files should be named ``in.name``, data files should be named
-  ``data.name`` and log files should be named ``log.version.name.<compiler>.<ncpu>``
-
-- the total file size of all the inputs and outputs should be small
-
-- where possible potential files from the "potentials" folder or data
-  file from other folders should be re-used through symbolic links
-
-Howto document (optional)
--------------------------
-
-If your feature requires some more complex steps and explanations to be
-used correctly or some external or bundled tools or scripts, we
-recommend that you also contribute a :doc:`Howto document <Howto>`
-providing some more background information and some tutorial material.
-This can also be used to provide more in-depth explanations for bundled
-examples.
-
-As a general rule-of-thumb, the more clear and self-explanatory you make
-your documentation, README files and examples, and the easier you make
-it for people to get started, the more likely it is that users will try
-out your new feature.
-
-Programming Style Requirements (varied)
----------------------------------------
-
-The LAMMPS developers aim to employ a consistent programming style and
-naming conventions across the entire code base, as this helps with
-maintenance, debugging, and understanding the code, both for developers
-and users.
-
-The files `pair_lj_cut.h`, `pair_lj_cut.cpp`, `utils.h`, and `utils.cpp`
-may serve as representative examples.
-
-Command or Style names, file names, and keywords (mostly strict)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All user-visible command or style names should be all lower case and
-should only use letters, numbers, or forward slashes.  They should be
-descriptive and initialisms should be avoided unless they are well
-established (e.g. lj for Lennard-Jones).  For a compute style
-"some/name" the source files must be called `compute_some_name.h` and
-`compute_some_name.cpp`. The "include guard" would then be
-`LMP_COMPUTE_SOME_NAME_H` and the class name `ComputeSomeName`.
-
-Whitespace and permissions (preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Source files should not contain TAB characters unless required by the
-syntax (e.g. in makefiles) and no trailing whitespace.  Text files
-should be added with Unix-style line endings (LF-only). Git will
-automatically convert those in both directions when running on Windows;
-use dos2unix on Linux machines to convert files.  Text files should have
-a line ending on the last line.
-
-All files should have 0644 permissions, i.e writable to the user only
-and readable by all and no executable permissions.  Executable
-permissions (0755) should only be on shell scripts or python or similar
-scripts for interpreted script languages.
-
-You can check for these issues with the python scripts in the
-:ref:`"tools/coding_standard" <coding_standard>` folder.  When run
-normally with a source file or a source folder as argument, they will
-list all non-conforming lines.  By adding the `-f` flag to the command
-line, they will modify the flagged files to try removing the detected
-issues.
-
-Indentation and Placement of Braces (strongly preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-LAMMPS uses 2 characters per indentation level and lines should be
-kept within 100 characters wide.
-
-For new files added to the "src" tree, a `clang-format
-<https://clang.llvm.org/docs/ClangFormat.html>`_ configuration file is
-provided under the name `.clang-format`.  This file is compatible with
-clang-format version 8 and later. With that file present files can be
-reformatted according to the configuration with a command like:
-`clang-format -i new-file.cpp`.  Ideally, this is done while writing the
-code or before a pull request is submitted.  Blocks of code where the
-reformatting from clang-format yields undesirable output may be
-protected with placing a pair `// clang-format off` and `// clang-format
-on` comments around that block.
-
-Error or warning messages and explanations (preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionchanged:: 4May2022
-
-Starting with LAMMPS version 4 May 2022 the LAMMPS developers have
-agreed on a new policy for error and warning messages.
-
-Previously, all error and warning strings were supposed to be listed in
-the class header files with an explanation.  Those would then be
-regularly "harvested" and transferred to alphabetically sorted lists in
-the manual.  To avoid excessively long lists and to reduce effort, this
-came with a requirement to have rather generic error messages (e.g.
-"Illegal ... command").  To identify the specific cause, the name of the
-source file and the line number of the error location would be printed,
-so that one could look up the cause by reading the source code.
-
-The new policy encourages more specific error messages that ideally
-indicate the cause directly and no further lookup would be needed.
-This is aided by using the `{fmt} library <https://fmt.dev>`_ to convert
-the Error class commands so that they take a variable number of arguments
-and error text will be treated like a {fmt} syntax format string.
-Error messages should still kept to a single line or two lines at the most.
-
-For more complex explanations or errors that have multiple possible
-reasons, a paragraph should be added to the `Error_details` page with an
-error code reference (e.g. ``.. _err0001:``) then the utility function
-:cpp:func:`utils::errorurl() <LAMMPS_NS::utils::errorurl>` can be used
-to generate an URL that will directly lead to that paragraph.  An error
-for missing arguments can be easily generated using the
-:cpp:func:`utils::missing_cmd_args()
-<LAMMPS_NS::utils::missing_cmd_args>` convenience function.
-
-The transformation of existing LAMMPS code to this new scheme is ongoing
-and - given the size of the LAMMPS source code - will take a significant
-amount of time until completion.  However, for new code following the
-new approach is strongly preferred.  The expectation is that the new
-scheme will make it easier for LAMMPS users, developers, and
-maintainers.
-
-An example for this approach would be the
-``src/read_data.cpp`` and ``src/atom.cpp`` files that implement the
-:doc:`read_data <read_data>` and :doc:`atom_modify <atom_modify>`
-commands and that may create :ref:`"Unknown identifier in data file" <err0001>`
-errors that seem difficult to debug for users because they may have
-one of multiple possible reasons, and thus require some additional explanations.
-
-Programming language standards (required)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The core of LAMMPS is written in C++11 in a style that can be mostly
-described as "C with classes".  Advanced C++ features like operator
-overloading or excessive use of templates are avoided with the intent to
-keep the code readable to programmers that have limited C++ programming
-experience.  C++ constructs are acceptable when they help improving the
-readability and reliability of the code, e.g. when using the
-`std::string` class instead of manipulating pointers and calling the
-string functions of the C library.  In addition a collection of
-convenient :doc:`utility functions and classes <Developer_utils>` for
-recurring tasks and a collection of
-:doc:`platform neutral functions <Developer_platform>` for improved
-portability are provided.
-
-Included Fortran code has to be compatible with the Fortran 2003
-standard.  Python code must be compatible with Python 3.5.  Large parts
-or LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
-compatible with Python 2.7.  Compatibility with Python 2.7 is
-desirable, but compatibility with Python 3.5 is **required**.
-
-Compatibility with these older programming language standards is very
-important to maintain portability and availability of LAMMPS on many
-platforms.  This applies especially to HPC cluster environments, which
-tend to be running older software stacks and LAMMPS users may be
-required to use those older tools for access to advanced hardware
-features or not have the option to install newer compilers or libraries.
-
-Programming conventions (varied)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following is a collection of conventions that should be applied when
-writing code for LAMMPS.  Following these steps will make it much easier
-to integrate your contribution. Please have a look at the existing files
-in packages in the src directory for examples.  As a demonstration for
-how can be adapted to these conventions you may compare the REAXFF
-package with the what it looked like when it was called USER-REAXC.  If
-you are uncertain, please ask.
-
-- system headers or from installed libraries are include with angular
-  brackets (example: ``#include <vector>``), while local include file
-  use double quotes (example: ``#include "atom.h"``).
-
-- when including system header files from the C library use the
-    C++-style names (``<cstdlib>`` or ``<cstring>``) instead of the
-    C-style names (``<stdlib.h>`` or ``<string.h>``)
-
-- the order of ``#include`` statements in a file ``some_name.cpp`` that
-  implements a class ``SomeName`` defined in a header file
+LAMMPS programming style
+========================
+
+The aim of the LAMMPS developers is to use a consistent programming
+style and naming conventions across the entire code base, as this
+helps with maintenance, debugging, and understanding the code, both
+for developers and users.  This page provides a list of standard style
+choices used in LAMMPS.  Some of these standards are required, while
+others are just preferred.  Following these conventions will make it
+much easier to integrate your contribution.  If you are uncertain,
+please ask.
+
+The files `pair_lj_cut.h`, `pair_lj_cut.cpp`, `utils.h`, and
+`utils.cpp` may serve as representative examples.
+
+Include files (varied)
+^^^^^^^^^^^^^^^^^^^^^^
+
+- Header files that define a new LAMMPS style (i.e. that have a
+  ``SomeStyle(some/name,SomeName);`` macro in them) should only use
+  the include file for the base class and otherwise use forward
+  declarations and pointers; when interfacing to a library use the
+  PIMPL (pointer to implementation) approach where you have a pointer
+  to a struct that contains all library specific data (and thus
+  requires the library header) but use a forward declaration and
+  define the struct only in the implementation file. This is a
+  **strict** requirement since this is where type clashes between
+  packages and hard-to-find bugs have regularly manifested in the
+  past.
+
+- Header files, especially those defining a "style", should only use the
+  absolute minimum number of include files and **must not** contain any
+  ``using`` statements. Typically, that would only be the header for the
+  base class.  Instead, any include statements should be put in the
+  corresponding implementation files and forward declarations be used.
+  For implementation files, the "include what you use" principle should
+  be employed.  However, there is the notable exception that when the
+  ``pointers.h`` header is included (or the header of one of the classes
+  derived from it), certain headers will *always* be included and thus
+  do not need to be explicitly specified.  These are: `mpi.h`,
+  `cstddef`, `cstdio`, `cstdlib`, `string`, `utils.h`, `vector`,
+  `fmt/format.h`, `climits`, `cinttypes`.  This also means any such file
+  can assume that `FILE`, `NULL`, and `INT_MAX` are defined.
+
+- Class members variables should not be initialized in the header file,
+  but instead should be initialized either in the initializer list of
+  the constructor or explicitly assigned in the body of the constructor.
+  If the member variable is relevant to the functionality of a class
+  (for example when it stores a value from a command line argument), the
+  member variable declaration is followed by a brief comment explaining
+  its purpose and what its values can be.  Class members that are
+  pointers should always be initialized to ``nullptr`` in the
+  initializer list of the constructor.  This reduces clutter in the
+  header and avoids accessing uninitialized pointers, which leads to
+  hard to debug issues, class members are often implicitly initialized
+  to ``NULL`` on the first use (but *not* after a :doc:`clear command
+  <clear>`).  Please see the files ``reset_atoms_mol.h`` and
+  ``reset_atoms_mol.cpp`` as an example.
+
+- System headers or headers from installed libraries are included with
+  angular brackets (example: ``#include <vector>``), while local
+  include files use double quotes (example: ``#include "atom.h"``)
+
+- When including system header files from the C library use the
+  C++-style names (``<cstdlib>`` or ``<cstring>``) instead of the
+  C-style names (``<stdlib.h>`` or ``<string.h>``)
+
+- The order of ``#include`` statements in a file ``some_name.cpp``
+  that implements a class ``SomeName`` defined in a header file
   ``some_name.h`` should be as follows:
 
   - ``#include "some_name.h"`` followed by an empty line
@@ -352,34 +74,70 @@ you are uncertain, please ask.
   - LAMMPS include files e.g. ``#include "comm.h"`` or ``#include
     "modify.h"`` in alphabetical order followed by an empty line
 
-  - system header files from the C++ or C standard library followed by
+  - System header files from the C++ or C standard library followed by
     an empty line
 
   - ``using namespace LAMMPS_NS`` or other namespace imports.
 
+Whitespace (preferred)
+^^^^^^^^^^^^^^^^^^^^^^
+
+Source files should not contain TAB characters unless required by the
+syntax (e.g. in makefiles) and no trailing whitespace.  Text files
+should have Unix-style line endings (LF-only). Git will automatically
+convert those in both directions when running on Windows; use dos2unix
+on Linux machines to convert files to Unix-style line endings.  The
+last line of text files include a line ending.
+
+You can check for these issues with the python scripts in the
+:ref:`"tools/coding_standard" <coding_standard>` folder.  When run
+normally with a source file or a source folder as argument, they will
+list all non-conforming lines.  By adding the `-f` flag to the command
+line, they will modify the flagged files to try to remove the detected
+issues.
+
+Placement of braces (strongly preferred)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For new files added to the "src" tree, a `clang-format
+<https://clang.llvm.org/docs/ClangFormat.html>`_ configuration file is
+provided under the name `.clang-format`.  This file is compatible with
+clang-format version 8 and later. With that file present, files can be
+reformatted according to the configuration with a command like:
+`clang-format -i new-file.cpp`.  Ideally, this is done while writing
+the code or before a pull request is submitted.  Blocks of code where
+the reformatting from clang-format yields hard-to-read or otherwise
+undesirable output may be protected with placing a pair `//
+clang-format off` and `// clang-format on` comments around that block.
+
+Miscellaneous standards (varied)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 - I/O is done via the C-style stdio library and **not** iostreams.
 
 - Do not use so-called "alternative tokens" like ``and``, ``or``,
   ``not`` and similar, but rather use the corresponding operators
   ``&&``, ``||``, and ``!``.  The alternative tokens are not available
-  by default on all compilers, and also we want to maintain a consistent
-  programming style.
+  by default on all compilers.
 
-- Output to the screen and the logfile should be using the corresponding
-  FILE pointers and only be done on MPI rank 0.  Use the :cpp:func:`utils::logmesg`
-  convenience function where possible.
+- Output to the screen and the logfile should use the corresponding
+  FILE pointers and only be done on MPI rank 0.  Use the
+  :cpp:func:`utils::logmesg` convenience function where possible.
 
-- Usage of C++11 `virtual`, `override`, `final` keywords: Please follow the
-  `C++ Core Guideline C.128 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
+- Usage of C++11 `virtual`, `override`, `final` keywords: Please
+  follow the `C++ Core Guideline C.128
+  <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
   That means, you should only use `virtual` to declare a new virtual
-  function, `override` to indicate you are overriding an existing virtual
-  function, and `final` to prevent any further overriding.
+  function, `override` to indicate you are overriding an existing
+  virtual function, and `final` to prevent any further overriding.
 
-- Trivial destructors: Prefer not writing destructors when they are empty and `default`.
+- Trivial destructors: Do not write destructors when they are empty
+  and `default`.
 
   .. code-block:: c++
 
      // don't write destructors for A or B like this
+
      class A : protected Pointers {
       public:
         A();
@@ -393,6 +151,7 @@ you are uncertain, please ask.
      };
 
      // instead, let the compiler create the implicit default destructor by not writing it
+
      class A : protected Pointers {
       public:
         A();
@@ -403,37 +162,11 @@ you are uncertain, please ask.
         B();
      };
 
-- Header files, especially those defining a "style", should only use
-  the absolute minimum number of include files and **must not** contain
-  any ``using`` statements. Typically that would be only the header for
-  the base class. Instead any include statements should be put into the
-  corresponding implementation files and forward declarations be used.
-  For implementation files, the "include what you use" principle should
-  be employed.  However, there is the notable exception that when the
-  ``pointers.h`` header is included (or one of the base classes derived
-  from it) certain headers will always be included and thus do not need
-  to be explicitly specified.
-  These are: `mpi.h`, `cstddef`, `cstdio`, `cstdlib`, `string`, `utils.h`,
-  `vector`, `fmt/format.h`, `climits`, `cinttypes`.
-  This also means any such file can assume that `FILE`, `NULL`, and
-  `INT_MAX` are defined.
-
-- Header files that define a new LAMMPS style (i.e. that have a
-  ``SomeStyle(some/name,SomeName);`` macro in them) should only use the
-  include file for the base class and otherwise use forward declarations
-  and pointers; when interfacing to a library use the PIMPL (pointer
-  to implementation) approach where you have a pointer to a struct
-  that contains all library specific data (and thus requires the library
-  header) but use a forward declaration and define the struct only in
-  the implementation file. This is a **strict** requirement since this
-  is where type clashes between packages and hard to find bugs have
-  regularly manifested in the past.
-
 - Please use clang-format only to reformat files that you have
   contributed.  For header files containing a ``SomeStyle(keyword,
-  ClassName)`` macros it is required to have this macro embedded with a
-  pair of ``// clang-format off``, ``// clang-format on`` commends and
-  the line must be terminated with a semi-colon (;).  Example:
+  ClassName)`` macros it is required to have this macro embedded with
+  a pair of ``// clang-format off``, ``// clang-format on`` comments
+  and the line must be terminated with a semicolon (;).  Example:
 
   .. code-block:: c++
 
@@ -446,92 +179,10 @@ you are uncertain, please ask.
      #ifndef LMP_RUN_H
      [...]
 
-  You may also use ``// clang-format on/off`` throughout your files
-  to protect individual sections from being reformatted.
+  You may also use ``// clang-format on/off`` throughout your files to
+  protect individual sections from being reformatted.
 
-- We rarely accept new styles in the core src folder.  Thus please
-  review the list of :doc:`available Packages <Packages_details>` to see
-  if your contribution could be added to be added to one of them.  It
-  should fit into the general purposed of that package.  If it does not
-  fit well, it may be added to one of the EXTRA- packages or the MISC
-  package.
-
-
-Contributing a package
-----------------------
-
-If your contribution has several related features that are not covered
-by one of the existing packages or is dependent on a library (bundled or
-external), it is best to make it a package directory with a name like
-FOO.  In addition to your new files, the directory should contain a
-README text file.  The README should contain your name and contact
-information and a brief description of what your new package does.
-
-
-Build system (strongly preferred)
----------------------------------
-
-LAMMPS currently supports two build systems: one that is based on
-:doc:`traditional Makefiles <Build_make>` and one that is based on
-:doc:`CMake <Build_cmake>`.  Thus your contribution must be compatible
-with and support both.
-
-For a single pair of header and implementation files that are an
-independent feature, it is usually only required to add them to
-`src/.gitignore``.
-
-For traditional make, if your contributed files or package depend on
-other LAMMPS style files or packages also being installed (e.g. because
-your file is a derived class from the other LAMMPS class), then an
-Install.sh file is also needed to check for those dependencies and
-modifications to src/Depend.sh to trigger the checks.  See other README
-and Install.sh files in other directories as examples.
-
-Similarly for CMake support, changes may need to be made to
-cmake/CMakeLists.txt, some of the files in cmake/presets, and possibly a
-file with specific instructions needs to be added to
-cmake/Modules/Packages/.  Please check out how this is handled for
-existing packages and ask the LAMMPS developers if you need assistance.
-
-
-Citation reminder (suggested)
------------------------------
-
-If there is a paper of yours describing your feature (either the
-algorithm/science behind the feature itself, or its initial usage, or
-its implementation in LAMMPS), you can add the citation to the \*.cpp
-source file.  See ``src/DIFFRACTION/compute_saed.cpp`` for an example.
-A BibTeX format citation is stored in a string variable at the top
-of the file and  a single line of code registering this variable is
-added to the constructor of the class.  When your feature is used,
-by default, LAMMPS will print the brief info and the DOI
-in the first line to the screen and the full citation to the log file.
-
-If there is additional functionality (which may have been added later)
-described in a different publication, additional citation descriptions
-may be added for as long as they are only registered when the
-corresponding keyword activating this functionality is used.  With these
-options it is possible to have LAMMPS output a specific citation
-reminder whenever a user invokes your feature from their input script.
-Please note that you should *only* use this for the *most* relevant
-paper for a feature and a publication that you or your group authored.
-E.g. adding a citation in the code for a paper by Nose and Hoover if you
-write a fix that implements their integrator is not the intended usage.
-That latter kind of citation should just be included in the
-documentation page you provide describing your contribution.  If you are
-not sure what the best option would be, please contact the LAMMPS
-developers for advice.
-
-
-Testing (optional)
-------------------
-
-If your contribution contains new utility functions or a supporting class
-(i.e. anything that does not depend on a LAMMPS object), new unit tests
-should be added to a suitable folder in the ``unittest`` tree.
-When adding a new LAMMPS style computing forces or selected fixes,
-a ``.yaml`` file with a test configuration and reference data should be
-added for the styles where a suitable tester program already exists
-(e.g. pair styles, bond styles, etc.). Please see
-:ref:`this section in the manual <testing>` for more information on
-how to enable, run, and expand testing.
+- All files should have 0644 permissions, i.e. writable by the user
+  only and readable by all and no executable permissions.  Executable
+  permissions (0755) should only be for shell scripts or python or
+  similar scripts for interpreted script languages.

doc/src/Packages_details.rst

@@ -67,7 +67,6 @@ page gives those details.
    * :ref:`KOKKOS <PKG-KOKKOS>`
    * :ref:`KSPACE <PKG-KSPACE>`
    * :ref:`LATBOLTZ <PKG-LATBOLTZ>`
-   * :ref:`LATTE <PKG-LATTE>`
    * :ref:`LEPTON <PKG-LEPTON>`
    * :ref:`MACHDYN <PKG-MACHDYN>`
    * :ref:`MANIFOLD <PKG-MANIFOLD>`
@@ -1357,43 +1356,6 @@ The LATBOLTZ package requires that LAMMPS is build in :ref:`MPI parallel mode <s
 
 ----------
 
-.. _PKG-LATTE:
-
-LATTE package
--------------
-
-**Contents:**
-
-A fix command which wraps the LATTE DFTB code, so that molecular
-dynamics can be run with LAMMPS using density-functional tight-binding
-quantum forces calculated by LATTE.
-
-More information on LATTE can be found at this website:
-`https://github.com/lanl/LATTE <latte-home_>`_.  A brief technical
-description is given with the :doc:`fix latte <fix_latte>` command.
-
-.. _latte-home: https://github.com/lanl/LATTE
-
-**Authors:** Christian Negre (LANL) and Steve Plimpton (Sandia).  LATTE
-itself is developed at Los Alamos National Laboratory by Marc
-Cawkwell, Anders Niklasson, and Christian Negre.
-
-**Install:**
-
-This package has :ref:`specific installation instructions <latte>` on
-the :doc:`Build extras <Build_extras>` page.
-
-**Supporting info:**
-
-* src/LATTE: filenames -> commands
-* src/LATTE/README
-* lib/latte/README
-* :doc:`fix latte <fix_latte>`
-* examples/latte
-* `LAMMPS-LATTE tutorial <https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS>`_
-
-----------
-
 .. _PKG-LEPTON:
 
 LEPTON package

doc/src/Packages_list.rst

@@ -233,11 +233,6 @@ whether an extra library is needed to build and use the package:
      - :doc:`fix lb/fluid <fix_lb_fluid>`
      - PACKAGES/latboltz
      - no
-   * - :ref:`LATTE <PKG-LATTE>`
-     - quantum DFTB forces via LATTE
-     - :doc:`fix latte <fix_latte>`
-     - latte
-     - ext
    * - :ref:`LEPTON <PKG-LEPTON>`
      - evaluate strings as potential function
      - :doc:`pair_style lepton <pair_lepton>`

doc/src/Python_properties.rst

@@ -53,6 +53,7 @@ against invalid accesses.
 
       * :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
       * :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
+      * :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
       * :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
       * :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
       * :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
@@ -60,6 +61,10 @@ against invalid accesses.
       * :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
       * :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
 
+      **Properties**:
+
+      * :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
+
    .. tab:: PyLammps/IPyLammps API
 
       In addition to the functions provided by :py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>` objects

doc/src/Speed_kokkos.rst

@@ -18,7 +18,7 @@ package was developed primarily by Christian Trott (Sandia) and Stan
 Moore (Sandia) with contributions of various styles by others,
 including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
 (Sandia). For more information on developing using Kokkos abstractions
-see the Kokkos `Wiki <https://github.com/kokkos/kokkos/wiki>`_.
+see the `Kokkos Wiki <https://github.com/kokkos/kokkos/wiki>`_.
 
 Kokkos currently provides support for 4 modes of execution (per MPI
 task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
@@ -29,11 +29,12 @@ produce an executable compatible with a specific hardware.
 .. admonition:: C++14 support
    :class: note
 
-   Kokkos requires using a compiler that supports the c++14 standard. For
-   some compilers, it may be necessary to add a flag to enable c++14 support.
+   Kokkos version 3.x requires using a compiler that supports the c++14 standard.
+   For some compilers, it may be necessary to add a flag to enable c++14 support.
    For example, the GNU compiler uses the -std=c++14 flag. For a list of
-   compilers that have been tested with the Kokkos library, see the Kokkos
-   `README <https://github.com/kokkos/kokkos/blob/master/README.md>`_.
+   compilers that have been tested with the Kokkos library, see the
+   `requirements document of the Kokkos Wiki
+   <https://kokkos.github.io/kokkos-core-wiki/requirements.html>`_.
 
 .. admonition:: NVIDIA CUDA support
    :class: note
@@ -285,6 +286,16 @@ one or more nodes, each with two GPUs:
    settings. Experimenting with its options can provide a speed-up for
    specific calculations. For example:
 
+.. note::
+
+   The default binsize for :doc:`atom sorting <atom_modify>` on GPUs
+   is equal to the default CPU neighbor binsize (i.e. 2x smaller than the
+   default GPU neighbor binsize). When running simple pair-wise
+   potentials like Lennard Jones on GPUs, using a 2x larger binsize for
+   atom sorting (equal to the default GPU neighbor binsize) and a more
+   frequent sorting than default (e.g. sorting every 100 time steps
+   instead of 1000) may improve performance.
+
 .. code-block:: bash
 
    mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighbor list, set binsize = neighbor ghost cutoff

doc/src/Tools.rst

@@ -93,6 +93,7 @@ Miscellaneous tools
    * :ref:`i-pi <ipi>`
    * :ref:`kate <kate>`
    * :ref:`LAMMPS shell <lammps_shell>`
+   * :ref:`LAMMPS GUI <lammps_gui>`
    * :ref:`LAMMPS magic patterns for file(1) <magic>`
    * :ref:`Offline build tool <offline>`
    * :ref:`singularity/apptainer <singularity_tool>`
@@ -634,6 +635,195 @@ you first need to use the :doc:`clear` command.
 
 ----------
 
+.. _lammps_gui:
+
+LAMMPS GUI
+----------
+
+.. versionadded:: 2Aug2023
+
+Overview
+^^^^^^^^
+
+LAMMPS GUI is a simple graphical text editor that is linked to the
+:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
+directly using the contents of the editor's text buffer as input.
+
+This is similar to what people traditionally would do to run LAMMPS:
+using a regular text editor to edit the input and run the necessary
+commands, possibly including the text editor, too, from a command line
+terminal window.  This similarity is a design goal. While making it easy
+for beginners to start with LAMMPS, it is also the intention to simplify
+the transition to workflows like most experienced LAMMPS users do.
+
+All features have been extensively exposed to hotkeys, so that there is
+also appeal for experienced LAMMPS users, too, especially for
+prototyping and testing simulations setups.
+
+Features
+^^^^^^^^
+
+A detailed discussion and explanation of all features and functionality
+are in the :doc:`Howto_lammps_gui` tutorial Howto page.
+
+Here are a few highlights of LAMMPS GUI
+
+- Text editor with syntax highlighting customized for LAMMPS
+- Text editor will switch working directory to folder of file in buffer
+- Text editor will remember up to 5 recent files
+- Context specific LAMMPS command help via online documentation
+- LAMMPS is running in a concurrent thread, so the GUI remains responsive
+- Support for accelerator packages
+- Progress bar indicates that LAMMPS is running
+- LAMMPS can be started and stopped with a hotkey
+- Screen output is captured in a Log Window
+- Thermodynamic output is captured and displayed as line graph in a Chart Window
+- Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
+- Many adjustable settings and preferences that are persistent
+- Dialog to set variables from the LAMMPS command line
+
+Parallelization
+^^^^^^^^^^^^^^^
+
+Due to its nature as a graphical application, it is not possible to use
+the LAMMPS GUI in parallel with MPI, but OpenMP multi-threading and GPU
+acceleration is available and enabled by default.
+
+Prerequisites and portability
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS GUI is programmed in C++ based on the C++11 standard and using
+the `Qt GUI framework <https://www.qt.io/product/framework>`_.
+Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
+recommended; Qt 6.x not (yet) supported.  Building LAMMPS with CMake 3.16
+or later is required.  The LAMMPS GUI has been successfully compiled and tested on:
+
+- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
+- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
+- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
+- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
+- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
+
+Pre-compiled executables
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Pre-compiled LAMMPS executables including the GUI are currently
+available from https://download.lammps.org/static or
+https://github.com/lammps/lammps/releases.  You can unpack the archives
+(or mount the macOS disk image) and run the GUI directly in place. The
+folder may also be moved around and added to the ``PATH`` environment
+variable so the executables will be found automatically.  The LAMMPS GUI
+executable is called ``lammps-gui`` and either takes no arguments or
+attempts to load the first argument as LAMMPS input file.
+
+Compilation
+^^^^^^^^^^^
+
+The source for the LAMMPS GUI is included with the LAMMPS source code
+distribution in the folder ``tools/lammps-gui`` and thus it can be can
+be built as part of a regular LAMMPS compilation.  :doc:`Using CMake
+<Howto_cmake>` is required.  To enable its compilation, the CMake
+variable ``-D BUILD_LAMMPS_GUI=on`` must be set when creating the CMake
+configuration.  All other settings (compiler, flags, compile type) for
+LAMMPS GUI are then inherited from the regular LAMMPS build.  If the Qt
+library is packaged for Linux distributions, then its location is
+typically auto-detected since the required CMake configuration files are
+stored in a location where CMake can find them without additional help.
+Otherwise, the location of the Qt library installation must be indicated
+by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
+a folder inside the Qt installation that contains the file
+``Qt5Config.cmake``.
+
+It should be possible to build the LAMMPS GUI as a standalone
+compilation (e.g. when LAMMPS has been compiled with traditional make),
+then the CMake configuration needs to be told where to find the LAMMPS
+headers and the LAMMPS library, via ``-D
+LAMMPS_SOURCE_DIR=/path/to/lammps/src``.  CMake will try to guess a
+build folder with the LAMMPS library from that path, but it can also be
+set with ``-D LAMMPS_LIB_DIR=/path/to/lammps/lib``.
+
+Rather than linking to the LAMMPS library during compilation, it is also
+possible to compile the GUI with a plugin loader library that will load
+the LAMMPS library dynamically at runtime during the start of the GUI
+from a shared library; e.g. ``liblammps.so`` or ``liblammps.dylib`` or
+``liblammps.dll`` (depending on the operating system).  This has the
+advantage that the LAMMPS library can be updated LAMMPS without having
+to recompile the GUI.  The ABI of the LAMMPS C-library interface is very
+stable and generally backward compatible.  This feature is enabled by
+setting ``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
+LAMMPS_PLUGINLIB_DIR=/path/to/lammps/plugin/loader``. Typically, this
+would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
+distribution.
+
+Platform notes
+^^^^^^^^^^^^^^
+
+macOS
+"""""
+
+When building on macOS, the build procedure will try to manufacture a
+drag-n-drop installer, LAMMPS-macOS-multiarch.dmg, when using the 'dmg'
+target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
+
+To build multi-arch executables that will run on both, arm64 and x86_64
+architectures natively, it is necessary to set the CMake variable ``-D
+CMAKE_OSX_ARCHITECTURES=arm64;x86_64``.  To achieve wide compatibility
+with different macOS versions, you can also set ``-D
+CMAKE_OSX_DEPLOYMENT_TARGET=11.0`` which will set compatibility to macOS
+11 (Big Sur) and later, even if you are compiling on a more recent macOS
+version.
+
+Windows
+"""""""
+
+On Windows either native compilation from within Visual Studio 2022 with
+Visual C++ is supported and tested, or compilation with the MinGW / GCC
+cross-compiler environment on Fedora Linux.
+
+**Visual Studio**
+
+Using CMake and Ninja as build system are required.  Qt needs to be
+installed, tested was a binary package downloaded from
+https://www.qt.io, which installs into the ``C:\\Qt`` folder by default.
+There is a custom `x64-GUI-MSVC` build configuration provided in the
+``CMakeSettings.json`` file that Visual Studio uses to store different
+compilation settings for project.  Choosing this configuration will
+activate building the `lammps-gui.exe` executable in addition to LAMMPS
+through importing package selection from the ``windows.cmake`` preset
+file and enabling building the LAMMPS GUI and disabling building with MPI.
+When requesting an installation from the `Build` menu in Visual Studio,
+it will create a compressed ``LAMMPS-Win10-amd64.zip`` zip file with the
+executables and required dependent .dll files.  This zip file can be
+uncompressed and ``lammps-gui.exe`` run directly from there.  The
+uncompressed folder can be added to the ``PATH`` environment and LAMMPS
+and LAMMPS GUI can be launched from anywhere from the command line.
+
+**MinGW64 Cross-compiler**
+
+The standard CMake build procedure can be applied and the
+``mingw-cross.cmake`` preset used. By using ``mingw64-cmake`` the CMake
+command will automatically include a suitable CMake toolset file (the
+regular cmake command can be used after that).  After building the
+libraries and executables, you can build the target 'zip'
+(i.e. ``cmake --build <build dir> --target zip`` or ``make zip``
+to stage all installed files into a LAMMPS_GUI folder and then
+run a script to copy all required dependencies, some other files,
+and create a zip file from it.
+
+Linux
+"""""
+
+Version 5.12 or later of the Qt library is required. Those are provided
+by, e.g., Ubuntu 20.04LTS.  Thus older Linux distributions are not
+likely to be supported, while more recent ones will work, even for
+pre-compiled executables (see above).  After compiling with
+``cmake --build <build folder>``, use ``cmake --build <build
+folder> --target tgz`` or ``make tgz`` to build a
+``LAMMPS-Linux-amd64.tar.gz`` file with the executables and their
+support libraries.
+
+----------
+
 .. _arc:
 
 lmp2arc tool
@@ -883,9 +1073,9 @@ dependencies and redirects the download to the local cache.
 phonon tool
 ------------------------
 
-The phonon subdirectory contains a post-processing tool useful for
-analyzing the output of the :doc:`fix phonon <fix_phonon>` command in
-the PHONON package.
+The phonon subdirectory contains a post-processing tool, *phana*, useful
+for analyzing the output of the :doc:`fix phonon <fix_phonon>` command
+in the PHONON package.
 
 See the README file for instruction on building the tool and what
 library it needs.  And see the examples/PACKAGES/phonon directory

doc/src/angle_dipole.rst

@@ -28,15 +28,15 @@ The *dipole* angle style is used to control the orientation of a dipolar
 atom within a molecule :ref:`(Orsi) <Orsi>`. Specifically, the *dipole* angle
 style restrains the orientation of a point dipole :math:`\mu_j` (embedded in atom
 :math:`j`) with respect to a reference (bond) vector
-:math:`\vec{r_{ij}} = \vec{r_i} - \vec{r_j}`, where :math:`i` is another atom of
+:math:`\vec{r}_{ij} = \vec{r}_i - \vec{r}_j`, where :math:`i` is another atom of
 the same molecule (typically, :math:`i` and :math:`j` are also covalently bonded).
 
-It is convenient to define an angle gamma between the 'free' vector :math:`\vec{\mu_j}`
-and the reference (bond) vector :math:`\vec{r_{ij}}`:
+It is convenient to define an angle gamma between the 'free' vector :math:`\vec{\mu}_j`
+and the reference (bond) vector :math:`\vec{r}_{ij}`:
 
 .. math::
 
-   \cos\gamma = \frac{\vec{\mu_j}\cdot\vec{r_{ij}}}{\mu_j\,r_{ij}}
+   \cos\gamma = \frac{\vec{\mu}_j\cdot\vec{r}_{ij}}{\mu_j\,r_{ij}}
 
 The *dipole* angle style uses the potential:
 
@@ -53,23 +53,23 @@ potential using the 'chain rule' as in appendix C.3 of
 
 .. math::
 
-   \vec{T_j} = \frac{2K(\cos\gamma - \cos\gamma_0)}{\mu_j\,r_{ij}}\, \vec{r_{ij}} \times \vec{\mu_j}
+   \vec{T}_j = \frac{2K(\cos\gamma - \cos\gamma_0)}{\mu_j\,r_{ij}}\, \vec{r}_{ij} \times \vec{\mu}_j
 
 Example: if :math:`\gamma_0` is set to 0 degrees, the torque generated by
 the potential will tend to align the dipole along the reference
-direction defined by the (bond) vector :math:`\vec{r_{ij}}` (in other words, :math:`\vec{\mu_j}` is
+direction defined by the (bond) vector :math:`\vec{r}_{ij}` (in other words, :math:`\vec{\mu}_j` is
 restrained to point towards atom :math:`i`).
 
-The dipolar torque :math:`\vec{T_j}` must be counterbalanced in order to conserve
+The dipolar torque :math:`\vec{T}_j` must be counterbalanced in order to conserve
 the local angular momentum. This is achieved via an additional force
-couple generating a torque equivalent to the opposite of :math:`\vec{T_j}`:
+couple generating a torque equivalent to the opposite of :math:`\vec{T}_j`:
 
 .. math::
 
-   -\vec{T_j} & = \vec{r_{ij}} \times \vec{F_i} \\
-   \vec{F_j}  & = -\vec{F_i}
+   -\vec{T}_j & = \vec{r}_{ij} \times \vec{F}_i \\
+   \vec{F}_j  & = -\vec{F}_i
 
-where :math:`\vec{F_i}` and :math:`\vec{F_j}` are applied on atoms :math:`i`
+where :math:`\vec{F}_i` and :math:`\vec{F}_j` are applied on atoms :math:`i`
 and :math:`j`, respectively.
 
 The following coefficients must be defined for each angle type via the