more changes to ATM source and doc file

.github/CODEOWNERS

@@ -17,6 +17,7 @@ src/GPU/*             @ndtrung81
 src/KOKKOS/*          @stanmoore1
 src/KIM/*             @ellio167
 src/LATTE/*           @cnegre
+src/SPIN/*            @julient31
 src/USER-CGDNA/*      @ohenrich
 src/USER-CGSDK/*      @akohlmey
 src/USER-COLVARS/*    @giacomofiorin
@@ -44,6 +45,7 @@ src/USER-MISC/*_grem.*              @dstelter92
 
 # tools
 tools/msi2lmp/*       @akohlmey
+tools/emacs/*         @HaoZeke
 
 # cmake
 cmake/*               @junghans @rbberger

cmake/CMakeLists.txt

@@ -9,6 +9,7 @@ set(SOVERSION 0)
 get_filename_component(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src ABSOLUTE)
 get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib ABSOLUTE)
 get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
+get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
 
 
 # To avoid conflicts with the conventional Makefile build system, we build everything here
@@ -137,8 +138,11 @@ set_property(CACHE LAMMPS_SIZE_LIMIT PROPERTY STRINGS LAMMPS_SMALLBIG LAMMPS_BIG
 add_definitions(-D${LAMMPS_SIZE_LIMIT})
 set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
 
-set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS")
+# posix_memalign is not available on Windows
-add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
+if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
+  set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS")
+  add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
+endif()
 
 option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" OFF)
 if(LAMMPS_EXCEPTIONS)
@@ -153,14 +157,15 @@ if(ENABLE_TESTING)
   enable_testing()
 endif(ENABLE_TESTING)
 
-set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GRANULAR
+set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
-  KSPACE MANYBODY MC MEAM MISC MOLECULE PERI QEQ REAX REPLICA RIGID SHOCK SPIN SNAP
+  KSPACE MANYBODY MC MEAM MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
   SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
   USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
   USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
   USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SMD
   USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
 set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
+set(OTHER_PACKAGES CORESHELL QEQ)
 foreach(PKG ${DEFAULT_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
@@ -174,13 +179,12 @@ macro(pkg_depends PKG1 PKG2)
   endif()
 endmacro()
 
+# "hard" dependencies between packages resulting
+# in an error instead of skipping over files
 pkg_depends(MPIIO MPI)
-pkg_depends(QEQ MANYBODY)
 pkg_depends(USER-ATC MANYBODY)
 pkg_depends(USER-LB MPI)
-pkg_depends(USER-MISC MANYBODY)
 pkg_depends(USER-PHONON KSPACE)
-pkg_depends(CORESHELL KSPACE)
 
 ######################################################
 # packages with special compiler needs or external libs
@@ -466,6 +470,11 @@ if(PKG_COMPRESS)
   list(APPEND LAMMPS_LINK_LIBS ${ZLIB_LIBRARIES})
 endif()
 
+# the windows version of LAMMPS requires a couple extra libraries
+if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
+  list(APPEND LAMMPS_LINK_LIBS -lwsock32 -lpsapi)
+endif()
+
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
@@ -574,6 +583,41 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
+if(PKG_CORESHELL)
+    set(CORESHELL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/CORESHELL)
+    set(CORESHELL_SOURCES)
+    set_property(GLOBAL PROPERTY "CORESHELL_SOURCES" "${CORESHELL_SOURCES}")
+
+    # detects styles which have a CORESHELL version
+    RegisterStylesExt(${CORESHELL_SOURCES_DIR} cs CORESHELL_SOURCES)
+
+    get_property(CORESHELL_SOURCES GLOBAL PROPERTY CORESHELL_SOURCES)
+
+    list(APPEND LIB_SOURCES ${CORESHELL_SOURCES})
+    include_directories(${CORESHELL_SOURCES_DIR})
+endif()
+
+# Fix qeq/fire requires MANYBODY (i.e. COMB and COMB3) to be installed
+if(PKG_QEQ)
+  set(QEQ_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/QEQ)
+  file(GLOB QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix*.h)
+  file(GLOB QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix*.cpp)
+
+  if(NOT PKG_MANYBODY)
+    list(REMOVE_ITEM QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix_qeq_fire.h)
+    list(REMOVE_ITEM QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix_qeq_fire.cpp)
+  endif()
+  set_property(GLOBAL PROPERTY "QEQ_SOURCES" "${QEQ_SOURCES}")
+
+  foreach(MY_HEADER ${QEQ_HEADERS})
+    AddStyleHeader(${MY_HEADER} FIX)
+  endforeach()
+
+  get_property(QEQ_SOURCES GLOBAL PROPERTY QEQ_SOURCES)
+  list(APPEND LIB_SOURCES ${QEQ_SOURCES})
+  include_directories(${QEQ_SOURCES_DIR})
+endif()
+
 if(PKG_USER-OMP)
     set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
     set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
@@ -585,8 +629,31 @@ if(PKG_USER-OMP)
     # detects styles which have USER-OMP version
     RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
 
+
     get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
 
+    # manually add package dependent source files from USER-OMP that do not provide styles
+
+    if(PKG_ASPHERE)
+      list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_nh_asphere_omp.cpp)
+    endif()
+
+    if(PKG_RIGID)
+      list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
+    endif()
+
+    if(PKG_USER-REAXC)
+      list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_forces_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
+                                   ${USER-OMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
+    endif()
+
     list(APPEND LIB_SOURCES ${USER-OMP_SOURCES})
     include_directories(${USER-OMP_SOURCES_DIR})
 endif()
@@ -900,6 +967,80 @@ if(BUILD_EXE)
   endif()
 endif()
 
+###############################################################################
+# Build documentation
+###############################################################################
+option(BUILD_DOC "Build LAMMPS documentation" OFF)
+if(BUILD_DOC)
+  include(ProcessorCount)
+  ProcessorCount(NPROCS)
+  find_package(PythonInterp 3 REQUIRED)
+
+  set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
+
+  file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
+  file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
+  list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})
+
+  add_custom_command(
+    OUTPUT docenv
+    COMMAND ${VIRTUALENV} docenv
+  )
+
+  set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
+
+  add_custom_command(
+    OUTPUT requirements.txt
+    DEPENDS docenv
+    COMMAND ${CMAKE_COMMAND} -E copy ${LAMMPS_DOC_DIR}/utils/requirements.txt requirements.txt
+    COMMAND ${DOCENV_BINARY_DIR}/pip install -r requirements.txt --upgrade
+    COMMAND ${DOCENV_BINARY_DIR}/pip install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
+  )
+
+  set(RST_FILES "")
+  set(RST_DIR ${CMAKE_BINARY_DIR}/rst)
+  file(MAKE_DIRECTORY ${RST_DIR})
+  foreach(TXT_FILE ${DOC_SOURCES})
+    get_filename_component(FILENAME ${TXT_FILE} NAME_WE)
+    set(RST_FILE ${RST_DIR}/${FILENAME}.rst)
+    list(APPEND RST_FILES ${RST_FILE})
+    add_custom_command(
+      OUTPUT ${RST_FILE}
+      DEPENDS requirements.txt docenv ${TXT_FILE}
+      COMMAND ${DOCENV_BINARY_DIR}/txt2rst -o ${RST_DIR} ${TXT_FILE}
+    )
+  endforeach()
+
+  add_custom_command(
+    OUTPUT html
+    DEPENDS ${RST_FILES}
+    COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src ${RST_DIR}
+    COMMAND ${DOCENV_BINARY_DIR}/sphinx-build -j ${NPROCS} -b html -c ${LAMMPS_DOC_DIR}/utils/sphinx-config -d ${CMAKE_BINARY_DIR}/doctrees ${RST_DIR} html
+  )
+
+  add_custom_target(
+    doc ALL
+    DEPENDS html
+    SOURCES ${LAMMPS_DOC_DIR}/utils/requirements.txt ${DOC_SOURCES}
+  )
+
+  install(DIRECTORY ${CMAKE_BINARY_DIR}/html DESTINATION ${CMAKE_INSTALL_DOCDIR})
+endif()
+
+###############################################################################
+# Install potential files in data directory
+###############################################################################
+set(LAMMPS_POTENTIALS_DIR ${CMAKE_INSTALL_FULL_DATADIR}/lammps/potentials)
+install(DIRECTORY ${LAMMPS_SOURCE_DIR}/../potentials DESTINATION ${CMAKE_INSTALL_DATADIR}/lammps/potentials)
+
+configure_file(etc/profile.d/lammps.sh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh @ONLY)
+configure_file(etc/profile.d/lammps.csh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh @ONLY)
+install(
+  FILES ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh
+        ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh
+  DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/profile.d
+)
+
 ###############################################################################
 # Testing
 #

cmake/README.md

@@ -275,6 +275,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code>BUILD_DOC</code></td>
+  <td>control whether to build LAMMPS documentation</td>
+  <td>
+  <dl>
+    <dt><code>off</code> (default)</dt>
+    <dt><code>on</code></dt>
+  </dl>
+  </td>
+</tr>
 <tr>
   <td><code>LAMMPS_LONGLONG_TO_LONG</code></td>
   <td>Workaround if your system or MPI version does not recognize <code>long long</code> data types</td>

cmake/etc/profile.d/lammps.csh.in

@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@

cmake/etc/profile.d/lammps.sh.in

@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}

doc/Makefile

@@ -157,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
 	@(\
 		mkdir -p $(RSTDIR) ; \
 		. $(VENV)/bin/activate ;\
-		txt2rst $< > $@ ;\
+		txt2rst -v $< > $@ ;\
 		deactivate ;\
 	)
 

doc/src/Commands.txt

@@ -0,0 +1,51 @@
+"Previous Section"_Run.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Packages.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html#comm)
+
+:line
+
+Commands :h2
+
+These pages describe how a LAMMPS input script is formatted and the
+commands in it are used to define a LAMMPS simulation.
+
+<!-- RST
+
+.. toctree::
+
+   Commands_input
+   Commands_parse
+   Commands_structure
+   Commands_category
+
+.. toctree::
+
+   Commands_all
+   Commands_fix
+   Commands_compute
+   Commands_pair
+   Commands_bond
+   Commands_kspace
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"LAMMPS input scripts"_Commands_input.html
+"Parsing rules for input scripts"_Commands_parse.html
+"Input script structure"_Commands_structure.html
+"Commands by category"_Commands_category.html :all(b)
+
+"All commands"_Commands_all.html 
+"Fix commands"_Commands_fix.html 
+"Compute commands"_Commands_compute.html 
+"Pair commands"_Commands_pair.html 
+"Bond, angle, dihedral, improper commands"_Commands_bond.html
+"KSpace solvers"_Commands_kspace.html  :all(b)
+
+<!-- END_HTML_ONLY -->
+

doc/src/Commands_all.txt

@@ -0,0 +1,128 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+All commands :h3
+
+An alphabetic list of all LAMMPS commmands.
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"clear"_clear.html,
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"create_box"_create_box.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"dimension"_dimension.html,
+"displace_atoms"_displace_atoms.html,
+"dump"_dump.html,
+"dump image"_dump_image.html,
+"dump_modify"_dump_modify.html,
+"dump movie"_dump_image.html,
+"dump netcdf"_dump_netcdf.html,
+"dump netcdf/mpiio"_dump_netcdf.html,
+"dump vtk"_dump_vtk.html,
+"echo"_echo.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"group"_group.html,
+"group2ndx"_group2ndx.html,
+"if"_if.html,
+"info"_info.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"include"_include.html,
+"jump"_jump.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"label"_label.html,
+"lattice"_lattice.html,
+"log"_log.html,
+"mass"_mass.html,
+"minimize"_minimize.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"molecule"_molecule.html,
+"ndx2group"_group2ndx.html,
+"neb"_neb.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"newton"_newton.html,
+"next"_next.html,
+"package"_package.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"partition"_partition.html,
+"prd"_prd.html,
+"print"_print.html,
+"processors"_processors.html,
+"python"_python.html,
+"quit"_quit.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"region"_region.html,
+"replicate"_replicate.html,
+"rerun"_rerun.html,
+"reset_ids"_reset_ids.html,
+"reset_timestep"_reset_timestep.html,
+"restart"_restart.html,
+"run"_run.html,
+"run_style"_run_style.html,
+"set"_set.html,
+"shell"_shell.html,
+"special_bonds"_special_bonds.html,
+"suffix"_suffix.html,
+"tad"_tad.html,
+"temper"_temper.html,
+"temper/grem"_temper_grem.html,
+"temper/npt"_temper_npt.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html,
+"uncompute"_uncompute.html,
+"undump"_undump.html,
+"unfix"_unfix.html,
+"units"_units.html,
+"variable"_variable.html,
+"velocity"_velocity.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :tb(c=6,ea=c)

doc/src/Commands_bond.txt

@@ -0,0 +1,124 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Bond, angle, dihedral, and improper commands :h3
+
+:line
+
+Bond_style potentials :h3,link(bond)
+
+All LAMMPS "bond_style"_bond_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_bond_none.html,
+"zero"_bond_zero.html,
+"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
+
+"class2 (ko)"_bond_class2.html,
+"fene (iko)"_bond_fene.html,
+"fene/expand (o)"_bond_fene_expand.html,
+"gromos (o)"_bond_gromos.html,
+"harmonic (ko)"_bond_harmonic.html,
+"harmonic/shift (o)"_bond_harmonic_shift.html,
+"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
+"morse (o)"_bond_morse.html,
+"nonlinear (o)"_bond_nonlinear.html,
+"oxdna/fene"_bond_oxdna.html,
+"oxdna2/fene"_bond_oxdna.html,
+"quartic (o)"_bond_quartic.html,
+"table (o)"_bond_table.html :tb(c=4,ea=c)
+
+:line
+
+Angle_style potentials :h3,link(angle)
+
+All LAMMPS "angle_style"_angle_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_angle_none.html,
+"zero"_angle_zero.html,
+"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
+
+"charmm (ko)"_angle_charmm.html,
+"class2 (ko)"_angle_class2.html,
+"cosine (o)"_angle_cosine.html,
+"cosine/delta (o)"_angle_cosine_delta.html,
+"cosine/periodic (o)"_angle_cosine_periodic.html,
+"cosine/shift (o)"_angle_cosine_shift.html,
+"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
+"cosine/squared (o)"_angle_cosine_squared.html,
+"dipole (o)"_angle_dipole.html,
+"fourier (o)"_angle_fourier.html,
+"fourier/simple (o)"_angle_fourier_simple.html,
+"harmonic (iko)"_angle_harmonic.html,
+"quartic (o)"_angle_quartic.html,
+"sdk"_angle_sdk.html,
+"table (o)"_angle_table.html :tb(c=4,ea=c)
+
+:line
+
+Dihedral_style potentials :h3,link(dihedral)
+
+All LAMMPS "dihedral_style"_dihedral_style.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_dihedral_none.html,
+"zero"_dihedral_zero.html,
+"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
+
+"charmm (iko)"_dihedral_charmm.html,
+"charmmfsw"_dihedral_charmm.html,
+"class2 (ko)"_dihedral_class2.html,
+"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
+"fourier (io)"_dihedral_fourier.html,
+"harmonic (io)"_dihedral_harmonic.html,
+"helix (o)"_dihedral_helix.html,
+"multi/harmonic (o)"_dihedral_multi_harmonic.html,
+"nharmonic (o)"_dihedral_nharmonic.html,
+"opls (iko)"_dihedral_opls.htm;,
+"quadratic (o)"_dihedral_quadratic.html,
+"spherical (o)"_dihedral_spherical.html,
+"table (o)"_dihedral_table.html,
+"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
+
+:line
+
+Improper_style potentials :h3,link(improper)
+
+All LAMMPS "improper_style"_improper_style.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_improper_none.html,
+"zero"_improper_zero.html,
+"hybrid"_improper_hybrid.html  :tb(c=3,ea=c)
+
+"class2 (ko)"_improper_class2.html,
+"cossq (o)"_improper_cossq.html,
+"cvff (io)"_improper_cvff.html,
+"distance"_improper_distance.html,
+"fourier (o)"_improper_fourier.html,
+"harmonic (iko)"_improper_harmonic.html,
+"ring (o)"_improper_ring.html,
+"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

doc/src/Commands_category.txt

@@ -0,0 +1,141 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Commands by category :h3
+
+This page lists most of the LAMMPS commands, grouped by category.  The
+"Commands all"_Commands_all.html doc page lists all commands
+alphabetically.  It also includes long lists of style options for
+entries that appear in the following categories as a single command
+(fix, compute, pair, etc).
+
+Initialization:
+
+"newton"_newton.html,
+"package"_package.html,
+"processors"_processors.html,
+"suffix"_suffix.html,
+"units"_units.html :ul
+
+Setup simulation box:
+
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"create_box"_create_box.html,
+"dimension"_dimension.html,
+"lattice"_lattice.html,
+"region"_region.html :ul
+
+Setup atoms:
+
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"displace_atoms"_displace_atoms.html,
+"group"_group.html,
+"mass"_mass.html,
+"molecule"_molecule.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"replicate"_replicate.html,
+"set"_set.html,
+"velocity"_velocity.html :ul
+
+Force fields:
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"special_bonds"_special_bonds.html :ul
+
+Settings:
+
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"info"_info.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"partition"_partition.html,
+"reset_timestep"_reset_timestep.html,
+"run_style"_run_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html :ul
+
+Operations within timestepping (fixes) and diagnostics (computes):
+
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"uncompute"_uncompute.html,
+"unfix"_unfix.html :ul
+
+Output:
+
+"dump image"_dump_image.html,
+"dump movie"_dump_image.html,
+"dump"_dump.html,
+"dump_modify"_dump_modify.html,
+"restart"_restart.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"undump"_undump.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :ul
+
+Actions:
+
+"minimize"_minimize.html,
+"neb"_neb.html,
+"prd"_prd.html,
+"rerun"_rerun.html,
+"run"_run.html,
+"tad"_tad.html,
+"temper"_temper.html :ul
+
+Input script control:
+
+"clear"_clear.html,
+"echo"_echo.html,
+"if"_if.html,
+"include"_include.html,
+"jump"_jump.html,
+"label"_label.html,
+"log"_log.html,
+"next"_next.html,
+"print"_print.html,
+"python"_python.html,
+"quit"_quit.html,
+"shell"_shell.html,
+"variable"_variable.html :ul
+

doc/src/Commands_compute.txt

@@ -0,0 +1,153 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Compute commands :h3
+
+An alphabetic list of all LAMMPS "compute"_compute.html commands.
+Some styles have accelerated versions.  This is indicated by
+additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
+KOKKOS, o = USER-OMP, t = OPT.
+
+"ackland/atom"_compute_ackland_atom.html,
+"aggregate/atom"_compute_cluster_atom.html,
+"angle"_compute_angle.html,
+"angle/local"_compute_angle_local.html,
+"angmom/chunk"_compute_angmom_chunk.html,
+"basal/atom"_compute_basal_atom.html,
+"body/local"_compute_body_local.html,
+"bond"_compute_bond.html,
+"bond/local"_compute_bond_local.html,
+"centro/atom"_compute_centro_atom.html,
+"chunk/atom"_compute_chunk_atom.html,
+"cluster/atom"_compute_cluster_atom.html,
+"cna/atom"_compute_cna_atom.html,
+"cnp/atom"_compute_cnp_atom.html,
+"com"_compute_com.html,
+"com/chunk"_compute_com_chunk.html,
+"contact/atom"_compute_contact_atom.html,
+"coord/atom"_compute_coord_atom.html,
+"damage/atom"_compute_damage_atom.html,
+"dihedral"_compute_dihedral.html,
+"dihedral/local"_compute_dihedral_local.html,
+"dilatation/atom"_compute_dilatation_atom.html,
+"dipole/chunk"_compute_dipole_chunk.html,
+"displace/atom"_compute_displace_atom.html,
+"dpd"_compute_dpd.html,
+"dpd/atom"_compute_dpd_atom.html,
+"edpd/temp/atom"_compute_edpd_temp_atom.html,
+"entropy/atom"_compute_entropy_atom.html,
+"erotate/asphere"_compute_erotate_asphere.html,
+"erotate/rigid"_compute_erotate_rigid.html,
+"erotate/sphere"_compute_erotate_sphere.html,
+"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
+"event/displace"_compute_event_displace.html,
+"fep"_compute_fep.html,
+"force/tally"_compute_tally.html,
+"fragment/atom"_compute_cluster_atom.html,
+"global/atom"_compute_global_atom.html,
+"group/group"_compute_group_group.html,
+"gyration"_compute_gyration.html,
+"gyration/chunk"_compute_gyration_chunk.html,
+"heat/flux"_compute_heat_flux.html,
+"heat/flux/tally"_compute_tally.html,
+"hexorder/atom"_compute_hexorder_atom.html,
+"improper"_compute_improper.html,
+"improper/local"_compute_improper_local.html,
+"inertia/chunk"_compute_inertia_chunk.html,
+"ke"_compute_ke.html,
+"ke/atom"_compute_ke_atom.html,
+"ke/atom/eff"_compute_ke_atom_eff.html,
+"ke/eff"_compute_ke_eff.html,
+"ke/rigid"_compute_ke_rigid.html,
+"meso/e/atom"_compute_meso_e_atom.html,
+"meso/rho/atom"_compute_meso_rho_atom.html,
+"meso/t/atom"_compute_meso_t_atom.html,
+"msd"_compute_msd.html,
+"msd/chunk"_compute_msd_chunk.html,
+"msd/nongauss"_compute_msd_nongauss.html,
+"omega/chunk"_compute_omega_chunk.html,
+"orientorder/atom"_compute_orientorder_atom.html,
+"pair"_compute_pair.html,
+"pair/local"_compute_pair_local.html,
+"pe"_compute_pe.html,
+"pe/atom"_compute_pe_atom.html,
+"pe/mol/tally"_compute_tally.html,
+"pe/tally"_compute_tally.html,
+"plasticity/atom"_compute_plasticity_atom.html,
+"pressure"_compute_pressure.html,
+"pressure/uef"_compute_pressure_uef.html,
+"property/atom"_compute_property_atom.html,
+"property/chunk"_compute_property_chunk.html,
+"property/local"_compute_property_local.html,
+"rdf"_compute_rdf.html,
+"reduce"_compute_reduce.html,
+"reduce/region"_compute_reduce.html,
+"rigid/local"_compute_rigid_local.html,
+"saed"_compute_saed.html,
+"slice"_compute_slice.html,
+"smd/contact/radius"_compute_smd_contact_radius.html,
+"smd/damage"_compute_smd_damage.html,
+"smd/hourglass/error"_compute_smd_hourglass_error.html,
+"smd/internal/energy"_compute_smd_internal_energy.html,
+"smd/plastic/strain"_compute_smd_plastic_strain.html,
+"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
+"smd/rho"_compute_smd_rho.html,
+"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
+"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
+"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
+"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
+"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
+"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
+"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
+"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
+"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
+"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
+"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
+"smd/vol"_compute_smd_vol.html,
+"sna/atom"_compute_sna_atom.html,
+"snad/atom"_compute_sna_atom.html,
+"snav/atom"_compute_sna_atom.html,
+"spin"_compute_spin.html,
+"stress/atom"_compute_stress_atom.html,
+"stress/tally"_compute_tally.html,
+"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
+"temp (k)"_compute_temp.html,
+"temp/asphere"_compute_temp_asphere.html,
+"temp/body"_compute_temp_body.html,
+"temp/chunk"_compute_temp_chunk.html,
+"temp/com"_compute_temp_com.html,
+"temp/deform"_compute_temp_deform.html,
+"temp/deform/eff"_compute_temp_deform_eff.html,
+"temp/drude"_compute_temp_drude.html,
+"temp/eff"_compute_temp_eff.html,
+"temp/partial"_compute_temp_partial.html,
+"temp/profile"_compute_temp_profile.html,
+"temp/ramp"_compute_temp_ramp.html,
+"temp/region"_compute_temp_region.html,
+"temp/region/eff"_compute_temp_region_eff.html,
+"temp/rotate"_compute_temp_rotate.html,
+"temp/sphere"_compute_temp_sphere.html,
+"temp/uef"_compute_temp_uef.html,
+"ti"_compute_ti.html,
+"torque/chunk"_compute_torque_chunk.html,
+"vacf"_compute_vacf.html,
+"vcm/chunk"_compute_vcm_chunk.html,
+"voronoi/atom"_compute_voronoi_atom.html,
+"xrd"_compute_xrd.html :tb(c=6,ea=c)

doc/src/Commands_fix.txt

@@ -0,0 +1,229 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Fix commands :h3
+
+An alphabetic list of all LAMMPS "fix"_fix.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"adapt"_fix_adapt.html,
+"adapt/fep"_fix_adapt_fep.html,
+"addforce"_fix_addforce.html,
+"addtorque"_fix_addtorque.html,
+"append/atoms"_fix_append_atoms.html,
+"atc"_fix_atc.html,
+"atom/swap"_fix_atom_swap.html,
+"ave/atom"_fix_ave_atom.html,
+"ave/chunk"_fix_ave_chunk.html,
+"ave/correlate"_fix_ave_correlate.html,
+"ave/correlate/long"_fix_ave_correlate_long.html,
+"ave/histo"_fix_ave_histo.html,
+"ave/histo/weight"_fix_ave_histo.html,
+"ave/time"_fix_ave_time.html,
+"aveforce"_fix_aveforce.html,
+"balance"_fix_balance.html,
+"bond/break"_fix_bond_break.html,
+"bond/create"_fix_bond_create.html,
+"bond/react"_fix_bond_react.html,
+"bond/swap"_fix_bond_swap.html,
+"box/relax"_fix_box_relax.html,
+"cmap"_fix_cmap.html,
+"colvars"_fix_colvars.html,
+"controller"_fix_controller.html,
+"deform (k)"_fix_deform.html,
+"deposit"_fix_deposit.html,
+"dpd/energy (k)"_fix_dpd_energy.html,
+"drag"_fix_drag.html,
+"drude"_fix_drude.html,
+"drude/transform/direct"_fix_drude_transform.html,
+"drude/transform/reverse"_fix_drude_transform.html,
+"dt/reset"_fix_dt_reset.html,
+"edpd/source"_fix_dpd_source.html,
+"efield"_fix_efield.html,
+"ehex"_fix_ehex.html,
+"enforce2d (k)"_fix_enforce2d.html,
+"eos/cv"_fix_eos_cv.html,
+"eos/table"_fix_eos_table.html,
+"eos/table/rx (k)"_fix_eos_table_rx.html,
+"evaporate"_fix_evaporate.html,
+"external"_fix_external.html,
+"filter/corotate"_fix_filter_corotate.html,
+"flow/gauss"_fix_flow_gauss.html,
+"freeze"_fix_freeze.html,
+"gcmc"_fix_gcmc.html,
+"gld"_fix_gld.html,
+"gle"_fix_gle.html,
+"gravity (o)"_fix_gravity.html,
+"grem"_fix_grem.html,
+"halt"_fix_halt.html,
+"heat"_fix_heat.html,
+"imd"_fix_imd.html,
+"indent"_fix_indent.html,
+"ipi"_fix_ipi.html,
+"langevin (k)"_fix_langevin.html,
+"langevin/drude"_fix_langevin_drude.html,
+"langevin/eff"_fix_langevin_eff.html,
+"langevin/spin"_fix_langevin_spin.html,
+"latte"_fix_latte.html,
+"lb/fluid"_fix_lb_fluid.html,
+"lb/momentum"_fix_lb_momentum.html,
+"lb/pc"_fix_lb_pc.html,
+"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
+"lb/viscous"_fix_lb_viscous.html,
+"lineforce"_fix_lineforce.html,
+"manifoldforce"_fix_manifoldforce.html,
+"meso"_fix_meso.html,
+"meso/stationary"_fix_meso_stationary.html,
+"momentum (k)"_fix_momentum.html,
+"move"_fix_move.html,
+"mscg"_fix_mscg.html,
+"msst"_fix_msst.html,
+"mvv/dpd"_fix_mvv_dpd.html,
+"mvv/edpd"_fix_mvv_dpd.html,
+"mvv/tdpd"_fix_mvv_dpd.html,
+"neb"_fix_neb.html,
+"nph (ko)"_fix_nh.html,
+"nph/asphere (o)"_fix_nph_asphere.html,
+"nph/body"_fix_nph_body.html,
+"nph/eff"_fix_nh_eff.html,
+"nph/sphere (o)"_fix_nph_sphere.html,
+"nphug (o)"_fix_nphug.html,
+"npt (kio)"_fix_nh.html,
+"npt/asphere (o)"_fix_npt_asphere.html,
+"npt/body"_fix_npt_body.html,
+"npt/eff"_fix_nh_eff.html,
+"npt/sphere (o)"_fix_npt_sphere.html,
+"npt/uef"_fix_nh_uef.html,
+"nve (kio)"_fix_nve.html,
+"nve/asphere (i)"_fix_nve_asphere.html,
+"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
+"nve/body"_fix_nve_body.html,
+"nve/dot"_fix_nve_dot.html,
+"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
+"nve/eff"_fix_nve_eff.html,
+"nve/limit"_fix_nve_limit.html,
+"nve/line"_fix_nve_line.html,
+"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
+"nve/noforce"_fix_nve_noforce.html,
+"nve/sphere (o)"_fix_nve_sphere.html,
+"nve/spin"_fix_nve_spin.html,
+"nve/tri"_fix_nve_tri.html,
+"nvk"_fix_nvk.html,
+"nvt (iko)"_fix_nh.html,
+"nvt/asphere (o)"_fix_nvt_asphere.html,
+"nvt/body"_fix_nvt_body.html,
+"nvt/eff"_fix_nh_eff.html,
+"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
+"nvt/sllod (io)"_fix_nvt_sllod.html,
+"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
+"nvt/sphere (o)"_fix_nvt_sphere.html,
+"nvt/uef"_fix_nh_uef.html,
+"oneway"_fix_oneway.html,
+"orient/bcc"_fix_orient.html,
+"orient/fcc"_fix_orient.html,
+"phonon"_fix_phonon.html,
+"pimd"_fix_pimd.html,
+"planeforce"_fix_planeforce.html,
+"poems"_fix_poems.html,
+"pour"_fix_pour.html,
+"precession/spin"_fix_precession_spin.html,
+"press/berendsen"_fix_press_berendsen.html,
+"print"_fix_print.html,
+"property/atom (k)"_fix_property_atom.html,
+"python/invoke"_fix_python_invoke.html,
+"python/move"_fix_python_move.html,
+"qbmsst"_fix_qbmsst.html,
+"qeq/comb (o)"_fix_qeq_comb.html,
+"qeq/dynamic"_fix_qeq.html,
+"qeq/fire"_fix_qeq.html,
+"qeq/point"_fix_qeq.html,
+"qeq/reax (ko)"_fix_qeq_reax.html,
+"qeq/shielded"_fix_qeq.html,
+"qeq/slater"_fix_qeq.html,
+"qmmm"_fix_qmmm.html,
+"qtb"_fix_qtb.html,
+"rattle"_fix_shake.html,
+"reax/bonds"_fix_reax_bonds.html,
+"reax/c/bonds (k)"_fix_reax_bonds.html,
+"reax/c/species (k)"_fix_reaxc_species.html,
+"recenter"_fix_recenter.html,
+"restrain"_fix_restrain.html,
+"rhok"_fix_rhok.html,
+"rigid (o)"_fix_rigid.html,
+"rigid/nph (o)"_fix_rigid.html,
+"rigid/npt (o)"_fix_rigid.html,
+"rigid/nve (o)"_fix_rigid.html,
+"rigid/nvt (o)"_fix_rigid.html,
+"rigid/small (o)"_fix_rigid.html,
+"rigid/small/nph"_fix_rigid.html,
+"rigid/small/npt"_fix_rigid.html,
+"rigid/small/nve"_fix_rigid.html,
+"rigid/small/nvt"_fix_rigid.html,
+"rx (k)"_fix_rx.html,
+"saed/vtk"_fix_saed_vtk.html,
+"setforce (k)"_fix_setforce.html,
+"shake"_fix_shake.html,
+"shardlow (k)"_fix_shardlow.html,
+"smd"_fix_smd.html,
+"smd/adjust/dt"_fix_smd_adjust_dt.html,
+"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
+"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
+"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
+"smd/setvel"_fix_smd_setvel.html,
+"smd/wall/surface"_fix_smd_wall_surface.html,
+"spring"_fix_spring.html,
+"spring/chunk"_fix_spring_chunk.html,
+"spring/rg"_fix_spring_rg.html,
+"spring/self"_fix_spring_self.html,
+"srd"_fix_srd.html,
+"store/force"_fix_store_force.html,
+"store/state"_fix_store_state.html,
+"tdpd/source"_fix_dpd_source.html,
+"temp/berendsen"_fix_temp_berendsen.html,
+"temp/csld"_fix_temp_csvr.html,
+"temp/csvr"_fix_temp_csvr.html,
+"temp/rescale"_fix_temp_rescale.html,
+"temp/rescale/eff"_fix_temp_rescale_eff.html,
+"tfmc"_fix_tfmc.html,
+"thermal/conductivity"_fix_thermal_conductivity.html,
+"ti/spring"_fix_ti_spring.html,
+"tmd"_fix_tmd.html,
+"ttm"_fix_ttm.html,
+"ttm/mod"_fix_ttm.html,
+"tune/kspace"_fix_tune_kspace.html,
+"vector"_fix_vector.html,
+"viscosity"_fix_viscosity.html,
+"viscous"_fix_viscous.html,
+"wall/body/polygon"_fix_wall_body_polygon.html,
+"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
+"wall/colloid"_fix_wall.html,
+"wall/ees"_fix_wall_ees.html,
+"wall/gran"_fix_wall_gran.html,
+"wall/gran/region"_fix_wall_gran_region.html,
+"wall/harmonic"_fix_wall.html,
+"wall/lj1043"_fix_wall.html,
+"wall/lj126"_fix_wall.html,
+"wall/lj93 (k)"_fix_wall.html,
+"wall/piston"_fix_wall_piston.html,
+"wall/reflect (k)"_fix_wall_reflect.html,
+"wall/region"_fix_wall_region.html,
+"wall/region/ees"_fix_wall_ees.html,
+"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)

doc/src/Commands_input.txt

@@ -0,0 +1,60 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS input scripts :h3
+
+LAMMPS executes by reading commands from a input script (text file),
+one line at a time.  When the input script ends, LAMMPS exits.  Each
+command causes LAMMPS to take some action.  It may set an internal
+variable, read in a file, or run a simulation.  Most commands have
+default settings, which means you only need to use the command if you
+wish to change the default.
+
+In many cases, the ordering of commands in an input script is not
+important.  However the following rules apply:
+
+(1) LAMMPS does not read your entire input script and then perform a
+simulation with all the settings.  Rather, the input script is read
+one line at a time and each command takes effect when it is read.
+Thus this sequence of commands:
+
+timestep 0.5
+run      100
+run      100 :pre
+
+does something different than this sequence:
+
+run      100
+timestep 0.5
+run      100 :pre
+
+In the first case, the specified timestep (0.5 fs) is used for two
+simulations of 100 timesteps each.  In the 2nd case, the default
+timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
+timestep is used for the 2nd one.
+
+(2) Some commands are only valid when they follow other commands.  For
+example you cannot set the temperature of a group of atoms until atoms
+have been defined and a group command is used to define which atoms
+belong to the group.
+
+(3) Sometimes command B will use values that can be set by command A.
+This means command A must precede command B in the input script if it
+is to have the desired effect.  For example, the
+"read_data"_read_data.html command initializes the system by setting
+up the simulation box and assigning atoms to processors.  If default
+values are not desired, the "processors"_processors.html and
+"boundary"_boundary.html commands need to be used before read_data to
+tell LAMMPS how to map processors to the simulation box.
+
+Many input script errors are detected by LAMMPS and an ERROR or
+WARNING message is printed.  The "Errors"_Errors.html doc page gives
+more information on what errors mean.  The documentation for each
+command lists restrictions on how the command can be used.
+

doc/src/Commands_kspace.txt

@@ -0,0 +1,36 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+KSpace solvers :h3
+
+All LAMMPS "kspace_style"_kspace_style.html solvers.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"ewald (o)"_kspace_style.html,
+"ewald/disp"_kspace_style.html,
+"msm (o)"_kspace_style.html,
+"msm/cg (o)"_kspace_style.html,
+"pppm (gok)"_kspace_style.html,
+"pppm/cg (o)"_kspace_style.html,
+"pppm/disp (i)"_kspace_style.html,
+"pppm/disp/tip4p"_kspace_style.html,
+"pppm/stagger"_kspace_style.html,
+"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)

doc/src/Commands_pair.txt

@@ -0,0 +1,231 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Pair_style potentials :h3
+
+All LAMMPS "pair_style"_pair_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_pair_none.html,
+"zero"_pair_zero.html,
+"hybrid"_pair_hybrid.html,
+"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
+
+"adp (o)"_pair_adp.html,
+"agni (o)"_pair_agni.html,
+"airebo (oi)"_pair_airebo.html,
+"airebo/morse (oi)"_pair_airebo.html,
+"awpmd/cut"_pair_awpmd.html,
+"beck (go)"_pair_beck.html,
+"body/nparticle"_pair_body_nparticle.html,
+"body/rounded/polygon"_pair_body_rounded_polygon.html,
+"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html,
+"bop"_pair_bop.html,
+"born (go)"_pair_born.html,
+"born/coul/dsf"_pair_born.html,
+"born/coul/dsf/cs"_pair_born.html,
+"born/coul/long (go)"_pair_born.html,
+"born/coul/long/cs"_pair_born.html,
+"born/coul/msm (o)"_pair_born.html,
+"born/coul/wolf (go)"_pair_born.html,
+"born/coul/wolf/cs"_pair_born.html,
+"brownian (o)"_pair_brownian.html,
+"brownian/poly (o)"_pair_brownian.html,
+"buck (giko)"_pair_buck.html,
+"buck/coul/cut (giko)"_pair_buck.html,
+"buck/coul/long (giko)"_pair_buck.html,
+"buck/coul/long/cs"_pair_buck.html,
+"buck/coul/msm (o)"_pair_buck.html,
+"buck/long/coul/long (o)"_pair_buck_long.html,
+"buck/mdf"_pair_mdf.html,
+"colloid (go)"_pair_colloid.html,
+"comb (o)"_pair_comb.html,
+"comb3"_pair_comb.html,
+"coul/cut (gko)"_pair_coul.html,
+"coul/cut/soft (o)"_pair_lj_soft.html,
+"coul/debye (gko)"_pair_coul.html,
+"coul/diel (o)"_pair_coul_diel.html,
+"coul/dsf (gko)"_pair_coul.html,
+"coul/long (gko)"_pair_coul.html,
+"coul/long/cs"_pair_coul.html,
+"coul/long/soft (o)"_pair_lj_soft.html,
+"coul/msm"_pair_coul.html,
+"coul/shield"_pair_coul_shield.html,
+"coul/streitz"_pair_coul.html,
+"coul/wolf (ko)"_pair_coul.html,
+"coul/wolf/cs"_pair_coul.html,
+"dpd (gio)"_pair_dpd.html,
+"dpd/fdt"_pair_dpd_fdt.html,
+"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
+"dpd/tstat (go)"_pair_dpd.html,
+"dsmc"_pair_dsmc.html,
+"eam (gikot)"_pair_eam.html,
+"eam/alloy (gikot)"_pair_eam.html,
+"eam/cd (o)"_pair_eam.html,
+"eam/fs (gikot)"_pair_eam.html,
+"edip (o)"_pair_edip.html,
+"edip/multi"_pair_edip.html,
+"edpd"_pair_meso.html,
+"eff/cut"_pair_eff.html,
+"eim (o)"_pair_eim.html,
+"exp6/rx (k)"_pair_exp6_rx.html,
+"extep"_pair_extep.html,
+"gauss (go)"_pair_gauss.html,
+"gauss/cut"_pair_gauss.html,
+"gayberne (gio)"_pair_gayberne.html,
+"gran/hertz/history (o)"_pair_gran.html,
+"gran/hooke (o)"_pair_gran.html,
+"gran/hooke/history (o)"_pair_gran.html,
+"gw"_pair_gw.html,
+"gw/zbl"_pair_gw.html,
+"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
+"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
+"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
+"kim"_pair_kim.html,
+"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
+"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
+"lcbop"_pair_lcbop.html,
+"lennard/mdf"_pair_mdf.html,
+"line/lj"_pair_line_lj.html,
+"list"_pair_list.html,
+"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
+"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
+"lj/charmm/coul/long (giko)"_pair_charmm.html,
+"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
+"lj/charmm/coul/msm"_pair_charmm.html,
+"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
+"lj/charmmfsw/coul/long"_pair_charmm.html,
+"lj/class2 (gko)"_pair_class2.html,
+"lj/class2/coul/cut (ko)"_pair_class2.html,
+"lj/class2/coul/long (gko)"_pair_class2.html,
+"lj/cubic (go)"_pair_lj_cubic.html,
+"lj/cut (gikot)"_pair_lj.html,
+"lj/cut/coul/cut (gko)"_pair_lj.html,
+"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
+"lj/cut/coul/debye (gko)"_pair_lj.html,
+"lj/cut/coul/dsf (gko)"_pair_lj.html,
+"lj/cut/coul/long (gikot)"_pair_lj.html,
+"lj/cut/coul/long/cs"_pair_lj.html,
+"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
+"lj/cut/coul/msm (go)"_pair_lj.html,
+"lj/cut/coul/wolf (o)"_pair_lj.html,
+"lj/cut/dipole/cut (go)"_pair_dipole.html,
+"lj/cut/dipole/long"_pair_dipole.html,
+"lj/cut/dipole/sf (go)"_pair_dipole.html,
+"lj/cut/soft (o)"_pair_lj_soft.html,
+"lj/cut/thole/long (o)"_pair_thole.html,
+"lj/cut/tip4p/cut (o)"_pair_lj.html,
+"lj/cut/tip4p/long (ot)"_pair_lj.html,
+"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
+"lj/expand (gko)"_pair_lj_expand.html,
+"lj/gromacs (gko)"_pair_gromacs.html,
+"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
+"lj/long/coul/long (io)"_pair_lj_long.html,
+"lj/long/dipole/long"_pair_dipole.html,
+"lj/long/tip4p/long"_pair_lj_long.html,
+"lj/mdf"_pair_mdf.html,
+"lj/sdk (gko)"_pair_sdk.html,
+"lj/sdk/coul/long (go)"_pair_sdk.html,
+"lj/sdk/coul/msm (o)"_pair_sdk.html,
+"lj/smooth (o)"_pair_lj_smooth.html,
+"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
+"lj96/cut (go)"_pair_lj96.html,
+"lubricate (o)"_pair_lubricate.html,
+"lubricate/poly (o)"_pair_lubricate.html,
+"lubricateU"_pair_lubricateU.html,
+"lubricateU/poly"_pair_lubricateU.html,
+"mdpd"_pair_meso.html,
+"mdpd/rhosum"_pair_meso.html,
+"meam"_pair_meam.html,
+"meam/c"_pair_meam.html,
+"meam/spline (o)"_pair_meam_spline.html,
+"meam/sw/spline"_pair_meam_sw_spline.html,
+"mgpt"_pair_mgpt.html,
+"mie/cut (o)"_pair_mie.html,
+"momb"_pair_momb.html,
+"morse (gkot)"_pair_morse.html,
+"morse/smooth/linear"_pair_morse.html,
+"morse/soft"_pair_morse.html,
+"multi/lucy"_pair_multi_lucy.html,
+"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
+"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
+"nm/cut (o)"_pair_nm.html,
+"nm/cut/coul/cut (o)"_pair_nm.html,
+"nm/cut/coul/long (o)"_pair_nm.html,
+"oxdna/coaxstk"_pair_oxdna.html,
+"oxdna/excv"_pair_oxdna.html,
+"oxdna/hbond"_pair_oxdna.html,
+"oxdna/stk"_pair_oxdna.html,
+"oxdna/xstk"_pair_oxdna.html,
+"oxdna2/coaxstk"_pair_oxdna2.html,
+"oxdna2/dh"_pair_oxdna2.html,
+"oxdna2/excv"_pair_oxdna2.html,
+"oxdna2/stk"_pair_oxdna2.html,
+"peri/eps"_pair_peri.html,
+"peri/lps (o)"_pair_peri.html,
+"peri/pmb (o)"_pair_peri.html,
+"peri/ves"_pair_peri.html,
+"polymorphic"_pair_polymorphic.html,
+"python"_pair_python.html,
+"quip"_pair_quip.html,
+"reax"_pair_reax.html,
+"reax/c (ko)"_pair_reaxc.html,
+"rebo (oi)"_pair_airebo.html,
+"resquared (go)"_pair_resquared.html,
+"smd/hertz"_pair_smd_hertz.html,
+"smd/tlsph"_pair_smd_tlsph.html,
+"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
+"smd/ulsph"_pair_smd_ulsph.html,
+"smtbq"_pair_smtbq.html,
+"snap (k)"_pair_snap.html,
+"snap (k)"_pair_snap.html,
+"soft (go)"_pair_soft.html,
+"sph/heatconduction"_pair_sph_heatconduction.html,
+"sph/idealgas"_pair_sph_idealgas.html,
+"sph/lj"_pair_sph_lj.html,
+"sph/rhosum"_pair_sph_rhosum.html,
+"sph/taitwater"_pair_sph_taitwater.html,
+"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
+"spin/dmi"_pair_spin_dmi.html,
+"spin/exchange"_pair_spin_exchange.html,
+"spin/magelec"_pair_spin_magelec.html,
+"spin/neel"_pair_spin_neel.html,
+"srp"_pair_srp.html,
+"sw (giko)"_pair_sw.html,
+"table (gko)"_pair_table.html,
+"table/rx (k)"_pair_table_rx.html,
+"tdpd"_pair_meso.html,
+"tersoff (giko)"_pair_tersoff.html,
+"tersoff/mod (gko)"_pair_tersoff_mod.html,
+"tersoff/mod/c (o)"_pair_tersoff_mod.html,
+"tersoff/table (o)"_pair_tersoff.html,
+"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
+"thole"_pair_thole.html,
+"tip4p/cut (o)"_pair_coul.html,
+"tip4p/long (o)"_pair_coul.html,
+"tip4p/long/soft (o)"_pair_lj_soft.html,
+"tri/lj"_pair_tri_lj.html,
+"ufm (got)"_pair_ufm.html,
+"vashishta (ko)"_pair_vashishta.html,
+"vashishta/table (o)"_pair_vashishta.html,
+"yukawa (gok)"_pair_yukawa.html,
+"yukawa/colloid (go)"_pair_yukawa_colloid.html,
+"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)

doc/src/Commands_parse.txt

@@ -0,0 +1,136 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Parsing rules for input scripts :h3
+
+Each non-blank line in the input script is treated as a command.
+LAMMPS commands are case sensitive.  Command names are lower-case, as
+are specified command arguments.  Upper case letters may be used in
+file names or user-chosen ID strings.
+
+Here are 6 rulse for how each line in the input script is parsed by
+LAMMPS:
+
+(1) If the last printable character on the line is a "&" character,
+the command is assumed to continue on the next line.  The next line is
+concatenated to the previous line by removing the "&" character and
+line break.  This allows long commands to be continued across two or
+more lines.  See the discussion of triple quotes in (6) for how to
+continue a command across multiple line without using "&" characters.
+
+(2) All characters from the first "#" character onward are treated as
+comment and discarded.  See an exception in (6).  Note that a
+comment after a trailing "&" character will prevent the command from
+continuing on the next line.  Also note that for multi-line commands a
+single leading "#" will comment out the entire command.
+
+(3) The line is searched repeatedly for $ characters, which indicate
+variables that are replaced with a text string.  See an exception in
+(6).
+
+If the $ is followed by curly brackets, then the variable name is the
+text inside the curly brackets.  If no curly brackets follow the $,
+then the variable name is the single character immediately following
+the $.  Thus $\{myTemp\} and $x refer to variable names "myTemp" and
+"x".
+
+How the variable is converted to a text string depends on what style
+of variable it is; see the "variable"_variable.html doc page for details.
+It can be a variable that stores multiple text strings, and return one
+of them.  The returned text string can be multiple "words" (space
+separated) which will then be interpreted as multiple arguments in the
+input command.  The variable can also store a numeric formula which
+will be evaluated and its numeric result returned as a string.
+
+As a special case, if the $ is followed by parenthesis, then the text
+inside the parenthesis is treated as an "immediate" variable and
+evaluated as an "equal-style variable"_variable.html.  This is a way
+to use numeric formulas in an input script without having to assign
+them to variable names.  For example, these 3 input script lines:
+
+variable X equal (xlo+xhi)/2+sqrt(v_area)
+region 1 block $X 2 INF INF EDGE EDGE
+variable X delete :pre
+
+can be replaced by
+
+region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
+
+so that you do not have to define (or discard) a temporary variable X.
+
+Additionally, the "immediate" variable expression may be followed by a
+colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
+The format string must be appropriate for a double-precision
+floating-point value.  The format string is used to output the result
+of the variable expression evaluation.  If a format string is not
+specified a high-precision "%.20g" is used as the default.
+
+This can be useful for formatting print output to a desired precion:
+
+print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
+
+Note that neither the curly-bracket or immediate form of variables can
+contain nested $ characters for other variables to substitute for.
+Thus you cannot do this:
+
+variable        a equal 2
+variable        b2 equal 4
+print           "B2 = $\{b$a\}" :pre
+
+Nor can you specify this $($x-1.0) for an immediate variable, but
+you could use $(v_x-1.0), since the latter is valid syntax for an
+"equal-style variable"_variable.html.
+
+See the "variable"_variable.html command for more details of how
+strings are assigned to variables and evaluated, and how they can be
+used in input script commands.
+
+(4) The line is broken into "words" separated by whitespace (tabs,
+spaces).  Note that words can thus contain letters, digits,
+underscores, or punctuation characters.
+
+(5) The first word is the command name.  All successive words in the
+line are arguments.
+
+(6) If you want text with spaces to be treated as a single argument,
+it can be enclosed in either single or double or triple quotes.  A
+long single argument enclosed in single or double quotes can span
+multiple lines if the "&" character is used, as described above.  When
+the lines are concatenated together (and the "&" characters and line
+breaks removed), the text will become a single line.  If you want
+multiple lines of an argument to retain their line breaks, the text
+can be enclosed in triple quotes, in which case "&" characters are not
+needed.  For example:
+
+print "Volume = $v"
+print 'Volume = $v'
+if "$\{steps\} > 1000" then quit
+variable a string "red green blue &
+                   purple orange cyan"
+print """
+System volume = $v
+System temperature = $t
+""" :pre
+
+In each case, the single, double, or triple quotes are removed when
+the single argument they enclose is stored internally.
+
+See the "dump modify format"_dump_modify.html, "print"_print.html,
+"if"_if.html, and "python"_python.html commands for examples.
+
+A "#" or "$" character that is between quotes will not be treated as a
+comment indicator in (2) or substituted for as a variable in (3).
+
+NOTE: If the argument is itself a command that requires a quoted
+argument (e.g. using a "print"_print.html command as part of an
+"if"_if.html or "run every"_run.html command), then single, double, or
+triple quotes can be nested in the usual manner.  See the doc pages
+for those commands for examples.  Only one of level of nesting is
+allowed, but that should be sufficient for most use cases.
+

doc/src/Commands_structure.txt

@@ -0,0 +1,95 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Input script structure :h3
+
+This page describes the structure of a typical LAMMPS input script.
+The examples directory in the LAMMPS distribution contains many sample
+input scripts; it is discussed on the "Examples"_Examples.html doc
+page.
+
+A LAMMPS input script typically has 4 parts:
+
+Initialization
+Atom definition
+Settings
+Run a simulation :ol
+
+The last 2 parts can be repeated as many times as desired.  I.e. run a
+simulation, change some settings, run some more, etc.  Each of the 4
+parts is now described in more detail.  Remember that almost all
+commands need only be used if a non-default value is desired.
+
+(1) Initialization
+
+Set parameters that need to be defined before atoms are created or
+read-in from a file.
+
+The relevant commands are "units"_units.html,
+"dimension"_dimension.html, "newton"_newton.html,
+"processors"_processors.html, "boundary"_boundary.html,
+"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
+
+If force-field parameters appear in the files that will be read, these
+commands tell LAMMPS what kinds of force fields are being used:
+"pair_style"_pair_style.html, "bond_style"_bond_style.html,
+"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
+"improper_style"_improper_style.html.
+
+(2) Atom definition
+
+There are 3 ways to define atoms in LAMMPS.  Read them in from a data
+or restart file via the "read_data"_read_data.html or
+"read_restart"_read_restart.html commands.  These files can contain
+molecular topology information.  Or create atoms on a lattice (with no
+molecular topology), using these commands: "lattice"_lattice.html,
+"region"_region.html, "create_box"_create_box.html,
+"create_atoms"_create_atoms.html.  The entire set of atoms can be
+duplicated to make a larger simulation using the
+"replicate"_replicate.html command.
+
+(3) Settings
+
+Once atoms and molecular topology are defined, a variety of settings
+can be specified: force field coefficients, simulation parameters,
+output options, etc.
+
+Force field coefficients are set by these commands (they can also be
+set in the read-in files): "pair_coeff"_pair_coeff.html,
+"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"improper_coeff"_improper_coeff.html,
+"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
+"special_bonds"_special_bonds.html.
+
+Various simulation parameters are set by these commands:
+"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
+"group"_group.html, "timestep"_timestep.html,
+"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
+"min_style"_min_style.html, "min_modify"_min_modify.html.
+
+Fixes impose a variety of boundary conditions, time integration, and
+diagnostic options.  The "fix"_fix.html command comes in many flavors.
+
+Various computations can be specified for execution during a
+simulation using the "compute"_compute.html,
+"compute_modify"_compute_modify.html, and "variable"_variable.html
+commands.
+
+Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
+and "restart"_restart.html commands.
+
+(4) Run a simulation
+
+A molecular dynamics simulation is run using the "run"_run.html
+command.  Energy minimization (molecular statics) is performed using
+the "minimize"_minimize.html command.  A parallel tempering
+(replica-exchange) simulation can be run using the
+"temper"_temper.html command.
+

doc/src/Eqs/pair_spin_dmi_forces.tex

@@ -0,0 +1,14 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times \left(\vec{e}_{ij}\times \vec{D} \right) 
+    ~~{\rm and}~~
+    \vec{F}_i = -\sum_{j}^{Neighb} \frac{1}{r_{ij}} \vec{D} \times \left( \vec{s}_{i}\times \vec{s}_{j} \right) 
+    , \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_dmi_interaction.tex

@@ -5,7 +5,7 @@
 \begin{document}
 \begin{varwidth}{50in}
   \begin{equation}
-    \bm{H}_{dm} = -\sum_{{ i,j}=1,i\neq j}^{N} 
+    \bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N} 
     \left( \vec{e}_{ij} \times \vec{D} \right)
     \cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right), 
     \nonumber

doc/src/Eqs/pair_spin_exchange_forces.tex

@@ -5,10 +5,12 @@
 \begin{document}
 \begin{varwidth}{50in}
   \begin{equation}
-    \vec{F}^{i} = \sum_{j}^{Neighbor} \frac{\partial {J} \left(r_{ij} \right)}{
+    \vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J} 
-    \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{r}_{ij}  
+    \left(r_{ij} \right)\,\vec{s}_{j} 
-    ~~{\rm and}~~ \vec{\omega}^{i} = \frac{1}{\hbar} \sum_{j}^{Neighbor} {J} 
+    ~~{\rm and}~~ 
-    \left(r_{ij} \right)\,\vec{s}_{j} \nonumber
+    \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
+    \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}  
+    \nonumber
   \end{equation}
 \end{varwidth}
 \end{document}

doc/src/Eqs/pair_spin_exchange_interaction.tex

@@ -5,7 +5,7 @@
 \begin{document}
 \begin{varwidth}{50in}
   \begin{equation}
-    \bm{H}_{exchange} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
+    \bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
   \end{equation}
 \end{varwidth}
 \end{document}

doc/src/Errors.txt

@@ -1,10 +1,10 @@
 "Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
 "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_history.html :c
+Section"_Manual.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Errors_bugs.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Errors_common.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Errors_messages.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -21,9 +21,9 @@ means that line #78 in the file src/velocity.cpp generated the error.
 Looking in the source code may help you figure out what went wrong.
 
 Note that error messages from "user-contributed
-packages"_Section_package.html#table_user are not listed here.  If
+packages"_Packages_user.html are not listed here.  If such an error
-such an error occurs and is not self-explanatory, you'll need to look
+occurs and is not self-explanatory, you'll need to look in the source
-in the source code or contact the author of the package.
+code or contact the author of the package.
 
 Doc page with "WARNING messages"_Errors_warnings.html
 

doc/src/Errors_warnings.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -21,9 +21,9 @@ means that line #187 in the file src/domain.cpp generated the error.
 Looking in the source code may help you figure out what went wrong.
 
 Note that warning messages from "user-contributed
-packages"_Section_start.html#table_user are not listed here.  If such
+packages"_Packages_user.html are not listed here.  If such a warning
-a warning occurs and is not self-explanatory, you'll need to look in
+occurs and is not self-explanatory, you'll need to look in the source
-the source code or contact the author of the package.
+code or contact the author of the package.
 
 Doc page with "ERROR messages"_Errors_messages.html
 

doc/src/Examples.txt

@@ -1,10 +1,10 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws -
+"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_perf.html :c
+Section"_Tools.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -143,5 +143,5 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the "Section 4"_Section_packages.html doc
+instructions.  See the "Packages_details"_Packages_details.html doc
 page for more info on specific USER packages.

doc/src/Howto.txt

@@ -0,0 +1,128 @@
+"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Examples.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+How to discussions :h2
+
+These doc pages describe how to perform various tasks with LAMMPS,
+both for users and developers.  The
+"glossary"_http://lammps.sandia.gov website page also lists MD
+terminology with links to corresponding LAMMPS manual pages.
+
+The example input scripts included in the examples dir of the LAMMPS
+distribution and highlighted on the "Examples"_Examples.html doc page
+also show how to setup and run various kinds of simulations.
+
+<!-- RST
+
+.. toctree::
+
+   Howto_github
+   Howto_pylammps
+   Howto_bash
+
+.. toctree::
+
+   Howto_restart
+   Howto_viz
+   Howto_multiple
+   Howto_replica
+   Howto_library
+   Howto_couple
+
+.. toctree::
+
+   Howto_output
+   Howto_chunk
+
+.. toctree::
+
+   Howto_2d
+   Howto_triclinic
+   Howto_walls
+   Howto_nemd
+   Howto_granular
+   Howto_spherical
+   Howto_dispersion
+
+.. toctree::
+
+   Howto_temperature
+   Howto_thermostat
+   Howto_barostat
+   Howto_elastic
+   Howto_kappa
+   Howto_viscosity
+   Howto_diffusion
+
+.. toctree::
+
+   Howto_bioFF
+   Howto_tip3p
+   Howto_tip4p
+   Howto_spc
+
+.. toctree::
+
+   Howto_body
+   Howto_polarizable
+   Howto_coreshell
+   Howto_drude
+   Howto_drude2
+   Howto_manifold
+   Howto_spins
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Using GitHub with LAMMPS"_Howto_github.html
+"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
+"Using LAMMPS with bash on Windows"_Howto_bash.html
+
+"Restart a simulation"_Howto_restart.html
+"Visualize LAMMPS snapshots"_Howto_viz.html
+"Run multiple simulations from one input script"_Howto_multiple.html
+"Multi-replica simulations"_Howto_replica.html
+"Library interface to LAMMPS"_Howto_library.html
+"Couple LAMMPS to other codes"_Howto_couple.html :all(b)
+
+"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
+"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
+
+"2d simulations"_Howto_2d.html
+"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
+"Walls"_Howto_walls.html
+"NEMD simulations"_Howto_nemd.html
+"Granular models"_Howto_granular.html
+"Finite-size spherical and aspherical particles"_Howto_spherical.html
+"Long-range dispersion settings"_Howto_dispersion.html :all(b)
+
+"Calculate temperature"_Howto_temperature.html
+"Thermostats"_Howto_thermostat.html
+"Barostats"_Howto_barostat.html
+"Calculate elastic constants"_Howto_elastic.html
+"Calculate thermal conductivity"_Howto_kappa.html
+"Calculate viscosity"_Howto_viscosity.html
+"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
+
+"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
+"TIP3P water model"_Howto_tip3p.html
+"TIP4P water model"_Howto_tip4p.html
+"SPC water model"_Howto_spc.html :all(b)
+
+"Body style particles"_Howto_body.html
+"Polarizable models"_Howto_polarizable.html
+"Adiabatic core/shell model"_Howto_coreshell.html
+"Drude induced dipoles"_Howto_drude.html
+"Drude induced dipoles (extended)"_Howto_drude2.html :all(b)
+"Manifolds (surfaces)"_Howto_manifold.html
+"Magnetic spins"_Howto_spins.html
+
+<!-- END_HTML_ONLY -->

doc/src/Howto_2d.txt

@@ -0,0 +1,48 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+2d simulations :h3
+
+Use the "dimension"_dimension.html command to specify a 2d simulation.
+
+Make the simulation box periodic in z via the "boundary"_boundary.html
+command.  This is the default.
+
+If using the "create box"_create_box.html command to define a
+simulation box, set the z dimensions narrow, but finite, so that the
+create_atoms command will tile the 3d simulation box with a single z
+plane of atoms - e.g.
+
+"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
+
+If using the "read data"_read_data.html 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
+z-boundaries of the box - e.g. 0.0.
+
+Use the "fix enforce2d"_fix_enforce2d.html command as the last
+defined fix to insure that the z-components of velocities and forces
+are zeroed out every timestep.  The reason to make it the last fix is
+so that any forces induced by other fixes will be zeroed out.
+
+Many of the example input scripts included in the LAMMPS distribution
+are for 2d models.
+
+NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
+opposed to point particles.  See the "atom_style
+sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
+commands for details.  By default, for 2d simulations, such particles
+will still be modeled as 3d spheres, not 2d discs (circles), meaning
+their moment of inertia will be that of a sphere.  If you wish to
+model them as 2d discs, see the "set density/disc"_set.html command
+and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
+"fix nvt/sphere"_fix_nvt_sphere.html, "fix
+nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
+commands.

doc/src/Howto_barostat.txt

@@ -0,0 +1,75 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Barostats :h3
+
+Barostatting means controlling the pressure in an MD simulation.
+"Thermostatting"_Howto_thermostat.html means controlling the
+temperature of the particles.  Since the pressure includes a kinetic
+component due to particle velocities, both these operations require
+calculation of the temperature.  Typically a target temperature (T)
+and/or pressure (P) is specified by the user, and the thermostat or
+barostat attempts to equilibrate the system to the requested T and/or
+P.
+
+Barostatting in LAMMPS is performed by "fixes"_fix.html.  Two
+barosttating methods are currently available: Nose-Hoover (npt and
+nph) and Berendsen:
+
+"fix npt"_fix_nh.html
+"fix npt/sphere"_fix_npt_sphere.html
+"fix npt/asphere"_fix_npt_asphere.html
+"fix nph"_fix_nh.html
+"fix press/berendsen"_fix_press_berendsen.html :ul
+
+The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
+and barostat.  "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
+it does no thermostatting.  Both "fix nph"_fix_nh.html and "fix
+press/berendsen"_fix_press_berendsen.html can be used in conjunction
+with any of the thermostatting fixes.
+
+As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
+and "fix nph"_fix_nh.html only use translational motion of the
+particles in computing T and P and performing thermo/barostatting.
+"Fix npt/sphere"_fix_npt_sphere.html and "fix
+npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
+translation velocities but also rotational velocities for spherical
+and aspherical particles.
+
+All of the barostatting fixes use the "compute
+pressure"_compute_pressure.html compute to calculate a current
+pressure.  By default, this compute is created with a simple "compute
+temp"_compute_temp.html (see the last argument of the "compute
+pressure"_compute_pressure.html command), which is used to calculated
+the kinetic component of the pressure.  The barostatting fixes can
+also use temperature computes that remove bias for the purpose of
+computing the kinetic component which contributes to the current
+pressure.  See the doc pages for the individual fixes and for the
+"fix_modify"_fix_modify.html command for instructions on how to assign
+a temperature or pressure compute to a barostatting fix.
+
+NOTE: As with the thermostats, the Nose/Hoover methods ("fix
+npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
+"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
+be used with one of the constant NVE fixes or with one of the NVT
+fixes.
+
+Thermodynamic output, which can be setup via the
+"thermo_style"_thermo_style.html command, often includes pressure
+values.  As explained on the doc page for the
+"thermo_style"_thermo_style.html command, the default pressure is
+setup by the thermo command itself.  It is NOT the presure associated
+with any barostatting fix you have defined or with any compute you
+have defined that calculates a presure.  The doc pages for the
+barostatting fixes explain the ID of the pressure compute they create.
+Thus if you want to view these pressurse, you need to specify them
+explicitly via the "thermo_style custom"_thermo_style.html command.
+Or you can use the "thermo_modify"_thermo_modify.html command to
+re-define what pressure compute is used for default thermodynamic
+output.

doc/src/Howto_bash.txt

@@ -2,7 +2,7 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
 [written by Richard Berger]
 
 :line
+
 Starting with Windows 10 you can install Linux tools directly in Windows. This
 allows you to compile LAMMPS following the same procedure as on a real Ubuntu
 Linux installation. Software can be easily installed using the package manager

doc/src/Howto_bioFF.txt

@@ -0,0 +1,101 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+CHARMM, AMBER, and DREIDING force fields :h3
+
+A force field has 2 parts: the formulas that define it and the
+coefficients used for a particular system.  Here we only discuss
+formulas implemented in LAMMPS that correspond to formulas commonly
+used in the CHARMM, AMBER, and DREIDING force fields.  Setting
+coefficients is done in the input data file via the
+"read_data"_read_data.html command or in the input script with
+commands like "pair_coeff"_pair_coeff.html or
+"bond_coeff"_bond_coeff.html.  See the "Tools"_Tools.html doc page for
+additional tools that can use CHARMM or AMBER to assign force field
+coefficients and convert their output into LAMMPS input.
+
+See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
+field.  See "(Cornell)"_#howto-Cornell for a description of the AMBER force
+field.
+
+:link(charmm,http://www.scripps.edu/brooks)
+:link(amber,http://amber.scripps.edu)
+
+These style choices compute force field formulas that are consistent
+with common options in CHARMM or AMBER.  See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"angle_style"_angle_charmm.html charmm
+"dihedral_style"_dihedral_charmm.html charmmfsh
+"dihedral_style"_dihedral_charmm.html charmm
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
+"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
+
+"special_bonds"_special_bonds.html charmm
+"special_bonds"_special_bonds.html amber :ul
+
+NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
+released in March 2017.  We recommend they be used instead of the
+older {charmm} styles.  See discussion of the differences on the "pair
+charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
+doc pages.
+
+DREIDING is a generic force field developed by the "Goddard
+group"_http://www.wag.caltech.edu at Caltech and is useful for
+predicting structures and dynamics of organic, biological and
+main-group inorganic molecules. The philosophy in DREIDING is to use
+general force constants and geometry parameters based on simple
+hybridization considerations, rather than individual force constants
+and geometric parameters that depend on the particular combinations of
+atoms involved in the bond, angle, or torsion terms. DREIDING has an
+"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
+interactions involving a hydrogen atom on very electronegative atoms
+(N, O, F).
+
+See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
+
+These style choices compute force field formulas that are consistent
+with the DREIDING force field.  See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"bond_style"_bond_morse.html morse :ul
+
+"angle_style"_angle_harmonic.html harmonic
+"angle_style"_angle_cosine.html cosine
+"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
+
+"dihedral_style"_dihedral_charmm.html charmm
+"improper_style"_improper_umbrella.html umbrella :ul
+
+"pair_style"_pair_buck.html buck
+"pair_style"_pair_buck.html buck/coul/cut
+"pair_style"_pair_buck.html buck/coul/long
+"pair_style"_pair_lj.html lj/cut
+"pair_style"_pair_lj.html lj/cut/coul/cut
+"pair_style"_pair_lj.html lj/cut/coul/long :ul
+
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
+
+"special_bonds"_special_bonds.html dreiding :ul
+
+:line
+
+:link(howto-MacKerell)
+[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
+Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
+
+:link(howto-Mayo)
+[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
+(1990).

doc/src/Howto_body.txt

@@ -1,24 +1,24 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
-Body particles :h2
+Body particles :h3
 
 [Overview:]
 
-This doc page is not about a LAMMPS input script command, but about
+In LAMMPS, body particles are generalized finite-size particles.
-body particles, which are generalized finite-size particles.
 Individual body particles can represent complex entities, such as
 surface meshes of discrete points, collections of sub-particles,
 deformable objects, etc.  Note that other kinds of finite-size
 spherical and aspherical particles are also supported by LAMMPS, such
 as spheres, ellipsoids, line segments, and triangles, but they are
-simpler entities that body particles.  See "Section
+simpler entities that body particles.  See the "Howto
-6.14"_Section_howto.html#howto_14 for a general overview of all
+spherical"_Howto_spherical.html doc page for a general overview of all
 these particle types.
 
 Body particles are used via the "atom_style body"_atom_style.html
@@ -151,8 +151,8 @@ center-of-mass position of the particle is specified by the x,y,z
 values in the {Atoms} section of the data file, as is the total mass
 of the body particle.
 
-The "pair_style body"_pair_body.html command can be used with this
+The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
-body style to compute body/body and body/non-body interactions.
+with this body style to compute body/body and body/non-body interactions.
 
 For output purposes via the "compute
 body/local"_compute_body_local.html and "dump local"_dump.html

doc/src/Howto_chunk.txt

@@ -0,0 +1,166 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Use chunks to calculate system properties :h3
+
+In LAMMS, "chunks" are collections of atoms, as defined by the
+"compute chunk/atom"_compute_chunk_atom.html command, which assigns
+each atom to a chunk ID (or to no chunk at all).  The number of chunks
+and the assignment of chunk IDs to atoms can be static or change over
+time.  Examples of "chunks" are molecules or spatial bins or atoms
+with similar values (e.g. coordination number or potential energy).
+
+The per-atom chunk IDs can be used as input to two other kinds of
+commands, to calculate various properties of a system:
+
+"fix ave/chunk"_fix_ave_chunk.html
+any of the "compute */chunk"_compute.html commands :ul
+
+Here, each of the 3 kinds of chunk-related commands is briefly
+overviewed.  Then some examples are given of how to compute different
+properties with chunk commands.
+
+Compute chunk/atom command: :h4
+
+This compute can assign atoms to chunks of various styles.  Only atoms
+in the specified group and optional specified region are assigned to a
+chunk.  Here are some possible chunk definitions:
+
+atoms in same molecule | chunk ID = molecule ID |
+atoms of same atom type | chunk ID = atom type |
+all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
+atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
+atoms in same spatial bin | chunk ID = bin ID |
+atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
+atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
+atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
+
+Note that chunk IDs are integer values, so for atom properties or
+computes that produce a floating point value, they will be truncated
+to an integer.  You could also use the compute in a variable that
+scales the floating point value to spread it across multiple integers.
+
+Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
+pencils, 3d bins = boxes, spherical bins, cylindrical bins.
+
+This compute also calculates the number of chunks {Nchunk}, which is
+used by other commands to tally per-chunk data.  {Nchunk} can be a
+static value or change over time (e.g. the number of clusters).  The
+chunk ID for an individual atom can also be static (e.g. a molecule
+ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
+
+Note that this compute allows the per-atom output of other
+"computes"_compute.html, "fixes"_fix.html, and
+"variables"_variable.html to be used to define chunk IDs for each
+atom.  This means you can write your own compute or fix to output a
+per-atom quantity to use as chunk ID.  See the "Modify"_Modify.html
+doc pages for info on how to do this.  You can also define a "per-atom
+variable"_variable.html in the input script that uses a formula to
+generate a chunk ID for each atom.
+
+Fix ave/chunk command: :h4
+
+This fix takes the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input.  For each chunk,
+it then sums one or more specified per-atom values over the atoms in
+each chunk.  The per-atom values can be any atom property, such as
+velocity, force, charge, potential energy, kinetic energy, stress,
+etc.  Additional keywords are defined for per-chunk properties like
+density and temperature.  More generally any per-atom value generated
+by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
+variables"_variable.html, can be summed over atoms in each chunk.
+
+Similar to other averaging fixes, this fix allows the summed per-chunk
+values to be time-averaged in various ways, and output to a file.  The
+fix produces a global array as output with one row of values per
+chunk.
+
+Compute */chunk commands: :h4
+
+Currently the following computes operate on chunks of atoms to produce
+per-chunk values.
+
+"compute com/chunk"_compute_com_chunk.html
+"compute gyration/chunk"_compute_gyration_chunk.html
+"compute inertia/chunk"_compute_inertia_chunk.html
+"compute msd/chunk"_compute_msd_chunk.html
+"compute property/chunk"_compute_property_chunk.html
+"compute temp/chunk"_compute_temp_chunk.html
+"compute torque/chunk"_compute_vcm_chunk.html
+"compute vcm/chunk"_compute_vcm_chunk.html :ul
+
+They each take the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input.  As their names
+indicate, they calculate the center-of-mass, radius of gyration,
+moments of inertia, mean-squared displacement, temperature, torque,
+and velocity of center-of-mass for each chunk of atoms.  The "compute
+property/chunk"_compute_property_chunk.html command can tally the
+count of atoms in each chunk and extract other per-chunk properties.
+
+The reason these various calculations are not part of the "fix
+ave/chunk command"_fix_ave_chunk.html, is that each requires a more
+complicated operation than simply summing and averaging over per-atom
+values in each chunk.  For example, many of them require calculation
+of a center of mass, which requires summing mass*position over the
+atoms and then dividing by summed mass.
+
+All of these computes produce a global vector or global array as
+output, wih one or more values per chunk.  They can be used
+in various ways:
+
+As input to the "fix ave/time"_fix_ave_time.html command, which can
+write the values to a file and optionally time average them. :ulb,l
+
+As input to the "fix ave/histo"_fix_ave_histo.html command to
+histogram values across chunks.  E.g. a histogram of cluster sizes or
+molecule diffusion rates. :l
+
+As input to special functions of "equal-style
+variables"_variable.html, like sum() and max().  E.g. to find the
+largest cluster or fastest diffusing molecule. :l
+:ule
+
+Example calculations with chunks :h4
+
+Here are examples using chunk commands to calculate various
+properties:
+
+(1) Average velocity in each of 1000 2d spatial bins:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
+fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
+
+(2) Temperature in each spatial bin, after subtracting a flow
+velocity:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
+compute vbias all temp/profile 1 0 0 y 10
+fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
+
+(3) Center of mass of each molecule:
+
+compute cc1 all chunk/atom molecule
+compute myChunk all com/chunk cc1
+fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
+
+(4) Total force on each molecule and ave/max across all molecules:
+
+compute cc1 all chunk/atom molecule
+fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
+variable xave equal ave(f_1\[2\])
+variable xmax equal max(f_1\[2\])
+thermo 1000
+thermo_style custom step temp v_xave v_xmax :pre
+
+(5) Histogram of cluster sizes:
+
+compute cluster all cluster/atom 1.0
+compute cc1 all chunk/atom c_cluster compress yes
+compute size all property/chunk cc1 count
+fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre

doc/src/Howto_coreshell.txt

@@ -0,0 +1,253 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Adiabatic core/shell model :h3
+
+The adiabatic core-shell model by "Mitchell and
+Fincham"_#MitchellFincham is a simple method for adding polarizability
+to a system.  In order to mimic the electron shell of an ion, a
+satellite particle is attached to it. This way the ions are split into
+a core and a shell where the latter is meant to react to the
+electrostatic environment inducing polarizability.  See the "Howto
+polarizable"_Howto_polarizable.html doc page for a discussion of all
+the polarizable models available in LAMMPS.
+
+Technically, shells are attached to the cores by a spring force f =
+k*r where k is a parametrized spring constant and r is the distance
+between the core and the shell. The charges of the core and the shell
+add up to the ion charge, thus q(ion) = q(core) + q(shell). This
+setup introduces the ion polarizability (alpha) given by
+alpha = q(shell)^2 / k. In a
+similar fashion the mass of the ion is distributed on the core and the
+shell with the core having the larger mass.
+
+To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
+be used since atom charge and bonds are needed.  Each kind of
+core/shell pair requires two atom types and a bond type.  The core and
+shell of a core/shell pair should be bonded to each other with a
+harmonic bond that provides the spring force. For example, a data file
+for NaCl, as found in examples/coreshell, has this format:
+
+432   atoms  # core and shell atoms
+216   bonds  # number of core/shell springs :pre
+
+4     atom types  # 2 cores and 2 shells for Na and Cl
+2     bond types :pre
+
+0.0 24.09597 xlo xhi
+0.0 24.09597 ylo yhi
+0.0 24.09597 zlo zhi :pre
+
+Masses       # core/shell mass ratio = 0.1 :pre
+
+1 20.690784  # Na core
+2 31.90500   # Cl core
+3 2.298976   # Na shell
+4 3.54500    # Cl shell :pre
+
+Atoms :pre
+
+1    1    2   1.5005    0.00000000   0.00000000   0.00000000 # core of core/shell pair 1
+2    1    4  -2.5005    0.00000000   0.00000000   0.00000000 # shell of core/shell pair 1
+3    2    1   1.5056    4.01599500   4.01599500   4.01599500 # core of core/shell pair 2
+4    2    3  -0.5056    4.01599500   4.01599500   4.01599500 # shell of core/shell pair 2
+(...) :pre
+
+Bonds   # Bond topology for spring forces :pre
+
+1     2     1     2   # spring for core/shell pair 1
+2     2     3     4   # spring for core/shell pair 2
+(...) :pre
+
+Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
+defined between the shells.  Coulombic interactions are defined
+between all cores and shells.  If desired, additional bonds can be
+specified between cores.
+
+The "special_bonds"_special_bonds.html command should be used to
+turn-off the Coulombic interaction within core/shell pairs, since that
+interaction is set by the bond spring.  This is done using the
+"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
+which is the default value.  It needs to be considered whether one has
+to adjust the "special_bonds"_special_bonds.html weighting according
+to the molecular topology since the interactions of the shells are
+bypassed over an extra bond.
+
+Note that this core/shell implementation does not require all ions to
+be polarized.  One can mix core/shell pairs and ions without a
+satellite particle if desired.
+
+Since the core/shell model permits distances of r = 0.0 between the
+core and shell, a pair style with a "cs" suffix needs to be used to
+implement a valid long-range Coulombic correction.  Several such pair
+styles are provided in the CORESHELL package.  See "this doc
+page"_pair_cs.html for details.  All of the core/shell enabled pair
+styles require the use of a long-range Coulombic solver, as specified
+by the "kspace_style"_kspace_style.html command.  Either the PPPM or
+Ewald solvers can be used.
+
+For the NaCL example problem, these pair style and bond style settings
+are used:
+
+pair_style      born/coul/long/cs 20.0 20.0
+pair_coeff      * *      0.0 1.000   0.00  0.00   0.00
+pair_coeff      3 3    487.0 0.23768 0.00  1.05   0.50 #Na-Na
+pair_coeff      3 4 145134.0 0.23768 0.00  6.99   8.70 #Na-Cl
+pair_coeff      4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
+
+bond_style      harmonic
+bond_coeff      1 63.014 0.0
+bond_coeff      2 25.724 0.0 :pre
+
+When running dynamics with the adiabatic core/shell model, the
+following issues should be considered.  The relative motion of
+the core and shell particles corresponds to the polarization,
+hereby an instantaneous relaxation of the shells is approximated
+and a fast core/shell spring frequency ensures a nearly constant
+internal kinetic energy during the simulation.
+Thermostats can alter this polarization behaviour, by scaling the
+internal kinetic energy, meaning the shell will not react freely to
+its electrostatic environment.
+Therefore it is typically desirable to decouple the relative motion of
+the core/shell pair, which is an imaginary degree of freedom, from the
+real physical system.  To do that, the "compute
+temp/cs"_compute_temp_cs.html command can be used, in conjunction with
+any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
+langevin"_fix_langevin.  This compute uses the center-of-mass velocity
+of the core/shell pairs to calculate a temperature, and insures that
+velocity is what is rescaled for thermostatting purposes.  This
+compute also works for a system with both core/shell pairs and
+non-polarized ions (ions without an attached satellite particle).  The
+"compute temp/cs"_compute_temp_cs.html command requires input of two
+groups, one for the core atoms, another for the shell atoms.
+Non-polarized ions which might also be included in the treated system
+should not be included into either of these groups, they are taken
+into account by the {group-ID} (2nd argument) of the compute.  The
+groups can be defined using the "group {type}"_group.html command.
+Note that to perform thermostatting using this definition of
+temperature, the "fix modify temp"_fix_modify.html command should be
+used to assign the compute to the thermostat fix.  Likewise the
+"thermo_modify temp"_thermo_modify.html command can be used to make
+this temperature be output for the overall system.
+
+For the NaCl example, this can be done as follows:
+
+group cores type 1 2
+group shells type 3 4
+compute CSequ all temp/cs cores shells
+fix thermoberendsen all temp/berendsen 1427 1427 0.4    # thermostat for the true physical system
+fix thermostatequ all nve                               # integrator as needed for the berendsen thermostat
+fix_modify thermoberendsen temp CSequ
+thermo_modify temp CSequ                                # output of center-of-mass derived temperature :pre
+
+The pressure for the core/shell system is computed via the regular
+LAMMPS convention by "treating the cores and shells as individual
+particles"_#MitchellFincham2. For the thermo output of the pressure
+as well as for the application of a barostat, it is necessary to
+use an additional "pressure"_compute_pressure compute based on the
+default "temperature"_compute_temp and specifying it as a second
+argument in "fix modify"_fix_modify.html and
+"thermo_modify"_thermo_modify.html resulting in:
+
+(...)
+compute CSequ all temp/cs cores shells
+compute thermo_press_lmp all pressure thermo_temp       # pressure for individual particles
+thermo_modify temp CSequ press thermo_press_lmp         # modify thermo to regular pressure
+fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
+fix_modify press_bar temp CSequ press thermo_press_lmp  # pressure modification for correct kinetic scalar :pre
+
+If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
+relative motion of the core and the shell should in theory be
+stable.  However numerical fluctuation can introduce a small
+momentum to the system, which is noticable over long trajectories.
+Therefore it is recommendable to use the "fix
+momentum"_fix_momentum.html command in combination with "compute
+temp/cs"_compute_temp_cs.html when equilibrating the system to
+prevent any drift.
+
+When initializing the velocities of a system with core/shell pairs, it
+is also desirable to not introduce energy into the relative motion of
+the core/shell particles, but only assign a center-of-mass velocity to
+the pairs.  This can be done by using the {bias} keyword of the
+"velocity create"_velocity.html command and assigning the "compute
+temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
+"velocity"_velocity.html command, e.g.
+
+velocity all create 1427 134 bias yes temp CSequ
+velocity all scale 1427 temp CSequ :pre
+
+To maintain the correct polarizability of the core/shell pairs, the
+kinetic energy of the internal motion shall remain nearly constant.
+Therefore the choice of spring force and mass ratio need to ensure
+much faster relative motion of the 2 atoms within the core/shell pair
+than their center-of-mass velocity. This allows the shells to
+effectively react instantaneously to the electrostatic environment and
+limits energy transfer to or from the core/shell oscillators.
+This fast movement also dictates the timestep that can be used.
+
+The primary literature of the adiabatic core/shell model suggests that
+the fast relative motion of the core/shell pairs only allows negligible
+energy transfer to the environment.
+The mentioned energy transfer will typically lead to a small drift
+in total energy over time.  This internal energy can be monitored
+using the "compute chunk/atom"_compute_chunk_atom.html and "compute
+temp/chunk"_compute_temp_chunk.html commands.  The internal kinetic
+energies of each core/shell pair can then be summed using the sum()
+special function of the "variable"_variable.html command.  Or they can
+be time/averaged and output using the "fix ave/time"_fix_ave_time.html
+command.  To use these commands, each core/shell pair must be defined
+as a "chunk".  If each core/shell pair is defined as its own molecule,
+the molecule ID can be used to define the chunks.  If cores are bonded
+to each other to form larger molecules, the chunks can be identified
+by the "fix property/atom"_fix_property_atom.html via assigning a
+core/shell ID to each atom using a special field in the data file read
+by the "read_data"_read_data.html command.  This field can then be
+accessed by the "compute property/atom"_compute_property_atom.html
+command, to use as input to the "compute
+chunk/atom"_compute_chunk_atom.html command to define the core/shell
+pairs as chunks.
+
+For example if core/shell pairs are the only molecules:
+
+read_data NaCl_CS_x0.1_prop.data
+compute prop all property/atom molecule
+compute cs_chunk all chunk/atom c_prop
+compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0     # note the chosen degrees of freedom for the core/shell pairs
+fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
+
+For example if core/shell pairs and other molecules are present:
+
+fix csinfo all property/atom i_CSID                       # property/atom command
+read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info  # atom property added in the data-file
+compute prop all property/atom i_CSID
+(...) :pre
+
+The additional section in the date file would be formatted like this:
+
+CS-Info         # header of additional section :pre
+
+1   1           # column 1 = atom ID, column 2 = core/shell ID
+2   1
+3   2
+4   2
+5   3
+6   3
+7   4
+8   4
+(...) :pre
+
+:line
+
+:link(MitchellFincham)
+[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
+5, 1031-1038 (1993).
+
+:link(MitchellFincham2)
+[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
+6, 393-404 (1994).

doc/src/Howto_couple.txt

@@ -0,0 +1,105 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Coupling LAMMPS to other codes :h3
+
+LAMMPS is designed to allow it to be coupled to other codes.  For
+example, a quantum mechanics code might compute forces on a subset of
+atoms and pass those forces to LAMMPS.  Or a continuum finite element
+(FE) simulation might use atom positions as boundary conditions on FE
+nodal points, compute a FE solution, and return interpolated forces on
+MD atoms.
+
+LAMMPS can be coupled to other codes in at least 3 ways.  Each has
+advantages and disadvantages, which you'll have to think about in the
+context of your application.
+
+(1) Define a new "fix"_fix.html command that calls the other code.  In
+this scenario, LAMMPS is the driver code.  During its 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
+"POEMS"_poems package that performs constrained rigid-body motion on
+groups of atoms is hooked to LAMMPS.  See the "fix
+poems"_fix_poems.html command for more details.  See the
+"Modify"_Modify.html doc pages for info on how to add a new fix to
+LAMMPS.
+
+:link(poems,http://www.rpi.edu/~anderk5/lab)
+
+(2) Define a new LAMMPS command that calls the other code.  This is
+conceptually similar to method (1), but in this case LAMMPS and the
+other code are on a more equal footing.  Note that now the other code
+is not called during the timestepping of a LAMMPS run, but between
+runs.  The LAMMPS input script can be used to alternate LAMMPS runs
+with calls to the other code, invoked via the new command.  The
+"run"_run.html command facilitates this with its {every} option, which
+makes it easy to run a few steps, invoke the command, run a few steps,
+invoke the command, etc.
+
+In this scenario, the other code can be called as a library, as in
+(1), or it could be a stand-alone code, invoked by a system() call
+made by the command (assuming your parallel machine allows one or more
+processors to start up another program).  In the latter case the
+stand-alone code could communicate with LAMMPS thru files that the
+command writes and reads.
+
+See the "Modify command"_Modify_command.html doc page for info on how
+to add a new command to LAMMPS.
+
+(3) Use LAMMPS as a library called by another code.  In this case the
+other code is the driver and calls LAMMPS as needed.  Or a wrapper
+code could link and call both LAMMPS and another code as libraries.
+Again, the "run"_run.html command has options that allow it to be
+invoked with minimal overhead (no setup or clean-up) if you wish to do
+multiple short runs, driven by another program.
+
+Examples of driver codes that call LAMMPS as a library are included in
+the examples/COUPLE directory of the LAMMPS distribution; see
+examples/COUPLE/README for more details:
+
+simple: simple driver programs in C++ and C which invoke LAMMPS as a
+library :ulb,l
+
+lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
+MD with quantum forces calculated by a density functional code :l
+
+lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
+a kinetic Monte Carlo model for grain growth using MD to calculate
+strain induced across grain boundaries :l
+:ule
+
+:link(quest,http://dft.sandia.gov/Quest)
+:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
+
+"This section"_Section_start.html#start_5 of the documentation
+describes how to build LAMMPS as a library.  Once this is done, you
+can interface with LAMMPS either via C++, C, Fortran, or Python (or
+any other language that supports a vanilla C-like interface).  For
+example, from C++ you could create one (or more) "instances" of
+LAMMPS, pass it an input script to process, or execute individual
+commands, all by invoking the correct class methods in LAMMPS.  From C
+or Fortran you can make function calls to do the same things.  See the
+"Python"_Python.html doc pages for a description of the Python wrapper
+provided with LAMMPS that operates through the LAMMPS library
+interface.
+
+The files src/library.cpp and library.h contain the C-style interface
+to LAMMPS.  See the "Howto library"_Howto_library.html doc page for a
+description of the interface and how to extend it for your needs.
+
+Note that the lammps_open() function that creates an instance of
+LAMMPS takes an MPI communicator as an argument.  This means that
+instance of LAMMPS will run on the set of processors in the
+communicator.  Thus the calling code can run LAMMPS on all or a subset
+of processors.  For example, a wrapper script might decide to
+alternate between LAMMPS and another code, allowing them both to run
+on all the processors.  Or it might allocate half the processors to
+LAMMPS and half to the other code and run both codes simultaneously
+before syncing them up periodically.  Or it might instantiate multiple
+instances of LAMMPS to perform different calculations.

doc/src/Howto_diffusion.txt

@@ -0,0 +1,31 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate a diffusion coefficient :h3
+
+The diffusion coefficient D of a material can be measured in at least
+2 ways using various options in LAMMPS.  See the examples/DIFFUSE
+directory for scripts that implement the 2 methods discussed here for
+a simple Lennard-Jones fluid model.
+
+The first method is to measure the mean-squared displacement (MSD) of
+the system, via the "compute msd"_compute_msd.html command.  The slope
+of the MSD versus time is proportional to the diffusion coefficient.
+The instantaneous MSD values can be accumulated in a vector via the
+"fix vector"_fix_vector.html command, and a line fit to the vector to
+compute its slope via the "variable slope"_variable.html function, and
+thus extract D.
+
+The second method is to measure the velocity auto-correlation function
+(VACF) of the system, via the "compute vacf"_compute_vacf.html
+command.  The time-integral of the VACF is proportional to the
+diffusion coefficient.  The instantaneous VACF values can be
+accumulated in a vector via the "fix vector"_fix_vector.html command,
+and time integrated via the "variable trap"_variable.html function,
+and thus extract D.

doc/src/Howto_dispersion.txt

@@ -0,0 +1,108 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Long-raage dispersion settings :h3
+
+The PPPM method computes interactions by splitting the pair potential
+into two parts, one of which is computed in a normal pairwise fashion,
+the so-called real-space part, and one of which is computed using the
+Fourier transform, the so called reciprocal-space or kspace part.  For
+both parts, the potential is not computed exactly but is approximated.
+Thus, there is an error in both parts of the computation, the
+real-space and the kspace error. The just mentioned facts are true
+both for the PPPM for Coulomb as well as dispersion interactions. The
+deciding difference - and also the reason why the parameters for
+pppm/disp have to be selected with more care - is the impact of the
+errors on the results: The kspace error of the PPPM for Coulomb and
+dispersion interaction and the real-space error of the PPPM for
+Coulomb interaction have the character of noise. In contrast, the
+real-space error of the PPPM for dispersion has a clear physical
+interpretation: the underprediction of cohesion. As a consequence, the
+real-space error has a much stronger effect than the kspace error on
+simulation results for pppm/disp.  Parameters must thus be chosen in a
+way that this error is much smaller than the kspace error.
+
+When using pppm/disp and not making any specifications on the PPPM
+parameters via the kspace modify command, parameters will be tuned
+such that the real-space error and the kspace error are equal.  This
+will result in simulations that are either inaccurate or slow, both of
+which is not desirable. For selecting parameters for the pppm/disp
+that provide fast and accurate simulations, there are two approaches,
+which both have their up- and downsides.
+
+The first approach is to set desired real-space an kspace accuracies
+via the {kspace_modify force/disp/real} and {kspace_modify
+force/disp/kspace} commands. Note that the accuracies have to be
+specified in force units and are thus dependent on the chosen unit
+settings. For real units, 0.0001 and 0.002 seem to provide reasonable
+accurate and efficient computations for the real-space and kspace
+accuracies.  0.002 and 0.05 work well for most systems using lj
+units. PPPM parameters will be generated based on the desired
+accuracies. The upside of this approach is that it usually provides a
+good set of parameters and will work for both the {kspace_modify diff
+ad} and {kspace_modify diff ik} options.  The downside of the method
+is that setting the PPPM parameters will take some time during the
+initialization of the simulation.
+
+The second approach is to set the parameters for the pppm/disp
+explicitly using the {kspace_modify mesh/disp}, {kspace_modify
+order/disp}, and {kspace_modify gewald/disp} commands. This approach
+requires a more experienced user who understands well the impact of
+the choice of parameters on the simulation accuracy and
+performance. This approach provides a fast initialization of the
+simulation. However, it is sensitive to errors: A combination of
+parameters that will perform well for one system might result in
+far-from-optimal conditions for other simulations. For example,
+parameters that provide accurate and fast computations for
+all-atomistic force fields can provide insufficient accuracy or
+united-atomistic force fields (which is related to that the latter
+typically have larger dispersion coefficients).
+
+To avoid inaccurate or inefficient simulations, the pppm/disp stops
+simulations with an error message if no action is taken to control the
+PPPM parameters. If the automatic parameter generation is desired and
+real-space and kspace accuracies are desired to be equal, this error
+message can be suppressed using the {kspace_modify disp/auto yes}
+command.
+
+A reasonable approach that combines the upsides of both methods is to
+make the first run using the {kspace_modify force/disp/real} and
+{kspace_modify force/disp/kspace} commands, write down the PPPM
+parameters from the outut, and specify these parameters using the
+second approach in subsequent runs (which have the same composition,
+force field, and approximately the same volume).
+
+Concerning the performance of the pppm/disp there are two more things
+to consider. The first is that when using the pppm/disp, the cutoff
+parameter does no longer affect the accuracy of the simulation
+(subject to that gewald/disp is adjusted when changing the cutoff).
+The performance can thus be increased by examining different values
+for the cutoff parameter. A lower bound for the cutoff is only set by
+the truncation error of the repulsive term of pair potentials.
+
+The second is that the mixing rule of the pair style has an impact on
+the computation time when using the pppm/disp. Fastest computations
+are achieved when using the geometric mixing rule. Using the
+arithmetic mixing rule substantially increases the computational cost.
+The computational overhead can be reduced using the {kspace_modify
+mix/disp geom} and {kspace_modify splittol} commands. The first
+command simply enforces geometric mixing of the dispersion
+coefficients in kspace computations.  This introduces some error in
+the computations but will also significantly speed-up the
+simulations. The second keyword sets the accuracy with which the
+dispersion coefficients are approximated using a matrix factorization
+approach.  This may result in better accuracy then using the first
+command, but will usually also not provide an equally good increase of
+efficiency.
+
+Finally, pppm/disp can also be used when no mixing rules apply.
+This can be achieved using the {kspace_modify mix/disp none} command.
+Note that the code does not check automatically whether any mixing
+rule is fulfilled. If mixing rules do not apply, the user will have
+to specify this command explicitly.

doc/src/Howto_drude.txt

@@ -0,0 +1,77 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Drude induced dipoles :h3
+
+The thermalized Drude model represents induced dipoles by a pair of
+charges (the core atom and the Drude particle) connected by a harmonic
+spring.  See the "Howto polarizable"_Howto_polarizable.html doc page
+for a discussion of all the polarizable models available in LAMMPS.
+
+The Drude model has a number of features aimed at its use in
+molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
+
+Thermostating of the additional degrees of freedom associated with the
+induced dipoles at very low temperature, in terms of the reduced
+coordinates of the Drude particles with respect to their cores. This
+makes the trajectory close to that of relaxed induced dipoles. :ulb,l
+
+Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
+pair represents a single (polarizable) atom, so the special screening
+factors in a covalent structure should be the same for the core and
+the Drude particle.  Drude particles have to inherit the 1-2, 1-3, 1-4
+special neighbor relations from their respective cores. :l
+
+Stabilization of the interactions between induced dipoles. Drude
+dipoles on covalently bonded atoms interact too strongly due to the
+short distances, so an atom may capture the Drude particle of a
+neighbor, or the induced dipoles within the same molecule may align
+too much. To avoid this, damping at short range can be done by Thole
+functions (for which there are physical grounds). This Thole damping
+is applied to the point charges composing the induced dipole (the
+charge of the Drude particle and the opposite charge on the core, not
+to the total charge of the core atom). :l,ule
+
+A detailed tutorial covering the usage of Drude induced dipoles in
+LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
+
+As with the core-shell model, the cores and Drude particles should
+appear in the data file as standard atoms. The same holds for the
+springs between them, which are described by standard harmonic bonds.
+The nature of the atoms (core, Drude particle or non-polarizable) is
+specified via the "fix drude"_fix_drude.html command.  The special
+list of neighbors is automatically refactored to account for the
+equivalence of core and Drude particles as regards special 1-2 to 1-4
+screening. It may be necessary to use the {extra/special/per/atom}
+keyword of the "read_data"_read_data.html command. If using "fix
+shake"_fix_shake.html, make sure no Drude particle is in this fix
+group.
+
+There are two ways to thermostat the Drude particles at a low
+temperature: use either "fix langevin/drude"_fix_langevin_drude.html
+for a Langevin thermostat, or "fix
+drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
+thermostat. The former requires use of the command "comm_modify vel
+yes"_comm_modify.html. The latter requires two separate integration
+fixes like {nvt} or {npt}. The correct temperatures of the reduced
+degrees of freedom can be calculated using the "compute
+temp/drude"_compute_temp_drude.html. This requires also to use the
+command {comm_modify vel yes}.
+
+Short-range damping of the induced dipole interactions can be achieved
+using Thole functions through the "pair style
+thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
+with a Coulomb pair style. It may be useful to use {coul/long/cs} or
+similar from the CORESHELL package if the core and Drude particle come
+too close, which can cause numerical issues.
+
+:line
+
+:link(howto-Lamoureux)
+[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

doc/src/Howto_drude2.txt

@@ -9,7 +9,7 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Howto_elastic.txt

@@ -0,0 +1,47 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate elastic constants :h3
+
+Elastic constants characterize the stiffness of a material. The formal
+definition is provided by the linear relation that holds between the
+stress and strain tensors in the limit of infinitesimal deformation.
+In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
+the repeated indices imply summation. s_ij are the elements of the
+symmetric stress tensor. e_kl are the elements of the symmetric strain
+tensor. C_ijkl are the elements of the fourth rank tensor of elastic
+constants. In three dimensions, this tensor has 3^4=81 elements. Using
+Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
+is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
+derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
+most 7*6/2 = 21 distinct elements.
+
+At zero temperature, it is easy to estimate these derivatives by
+deforming the simulation box in one of the six directions using the
+"change_box"_change_box.html command and measuring the change in the
+stress tensor. A general-purpose script that does this is given in the
+examples/elastic directory described on the "Examples"_Examples.html
+doc page.
+
+Calculating elastic constants at finite temperature is more
+challenging, because it is necessary to run a simulation that perfoms
+time averages of differential properties. One way to do this is to
+measure the change in average stress tensor in an NVT simulations when
+the cell volume undergoes a finite deformation. In order to balance
+the systematic and statistical errors in this method, the magnitude of
+the deformation must be chosen judiciously, and care must be taken to
+fully equilibrate the deformed cell before sampling the stress
+tensor. Another approach is to sample the triclinic cell fluctuations
+that occur in an NPT simulation. This method can also be slow to
+converge and requires careful post-processing "(Shinoda)"_#Shinoda1
+
+:line
+
+:link(Shinoda1)
+[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

doc/src/Howto_github.txt

@@ -2,7 +2,7 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -25,8 +25,8 @@ or improvements to LAMMPS, as it significantly reduces the amount of
 work required by the LAMMPS developers. Consequently, creating a pull
 request will increase your chances to have your contribution included
 and will reduce the time until the integration is complete. For more
-information on the requirements to have your code included in LAMMPS,
+information on the requirements to have your code included into LAMMPS
-see the "Modify contribute"_Modify_contribute.html doc page.
+please see the "Modify contribute"_Modify_contribute.html doc page.
 
 :line
 
@@ -124,7 +124,7 @@ unrelated feature, you should switch branches!
 
 After everything is done, add the files to the branch and commit them:
 
- $ git add doc/src/tutorial_github.txt
+ $ git add doc/src/Howto_github.txt
  $ git add doc/src/JPG/tutorial*.png :pre
 
 IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}).  The -a
@@ -318,7 +318,7 @@ Because the changes are OK with us, we are going to merge by clicking on
 Now, since in the meantime our local text for the tutorial also changed,
 we need to pull Axel's change back into our branch, and merge them:
 
- $ git add tutorial_github.txt
+ $ git add Howto_github.txt
  $ git add JPG/tutorial_reverse_pull_request*.png
  $ git commit -m "Updated text and images on reverse pull requests"
  $ git pull :pre
@@ -331,7 +331,7 @@ With Axel's changes merged in and some final text updates, our feature
 branch is now perfect as far as we are concerned, so we are going to
 commit and push again:
 
- $ git add tutorial_github.txt
+ $ git add Howto_github.txt
  $ git add JPG/tutorial_reverse_pull_request6.png
  $ git commit -m "Merged Axel's suggestions and updated text"
  $ git push git@github.com:Pakketeretet2/lammps :pre

doc/src/Howto_granular.txt

@@ -0,0 +1,57 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Granular models :h3
+
+Granular system are composed of spherical particles with a diameter,
+as opposed to point particles.  This means they have an angular
+velocity and torque can be imparted to them to cause them to rotate.
+
+To run a simulation of a granular model, you will want to use
+the following commands:
+
+"atom_style sphere"_atom_style.html
+"fix nve/sphere"_fix_nve_sphere.html
+"fix gravity"_fix_gravity.html :ul
+
+This compute
+
+"compute erotate/sphere"_compute_erotate_sphere.html :ul
+
+calculates rotational kinetic energy which can be "output with
+thermodynamic info"_Howto_output.html.
+
+Use one of these 3 pair potentials, which compute forces and torques
+between interacting pairs of particles:
+
+"pair_style"_pair_style.html gran/history
+"pair_style"_pair_style.html gran/no_history
+"pair_style"_pair_style.html gran/hertzian :ul
+
+These commands implement fix options specific to granular systems:
+
+"fix freeze"_fix_freeze.html
+"fix pour"_fix_pour.html
+"fix viscous"_fix_viscous.html
+"fix wall/gran"_fix_wall_gran.html :ul
+
+The fix style {freeze} zeroes both the force and torque of frozen
+atoms, and should be used for granular system instead of the fix style
+{setforce}.
+
+For computational efficiency, you can eliminate needless pairwise
+computations between frozen atoms by using this command:
+
+"neigh_modify"_neigh_modify.html exclude :ul
+
+NOTE: By default, for 2d systems, granular particles are still modeled
+as 3d spheres, not 2d discs (circles), meaning their moment of inertia
+will be the same as in 3d.  If you wish to model granular particles in
+2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d
+doc page, where 2d simulations are discussed.

doc/src/Howto_kappa.txt

@@ -0,0 +1,90 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate thermal conductivity :h3
+
+The thermal conductivity kappa of a material can be measured in at
+least 4 ways using various options in LAMMPS.  See the examples/KAPPA
+directory for scripts that implement the 4 methods discussed here for
+a simple Lennard-Jones fluid model.  Also, see the "Howto
+viscosity"_Howto_viscosity.html doc page for an analogous discussion
+for viscosity.
+
+The thermal conductivity tensor kappa is a measure of the propensity
+of a material to transmit heat energy in a diffusive manner as given
+by Fourier's law
+
+J = -kappa grad(T)
+
+where J is the heat flux in units of energy per area per time and
+grad(T) is the spatial gradient of temperature.  The thermal
+conductivity thus has units of energy per distance per time per degree
+K and is often approximated as an isotropic quantity, i.e. as a
+scalar.
+
+The first method is to setup two thermostatted regions at opposite
+ends of a simulation box, or one in the middle and one at the end of a
+periodic box.  By holding the two regions at different temperatures
+with a "thermostatting fix"_Howto_thermostat.html, the energy added to
+the hot region should equal the energy subtracted from the cold region
+and be proportional to the heat flux moving between the regions.  See
+the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji and
+"Wirnsberger et al"_#howto-Wirnsberger for details of this idea.  Note
+that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
+langevin"_fix_langevin.html, and "fix
+temp/rescale"_fix_temp_rescale.html store the cumulative energy they
+add/subtract.
+
+Alternatively, as a second method, the "fix heat"_fix_heat.html or
+"fix ehex"_fix_ehex.html commands can be used in place of thermostats
+on each of two regions to add/subtract specified amounts of energy to
+both regions.  In both cases, the resulting temperatures of the two
+regions can be monitored with the "compute temp/region" command and
+the temperature profile of the intermediate region can be monitored
+with the "fix ave/chunk"_fix_ave_chunk.html and "compute
+ke/atom"_compute_ke_atom.html commands.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the "fix thermal/conductivity"_fix_thermal_conductivity.html
+command which implements the rNEMD algorithm of Muller-Plathe.
+Kinetic energy is swapped between atoms in two different layers of the
+simulation box.  This induces a temperature gradient between the two
+layers which can be monitored with the "fix
+ave/chunk"_fix_ave_chunk.html and "compute
+ke/atom"_compute_ke_atom.html commands.  The fix tallies the
+cumulative energy transfer that it performs.  See the "fix
+thermal/conductivity"_fix_thermal_conductivity.html command for
+details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the heat flux
+to kappa.  The heat flux can be calculated from the fluctuations of
+per-atom potential and kinetic energies and per-atom stress tensor in
+a steady-state equilibrated simulation.  This is in contrast to the
+two preceding non-equilibrium methods, where energy flows continuously
+between hot and cold regions of the simulation box.
+
+The "compute heat/flux"_compute_heat_flux.html command can calculate
+the needed heat flux and describes how to implement the Green_Kubo
+formalism using additional LAMMPS commands, such as the "fix
+ave/correlate"_fix_ave_correlate.html command to calculate the needed
+auto-correlation.  See the doc page for the "compute
+heat/flux"_compute_heat_flux.html command for an example input script
+that calculates the thermal conductivity of solid Ar via the GK
+formalism.
+
+:line
+
+:link(howto-Ikeshoji)
+[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
+(1994).
+
+:link(howto-Wirnsberger)
+[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
+(2015).

doc/src/Howto_library.txt

@@ -0,0 +1,208 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Library interface to LAMMPS :h3
+
+As described in "Section 2.5"_Section_start.html#start_5, LAMMPS can
+be built as a library, so that it can be called by another code, used
+in a "coupled manner"_Howto_couple.html with other codes, or driven
+through a "Python interface"_Python.html.
+
+All of these methodologies use a C-style interface to LAMMPS that is
+provided in the files src/library.cpp and src/library.h.  The
+functions therein have a C-style argument list, but contain C++ code
+you could write yourself in a C++ application that was invoking LAMMPS
+directly.  The C++ code in the functions illustrates how to invoke
+internal LAMMPS operations.  Note that LAMMPS classes are defined
+within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
+application.
+
+The examples/COUPLE and python/examples directories have example C++
+and C and Python codes which show how a driver code can link to LAMMPS
+as a library, run LAMMPS on a subset of processors, grab data from
+LAMMPS, change it, and put it back into LAMMPS.
+
+The file src/library.cpp contains the following functions for creating
+and destroying an instance of LAMMPS and sending it commands to
+execute.  See the documentation in the src/library.cpp file for
+details.
+
+NOTE: You can write code for additional functions as needed to define
+how your code talks to LAMMPS and add them to src/library.cpp and
+src/library.h, as well as to the "Python interface"_Python.html.  The
+added functions can access or change any internal LAMMPS data you
+wish.
+
+void lammps_open(int, char **, MPI_Comm, void **)
+void lammps_open_no_mpi(int, char **, void **)
+void lammps_close(void *)
+int lammps_version(void *)
+void lammps_file(void *, char *)
+char *lammps_command(void *, char *)
+void lammps_commands_list(void *, int, char **)
+void lammps_commands_string(void *, char *)
+void lammps_free(void *) :pre
+
+The lammps_open() function is used to initialize LAMMPS, passing in a
+list of strings as if they were "command-line
+arguments"_Section_start.html#start_6 when LAMMPS is run in
+stand-alone mode from the command line, and a MPI communicator for
+LAMMPS to run under.  It returns a ptr to the LAMMPS object that is
+created, and which is used in subsequent library calls.  The
+lammps_open() function can be called multiple times, to create
+multiple instances of LAMMPS.
+
+LAMMPS will run on the set of processors in the communicator.  This
+means the calling code can run LAMMPS on all or a subset of
+processors.  For example, a wrapper script might decide to alternate
+between LAMMPS and another code, allowing them both to run on all the
+processors.  Or it might allocate half the processors to LAMMPS and
+half to the other code and run both codes simultaneously before
+syncing them up periodically.  Or it might instantiate multiple
+instances of LAMMPS to perform different calculations.
+
+The lammps_open_no_mpi() function is similar except that no MPI
+communicator is passed from the caller.  Instead, MPI_COMM_WORLD is
+used to instantiate LAMMPS, and MPI is initialized if necessary.
+
+The lammps_close() function is used to shut down an instance of LAMMPS
+and free all its memory.
+
+The lammps_version() function can be used to determined the specific
+version of the underlying LAMMPS code. This is particularly useful
+when loading LAMMPS as a shared library via dlopen(). The code using
+the library interface can than use this information to adapt to
+changes to the LAMMPS command syntax between versions. The returned
+LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
+20150902) that grows with every new LAMMPS version.
+
+The lammps_file(), lammps_command(), lammps_commands_list(), and
+lammps_commands_string() functions are used to pass one or more
+commands to LAMMPS to execute, the same as if they were coming from an
+input script.
+
+Via these functions, the calling code can read or generate a series of
+LAMMPS commands one or multiple at a time and pass it thru the library
+interface to setup a problem and then run it in stages.  The caller
+can interleave the command function calls with operations it performs,
+calls to extract information from or set information within LAMMPS, or
+calls to another code's library.
+
+The lammps_file() function passes the filename of an input script.
+The lammps_command() function passes a single command as a string.
+The lammps_commands_list() function passes multiple commands in a
+char** list.  In both lammps_command() and lammps_commands_list(),
+individual commands may or may not have a trailing newline.  The
+lammps_commands_string() function passes multiple commands
+concatenated into one long string, separated by newline characters.
+In both lammps_commands_list() and lammps_commands_string(), a single
+command can be spread across multiple lines, if the last printable
+character of all but the last line is "&", the same as if the lines
+appeared in an input script.
+
+The lammps_free() function is a clean-up function to free memory that
+the library allocated previously via other function calls.  See
+comments in src/library.cpp file for which other functions need this
+clean-up.
+
+The file src/library.cpp also contains these functions for extracting
+information from LAMMPS and setting value within LAMMPS.  Again, see
+the documentation in the src/library.cpp file for details, including
+which quantities can be queried by name:
+
+int lammps_extract_setting(void *, char *)
+void *lammps_extract_global(void *, char *)
+void lammps_extract_box(void *, double *, double *,
+                        double *, double *, double *, int *, int *)
+void *lammps_extract_atom(void *, char *)
+void *lammps_extract_compute(void *, char *, int, int)
+void *lammps_extract_fix(void *, char *, int, int, int, int)
+void *lammps_extract_variable(void *, char *, char *) :pre
+
+The extract_setting() function returns info on the size
+of data types (e.g. 32-bit or 64-bit atom IDs) used
+by the LAMMPS executable (a compile-time choice).
+
+The other extract functions return a pointer to various global or
+per-atom quantities stored in LAMMPS or to values calculated by a
+compute, fix, or variable.  The pointer returned by the
+extract_global() function can be used as a permanent reference to a
+value which may change.  For the extract_atom() method, see the
+extract() method in the src/atom.cpp file for a list of valid per-atom
+properties.  New names could easily be added if the property you want
+is not listed.  For the other extract functions, the underlying
+storage may be reallocated as LAMMPS runs, so you need to re-call the
+function to assure a current pointer or returned value(s).
+
+double lammps_get_thermo(void *, char *)
+int lammps_get_natoms(void *) :pre
+
+int lammps_set_variable(void *, char *, char *)
+void lammps_reset_box(void *, double *, double *, double, double, double) :pre
+
+The lammps_get_thermo() function returns the current value of a thermo
+keyword as a double precision value.
+
+The lammps_get_natoms() function returns the total number of atoms in
+the system and can be used by the caller to allocate memory for the
+lammps_gather_atoms() and lammps_scatter_atoms() functions.
+
+The lammps_set_variable() function can set an existing string-style
+variable to a new string value, so that subsequent LAMMPS commands can
+access the variable.
+
+The lammps_reset_box() function resets the size and shape of the
+simulation box, e.g. as part of restoring a previously extracted and
+saved state of a simulation.
+
+void lammps_gather_atoms(void *, char *, int, int, void *)
+void lammps_gather_atoms_concat(void *, char *, int, int, void *)
+void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
+void lammps_scatter_atoms(void *, char *, int, int, void *)
+void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
+
+void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
+                         imageint *, int) :pre
+
+The gather functions collect peratom info of the requested type (atom
+coords, atom types, forces, etc) from all processors, and returns the
+same vector of values to each callling processor.  The scatter
+functions do the inverse.  They distribute a vector of peratom values,
+passed by all calling processors, to invididual atoms, which may be
+owned by different processos.
+
+The lammps_gather_atoms() function does this for all N atoms in the
+system, ordered by atom ID, from 1 to N.  The
+lammps_gather_atoms_concat() function does it for all N atoms, but
+simply concatenates the subset of atoms owned by each processor.  The
+resulting vector is not ordered by atom ID.  Atom IDs can be requetsed
+by the same function if the caller needs to know the ordering.  The
+lammps_gather_subset() function allows the caller to request values
+for only a subset of atoms (identified by ID).
+For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
+If the count is specified as 1, they are returned 
+in a packed format with all three image flags stored in a single integer.
+If the count is specified as 3, the values are unpacked into xyz flags
+by the library before returning them.
+
+The lammps_scatter_atoms() function takes a list of values for all N
+atoms in the system, ordered by atom ID, from 1 to N, and assigns
+those values to each atom in the system.  The
+lammps_scatter_atoms_subset() function takes a subset of IDs as an
+argument and only scatters those values to the owning atoms.
+
+The lammps_create_atoms() function takes a list of N atoms as input
+with atom types and coords (required), an optionally atom IDs and
+velocities and image flags.  It uses the coords of each atom to assign
+it as a new atom to the processor that owns it.  This function is
+useful to add atoms to a simulation or (in tandem with
+lammps_reset_box()) to restore a previously extracted and saved state
+of a simulation.  Additional properties for the new atoms can then be
+assigned via the lammps_scatter_atoms() or lammps_extract_atom()
+functions.

doc/src/Howto_manifold.txt

@@ -2,11 +2,11 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
-Manifolds (surfaces) :h2
+Manifolds (surfaces) :h3
 
 [Overview:]
 

doc/src/Howto_multiple.txt

@@ -0,0 +1,95 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Run multiple simulations from one input script :h3
+
+This can be done in several ways.  See the documentation for
+individual commands for more details on how these examples work.
+
+If "multiple simulations" means continue a previous simulation for
+more timesteps, then you simply use the "run"_run.html command
+multiple times.  For example, this script
+
+units lj
+atom_style atomic
+read_data data.lj
+run 10000
+run 10000
+run 10000
+run 10000
+run 10000 :pre
+
+would run 5 successive simulations of the same system for a total of
+50,000 timesteps.
+
+If you wish to run totally different simulations, one after the other,
+the "clear"_clear.html command can be used in between them to
+re-initialize LAMMPS.  For example, this script
+
+units lj
+atom_style atomic
+read_data data.lj
+run 10000
+clear
+units lj
+atom_style atomic
+read_data data.lj.new
+run 10000 :pre
+
+would run 2 independent simulations, one after the other.
+
+For large numbers of independent simulations, you can use
+"variables"_variable.html and the "next"_next.html and
+"jump"_jump.html commands to loop over the same input script
+multiple times with different settings.  For example, this
+script, named in.polymer
+
+variable d index run1 run2 run3 run4 run5 run6 run7 run8
+shell cd $d
+read_data data.polymer
+run 10000
+shell cd ..
+clear
+next d
+jump in.polymer :pre
+
+would run 8 simulations in different directories, using a data.polymer
+file in each directory.  The same concept could be used to run the
+same system at 8 different temperatures, using a temperature variable
+and storing the output in different log and dump files, for example
+
+variable a loop 8
+variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
+log log.$a
+read data.polymer
+velocity all create $t 352839
+fix 1 all nvt $t $t 100.0
+dump 1 all atom 1000 dump.$a
+run 100000
+clear
+next t
+next a
+jump in.polymer :pre
+
+All of the above examples work whether you are running on 1 or
+multiple processors, but assumed you are running LAMMPS on a single
+partition of processors.  LAMMPS can be run on multiple partitions via
+the "-partition" command-line switch as described in "this
+section"_Section_start.html#start_6 of the manual.
+
+In the last 2 examples, if LAMMPS were run on 3 partitions, the same
+scripts could be used if the "index" and "loop" variables were
+replaced with {universe}-style variables, as described in the
+"variable"_variable.html command.  Also, the "next t" and "next a"
+commands would need to be replaced with a single "next a t" command.
+With these modifications, the 8 simulations of each script would run
+on the 3 partitions one after the other until all were finished.
+Initially, 3 simulations would be started simultaneously, one on each
+partition.  When one finished, that partition would then start
+the 4th simulation, and so forth, until all 8 were completed.

doc/src/Howto_nemd.txt

@@ -0,0 +1,48 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+NEMD simulations :h3
+
+Non-equilibrium molecular dynamics or NEMD simulations are typically
+used to measure a fluid's rheological properties such as viscosity.
+In LAMMPS, such simulations can be performed by first setting up a
+non-orthogonal simulation box (see the preceding Howto section).
+
+A shear strain can be applied to the simulation box at a desired
+strain rate by using the "fix deform"_fix_deform.html command.  The
+"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
+the sheared fluid and integrate the SLLOD equations of motion for the
+system.  Fix nvt/sllod uses "compute
+temp/deform"_compute_temp_deform.html to compute a thermal temperature
+by subtracting out the streaming velocity of the shearing atoms.  The
+velocity profile or other properties of the fluid can be monitored via
+the "fix ave/chunk"_fix_ave_chunk.html command.
+
+As discussed in the previous section on non-orthogonal simulation
+boxes, the amount of tilt or skew that can be applied is limited by
+LAMMPS for computational efficiency to be 1/2 of the parallel box
+length.  However, "fix deform"_fix_deform.html can continuously strain
+a box by an arbitrary amount.  As discussed in the "fix
+deform"_fix_deform.html command, when the tilt value reaches a limit,
+the box is flipped to the opposite limit which is an equivalent tiling
+of periodic space.  The strain rate can then continue to change as
+before.  In a long NEMD simulation these box re-shaping events may
+occur many times.
+
+In a NEMD simulation, the "remap" option of "fix
+deform"_fix_deform.html should be set to "remap v", since that is what
+"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
+profile consistent with the applied shear strain rate.
+
+An alternative method for calculating viscosities is provided via the
+"fix viscosity"_fix_viscosity.html command.
+
+NEMD simulations can also be used to measure transport properties of a fluid
+through a pore or channel. Simulations of steady-state flow can be performed
+using the "fix flow/gauss"_fix_flow_gauss.html command.

doc/src/Howto_output.txt

@@ -0,0 +1,307 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Output from LAMMPS (thermo, dumps, computes, fixes, variables) :h3
+
+There are four basic kinds of LAMMPS output:
+
+"Thermodynamic output"_thermo_style.html, which is a list
+of quantities printed every few timesteps to the screen and logfile. :ulb,l
+
+"Dump files"_dump.html, which contain snapshots of atoms and various
+per-atom values and are written at a specified frequency. :l
+
+Certain fixes can output user-specified quantities to files: "fix
+ave/time"_fix_ave_time.html for time averaging, "fix
+ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
+print"_fix_print.html for single-line output of
+"variables"_variable.html.  Fix print can also output to the
+screen. :l
+
+"Restart files"_restart.html. :l
+:ule
+
+A simulation prints one set of thermodynamic output and (optionally)
+restart files.  It can generate any number of dump files and fix
+output files, depending on what "dump"_dump.html and "fix"_fix.html
+commands you specify.
+
+As discussed below, LAMMPS gives you a variety of ways to determine
+what quantities are computed and printed when the thermodynamics,
+dump, or fix commands listed above perform output.  Throughout this
+discussion, note that users can also "add their own computes and fixes
+to LAMMPS"_Modify.html which can then generate values that can then be
+output with these commands.
+
+The following sub-sections discuss different LAMMPS command related
+to output and the kind of data they operate on and produce:
+
+"Global/per-atom/local data"_#global
+"Scalar/vector/array data"_#scalar
+"Thermodynamic output"_#thermo
+"Dump file output"_#dump
+"Fixes that write output files"_#fixoutput
+"Computes that process output quantities"_#computeoutput
+"Fixes that process output quantities"_#fixprocoutput
+"Computes that generate values to output"_#compute
+"Fixes that generate values to output"_#fix
+"Variables that generate values to output"_#variable
+"Summary table of output options and data flow between commands"_#table :ul
+
+Global/per-atom/local data :h4,link(global)
+
+Various output-related commands work with three different styles of
+data: global, per-atom, or local.  A global datum is one or more
+system-wide values, e.g. the temperature of the system.  A per-atom
+datum is one or more values per atom, e.g. the kinetic energy of each
+atom.  Local datums are calculated by each processor based on the
+atoms it owns, but there may be zero or more per atom, e.g. a list of
+bond distances.
+
+Scalar/vector/array data :h4,link(scalar)
+
+Global, per-atom, and local datums can each come in three kinds: a
+single scalar value, a vector of values, or a 2d array of values.  The
+doc page for a "compute" or "fix" or "variable" that generates data
+will specify both the style and kind of data it produces, e.g. a
+per-atom vector.
+
+When a quantity is accessed, as in many of the output commands
+discussed below, it can be referenced via the following bracket
+notation, where ID in this case is the ID of a compute.  The leading
+"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
+
+c_ID | entire scalar, vector, or array
+c_ID\[I\] | one element of vector, one column of array
+c_ID\[I\]\[J\] | one element of array :tb(s=|)
+
+In other words, using one bracket reduces the dimension of the data
+once (vector -> scalar, array -> vector).  Using two brackets reduces
+the dimension twice (array -> scalar).  Thus a command that uses
+scalar values as input can typically also process elements of a vector
+or array.
+
+Thermodynamic output :h4,link(thermo)
+
+The frequency and format of thermodynamic output is set by the
+"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
+"thermo_modify"_thermo_modify.html commands.  The
+"thermo_style"_thermo_style.html command also specifies what values
+are calculated and written out.  Pre-defined keywords can be specified
+(e.g. press, etotal, etc).  Three additional kinds of keywords can
+also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
+or "fix"_fix.html or "variable"_variable.html provides the value to be
+output.  In each case, the compute, fix, or variable must generate
+global values for input to the "thermo_style custom"_dump.html
+command.
+
+Note that thermodynamic output values can be "extensive" or
+"intensive".  The former scale with the number of atoms in the system
+(e.g. total energy), the latter do not (e.g. temperature).  The
+setting for "thermo_modify norm"_thermo_modify.html determines whether
+extensive quantities are normalized or not.  Computes and fixes
+produce either extensive or intensive values; see their individual doc
+pages for details.  "Equal-style variables"_variable.html produce only
+intensive values; you can include a division by "natoms" in the
+formula if desired, to make an extensive calculation produce an
+intensive result.
+
+Dump file output :h4,link(dump)
+
+Dump file output is specified by the "dump"_dump.html and
+"dump_modify"_dump_modify.html commands.  There are several
+pre-defined formats (dump atom, dump xtc, etc).
+
+There is also a "dump custom"_dump.html format where the user
+specifies what values are output with each atom.  Pre-defined atom
+attributes can be specified (id, x, fx, etc).  Three additional kinds
+of keywords can also be specified (c_ID, f_ID, v_name), where a
+"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
+provides the values to be output.  In each case, the compute, fix, or
+variable must generate per-atom values for input to the "dump
+custom"_dump.html command.
+
+There is also a "dump local"_dump.html format where the user specifies
+what local values to output.  A pre-defined index keyword can be
+specified to enumerate the local values.  Two additional kinds of
+keywords can also be specified (c_ID, f_ID), where a
+"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
+provides the values to be output.  In each case, the compute or fix
+must generate local values for input to the "dump local"_dump.html
+command.
+
+Fixes that write output files :h4,link(fixoutput)
+
+Several fixes take various quantities as input and can write output
+files: "fix ave/time"_fix_ave_time.html, "fix
+ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
+"fix ave/correlate"_fix_ave_correlate.html, and "fix
+print"_fix_print.html.
+
+The "fix ave/time"_fix_ave_time.html command enables direct output to
+a file and/or time-averaging of global scalars or vectors.  The user
+specifies one or more quantities as input.  These can be global
+"compute"_compute.html values, global "fix"_fix.html values, or
+"variables"_variable.html of any style except the atom style which
+produces per-atom values.  Since a variable can refer to keywords used
+by the "thermo_style custom"_thermo_style.html command (like temp or
+press) and individual per-atom values, a wide variety of quantities
+can be time averaged and/or output in this way.  If the inputs are one
+or more scalar values, then the fix generate a global scalar or vector
+of output.  If the inputs are one or more vector values, then the fix
+generates a global vector or array of output.  The time-averaged
+output of this fix can also be used as input to other output commands.
+
+The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
+to a file of chunk-averaged per-atom quantities like those output in
+dump files.  Chunks can represent spatial bins or other collections of
+atoms, e.g. individual molecules.  The per-atom quantities can be atom
+density (mass or number) or atom attributes such as position,
+velocity, force.  They can also be per-atom quantities calculated by a
+"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
+"variable"_variable.html.  The chunk-averaged output of this fix can
+also be used as input to other output commands.
+
+The "fix ave/histo"_fix_ave_histo.html command enables direct output
+to a file of histogrammed quantities, which can be global or per-atom
+or local quantities.  The histogram output of this fix can also be
+used as input to other output commands.
+
+The "fix ave/correlate"_fix_ave_correlate.html command enables direct
+output to a file of time-correlated quantities, which can be global
+values.  The correlation matrix output of this fix can also be used as
+input to other output commands.
+
+The "fix print"_fix_print.html command can generate a line of output
+written to the screen and log file or to a separate file, periodically
+during a running simulation.  The line can contain one or more
+"variable"_variable.html values for any style variable except the
+vector or atom styles).  As explained above, variables themselves can
+contain references to global values generated by "thermodynamic
+keywords"_thermo_style.html, "computes"_compute.html,
+"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
+values for a specific atom.  Thus the "fix print"_fix_print.html
+command is a means to output a wide variety of quantities separate
+from normal thermodynamic or dump file output.
+
+Computes that process output quantities :h4,link(computeoutput)
+
+The "compute reduce"_compute_reduce.html and "compute
+reduce/region"_compute_reduce.html commands take one or more per-atom
+or local vector quantities as inputs and "reduce" them (sum, min, max,
+ave) to scalar quantities.  These are produced as output values which
+can be used as input to other output commands.
+
+The "compute slice"_compute_slice.html command take one or more global
+vector or array quantities as inputs and extracts a subset of their
+values to create a new vector or array.  These are produced as output
+values which can be used as input to other output commands.
+
+The "compute property/atom"_compute_property_atom.html command takes a
+list of one or more pre-defined atom attributes (id, x, fx, etc) and
+stores the values in a per-atom vector or array.  These are produced
+as output values which can be used as input to other output commands.
+The list of atom attributes is the same as for the "dump
+custom"_dump.html command.
+
+The "compute property/local"_compute_property_local.html command takes
+a list of one or more pre-defined local attributes (bond info, angle
+info, etc) and stores the values in a local vector or array.  These
+are produced as output values which can be used as input to other
+output commands.
+
+Fixes that process output quantities :h4,link(fixprocoutput)
+
+The "fix vector"_fix_vector.html command can create global vectors as
+output from global scalars as input, accumulating them one element at
+a time.
+
+The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
+of per-atom vectors.  The per-atom quantities can be atom attributes
+such as position, velocity, force.  They can also be per-atom
+quantities calculated by a "compute"_compute.html, by a
+"fix"_fix.html, or by an atom-style "variable"_variable.html.  The
+time-averaged per-atom output of this fix can be used as input to
+other output commands.
+
+The "fix store/state"_fix_store_state.html command can archive one or
+more per-atom attributes at a particular time, so that the old values
+can be used in a future calculation or output.  The list of atom
+attributes is the same as for the "dump custom"_dump.html command,
+including per-atom quantities calculated by a "compute"_compute.html,
+by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
+The output of this fix can be used as input to other output commands.
+
+Computes that generate values to output :h4,link(compute)
+
+Every "compute"_compute.html in LAMMPS produces either global or
+per-atom or local values.  The values can be scalars or vectors or
+arrays of data.  These values can be output using the other commands
+described in this section.  The doc page for each compute command
+describes what it produces.  Computes that produce per-atom or local
+values have the word "atom" or "local" in their style name.  Computes
+without the word "atom" or "local" produce global values.
+
+Fixes that generate values to output :h4,link(fix)
+
+Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
+local values which can be accessed by other commands.  The values can
+be scalars or vectors or arrays of data.  These values can be output
+using the other commands described in this section.  The doc page for
+each fix command tells whether it produces any output quantities and
+describes them.
+
+Variables that generate values to output :h4,link(variable)
+
+"Variables"_variable.html defined in an input script can store one or
+more strings.  But equal-style, vector-style, and atom-style or
+atomfile-style variables generate a global scalar value, global vector
+or values, or a per-atom vector, respectively, when accessed.  The
+formulas used to define these variables can contain references to the
+thermodynamic keywords and to global and per-atom data generated by
+computes, fixes, and other variables.  The values generated by
+variables can be used as input to and thus output by the other
+commands described in this section.
+
+Summary table of output options and data flow between commands :h4,link(table)
+
+This table summarizes the various commands that can be used for
+generating output from LAMMPS.  Each command produces output data of
+some kind and/or writes data to a file.  Most of the commands can take
+data from other commands as input.  Thus you can link many of these
+commands together in pipeline form, where data produced by one command
+is used as input to another command and eventually written to the
+screen or to a file.  Note that to hook two commands together the
+output and input data types must match, e.g. global/per-atom/local
+data and scalar/vector/array data.
+
+Also note that, as described above, when a command takes a scalar as
+input, that could be an element of a vector or array.  Likewise a
+vector input could be a column of an array.
+
+Command: Input: Output:
+"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
+"dump custom"_dump.html: per-atom vectors: dump file:
+"dump local"_dump.html: local vectors: dump file:
+"fix print"_fix_print.html: global scalar from variable: screen, file:
+"print"_print.html: global scalar from variable: screen:
+"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
+"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
+"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
+"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
+"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
+"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
+"compute property/local"_compute_property_local.html: local vectors: local vector/array:
+"fix vector"_fix_vector.html: global scalars: global vector:
+"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
+"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
+"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
+"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
+"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
+"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)

doc/src/Howto_polarizable.txt

@@ -0,0 +1,81 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Polarizable models :h3
+
+In polarizable force fields the charge distributions in molecules and
+materials respond to their electrostatic environments. Polarizable
+systems can be simulated in LAMMPS using three methods:
+
+the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
+package, :ulb,l
+the adiabatic core-shell method, implemented in the
+"CORESHELL"_Howto_coreshell.html package, :l
+the thermalized Drude dipole method, implemented in the
+"USER-DRUDE"_Howto_drude.html package. :l,ule
+
+The fluctuating charge method calculates instantaneous charges on
+interacting atoms based on the electronegativity equalization
+principle. It is implemented in the "fix qeq"_fix_qeq.html which is
+available in several variants. It is a relatively efficient technique
+since no additional particles are introduced. This method allows for
+charge transfer between molecules or atom groups. However, because the
+charges are located at the interaction sites, off-plane components of
+polarization cannot be represented in planar molecules or atom groups.
+
+The two other methods share the same basic idea: polarizable atoms are
+split into one core atom and one satellite particle (called shell or
+Drude particle) attached to it by a harmonic spring.  Both atoms bear
+a charge and they represent collectively an induced electric dipole.
+These techniques are computationally more expensive than the QEq
+method because of additional particles and bonds. These two
+charge-on-spring methods differ in certain features, with the
+core-shell model being normally used for ionic/crystalline materials,
+whereas the so-called Drude model is normally used for molecular
+systems and fluid states.
+
+The core-shell model is applicable to crystalline materials where the
+high symmetry around each site leads to stable trajectories of the
+core-shell pairs. However, bonded atoms in molecules can be so close
+that a core would interact too strongly or even capture the Drude
+particle of a neighbor. The Drude dipole model is relatively more
+complex in order to remediate this and other issues. Specifically, the
+Drude model includes specific thermostating of the core-Drude pairs
+and short-range damping of the induced dipoles.
+
+The three polarization methods can be implemented through a
+self-consistent calculation of charges or induced dipoles at each
+timestep. In the fluctuating charge scheme this is done by the matrix
+inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
+or Drude-dipoles the relaxed-dipoles technique would require an slow
+iterative procedure. These self-consistent solutions yield accurate
+trajectories since the additional degrees of freedom representing
+polarization are massless.  An alternative is to attribute a mass to
+the additional degrees of freedom and perform time integration using
+an extended Lagrangian technique. For the fluctuating charge scheme
+this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
+charge-on-spring models by the methods outlined in the next two
+sections. The assignment of masses to the additional degrees of
+freedom can lead to unphysical trajectories if care is not exerted in
+choosing the parameters of the polarizable models and the simulation
+conditions.
+
+In the core-shell model the vibration of the shells is kept faster
+than the ionic vibrations to mimic the fast response of the
+polarizable electrons.  But in molecular systems thermalizing the
+core-Drude pairs at temperatures comparable to the rest of the
+simulation leads to several problems (kinetic energy transfer, too
+short a timestep, etc.) In order to avoid these problems the relative
+motion of the Drude particles with respect to their cores is kept
+"cold" so the vibration of the core-Drude pairs is very slow,
+approaching the self-consistent regime.  In both models the
+temperature is regulated using the velocities of the center of mass of
+core+shell (or Drude) pairs, but in the Drude model the actual
+relative core-Drude particle motion is thermostated separately as
+well.

doc/src/Howto_pylammps.txt

@@ -2,7 +2,7 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -15,13 +15,19 @@ END_RST -->
 
 Overview :h4
 
-PyLammps is a Python wrapper class which can be created on its own or use an
+PyLammps is a Python wrapper class which can be created on its own or
-existing lammps Python object. It creates a simpler, Python-like interface to
+use an existing lammps Python object.  It creates a simpler,
-common LAMMPS functionality. Unlike the original flat C-types interface, it
+Python-like interface to common LAMMPS functionality, in contrast to
-exposes a discoverable API. It no longer requires knowledge of the underlying
+the lammps.py wrapper on the C-style LAMMPS library interface which is
-C++ code implementation.  Finally, the IPyLammps wrapper builds on top of
+written using Python ctypes.  The lammps.py wrapper is discussed on
-PyLammps and adds some additional features for IPython integration into IPython
+the "Python library"_Python_library.html doc page.
-notebooks, e.g. for embedded visualization output from dump/image.
+
+Unlike the flat ctypes interface, PyLammps exposes a discoverable API.
+It no longer requires knowledge of the underlying C++ code
+implementation.  Finally, the IPyLammps wrapper builds on top of
+PyLammps and adds some additional features for IPython integration
+into IPython notebooks, e.g. for embedded visualization output from
+dump/image.
 
 Comparison of lammps and PyLammps interfaces :h5
 
@@ -40,7 +46,6 @@ communication with LAMMPS is hidden from API user
 shorter, more concise Python
 better IPython integration, designed for quick prototyping :ul
 
-
 Quick Start :h4
 
 System-wide Installation :h5

doc/src/Howto_replica.txt

@@ -0,0 +1,61 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Multi-replica simulations :h3
+
+Several commands in LAMMPS run mutli-replica simulations, meaning
+that multiple instances (replicas) of your simulation are run
+simultaneously, with small amounts of data exchanged between replicas
+periodically.
+
+These are the relevant commands:
+
+"neb"_neb.html for nudged elastic band calculations
+"prd"_prd.html for parallel replica dynamics
+"tad"_tad.html for temperature accelerated dynamics
+"temper"_temper.html for parallel tempering
+"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
+
+NEB is a method for finding transition states and barrier energies.
+PRD and TAD are methods for performing accelerated dynamics to find
+and perform infrequent events.  Parallel tempering or replica exchange
+runs different replicas at a series of temperature to facilitate
+rare-event sampling.
+
+These commands can only be used if LAMMPS was built with the REPLICA
+package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info on packages.
+
+PIMD runs different replicas whose individual particles are coupled
+together by springs to model a system or ring-polymers.
+
+This commands can only be used if LAMMPS was built with the USER-MISC
+package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info on packages.
+
+In all these cases, you must run with one or more processors per
+replica.  The processors assigned to each replica are determined at
+run-time by using the "-partition command-line
+switch"_Section_start.html#start_6 to launch LAMMPS on multiple
+partitions, which in this context are the same as replicas.  E.g.
+these commands:
+
+mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
+mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
+
+would each run 8 replicas, on either 16 or 8 processors.  Note the use
+of the "-in command-line switch"_Section_start.html#start_6 to specify
+the input script which is required when running in multi-replica mode.
+
+Also note that with MPI installed on a machine (e.g. your desktop),
+you can run on more (virtual) processors than you have physical
+processors.  Thus the above commands could be run on a
+single-processor (or few-processor) desktop so that you can run
+a multi-replica simulation on more replicas than you have
+physical processors.

doc/src/Howto_restart.txt

@@ -0,0 +1,97 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Restart a simulation :h3
+
+There are 3 ways to continue a long LAMMPS simulation.  Multiple
+"run"_run.html commands can be used in the same input script.  Each
+run will continue from where the previous run left off.  Or binary
+restart files can be saved to disk using the "restart"_restart.html
+command.  At a later time, these binary files can be read via a
+"read_restart"_read_restart.html command in a new script.  Or they can
+be converted to text data files using the "-r command-line
+switch"_Section_start.html#start_6 and read by a
+"read_data"_read_data.html command in a new script.
+
+Here we give examples of 2 scripts that read either a binary restart
+file or a converted data file and then issue a new run command to
+continue where the previous run left off.  They illustrate what
+settings must be made in the new script.  Details are discussed in the
+documentation for the "read_restart"_read_restart.html and
+"read_data"_read_data.html commands.
+
+Look at the {in.chain} input script provided in the {bench} directory
+of the LAMMPS distribution to see the original script that these 2
+scripts are based on.  If that script had the line
+
+restart         50 tmp.restart :pre
+
+added to it, it would produce 2 binary restart files (tmp.restart.50
+and tmp.restart.100) as it ran.
+
+This script could be used to read the 1st restart file and re-run the
+last 50 timesteps:
+
+read_restart    tmp.restart.50 :pre
+
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1 :pre
+
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297 :pre
+
+timestep        0.012 :pre
+
+run             50 :pre
+
+Note that the following commands do not need to be repeated because
+their settings are included in the restart file: {units, atom_style,
+special_bonds, pair_style, bond_style}.  However these commands do
+need to be used, since their settings are not in the restart file:
+{neighbor, fix, timestep}.
+
+If you actually use this script to perform a restarted run, you will
+notice that the thermodynamic data match at step 50 (if you also put a
+"thermo 50" command in the original script), but do not match at step
+100.  This is because the "fix langevin"_fix_langevin.html command
+uses random numbers in a way that does not allow for perfect restarts.
+
+As an alternate approach, the restart file could be converted to a data
+file as follows:
+
+lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
+
+Then, this script could be used to re-run the last 50 steps:
+
+units           lj
+atom_style      bond
+pair_style      lj/cut 1.12
+pair_modify     shift yes
+bond_style      fene
+special_bonds   0.0 1.0 1.0 :pre
+
+read_data       tmp.restart.data :pre
+
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1 :pre
+
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297 :pre
+
+timestep        0.012 :pre
+
+reset_timestep  50
+run             50 :pre
+
+Note that nearly all the settings specified in the original {in.chain}
+script must be repeated, except the {pair_coeff} and {bond_coeff}
+commands since the new data file lists the force field coefficients.
+Also, the "reset_timestep"_reset_timestep.html command is used to tell
+LAMMPS the current timestep.  This value is stored in restart files,
+but not in data files.

doc/src/Howto_spc.txt

@@ -0,0 +1,54 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+SPC water model :h3
+
+The SPC water model specifies a 3-site rigid water molecule with
+charges and Lennard-Jones parameters assigned to each of the 3 atoms.
+In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
+the two O-H bonds and the H-O-H angle rigid.  A bond style of
+{harmonic} and an angle style of {harmonic} or {charmm} should also be
+used.
+
+These are the additional parameters (in real units) to set for O and H
+atoms and the water molecule to run a rigid SPC model.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.820
+H charge = 0.410
+LJ epsilon of OO = 0.1553
+LJ sigma of OO = 3.166
+LJ epsilon, sigma of OH, HH = 0.0
+r0 of OH bond = 1.0
+theta of HOH angle = 109.47 :all(b),p
+
+Note that as originally proposed, the SPC model was run with a 9
+Angstrom cutoff for both LJ and Coulommbic terms.  It can also be used
+with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
+any of the parameters above, though it becomes a different model in
+that mode of usage.
+
+The SPC/E (extended) water model is the same, except
+the partial charge assignments change:
+
+O charge = -0.8476
+H charge = 0.4238 :all(b),p
+
+See the "(Berendsen)"_#howto-Berendsen reference for more details on both
+the SPC and SPC/E models.
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(howto-Berendsen)
+[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
+6269-6271 (1987).

doc/src/Howto_spherical.txt

@@ -0,0 +1,243 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Finite-size spherical and aspherical particles :h3
+
+Typical MD models treat atoms or particles as point masses.  Sometimes
+it is desirable to have a model with finite-size particles such as
+spheroids or ellipsoids or generalized aspherical bodies.  The
+difference is that such particles have a moment of inertia, rotational
+energy, and angular momentum.  Rotation is induced by torque coming
+from interactions with other particles.
+
+LAMMPS has several options for running simulations with these kinds of
+particles.  The following aspects are discussed in turn:
+
+atom styles
+pair potentials
+time integration
+computes, thermodynamics, and dump output
+rigid bodies composed of finite-size particles :ul
+
+Example input scripts for these kinds of models are in the body,
+colloid, dipole, ellipse, line, peri, pour, and tri directories of the
+"examples directory"_Examples.html in the LAMMPS distribution.
+
+Atom styles :h4
+
+There are several "atom styles"_atom_style.html that allow for
+definition of finite-size particles: sphere, dipole, ellipsoid, line,
+tri, peri, and body.
+
+The sphere style defines particles that are spheriods and each
+particle can have a unique diameter and mass (or density).  These
+particles store an angular velocity (omega) and can be acted upon by
+torque.  The "set" command can be used to modify the diameter and mass
+of individual particles, after then are created.
+
+The dipole style does not actually define finite-size particles, but
+is often used in conjunction with spherical particles, via a command
+like
+
+atom_style hybrid sphere dipole :pre
+
+This is because when dipoles interact with each other, they induce
+torques, and a particle must be finite-size (i.e. have a moment of
+inertia) in order to respond and rotate.  See the "atom_style
+dipole"_atom_style.html command for details.  The "set" command can be
+used to modify the orientation and length of the dipole moment of
+individual particles, after then are created.
+
+The ellipsoid style defines particles that are ellipsoids and thus can
+be aspherical.  Each particle has a shape, specified by 3 diameters,
+and mass (or density).  These particles store an angular momentum and
+their orientation (quaternion), and can be acted upon by torque.  They
+do not store an angular velocity (omega), which can be in a different
+direction than angular momentum, rather they compute it as needed.
+The "set" command can be used to modify the diameter, orientation, and
+mass of individual particles, after then are created.  It also has a
+brief explanation of what quaternions are.
+
+The line style defines line segment particles with two end points and
+a mass (or density).  They can be used in 2d simulations, and they can
+be joined together to form rigid bodies which represent arbitrary
+polygons.
+
+The tri style defines triangular particles with three corner points
+and a mass (or density).  They can be used in 3d simulations, and they
+can be joined together to form rigid bodies which represent arbitrary
+particles with a triangulated surface.
+
+The peri style is used with "Peridynamic models"_pair_peri.html and
+defines particles as having a volume, that is used internally in the
+"pair_style peri"_pair_peri.html potentials.
+
+The body style allows for definition of particles which can represent
+complex entities, such as surface meshes of discrete points,
+collections of sub-particles, deformable objects, etc.  The body style
+is discussed in more detail on the "Howto body"_Howto_body.html doc
+page.
+
+Note that if one of these atom styles is used (or multiple styles via
+the "atom_style hybrid"_atom_style.html command), not all particles in
+the system are required to be finite-size or aspherical.
+
+For example, in the ellipsoid style, if the 3 shape parameters are set
+to the same value, the particle will be a sphere rather than an
+ellipsoid.  If the 3 shape parameters are all set to 0.0 or if the
+diameter is set to 0.0, it will be a point particle.  In the line or
+tri style, if the lineflag or triflag is specified as 0, then it
+will be a point particle.
+
+Some of the pair styles used to compute pairwise interactions between
+finite-size particles also compute the correct interaction with point
+particles as well, e.g. the interaction between a point particle and a
+finite-size particle or between two point particles.  If necessary,
+"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
+interactions are computed for the appropriate style of interactions.
+Likewise, using groups to partition particles (ellipsoids versus
+spheres versus point particles) will allow you to use the appropriate
+time integrators and temperature computations for each class of
+particles.  See the doc pages for various commands for details.
+
+Also note that for "2d simulations"_dimension.html, atom styles sphere
+and ellipsoid still use 3d particles, rather than as circular disks or
+ellipses.  This means they have the same moment of inertia as the 3d
+object.  When temperature is computed, the correct degrees of freedom
+are used for rotation in a 2d versus 3d system.
+
+Pair potentials :h4
+
+When a system with finite-size particles is defined, the particles
+will only rotate and experience torque if the force field computes
+such interactions.  These are the various "pair
+styles"_pair_style.html that generate torque:
+
+"pair_style gran/history"_pair_gran.html
+"pair_style gran/hertzian"_pair_gran.html
+"pair_style gran/no_history"_pair_gran.html
+"pair_style dipole/cut"_pair_dipole.html
+"pair_style gayberne"_pair_gayberne.html
+"pair_style resquared"_pair_resquared.html
+"pair_style brownian"_pair_brownian.html
+"pair_style lubricate"_pair_lubricate.html
+"pair_style line/lj"_pair_line_lj.html
+"pair_style tri/lj"_pair_tri_lj.html
+"pair_style body/nparticle"_pair_body_nparticle.html :ul
+
+The granular pair styles are used with spherical particles.  The
+dipole pair style is used with the dipole atom style, which could be
+applied to spherical or ellipsoidal particles.  The GayBerne and
+REsquared potentials require ellipsoidal particles, though they will
+also work if the 3 shape parameters are the same (a sphere).  The
+Brownian and lubrication potentials are used with spherical particles.
+The line, tri, and body potentials are used with line segment,
+triangular, and body particles respectively.
+
+Time integration :h4
+
+There are several fixes that perform time integration on finite-size
+spherical particles, meaning the integrators update the rotational
+orientation and angular velocity or angular momentum of the particles:
+
+"fix nve/sphere"_fix_nve_sphere.html
+"fix nvt/sphere"_fix_nvt_sphere.html
+"fix npt/sphere"_fix_npt_sphere.html :ul
+
+Likewise, there are 3 fixes that perform time integration on
+ellipsoidal particles:
+
+"fix nve/asphere"_fix_nve_asphere.html
+"fix nvt/asphere"_fix_nvt_asphere.html
+"fix npt/asphere"_fix_npt_asphere.html :ul
+
+The advantage of these fixes is that those which thermostat the
+particles include the rotational degrees of freedom in the temperature
+calculation and thermostatting.  The "fix langevin"_fix_langevin
+command can also be used with its {omgea} or {angmom} options to
+thermostat the rotational degrees of freedom for spherical or
+ellipsoidal particles.  Other thermostatting fixes only operate on the
+translational kinetic energy of finite-size particles.
+
+These fixes perform constant NVE time integration on line segment,
+triangular, and body particles:
+
+"fix nve/line"_fix_nve_line.html
+"fix nve/tri"_fix_nve_tri.html
+"fix nve/body"_fix_nve_body.html :ul
+
+Note that for mixtures of point and finite-size particles, these
+integration fixes can only be used with "groups"_group.html which
+contain finite-size particles.
+
+Computes, thermodynamics, and dump output :h4
+
+There are several computes that calculate the temperature or
+rotational energy of spherical or ellipsoidal particles:
+
+"compute temp/sphere"_compute_temp_sphere.html
+"compute temp/asphere"_compute_temp_asphere.html
+"compute erotate/sphere"_compute_erotate_sphere.html
+"compute erotate/asphere"_compute_erotate_asphere.html :ul
+
+These include rotational degrees of freedom in their computation.  If
+you wish the thermodynamic output of temperature or pressure to use
+one of these computes (e.g. for a system entirely composed of
+finite-size particles), then the compute can be defined and the
+"thermo_modify"_thermo_modify.html command used.  Note that by default
+thermodynamic quantities will be calculated with a temperature that
+only includes translational degrees of freedom.  See the
+"thermo_style"_thermo_style.html command for details.
+
+These commands can be used to output various attributes of finite-size
+particles:
+
+"dump custom"_dump.html
+"compute property/atom"_compute_property_atom.html
+"dump local"_dump.html
+"compute body/local"_compute_body_local.html :ul
+
+Attributes include the dipole moment, the angular velocity, the
+angular momentum, the quaternion, the torque, the end-point and
+corner-point coordinates (for line and tri particles), and
+sub-particle attributes of body particles.
+
+Rigid bodies composed of finite-size particles :h4
+
+The "fix rigid"_fix_rigid.html command treats a collection of
+particles as a rigid body, computes its inertia tensor, sums the total
+force and torque on the rigid body each timestep due to forces on its
+constituent particles, and integrates the motion of the rigid body.
+
+If any of the constituent particles of a rigid body are finite-size
+particles (spheres or ellipsoids or line segments or triangles), then
+their contribution to the inertia tensor of the body is different than
+if they were point particles.  This means the rotational dynamics of
+the rigid body will be different.  Thus a model of a dimer is
+different if the dimer consists of two point masses versus two
+spheroids, even if the two particles have the same mass.  Finite-size
+particles that experience torque due to their interaction with other
+particles will also impart that torque to a rigid body they are part
+of.
+
+See the "fix rigid" command for example of complex rigid-body models
+it is possible to define in LAMMPS.
+
+Note that the "fix shake"_fix_shake.html command can also be used to
+treat 2, 3, or 4 particles as a rigid body, but it always assumes the
+particles are point masses.
+
+Also note that body particles cannot be modeled with the "fix
+rigid"_fix_rigid.html command.  Body particles are treated by LAMMPS
+as single particles, though they can store internal state, such as a
+list of sub-particles.  Individual body partices are typically treated
+as rigid bodies, and their motion integrated with a command like "fix
+nve/body"_fix_nve_body.html.  Interactions between pairs of body
+particles are computed via a command like "pair_style
+body/nparticle"_pair_body_nparticle.html.

doc/src/Howto_spins.txt

@@ -0,0 +1,59 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Magnetic spins :h3
+
+The magnetic spin simualtions are enabled by the SPIN package, whose
+implementation is detailed in "Tranchida"_#Tranchida7.
+
+The model representents the simulation of atomic magnetic spins coupled 
+to lattice vibrations. The dynamics of those magnetic spins can be used 
+to simulate a broad range a phenomena related to magneto-elasticity, or 
+or to study the influence of defects on the magnetic properties of 
+materials. 
+
+The magnetic spins are interacting with each others and with the 
+lattice via pair interactions. Typically, the magnetic exchange 
+interaction can be defined using the 
+"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
+applies a magnetic torque to a given spin, considering the orientation
+of its neighboring spins and their relative distances. 
+It also applies a force on the atoms as a function of the spin 
+orientations and their associated inter-atomic distances. 
+ 
+The command "fix precession/spin"_fix_precession_spin.html allows to
+apply a constant magnetic torque on all the spins in the system. This
+torque can be an external magnetic field (Zeeman interaction), or an
+uniaxial magnetic anisotropy. 
+
+A Langevin thermostat can be applied to those magnetic spins using 
+"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat 
+can be coupled to another Langevin thermostat applied to the atoms 
+using "fix langevin"_fix_langevin.html in order to simulate 
+thermostated spin-lattice system. 
+
+The magnetic Gilbert damping can also be applied using "fix 
+langevin/spin"_fix_langevin_spin.html. It allows to either dissipate 
+the thermal energy of the Langevin thermostat, or to perform a 
+relaxation of the magnetic configuration toward an equilibrium state.
+
+All the computed magnetic properties can be outputed by two main 
+commands. The first one is "compute spin"_compute_spin.html, that 
+enables to evaluate magnetic averaged quantities, such as the total 
+magnetization of the system along x, y, or z, the spin temperature, or
+the magnetic energy. The second command is "compute 
+property/atom"_compute_property_atom.html. It enables to output all the
+per atom magnetic quantities. Typically, the orientation of a given 
+magnetic spin, or the magnetic force acting on this spin.
+
+:line
+
+:link(Tranchida7)
+[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson, 
+arXiv preprint arXiv:1801.10233, (2018).

doc/src/Howto_temperature.txt

@@ -0,0 +1,40 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calcalate temperature :h3
+
+Temperature is computed as kinetic energy divided by some number of
+degrees of freedom (and the Boltzmann constant).  Since kinetic energy
+is a function of particle velocity, there is often a need to
+distinguish between a particle's advection velocity (due to some
+aggregate motion of particles) and its thermal velocity.  The sum of
+the two is the particle's total velocity, but the latter is often what
+is wanted to compute a temperature.
+
+LAMMPS has several options for computing temperatures, any of which can be used in "thermostatting"_Howto_thermostat.html and "barostatting"_Howto_barostat.html.  These "compute commands"_compute.html calculate temperature:
+
+"compute temp"_compute_temp.html
+"compute temp/sphere"_compute_temp_sphere.html
+"compute temp/asphere"_compute_temp_asphere.html
+"compute temp/com"_compute_temp_com.html
+"compute temp/deform"_compute_temp_deform.html
+"compute temp/partial"_compute_temp_partial.html
+"compute temp/profile"_compute_temp_profile.html
+"compute temp/ramp"_compute_temp_ramp.html
+"compute temp/region"_compute_temp_region.html :ul
+
+All but the first 3 calculate velocity biases directly (e.g. advection
+velocities) that are removed when computing the thermal temperature.
+"Compute temp/sphere"_compute_temp_sphere.html and "compute
+temp/asphere"_compute_temp_asphere.html compute kinetic energy for
+finite-size particles that includes rotational degrees of freedom.
+They both allow for velocity biases indirectly, via an optional extra
+argument which is another temperature compute that subtracts a velocity bias.
+This allows the translational velocity of spherical or aspherical
+particles to be adjusted in prescribed ways.

doc/src/Howto_thermostat.txt

@@ -0,0 +1,89 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Thermostats :h3
+
+Thermostatting means controlling the temperature of particles in an MD
+simulation.  "Barostatting"_Howto_barostat.html means controlling the
+pressure.  Since the pressure includes a kinetic component due to
+particle velocities, both these operations require calculation of the
+temperature.  Typically a target temperature (T) and/or pressure (P)
+is specified by the user, and the thermostat or barostat attempts to
+equilibrate the system to the requested T and/or P.
+
+Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
+case by a pair style.  Several thermostatting fixes are available:
+Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
+(temp/rescale).  Dissipative particle dynamics (DPD) thermostatting
+can be invoked via the {dpd/tstat} pair style:
+
+"fix nvt"_fix_nh.html
+"fix nvt/sphere"_fix_nvt_sphere.html
+"fix nvt/asphere"_fix_nvt_asphere.html
+"fix nvt/sllod"_fix_nvt_sllod.html
+"fix temp/berendsen"_fix_temp_berendsen.html
+"fix temp/csvr"_fix_temp_csvr.html
+"fix langevin"_fix_langevin.html
+"fix temp/rescale"_fix_temp_rescale.html
+"pair_style dpd/tstat"_pair_dpd.html :ul
+
+"Fix nvt"_fix_nh.html only thermostats the translational velocity of
+particles.  "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
+that it subtracts out a velocity bias due to a deforming box and
+integrates the SLLOD equations of motion.  See the "Howto
+nemd"_Howto_nemd.html doc page for further details.  "Fix
+nvt/sphere"_fix_nvt_sphere.html and "fix
+nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
+velocities but also rotational velocities for spherical and aspherical
+particles.
+
+DPD thermostatting alters pairwise interactions in a manner analogous
+to the per-particle thermostatting of "fix
+langevin"_fix_langevin.html.
+
+Any of the thermostatting fixes can use "temperature
+computes"_Howto_thermostat.html that remove bias which has two
+effects.  First, the current calculated temperature, which is compared
+to the requested target temperature, is calculated with the velocity
+bias removed.  Second, the thermostat adjusts only the thermal
+temperature component of the particle's velocities, which are the
+velocities with the bias removed.  The removed bias is then added back
+to the adjusted velocities.  See the doc pages for the individual
+fixes and for the "fix_modify"_fix_modify.html command for
+instructions on how to assign a temperature compute to a
+thermostatting fix.  For example, you can apply a thermostat to only
+the x and z components of velocity by using it in conjunction with
+"compute temp/partial"_compute_temp_partial.html.  Of you could
+thermostat only the thermal temperature of a streaming flow of
+particles without affecting the streaming velocity, by using "compute
+temp/profile"_compute_temp_profile.html.
+
+NOTE: Only the nvt fixes perform time integration, meaning they update
+the velocities and positions of particles due to forces and velocities
+respectively.  The other thermostat fixes only adjust velocities; they
+do NOT perform time integration updates.  Thus they should be used in
+conjunction with a constant NVE integration fix such as these:
+
+"fix nve"_fix_nve.html
+"fix nve/sphere"_fix_nve_sphere.html
+"fix nve/asphere"_fix_nve_asphere.html :ul
+
+Thermodynamic output, which can be setup via the
+"thermo_style"_thermo_style.html command, often includes temperature
+values.  As explained on the doc page for the
+"thermo_style"_thermo_style.html command, the default temperature is
+setup by the thermo command itself.  It is NOT the temperature
+associated with any thermostatting fix you have defined or with any
+compute you have defined that calculates a temperature.  The doc pages
+for the thermostatting fixes explain the ID of the temperature compute
+they create.  Thus if you want to view these temperatures, you need to
+specify them explicitly via the "thermo_style
+custom"_thermo_style.html command.  Or you can use the
+"thermo_modify"_thermo_modify.html command to re-define what
+temperature compute is used for default thermodynamic output.

doc/src/Howto_tip3p.txt

@@ -0,0 +1,69 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+TIP3P water model :h3
+
+The TIP3P water model as implemented in CHARMM
+"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
+charges and Lennard-Jones parameters assigned to each of the 3 atoms.
+In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
+the two O-H bonds and the H-O-H angle rigid.  A bond style of
+{harmonic} and an angle style of {harmonic} or {charmm} should also be
+used.
+
+These are the additional parameters (in real units) to set for O and H
+atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
+cutoff.  The K values can be used if a flexible TIP3P model (without
+fix shake) is desired.  If the LJ epsilon and sigma for HH and OH are
+set to 0.0, it corresponds to the original 1983 TIP3P model
+"(Jorgensen)"_#Jorgensen1.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.834
+H charge = 0.417
+LJ epsilon of OO = 0.1521
+LJ sigma of OO = 3.1507
+LJ epsilon of HH = 0.0460
+LJ sigma of HH = 0.4000
+LJ epsilon of OH = 0.0836
+LJ sigma of OH = 1.7753
+K of OH bond = 450
+r0 of OH bond = 0.9572
+K of HOH angle = 55
+theta of HOH angle = 104.52 :all(b),p
+
+These are the parameters to use for TIP3P with a long-range Coulombic
+solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
+details:
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.830
+H charge = 0.415
+LJ epsilon of OO = 0.102
+LJ sigma of OO = 3.188
+LJ epsilon, sigma of OH, HH = 0.0
+K of OH bond = 450
+r0 of OH bond = 0.9572
+K of HOH angle = 55
+theta of HOH angle = 104.52 :all(b),p
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(Jorgensen1)
+[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
+Phys, 79, 926 (1983).
+
+:link(Price1)
+[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
+

doc/src/Howto_tip4p.txt

@@ -0,0 +1,112 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+TIP4P water model :h3
+
+The four-point TIP4P rigid water model extends the traditional
+three-point TIP3P model by adding an additional site, usually
+massless, where the charge associated with the oxygen atom is placed.
+This site M is located at a fixed distance away from the oxygen along
+the bisector of the HOH bond angle.  A bond style of {harmonic} and an
+angle style of {harmonic} or {charmm} should also be used.
+
+A TIP4P model is run with LAMMPS using either this command
+for a cutoff model:
+
+"pair_style lj/cut/tip4p/cut"_pair_lj.html
+
+or these two commands for a long-range model:
+
+"pair_style lj/cut/tip4p/long"_pair_lj.html
+"kspace_style pppm/tip4p"_kspace_style.html :ul
+
+For both models, the bond lengths and bond angles should be held fixed
+using the "fix shake"_fix_shake.html command.
+
+These are the additional parameters (in real units) to set for O and H
+atoms and the water molecule to run a rigid TIP4P model with a cutoff
+"(Jorgensen)"_#Jorgensen1.  Note that the OM distance is specified in
+the "pair_style"_pair_style.html command, not as part of the pair
+coefficients.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.040
+H charge = 0.520
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.15
+LJ epsilon of O-O = 0.1550
+LJ sigma of O-O = 3.1536
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
+http://dx.doi.org/10.1063/1.1931662) these values can be used:
+
+O mass = 15.9994
+H mass =  1.008
+O charge = -1.1794
+H charge =  0.5897
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1577
+LJ epsilon of O-O = 0.21084
+LJ sigma of O-O = 3.1668
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
+http://dx.doi.org/10.1063/1.2121687), these values can be used:
+
+O mass = 15.9994
+H mass =  1.008
+O charge = -1.1128
+H charge = 0.5564
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1546
+LJ epsilon of O-O = 0.1852
+LJ sigma of O-O = 3.1589
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+These are the parameters to use for TIP4P with a long-range Coulombic
+solver (e.g. Ewald or PPPM in LAMMPS):
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.0484
+H charge = 0.5242
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1250
+LJ epsilon of O-O = 0.16275
+LJ sigma of O-O = 3.16435
+LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
+
+Note that the when using the TIP4P pair style, the neighbor list
+cutoff for Coulomb interactions is effectively extended by a distance
+2 * (OM distance), to account for the offset distance of the
+fictitious charges on O atoms in water molecules.  Thus it is
+typically best in an efficiency sense to use a LJ cutoff >= Coulomb
+cutoff + 2*(OM distance), to shrink the size of the neighbor list.
+This leads to slightly larger cost for the long-range calculation, so
+you can test the trade-off for your model.  The OM distance and the LJ
+and Coulombic cutoffs are set in the "pair_style
+lj/cut/tip4p/long"_pair_lj.html command.
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(Jorgensen1)
+[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
+Phys, 79, 926 (1983).

doc/src/Howto_triclinic.txt

@@ -0,0 +1,213 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+Triclinic (non-orthogonal) simulation boxes :h3
+
+By default, LAMMPS uses an orthogonal simulation box to encompass the
+particles.  The "boundary"_boundary.html command sets the boundary
+conditions of the box (periodic, non-periodic, etc).  The orthogonal
+box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
+starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
+(0,yhi-ylo,0); [c] = (0,0,zhi-zlo).  The 6 parameters
+(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
+is created, e.g. by the "create_box"_create_box.html or
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands.  Additionally, LAMMPS defines box size parameters lx,ly,lz
+where lx = xhi-xlo, and similarly in the y and z dimensions.  The 6
+parameters, as well as lx,ly,lz, can be output via the "thermo_style
+custom"_thermo_style.html command.
+
+LAMMPS also allows simulations to be performed in triclinic
+(non-orthogonal) simulation boxes shaped as a parallelepiped with
+triclinic symmetry.  The parallelepiped has its "origin" at
+(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
+origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
+(xz,yz,zhi-zlo).  {xy,xz,yz} can be 0.0 or positive or negative values
+and are called "tilt factors" because they are the amount of
+displacement applied to faces of an originally orthogonal box to
+transform it into the parallelepiped.  In LAMMPS the triclinic
+simulation box edge vectors [a], [b], and [c] cannot be arbitrary
+vectors.  As indicated, [a] must lie on the positive x axis.  [b] must
+lie in the xy plane, with strictly positive y component. [c] may have
+any orientation with strictly positive z component.  The requirement
+that [a], [b], and [c] have strictly positive x, y, and z components,
+respectively, ensures that [a], [b], and [c] form a complete
+right-handed basis.  These restrictions impose no loss of generality,
+since it is possible to rotate/invert any set of 3 crystal basis
+vectors so that they conform to the restrictions.
+
+For example, assume that the 3 vectors [A],[B],[C] are the edge
+vectors of a general parallelepiped, where there is no restriction on
+[A],[B],[C] other than they form a complete right-handed basis i.e.
+[A] x [B] . [C] > 0.  The equivalent LAMMPS [a],[b],[c] are a linear
+rotation of [A], [B], and [C] and can be computed as follows:
+
+:c,image(Eqs/transform.jpg)
+
+where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
+indicates the corresponding unit vector. {beta} and {gamma} are angles
+between the vectors described below. Note that by construction,
+[a], [b], and [c] have strictly positive x, y, and z components, respectively.
+If it should happen that
+[A], [B], and [C] form a left-handed basis, then the above equations
+are not valid for [c]. In this case, it is necessary
+to first apply an inversion. This can be achieved
+by interchanging two basis vectors or by changing the sign of one of them.
+
+For consistency, the same rotation/inversion applied to the basis vectors
+must also be applied to atom positions, velocities,
+and any other vector quantities.
+This can be conveniently achieved by first converting to
+fractional coordinates in the
+old basis and then converting to distance coordinates in the new basis.
+The transformation is given by the following equation:
+
+:c,image(Eqs/rotate.jpg)
+
+where {V} is the volume of the box, [X] is the original vector quantity and
+[x] is the vector in the LAMMPS basis.
+
+There is no requirement that a triclinic box be periodic in any
+dimension, though it typically should be in at least the 2nd dimension
+of the tilt (y in xy) if you want to enforce a shift in periodic
+boundary conditions across that boundary.  Some commands that work
+with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
+npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
+boundary conditions in specific dimensions.  See the command doc pages
+for details.
+
+The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
+time the simulation box is created.  This happens in one of 3 ways.
+If the "create_box"_create_box.html command is used with a region of
+style {prism}, then a triclinic box is setup.  See the
+"region"_region.html command for details.  If the
+"read_data"_read_data.html command is used to define the simulation
+box, and the header of the data file contains a line with the "xy xz
+yz" keyword, then a triclinic box is setup.  See the
+"read_data"_read_data.html command for details.  Finally, if the
+"read_restart"_read_restart.html command reads a restart file which
+was written from a simulation using a triclinic box, then a triclinic
+box will be setup for the restarted simulation.
+
+Note that you can define a triclinic box with all 3 tilt factors =
+0.0, so that it is initially orthogonal.  This is necessary if the box
+will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
+"fix deform"_fix_deform.html commands.  Alternatively, you can use the
+"change_box"_change_box.html command to convert a simulation box from
+orthogonal to triclinic and vice versa.
+
+As with orthogonal boxes, LAMMPS defines triclinic box size parameters
+lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
+The 9 parameters, as well as lx,ly,lz, can be output via the
+"thermo_style custom"_thermo_style.html command.
+
+To avoid extremely tilted boxes (which would be computationally
+inefficient), LAMMPS normally requires that no tilt factor can skew
+the box more than half the distance of the parallel box length, which
+is the 1st dimension in the tilt factor (x for xz).  This is required
+both when the simulation box is created, e.g. via the
+"create_box"_create_box.html or "read_data"_read_data.html commands,
+as well as when the box shape changes dynamically during a simulation,
+e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
+commands.
+
+For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
+the xy tilt factor must be between -5 and 5.  Similarly, both xz and
+yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2.  Note that this is
+not a limitation, since if the maximum tilt factor is 5 (as in this
+example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
+... are geometrically all equivalent.  If the box tilt exceeds this
+limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
+command), then the box is "flipped" to an equivalent shape with a tilt
+factor within the bounds, so the run can continue.  See the "fix
+deform"_fix_deform.html doc page for further details.
+
+One exception to this rule is if the 1st dimension in the tilt
+factor (x for xy) is non-periodic.  In that case, the limits on the
+tilt factor are not enforced, since flipping the box in that dimension
+does not change the atom positions due to non-periodicity.  In this
+mode, if you tilt the system to extreme angles, the simulation will
+simply become inefficient, due to the highly skewed simulation box.
+
+The limitation on not creating a simulation box with a tilt factor
+skewing the box more than half the distance of the parallel box length
+can be overridden via the "box"_box.html command.  Setting the {tilt}
+keyword to {large} allows any tilt factors to be specified.
+
+Box flips that may occur using the "fix deform"_fix_deform.html or
+"fix npt"_fix_nh.html commands can be turned off using the {flip no}
+option with either of the commands.
+
+Note that if a simulation box has a large tilt factor, LAMMPS will run
+less efficiently, due to the large volume of communication needed to
+acquire ghost atoms around a processor's irregular-shaped sub-domain.
+For extreme values of tilt, LAMMPS may also lose atoms and generate an
+error.
+
+Triclinic crystal structures are often defined using three lattice
+constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
+{gamma}. Note that in this nomenclature, the a, b, and c lattice
+constants are the scalar lengths of the edge vectors [a], [b], and [c]
+defined above.  The relationship between these 6 quantities
+(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
+(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
+
+:c,image(Eqs/box.jpg)
+
+The inverse relationship can be written as follows:
+
+:c,image(Eqs/box_inverse.jpg)
+
+The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
+out or accessed by computes using the
+"thermo_style custom"_thermo_style.html keywords
+{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
+respectively.
+
+As discussed on the "dump"_dump.html command doc page, when the BOX
+BOUNDS for a snapshot is written to a dump file for a triclinic box,
+an orthogonal bounding box which encloses the triclinic simulation box
+is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
+box, formatted as follows:
+
+ITEM: BOX BOUNDS xy xz yz
+xlo_bound xhi_bound xy
+ylo_bound yhi_bound xz
+zlo_bound zhi_bound yz :pre
+
+This bounding box is convenient for many visualization programs and is
+calculated from the 9 triclinic box parameters
+(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
+
+xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
+xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
+ylo_bound = ylo + MIN(0.0,yz)
+yhi_bound = yhi + MAX(0.0,yz)
+zlo_bound = zlo
+zhi_bound = zhi :pre
+
+These formulas can be inverted if you need to convert the bounding box
+back into the triclinic box parameters, e.g. xlo = xlo_bound -
+MIN(0.0,xy,xz,xy+xz).
+
+One use of triclinic simulation boxes is to model solid-state crystals
+with triclinic symmetry.  The "lattice"_lattice.html command can be
+used with non-orthogonal basis vectors to define a lattice that will
+tile a triclinic simulation box via the
+"create_atoms"_create_atoms.html command.
+
+A second use is to run Parinello-Rahman dynamics via the "fix
+npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
+factors to compensate for off-diagonal components of the pressure
+tensor.  The analog for an "energy minimization"_minimize.html is
+the "fix box/relax"_fix_box_relax.html command.
+
+A third use is to shear a bulk solid to study the response of the
+material.  The "fix deform"_fix_deform.html command can be used for
+this purpose.  It allows dynamic control of the xy, xz, yz tilt
+factors as a simulation runs.  This is discussed in the next section
+on non-equilibrium MD (NEMD) simulations.

doc/src/Howto_viscosity.txt

@@ -0,0 +1,133 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate viscosity :h3
+
+The shear viscosity eta of a fluid can be measured in at least 5 ways
+using various options in LAMMPS.  See the examples/VISCOSITY directory
+for scripts that implement the 5 methods discussed here for a simple
+Lennard-Jones fluid model.  Also, see the "Howto
+kappa"_Howto_kappa.html doc page for an analogous discussion for
+thermal conductivity.
+
+Eta is a measure of the propensity of a fluid to transmit momentum in
+a direction perpendicular to the direction of velocity or momentum
+flow.  Alternatively it is the resistance the fluid has to being
+sheared.  It is given by
+
+J = -eta grad(Vstream)
+
+where J is the momentum flux in units of momentum per area per time.
+and grad(Vstream) is the spatial gradient of the velocity of the fluid
+moving in another direction, normal to the area through which the
+momentum flows.  Viscosity thus has units of pressure-time.
+
+The first method is to perform a non-equilibrium MD (NEMD) simulation
+by shearing the simulation box via the "fix deform"_fix_deform.html
+command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
+thermostat the fluid via the SLLOD equations of motion.
+Alternatively, as a second method, one or more moving walls can be
+used to shear the fluid in between them, again with some kind of
+thermostat that modifies only the thermal (non-shearing) components of
+velocity to prevent the fluid from heating up.
+
+In both cases, the velocity profile setup in the fluid by this
+procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
+command, which determines grad(Vstream) in the equation above.
+E.g. the derivative in the y-direction of the Vx component of fluid
+motion or grad(Vstream) = dVx/dy.  The Pxy off-diagonal component of
+the pressure or stress tensor, as calculated by the "compute
+pressure"_compute_pressure.html command, can also be monitored, which
+is the J term in the equation above.  See the "Howto
+nemd"_Howto_nemd.html doc page for details on NEMD simulations.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the "fix viscosity"_fix_viscosity.html command which implements
+the rNEMD algorithm of Muller-Plathe.  Momentum in one dimension is
+swapped between atoms in two different layers of the simulation box in
+a different dimension.  This induces a velocity gradient which can be
+monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
+The fix tallies the cumulative momentum transfer that it performs.
+See the "fix viscosity"_fix_viscosity.html command for details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the
+stress/pressure tensor to eta.  This can be done in a fully
+equilibrated simulation which is in contrast to the two preceding
+non-equilibrium methods, where momentum flows continuously through the
+simulation box.
+
+Here is an example input script that calculates the viscosity of
+liquid Ar via the GK formalism:
+
+# Sample LAMMPS input script for viscosity of liquid Ar :pre
+
+units       real
+variable    T equal 86.4956
+variable    V equal vol
+variable    dt equal 4.0
+variable    p equal 400     # correlation length
+variable    s equal 5       # sample interval
+variable    d equal $p*$s   # dump interval :pre
+
+# convert from LAMMPS real units to SI :pre
+
+variable    kB equal 1.3806504e-23    # \[J/K/] Boltzmann
+variable    atm2Pa equal 101325.0
+variable    A2m equal 1.0e-10
+variable    fs2s equal 1.0e-15
+variable    convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
+
+# setup problem :pre
+
+dimension    3
+boundary     p p p
+lattice      fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
+region       box block 0 4 0 4 0 4
+create_box   1 box
+create_atoms 1 box
+mass         1 39.948
+pair_style   lj/cut 13.0
+pair_coeff   * * 0.2381 3.405
+timestep     $\{dt\}
+thermo       $d :pre
+
+# equilibration and thermalization :pre
+
+velocity     all create $T 102486 mom yes rot yes dist gaussian
+fix          NVT all nvt temp $T $T 10 drag 0.2
+run          8000 :pre
+
+# viscosity calculation, switch to NVE if desired :pre
+
+#unfix       NVT
+#fix         NVE all nve :pre
+
+reset_timestep 0
+variable     pxy equal pxy
+variable     pxz equal pxz
+variable     pyz equal pyz
+fix          SS all ave/correlate $s $p $d &
+             v_pxy v_pxz v_pyz type auto file S0St.dat ave running
+variable     scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
+variable     v11 equal trap(f_SS\[3\])*$\{scale\}
+variable     v22 equal trap(f_SS\[4\])*$\{scale\}
+variable     v33 equal trap(f_SS\[5\])*$\{scale\}
+thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
+run          100000
+variable     v equal (v_v11+v_v22+v_v33)/3.0
+variable     ndens equal count(all)/vol
+print        "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
+
+The fifth method is related to the above Green-Kubo method,
+but uses the Einstein formulation, analogous to the Einstein
+mean-square-displacement formulation for self-diffusivity. The
+time-integrated momentum fluxes play the role of Cartesian
+coordinates, whose mean-square displacement increases linearly
+with time at sufficiently long times.

doc/src/Howto_viz.txt

@@ -0,0 +1,40 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Visualize LAMMPS snapshots :h3
+
+LAMMPS itself does not do visualization, but snapshots from LAMMPS
+simulations can be visualized (and analyzed) in a variety of ways.
+
+Mention dump image and dump movie.
+
+LAMMPS snapshots are created by the "dump"_dump.html command which can
+create files in several formats. The native LAMMPS dump format is a
+text file (see "dump atom" or "dump custom") which can be visualized
+by several popular visualization tools. The "dump
+image"_dump_image.html and "dump movie"_dump_image.html styles can
+output internally rendered images and convert a sequence of them to a
+movie during the MD run.  Several programs included with LAMMPS as
+auxiliary tools can convert between LAMMPS format files and other
+formats.  See the "Tools"_Tools.html doc page for details.
+
+A Python-based toolkit distributed by our group can read native LAMMPS
+dump files, including custom dump files with additional columns of
+user-specified atom information, and convert them to various formats
+or pipe them into visualization software directly.  See the "Pizza.py
+WWW site"_pizza for details.  Specifically, Pizza.py can convert
+LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
+Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
+RasMol visualization programs.  Pizza.py has tools that do interactive
+3d OpenGL visualization and one that creates SVG images of dump file
+snapshots.
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+:link(ensight,http://www.ensight.com)
+:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)

doc/src/Howto_walls.txt

@@ -0,0 +1,80 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Walls :h3
+
+Walls in an MD simulation are typically used to bound particle motion,
+i.e. to serve as a boundary condition.
+
+Walls in LAMMPS can be of rough (made of particles) or idealized
+surfaces.  Ideal walls can be smooth, generating forces only in the
+normal direction, or frictional, generating forces also in the
+tangential direction.
+
+Rough walls, built of particles, can be created in various ways.  The
+particles themselves can be generated like any other particle, via the
+"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
+or read in via the "read_data"_read_data.html command.
+
+Their motion can be constrained by many different commands, so that
+they do not move at all, move together as a group at constant velocity
+or in response to a net force acting on them, move in a prescribed
+fashion (e.g. rotate around a point), etc.  Note that if a time
+integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
+is not used with the group that contains wall particles, their
+positions and velocities will not be updated.
+
+"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
+"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
+"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
+"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
+"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
+
+The "fix move"_fix_move.html command offers the most generality, since
+the motion of individual particles can be specified with
+"variable"_variable.html formula which depends on time and/or the
+particle position.
+
+For rough walls, it may be useful to turn off pairwise interactions
+between wall particles via the "neigh_modify
+exclude"_neigh_modify.html command.
+
+Rough walls can also be created by specifying frozen particles that do
+not move and do not interact with mobile particles, and then tethering
+other particles to the fixed particles, via a "bond"_bond_style.html.
+The bonded particles do interact with other mobile particles.
+
+Idealized walls can be specified via several fix commands.  "Fix
+wall/gran"_fix_wall_gran.html creates frictional walls for use with
+granular particles; all the other commands create smooth walls.
+
+"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
+"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
+"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
+"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
+"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
+"fix wall/region"_fix_wall_region.html - use region surface as wall
+"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
+
+The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
+flat walls to move with a constant velocity, or oscillate in time.
+The "fix wall/region"_fix_wall_region.html command offers the most
+generality, since the region surface is treated as a wall, and the
+geometry of the region can be a simple primitive volume (e.g. a
+sphere, or cube, or plane), or a complex volume made from the union
+and intersection of primitive volumes.  "Regions"_region.html can also
+specify a volume "interior" or "exterior" to the specified primitive
+shape or {union} or {intersection}.  "Regions"_region.html can also be
+"dynamic" meaning they move with constant velocity, oscillate, or
+rotate.
+
+The only frictional idealized walls currently in LAMMPS are flat or
+curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
+command.  At some point we plan to allow regoin surfaces to be used as
+frictional walls, as well as triangulated surfaces.

doc/src/Intro.txt

@@ -0,0 +1,37 @@
+"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Install.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Introduction :h2
+
+These pages provide a brief introduction to LAMMPS.
+
+<!-- RST
+
+.. toctree::
+
+   Intro_overview
+   Intro_features
+   Intro_nonfeatures
+   Intro_opensource
+   Intro_authors
+   Intro_website
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview of LAMMPS"_Intro_overview.html
+"LAMMPS features"_Intro_features.html
+"LAMMPS non-features"_Intro_nonfeatures.html
+"LAMMPS open-source license"_Intro_license.html
+"LAMMPS authors"_Intro_authors.html
+"Additional website links"_Intro_website.html :all(b)
+
+<!-- END_HTML_ONLY -->

doc/src/Intro_authors.txt

@@ -0,0 +1,379 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS authors :h3
+
+The primary LAMMPS developers are at Sandia National Labs and Temple
+University:
+
+"Steve Plimpton"_sjp, sjplimp at sandia.gov
+Aidan Thompson, athomps at sandia.gov
+Stan Moore, stamoor at sandia.gov
+Axel Kohlmeyer, akohlmey at gmail.com :ul
+
+:link(sjp,http://www.cs.sandia.gov/~sjplimp)
+
+Past developers include Paul Crozier and Mark Stevens, both at Sandia,
+and Ray Shan, now at Materials Design.
+
+:line
+
+The following folks are responsible for significant contributions to
+the code, or other aspects of the LAMMPS development effort.  Many of
+the packages they have written are somewhat unique to LAMMPS and the
+code would not be as general-purpose as it is without their expertise
+and efforts.
+
+Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM, USER-OMP, USER-COLVARS, USER-MOLFILE, USER-QMMM packages
+Roy Pollock (LLNL), Ewald and PPPM solvers
+Mike Brown (ORNL), brownw at ornl.gov, GPU and USER-INTEL packages
+Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
+Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
+Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
+Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
+Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
+Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA and KOKKOS packages
+Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
+Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling
+Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
+Georg Gunzenmueller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SMD and USER-SPH packages
+Colin Denniston (U Western Ontario), cdennist at uwo.ca, USER-LB package :ul
+
+:line
+
+As discussed on the "History
+page"_http://lammps.sandia.gov/history.html of the website, LAMMPS
+originated as a cooperative project between DOE labs and industrial
+partners.  Folks involved in the design and testing of the original
+version of LAMMPS were the following:
+    
+John Carpenter (Mayo Clinic, formerly at Cray Research)
+Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
+Steve Lustig (Dupont)
+Jim Belak and Roy Pollock (LLNL) :ul
+
+:line
+:line
+
+Here is a timeline for when various individuals contributed to a new
+feature or command or tool added to LAMMPS:
+
+Jul18 : DEM polygonal and polyhedron particles : Trung Nguyen (Northwestern U)
+Jun18 : SPIN package : Julien Tranchida (Sandia and CEA)
+Jun18 : compute entropy/atom : Pablo Piaggi (EPLF, Switzerland)
+May18 : fix bond/react : Jake Gissinger (CU Boulder)
+Apr18 : USER-BOCS package : Nicholas Dunn and Michael DeLyser (Penn State U)
+Mar18: pair coul/shield, kolmogorov/crespi/full, ilp/graphene/hbn : Wengen Ouyang (Tel Aviv U) 
+Feb18 : pair lj/cut/coul/wolf : Vishal Boddu (U of Erlangen-Nuremberg)
+Feb18 : USER-MOFFF package : Hendrik Heenen (Technical U of Munich) and Rochus Schmid (Ruhr-University Bochum)
+Feb18 : pair ufm : Rodolfo Paula Leite and Maurice de Koning (Unicamp/Brazil)
+Dec17 : fix python/move : Richard Berger (Temple U)
+Nov17 : pair extep : Jaap Kroes (Radboud U)
+Oct17 : USER-UEF package : David Nicholson (MIT)
+Oct17 : fix rhok : Ulf Pederson (Roskilde U)
+Oct17 : bond gromos : Axel Kohlmeyer (Temple U)
+Oct17 : pair born/coul/wolf/cs and coul/wolf/cs : Vishal Boddu
+Sep17 : fix latte : Christian Negre (LANL)
+Sep17 : temper_npt : Amulya Pervaje and Cody Addington (NCSU)
+Aug17 : USER-MESO package : Zhen Li (Brown University)
+Aug17 : compute aggregate/atom & fragment/atom : Axel Kohlmeyer (Temple U)
+Jul17 : pair meam/c : Sebastian Hutter (Otto-von-Guericke University)
+Jun17 : pair reaxc/omp : Metin Aktulga (MSU) and Axel Kohlmeyer (Temple U)
+Jun17 : pair vashishita/gpu : Anders Hafreager (UiO)
+Jun17 : kspace pppm/disp/intel and pair lj/long/coul/long/intel : Mike Brown (Intel) and William McDoniel (RWTH Aachen U)
+Jun17 : compute cnp/atom : Paulo Branicio (USC)
+May17 : fix python and pair python : Richard Berger (Temple U)
+May17 : pair edip/multi : Chao Jiang (U Wisconsin)
+May17 : pair gw and gw/zbl : German Samolyuk (ORNL)
+Mar17 : pair charmm fsw and fsh : Robert Meissner & Lucio Colombi Ciacchi (Bremen U), Robert Latour (Clemson U)
+Mar17 : pair momb : Ya Zhou, Kristen Fichthorn, and Tonnam Balankura (PSU)
+Mar17 : fix filter/corotate : Lukas Fath (KIT)
+Mar17 : pair kolmogorov/crespi/z : Jaap Kroes (Radboud Universiteit)
+Feb17 : Kokkos versions of the class2 bond/angle/dihedral/improper : Ray Shan (Materials Design)
+Jan17 : USER-CGDNA package : Oliver Henrich (U Edinburgh)
+Jan17 : fix mscg : Lauren Abbott (Sandia)
+Nov16 : temper/grem and fix grem : David Stelter (BU), Edyta Malolepsza (Broad Institute), Tom Keyes (BU)
+Nov16 : pair agni : Axel Kohlmeyer (Temple U) and Venkatesh Botu
+Nov16 : pair tersoff/mod.c : Ganga P Purja Pun (George Mason University)
+Nov16 : pair born/coul/dsf and pair born/coul/dsf/cs : Ariel Lozano
+Nov16 : fix reaxc/species/kk & fix reaxc/bonds/kk : Stan Moore (Sandia)
+Oct16 : fix wall/gran/region : Dan Bolintineanu (Sandia)
+Sep16 : weight options for balance & fix balance : Axel Kohlmeyer (Temple U) & Iain Bethune (EPCC)
+Sep16 : fix cmap : Xiaohu Hu (ORNL), David Hyde-Volpe & Tigran Abramyan & Robert Latour (Clemson U), Chris Lorenz (Kings College, London)
+Sep16 : pair vashishta/table : Anders Hafreager (U Oslo)
+Sep16 : kspace pppm/kk : Stan Moore (Sandia)
+Aug16 : fix flow/gauss : Steve Strong and Joel Eaves (U Colorado)
+Aug16 : fix controller : Aidan Thompson (Sandia)
+Jul16 : dipole integration by DLM method : Iain Bethune (EPCC)
+Jul16 : dihedral spherical : Andrew Jewett
+Jun16 : pair reax/c/kk : Ray Shan (Materials Design), Stan Moore (Sandia)
+Jun16 : fix orient/bcc : Tegar Wicaksono (UBC) 
+Jun16 : fix ehex : Peter Wirnsberger (University of Cambridge)
+Jun16 : reactive DPD extensions to USER-DPD : James Larentzos (ARL), Timothy Mattox (Engility Corp), John Brennan (ARL), Christopher Stone (Computational Science & Engineering, LLC)
+May16 : USER-MANIFOLD package : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
+Apr16 : write_coeff : Axel Kohlmeyer (Temple U)
+Apr16 : pair morse/soft : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
+Apr16 : compute dipole/chunk : Axel Kohlmeyer (Temple U)
+Apr16 : bond write : Axel Kohlmeyer (Temple U)
+Mar16 : pair morse/smooth/linear : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
+Feb16 : pair/bond/angle/dihedral/improper zero : Carsten Svaneborg (SDU)
+Feb16 : dump custom/vtk : Richard Berger (JKU) and Daniel Queteschiner (DCS Computing)
+Feb16 : fix (nvt/npt/nph)/body and compute temp/body : Trung Nguyen
+Feb16 : USER-DPD package : James Larentzos (ARL), Timothy Mattox (Engility Corp), John Brennan (ARL)
+Dec15 : fix qeq/fire : Ray Shan (Sandia)
+Dec15 : pair lj/mdf, pair lennard/mdf, pair buck/mdf, improper distance : Paolo Raiteri (Curtin University)
+Nov15 : compute orientorder/atom : Aidan Thompson (Sandia) and Axel Kohlmeyer (U Temple)
+Nov15 : compute hexorder/atom : Aidan Thompson (Sandia)
+Oct15 : displace_atoms variable option : Reese Jones (Sandia)
+Oct15 : pair mgpt & USER-MGPT package : Tomas Oppelstrup and John Moriarty (LLNL)
+Oct15 : pair smtbq & USER-SMTBQ package : Nicolas Salles, Emile Maras, Olivier Politano, and Robert Tetot (LAAS-CNRS)
+Oct15 : fix ave/correlate/long command : Jorge Ramirez (UPM) and Alexei Likhtman (U Reading)
+Oct15 : pair vashishta command : Aidan Thompson (Sandia) and Yongnan Xiong (HNU)
+Aug15 : USER-TALLY package : Axel Kohlmeyer (Temple U)
+Aug15 : timer command : Axel Kohlmeyer (Temple U)
+Aug15 : USER-H5MD package : Pierre de Buyl (KU Leuven)
+Aug15 : COMPRESS package : Axel Kohlmeyer (Temple U)
+Aug15 : USER-SMD package : Georg Gunzenmueller (EMI)
+Jul15 : new HTML format for "doc pages"_Manual.html with search option : Richard Berger (JKU)
+Jul15 : rRESPA with pair hybrid : Sam Genheden (U of Southampton)
+Jul15 : pair_modify special : Axel Kohlmeyer (Temple U)
+Jul15 : pair polymorphic : Xiaowang Zhou and Reese Jones (Sandia)
+Jul15 : USER-DRUDE package : Alain Dequidt and Agilio Padua (U Blaise Pascal Clermont-Ferrand) and Julien Devemy (CNRS)
+Jul15 : USER-QTB package : Yuan Shen, Tingting Qi, and Evan Reed (Stanford U)
+Jul15 : USER-DIFFRACTION package : Shawn Coleman (ARL)
+Mar15 : fix temp/csld : Axel Kohlmeyer (Temple U)
+Mar15 : CORESHELL package : Hendrik Heenen (Technical University of Munich)
+Feb15 : pair quip for GAP and other potentials : Albert Bartok-Partay (U Cambridge)
+Feb15 : pair coul/streitz for Streitz-Mintmire potential : Ray Shan (Sandia)
+Feb15 : fix tfmc : Kristof Bal (U of Antwerp) 
+Feb15 : fix ttm/mod : Sergey Starikov and Vasily Pisarev (JIHT of RAS)
+Jan15 : fix atom/swap for MC swaps of atom types/charge : Paul Crozier (Sandia)
+Nov14 : fix pimd for path-integral MD : Chris Knight and Yuxing Peng (U Chicago)
+Nov14 : fix gle and fix ipi for path-integral MD : Michele Ceriotti (EPFL)
+Nov14 : pair style srp : Tim Sirk (ARL) and Pieter in 't Veld (BASF) 
+Nov14 : fix ave/spatial/sphere : Niall Jackson (Imperial College)
+Sep14 : QEQ package and several fix qeq/variant styles : Ray Shan (Sandia)
+Sep14 : SNAP package and pair style : Aidan Thompson (Sandia) and collaborators
+Aug14 : USER-INTEL package : Mike Brown (Intel)
+May14 : KOKKOS pacakge : Christian Trott and Carter Edwards (Sandia)
+May14 : USER-FEP pacakge : Agilio Padua (U Blaise Pascal Clermont-Ferrand)
+Apr14 : fix rigid/small NVE/NVT/NPH/NPT : Trung Nguyen (ORNL)
+Apr14 : fix qmmm for QM/MM coupling : Axel Kohlmeyer (Temple U)
+Mar14 : kspace_modify collective for faster FFTs on BG/Q : Paul Coffman (IBM)
+Mar14 : fix temp/csvr and fix oneway : Axel Kohlmeyer (Temple U)
+Feb14 : pair peri/eps, compute dilatation/atom, compute plasticity/atom : Rezwanur Rahman and John Foster (UTSA)
+Jan14 : MPI-IO options for dump and restart files : Paul Coffman (IBM)
+Nov13 : USER-LB package for Lattice Boltzmann : Francis Mackay and Colin Denniston (U Western Ontario)
+Nov13 : fix ti/rs and ti/spring : Rodrigo Freitas (UC Berkeley)
+Nov13 : pair comb3 : Ray Shan (Sandia), Tao Liang and Dundar Yilmaz (U Florida)
+Nov13 : write_dump and dump movie : Axel Kohlmeyer (Temple U)
+Sep13 : xmgrace tool : Vikas Varshney
+Sep13 : pair zbl : Aidan Thompson and Stephen Foiles (Sandia)
+Aug13 : pair nm and variants : Julien Devemy (ICCF)
+Aug13 : fix wall/lj1043 : Jonathan Lee (Sandia)
+Jul13 : pair peri/ves : Rezwan Rahman, JT Foster (U Texas San Antonio)
+Jul13 : pair tersoff/mod : Vitaly Dozhdikov (JIHT of RAS)
+Jul13 : compute basal/atom : Christopher Barrett,(Mississippi State)
+Jul13 : polybond tool : Zachary Kraus (Georgia Tech)
+Jul13 : fix gld : Stephen Bond and Andrew Baczewski (Sandia) 
+Jun13 : pair nb3b/harmonic : Todd Zeitler (Sandia)
+Jun13 : kspace_style pppm/stagger : Stan Moore (Sandia)
+Jun13 : fix tune/kspace : Paul Crozier (Sandia)
+Jun13 : long-range point dipoles : Stan Moore (Sandia) and Pieter in 't Veld (BASF)
+May13 : compute msd/nongauss : Rob Hoy
+May13 : pair list : Axel Kohlmeyer (Temple U)
+May13 : triclinic support for long-range solvers : Stan Moore (Sandia)
+Apr13 : dump_modify nfile and fileper : Christopher Knight
+Mar13 : fix phonon : Ling-Ti Kong (Shanghai Jiao Tong University)
+Mar13 : pair_style lj/cut/tip4p/cut : Pavel Elkind (Gothenburg University)
+Feb13 : immediate variables in input script : Daniel Moller (Autonomous University of Barcelona)
+Feb13 : fix species : Ray Shan (Sandia)
+Jan13 : compute voronoi/atom : Daniel Schwen
+Nov12 : pair_style mie/cut : Cassiano Aimoli Petrobras (U Notre Dame)
+Oct12 : pair_style meam/sw/spline : Robert Rudd (LLNL)
+Oct12 : angle_style fourier and fourier/simple and quartic : Loukas Peristeras (Scienomics)
+Oct12 : dihedral_style fourier and nharmonic and quadratic : Loukas Peristeras (Scienomics)
+Oct12 : improper_style fourier : Loukas Peristeras (Scienomics)
+Oct12 : kspace_style pppm/disp for 1/r^6 : Rolf Isele-Holder (Aachen University)
+Oct12 : moltemplate molecular builder tool : Andrew Jewett (UCSB)
+Sep12 : pair_style lj/cut/coul/dsf and coul/dsf : Trung Nguyen (ORNL)
+Sep12 : multi-level summation long-range solver : Stan Moore, Stephen Bond, and Paul Crozier (Sandia)
+Aug12 : fix rigid/npt and fix rigid/nph : Trung Nguyen (ORNL)
+Aug12 : Fortran wrapper on lib interface : Karl Hammond (UT, Knoxville)
+Aug12 : kspace_modify diff for 2-FFT PPPM : Rolf Isele-Holder (Aachen University), Stan Moore (BYU), Paul Crozier (Sandia)
+Jun12 : pair_style bop : Don Ward and Xiaowang Zhou (Sandia)
+Jun12 : USER-MOLFILE package : Axel Kohlmeyer (U Temple)
+Jun12 : USER-COLVARS package : Axel Kohlmeyer (U Temple)
+May12 : read_dump : Tim Sirk (ARL)
+May12 : improper_style cossq and ring : Georgios Vogiatzis (CoMSE, NTU Athens)
+May12 : pair_style lcbop : Dominik Wojt (Wroclaw University of Technology)
+Feb12 : PPPM per-atom energy/virial : Stan Moore (BYU)
+Feb12 : Ewald per-atom energy/virial : German Samolyuk (ORNL), Stan Moore (BYU)
+Feb12 : minimize forcezero linesearch : Asad Hasan (CMU)
+Feb12 : pair_style beck : Jon Zimmerman (Sandia)
+Feb12 : pair_style meam/spline : Alex Stukowski (LLNL)
+Jan12 : pair_style kim : Valeriu Smirichinski, Ryan Elliott, Ellad Tadmor (U Minn)
+Jan12 : dihedral_style table : Andrew Jewett (UCSB)
+Jan12 : angle_style dipole : Mario Orsi
+Jan12 : pair_style lj/smooth/linear : Jon Zimmerman (Sandia)
+Jan12 : fix reax/c/bond : Tzu-Ray Shan (Sandia)
+Dec11 : pair_style coul/wolf : Yongfeng Zhang (INL)
+Dec11 : run_style verlet/split : Yuxing Peng and Chris Knight (U Chicago)
+Dec11 : pair_style tersoff/table : Luca Ferraro (CASPUR)
+Nov11 : per-atom energy/stress for reax/c : Tzu-Ray Shan (Sandia)
+Oct11 : Fast Lubrication Dynamics (FLD) package: Amit Kumar, Michael Bybee, Jonathan Higdon (UIUC)
+Oct11 : USER-OMP package : Axel Kohlmeyer (Temple U)
+Sep11 : pair_style edip : Luca Ferraro (CASPUR)
+Aug11 : USER-SPH package : Georg Ganzenmuller (FIHSD, EMI, Germany)
+Aug11 : fix restrain : Craig Tenney (Sandia)
+Aug11 : USER-CUDA package : Christian Trott (U Tech Ilmenau)
+Aug11 : pair_style lj/sf : Laurent Joly (U Lyon)
+Aug11 : bond_style harmonic/shift and harmonic/shift/cut : Carsten Svaneborg
+Aug11 : angle_style cosine/shift and cosine/shift/exp : Carsten Svaneborg
+Aug11 : dihedral_style cosine/shift/exp : Carsten Svaneborg
+Aug11 : pair_style dipole/sf : Mario Orsi
+Aug11 : fix addtorque and compute temp/rotate : Laurent Joly (U Lyon)
+Aug11 : FFT support via FFTW3, MKL, ACML, KISSFFT libraries : \
+  Axel Kohlmeyer (Temple U)
+Jun11 : pair_style adp : Chris Weinberger (Sandia), Stephen Foiles (Sandia), \
+  Chandra Veer Singh (Cornell)
+Jun11 : Windows build option via Microsoft Visual Studio : \
+  Ilya Valuev (JIHT, Moscow, Russia)
+Jun11 : antisymmetrized wave packet MD : Ilya Valuev (JIHT, Moscow, Russia)
+Jun11 : dump image : Nathan Fabian (Sandia)
+May11 : pppm GPU single and double : Mike Brown (ORNL)
+May11 : pair_style lj/expand/gpu : Inderaj Bains (NVIDIA)
+2010 : pair_style reax/c and fix qeq/reax : Metin Aktulga (Purdue, now LBNL)
+- : DREIDING force field, pair_style hbond/dreiding, etc : Tod Pascal (Caltech)
+- : fix adapt and compute ti for thermodynamic integration for \
+  free energies : Sai Jayaraman (Sandia)
+- : pair_style born and gauss : Sai Jayaraman (Sandia)
+- : stochastic rotation dynamics (SRD) via fix srd : \
+  Jeremy Lechman (Sandia) and Pieter in 't Veld (BASF)
+- : ipp Perl script tool : Reese Jones (Sandia)
+- : eam_database and createatoms tools : Xiaowang Zhou (Sandia)
+- : electron force field (eFF) : Andres Jaramillo-Botero and Julius Su (Caltech)
+- : embedded ion method (EIM) potential : Xiaowang Zhou (Sandia)
+- : COMB potential with charge equilibration : Tzu-Ray Shan (U Florida)
+- : fix ave/correlate :  Benoit Leblanc, Dave Rigby, \
+  Paul Saxe (Materials Design) and Reese Jones (Sandia)
+- : pair_style peri/lps : Mike Parks (Sandia)
+- : fix msst : Lawrence Fried (LLNL), Evan Reed (LLNL, Stanford)
+- : thermo_style custom tpcpu & spcpu keywords : Axel Kohlmeyer (Temple U) 
+- : fix rigid/nve, fix rigid/nvt : Tony Sheh and Trung Dac Nguyen (U Michigan)
+- : public SVN & Git repositories for LAMMPS : \
+  Axel Kohlmeyer (Temple U) and Bill Goldman (Sandia)
+- : compute heat/flux : German Samolyuk (ORNL) and \
+  Mario Pinto (Computational Research Lab, Pune, India)
+- : pair_style yukawa/colloid : Randy Schunk (Sandia)
+- : fix wall/colloid : Jeremy Lechman (Sandia)
+2009 : fix imd for real-time viz and interactive MD : Axel Kohlmeyer (Temple Univ)
+- : concentration-dependent EAM potential : \
+  Alexander Stukowski (Technical University of Darmstadt)
+- : parallel replica dymamics (PRD) : Mike Brown (Sandia)
+- : min_style hftn : Todd Plantenga (Sandia)
+- : fix atc : Reese Jones, Jon Zimmerman, Jeremy Templeton (Sandia)
+- : dump cfg : Liang Wan (Chinese Academy of Sciences)
+- : fix nvt with Nose/Hoover chains : Andy Ballard (U Maryland)
+- : pair_style lj/cut/gpu, pair_style gayberne/gpu : Mike Brown (Sandia)
+- : pair_style lj96/cut, bond_style table, angle_style table : Chuanfu Luo
+- : fix langevin tally : Carolyn Phillips (U Michigan)
+- : compute heat/flux for Green-Kubo : Reese Jones (Sandia), \
+  Philip Howell (Siemens), Vikas Varsney (AFRL)
+- : region cone : Pim Schravendijk
+- : pair_style born/coul/long : Ahmed Ismail (Sandia)
+- : fix ttm : Paul Crozier (Sandia) and Carolyn Phillips (U Michigan)
+- : fix box/relax : Aidan Thompson and David Olmsted (Sandia)
+- : ReaxFF potential : Aidan Thompson (Sandia) and Hansohl Cho (MIT)
+- : compute cna/atom : Liang Wan (Chinese Academy of Sciences)
+2008 : Tersoff/ZBL potential : Dave Farrell (Northwestern U)
+- : peridynamics : Mike Parks (Sandia)
+- : fix smd for steered MD : Axel Kohlmeyer (U Penn)
+- : GROMACS pair potentials : Mark Stevens (Sandia)
+- : lmp2vmd tool : Axel Kohlmeyer (U Penn)
+- : compute group/group : Naveen Michaud-Agrawal (Johns Hopkins U)
+- : USER-CG-CMM package for coarse-graining : Axel Kohlmeyer (U Penn)
+- : cosine/delta angle potential : Axel Kohlmeyer (U Penn)
+- : VIM editor add-ons for LAMMPS input scripts : Gerolf Ziegenhain
+- : pair_style lubricate : Randy Schunk (Sandia)
+- : compute ackland/atom : Gerolf Ziegenhain
+- : kspace_style ewald/n, pair_style lj/coul, pair_style buck/coul : \
+  Pieter in 't Veld (Sandia)
+- : AI-REBO bond-order potential : Ase Henry (MIT)
+- : making LAMMPS a true "object" that can be instantiated \
+  multiple times, e.g. as a library : Ben FrantzDale (RPI)
+- : pymol_asphere viz tool : Mike Brown (Sandia)
+2007 : NEMD SLLOD integration : Pieter in 't Veld (Sandia)
+- : tensile and shear deformations : Pieter in 't Veld (Sandia)
+- : GayBerne potential : Mike Brown (Sandia)
+- : ellipsoidal particles : Mike Brown (Sandia)
+- : colloid potentials : Pieter in 't Veld (Sandia)
+- : fix heat : Paul Crozier and Ed Webb (Sandia)
+- : neighbor multi and communicate multi : Pieter in 't Veld (Sandia)
+- : MATLAB post-processing scripts : Arun Subramaniyan (Purdue)
+- : triclinic (non-orthogonal) simulation domains : Pieter in 't Veld (Sandia)
+- : thermo_extract tool: Vikas Varshney (Wright Patterson AFB)
+- : fix ave/time and fix ave/spatial : Pieter in 't Veld (Sandia)
+- : MEAM potential : Greg Wagner (Sandia)
+- : optimized pair potentials for lj/cut, charmm/long, eam, morse : \
+  James Fischer (High Performance Technologies), \
+  David Richie and Vincent Natoli (Stone Ridge Technologies)
+2006 : fix wall/lj126 : Mark Stevens (Sandia)
+- : Stillinger-Weber and Tersoff potentials : \
+  Aidan Thompson and Xiaowang Zhou (Sandia)
+- : region prism : Pieter in 't Veld (Sandia)
+- : fix momentum and recenter : Naveen Michaud-Agrawal (Johns Hopkins U)
+- : multi-letter variable names : Naveen Michaud-Agrawal (Johns Hopkins U)
+- : OPLS dihedral potential: Mark Stevens (Sandia)
+- : POEMS coupled rigid body integrator: Rudranarayan Mukherjee (RPI)
+- : faster pair hybrid potential: James Fischer \
+    (High Performance Technologies, Inc), Vincent Natoli and \
+    David Richie (Stone Ridge Technology)
+- : breakable bond quartic potential: Chris Lorenz and Mark Stevens (Sandia)
+- : DCD and XTC dump styles: Naveen Michaud-Agrawal (Johns Hopkins U)
+- : grain boundary orientation fix : Koenraad Janssens and \
+  David Olmsted (Sandia)
+- : pair_style lj/smooth potential : Craig Maloney (UCSB) 
+- : radius-of-gyration spring fix : Naveen Michaud-Agrawal \
+  (Johns Hopkins U) and Paul Crozier (Sandia)
+- : self spring fix : Naveen Michaud-Agrawal (Johns Hopkins U)
+- : EAM CoAl and AlCu potentials : Kwang-Reoul Lee (KIST, Korea)
+- : cosine/squared angle potential : Naveen Michaud-Agrawal (Johns Hopkins U)
+- : helix dihedral potential : Naveen Michaud-Agrawal (Johns Hopkins U) and \
+    Mark Stevens (Sandia)
+- : Finnis/Sinclair EAM: Tim Lau (MIT)
+- : dissipative particle dynamics (DPD) potentials: Kurt Smith (U Pitt) and \
+    Frank van Swol (Sandia)
+- : TIP4P potential (4-site water): Ahmed Ismail and \
+  Amalie Frischknecht (Sandia)
+2005 : uniaxial strain fix: Carsten Svaneborg (Max Planck Institute)
+- : compressed dump files: Erik Luijten (U Illinois)
+- : cylindrical indenter fix: Ravi Agrawal (Northwestern U)
+- : electric field fix: Christina Payne (Vanderbilt U)
+- : AMBER <-> LAMMPS tool: Keir Novik (Univ College London) and \
+  Vikas Varshney (U Akron)
+- : CHARMM <-> LAMMPS tool: Pieter in 't Veld and Paul Crozier (Sandia)
+- : Morse bond potential: Jeff Greathouse (Sandia)
+- : radial distribution functions: Paul Crozier & Jeff Greathouse (Sandia)
+- : force tables for long-range Coulombics: Paul Crozier (Sandia)
+2004 : targeted molecular dynamics (TMD): Paul Crozier (Sandia) and \
+  Christian Burisch (Bochum University, Germany)
+- : FFT support for SGI SCLS (Altix): Jim Shepherd (Ga Tech)
+- : lmp2cfg and lmp2traj tools: Ara Kooser, Jeff Greathouse, \
+    Andrey Kalinichev (Sandia)
+- : parallel tempering: Mark Sears (Sandia)
+earlier : granular force fields and BC: Leo Silbert & Gary Grest (Sandia)
+- : multi-harmonic dihedral potential: Mathias Putz (Sandia)
+- : embedded atom method (EAM) potential: Stephen Foiles (Sandia)
+- : msi2lmp tool: Steve Lustig (Dupont), Mike Peachey & John Carpenter (Cray)
+- : HTFN energy minimizer: Todd Plantenga (Sandia)
+- : class 2 force fields: Eric Simon (Cray)
+- : NVT/NPT integrators: Mark Stevens (Sandia)
+- : rRESPA: Mark Stevens & Paul Crozier (Sandia)
+- : Ewald and PPPM solvers: Roy Pollock (LLNL) : :tb(s=:,ca1=c)

doc/src/Intro_features.txt

@@ -0,0 +1,202 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS features :h3
+
+LAMMPS is a classical molecular dynamics (MD) code with these general
+classes of functionality:
+
+"General features"_#general
+"Particle and model types"_#particle
+"Interatomic potentials (force fields)"_#ff
+"Atom creation"_#create
+"Ensembles, constraints, and boundary conditions"_#ensemble
+"Integrators"_#integrate
+"Diagnostics"_#diag
+"Output"_#output
+"Multi-replica models"_#replica
+"Pre- and post-processing"_#prepost
+"Specialized features (beyond MD itself)"_#special :ul
+
+:line
+
+General features :h4,link(general)
+
+  runs on a single processor or in parallel
+  distributed-memory message-passing parallelism (MPI)
+  spatial-decomposition of simulation domain for parallelism
+  open-source distribution
+  highly portable C++
+  optional libraries used: MPI and single-processor FFT
+  GPU (CUDA and OpenCL), Intel Xeon Phi, and OpenMP support for many code features
+  easy to extend with new features and functionality
+  runs from an input script
+  syntax for defining and using variables and formulas
+  syntax for looping over runs and breaking out of loops
+  run one or multiple simulations simultaneously (in parallel) from one script
+  build as library, invoke LAMMPS thru library interface or provided Python wrapper
+  couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
+
+Particle and model types :h4,link(particle)
+("atom style"_atom_style.html command)
+
+  atoms
+  coarse-grained particles (e.g. bead-spring polymers)
+  united-atom polymers or organic molecules
+  all-atom polymers, organic molecules, proteins, DNA
+  metals
+  granular materials
+  coarse-grained mesoscale models
+  finite-size spherical and ellipsoidal particles
+  finite-size  line segment (2d) and triangle (3d) particles
+  point dipole particles
+  rigid collections of particles
+  hybrid combinations of these :ul
+
+Interatomic potentials (force fields) :h4,link(ff)
+("pair style"_pair_style.html, "bond style"_bond_style.html,
+"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
+"improper style"_improper_style.html, "kspace style"_kspace_style.html
+commands)
+
+  pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
+    Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
+  charged pairwise potentials: Coulombic, point-dipole
+  manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
+    embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
+    REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
+  long-range interactions for charge, point-dipoles, and LJ dispersion: \
+    Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
+  polarization models: "QEq"_fix_qeq.html, \
+    "core/shell model"_Howto_coreshell.html, \
+    "Drude dipole model"_Howto_drude.html
+  charge equilibration (QEq via dynamic, point, shielded, Slater methods)
+  coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
+  mesoscopic potentials: granular, Peridynamics, SPH
+  electron force field (eFF, AWPMD)
+  bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
+    quartic (breakable)
+  angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
+    class 2 (COMPASS)
+  dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
+    class 2 (COMPASS), OPLS
+  improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
+  polymer potentials: all-atom, united-atom, bead-spring, breakable
+  water potentials: TIP3P, TIP4P, SPC
+  implicit solvent potentials: hydrodynamic lubrication, Debye
+  force-field compatibility with common CHARMM, AMBER, DREIDING, \
+    OPLS, GROMACS, COMPASS options
+  access to "KIM archive"_http://openkim.org of potentials via \
+    "pair kim"_pair_kim.html
+  hybrid potentials: multiple pair, bond, angle, dihedral, improper \
+    potentials can be used in one simulation
+  overlaid potentials: superposition of multiple pair potentials :ul
+
+Atom creation :h4,link(create)
+("read_data"_read_data.html, "lattice"_lattice.html,
+"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
+"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
+
+  read in atom coords from files
+  create atoms on one or more lattices (e.g. grain boundaries)
+  delete geometric or logical groups of atoms (e.g. voids)
+  replicate existing atoms multiple times
+  displace atoms :ul
+
+Ensembles, constraints, and boundary conditions :h4,link(ensemble)
+("fix"_fix.html command) 
+
+  2d or 3d systems
+  orthogonal or non-orthogonal (triclinic symmetry) simulation domains
+  constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
+  thermostatting options for groups and geometric regions of atoms
+  pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
+  simulation box deformation (tensile and shear)
+  harmonic (umbrella) constraint forces
+  rigid body constraints
+  SHAKE bond and angle constraints
+  Monte Carlo bond breaking, formation, swapping
+  atom/molecule insertion and deletion
+  walls of various kinds
+  non-equilibrium molecular dynamics (NEMD)
+  variety of additional boundary conditions and constraints :ul
+
+Integrators :h4,link(integrate)
+("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands) 
+
+  velocity-Verlet integrator
+  Brownian dynamics
+  rigid body integration
+  energy minimization via conjugate gradient or steepest descent relaxation
+  rRESPA hierarchical timestepping
+  rerun command for post-processing of dump files :ul
+
+Diagnostics :h4,link(diag)
+
+  see various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
+
+Output :h4,link(output)
+("dump"_dump.html, "restart"_restart.html commands) 
+
+  log file of thermodynamic info
+  text dump files of atom coords, velocities, other per-atom quantities
+  binary restart files
+  parallel I/O of dump and restart files
+  per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
+  user-defined system-wide (log file) or per-atom (dump file) calculations
+  spatial and time averaging of per-atom quantities
+  time averaging of system-wide quantities
+  atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
+
+Multi-replica models :h4,link(replica)
+
+"nudged elastic band"_neb.html
+"parallel replica dynamics"_prd.html
+"temperature accelerated dynamics"_tad.html
+"parallel tempering"_temper.html :ul
+
+Pre- and post-processing :h4,link(prepost)
+
+A handful of pre- and post-processing tools are packaged with LAMMPS,
+some of which can convert input and output files to/from formats used
+by other codes; see the "Toos"_Tools.html doc page. :ulb,l
+
+Our group has also written and released a separate toolkit called
+"Pizza.py"_pizza which provides tools for doing setup, analysis,
+plotting, and visualization for LAMMPS simulations.  Pizza.py is
+written in "Python"_python and is available for download from "the
+Pizza.py WWW site"_pizza. :l,ule
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+:link(python,http://www.python.org)
+
+Specialized features :h4,link(special)
+
+LAMMPS can be built with optional packages which implement a variety
+of additional capabilities.  See the "Packages"_Packages.html doc
+page for details.
+
+These are LAMMPS capabilities which you may not think of as typical
+classical MD options:
+
+"static"_balance.html and "dynamic load-balancing"_fix_balance.html
+"generalized aspherical particles"_Howto_body.html
+"stochastic rotation dynamics (SRD)"_fix_srd.html
+"real-time visualization and interactive MD"_fix_imd.html
+calculate "virtual diffraction patterns"_compute_xrd.html
+"atom-to-continuum coupling"_fix_atc.html with finite elements
+coupled rigid body integration via the "POEMS"_fix_poems.html library
+"QM/MM coupling"_fix_qmmm.html
+Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_atom_swap.html
+"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
+"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
+"Peridynamics mesoscale modeling"_pair_peri.html
+"Lattice Boltzmann fluid"_fix_lb_fluid.html
+"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
+"two-temperature electron model"_fix_ttm.html :ul

doc/src/Intro_nonfeatures.txt

@@ -0,0 +1,83 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS non-features :h3
+
+LAMMPS is designed to be a fast, parallel engine for molecular
+dynamics (MD) simulations.  It provides only a modest amount of
+functionality for setting up simulations and analyzing their output.
+
+Specifically, LAMMPS does not:
+
+run thru a GUI
+build molecular systems
+assign force-field coefficients automagically
+perform sophisticated analyses of your MD simulation
+visualize your MD simulation interactively
+plot your output data :ul
+
+Here are suggestions on how to perform these tasks:
+
+GUI: LAMMPS can be built as a library and a Python wrapper that wraps
+the library interface is provided.  Thus, GUI interfaces can be
+written in Python (or C or C++ if desired) that run LAMMPS and
+visualize or plot its output.  Examples of this are provided in the
+python directory and described on the "Python"_Python.html doc
+page. :ulb,l
+
+Builder: Several pre-processing tools are packaged with LAMMPS.  Some
+of them convert input files in formats produced by other MD codes such
+as CHARMM, AMBER, or Insight into LAMMPS input formats.  Some of them
+are simple programs that will build simple molecular systems, such as
+linear bead-spring polymer chains.  The moltemplate program is a true
+molecular builder that will generate complex molecular models.  See
+the "Tools"_Tools.html doc page for details on tools packaged with
+LAMMPS.  The "Pre/post processing
+page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
+describes a variety of 3rd party tools for this task. :l
+
+Force-field assignment: The conversion tools described in the previous
+bullet for CHARMM, AMBER, and Insight will also assign force field
+coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
+or Accelerys force field files. :l
+
+Simulation analyses: If you want to perform analyses on-the-fly as
+your simulation runs, see the "compute"_compute.html and
+"fix"_fix.html doc pages, which list commands that can be used in a
+LAMMPS input script.  Also see the "Modify"_Modify.html doc page for
+info on how to add your own analysis code or algorithms to LAMMPS.
+For post-processing, LAMMPS output such as "dump file
+snapshots"_dump.html can be converted into formats used by other MD or
+post-processing codes.  Some post-processing tools packaged with
+LAMMPS will do these conversions.  Scripts provided with the {python}
+tool in the tools directory can extract and massage data in dump files
+to make it easier to import into other programs.  See the
+"Tools"_Tools.html doc page for details on these various options. :l
+
+Visualization: LAMMPS can produce JPG or PNG snapshot images
+on-the-fly via its "dump image"_dump_image.html command.  For
+high-quality, interactive visualization there are many excellent and
+free tools available.  See the "Other Codes
+page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
+visualization packages that can use LAMMPS output data. :l
+
+Plotting: See the next bullet about Pizza.py as well as the
+"Python"_Python.html doc page for examples of plotting LAMMPS output.
+Scripts provided with the {python} tool in the tools directory will
+extract and massage data in log and dump files to make it easier to
+analyze and plot.  See the "Tools"_Tools.html doc page for more
+discussion of the various tools. :l
+
+Pizza.py: Our group has also written a separate toolkit called
+"Pizza.py"_http://pizza.sandia.gov which can do certain kinds of
+setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
+simulations.  It thus provides some functionality for several of the
+above bullets.  Pizza.py is written in "Python"_http://www.python.org
+and is available for download from "this
+page"_http://www.cs.sandia.gov/~sjplimp/download.html. :l,ule

doc/src/Intro_opensource.txt

@@ -0,0 +1,44 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS open-source license :h3
+
+LAMMPS is a freely-available open-source code, distributed under the
+terms of the "GNU Public License"_gnu, which means you can use or
+modify the code however you wish.
+
+LAMMPS comes with no warranty of any kind.  As each source file states
+in its header, it is a copyrighted code that is distributed free-of-
+charge, under the terms of the "GNU Public License"_gnu (GPL).  This
+is often referred to as open-source distribution - see
+"www.gnu.org"_gnuorg or "www.opensource.org"_opensource.  The legal
+text of the GPL is in the LICENSE file included in the LAMMPS
+distribution.
+
+:link(gnu,http://www.gnu.org/copyleft/gpl.html)
+:link(gnuorg,http://www.gnu.org)
+:link(opensource,http://www.opensource.org)
+
+Here is a summary of what the GPL means for LAMMPS users:
+
+(1) Anyone is free to use, modify, or extend LAMMPS in any way they
+choose, including for commercial purposes.
+
+(2) If you distribute a modified version of LAMMPS, it must remain
+open-source, meaning you distribute it under the terms of the GPL.
+You should clearly annotate such a code as a derivative version of
+LAMMPS.
+
+(3) If you release any code that includes LAMMPS source code, then it
+must also be open-sourced, meaning you distribute it under the terms
+of the GPL.
+
+(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
+source file headers (including the copyright and GPL notices) should
+remain part of the code.

doc/src/Intro_overview.txt

@@ -0,0 +1,58 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Overview of LAMMPS :h3
+
+LAMMPS is a classical molecular dynamics (MD) code that models
+ensembles of particles in a liquid, solid, or gaseous state.  It can
+model atomic, polymeric, biological, solid-state (metals, ceramics,
+oxides), granular, coarse-grained, or macroscopic systems using a
+variety of interatomic potentials (force fields) and boundary
+conditions.  It can model 2d or 3d systems with only a few particles
+up to millions or billions.
+
+LAMMPS can be built and run on a laptop or destop machine, but is
+designed for parallel computers.  It will run on any parallel machine
+that supports the "MPI"_mpi message-passing library.  This includes
+shared-memory boxes and distributed-memory clusters and
+supercomputers.
+
+:link(mpi,http://www-unix.mcs.anl.gov/mpi)
+
+LAMMPS is written in C++.  Earlier versions were written in F77 and
+F90.  See the "History page"_http://lammps.sandia.gov/history.html of
+the website for details.  All versions can be downloaded from the
+"LAMMPS website"_lws.
+
+LAMMPS is designed to be easy to modify or extend with new
+capabilities, such as new force fields, atom types, boundary
+conditions, or diagnostics.  See the "Modify"_Modify.html doc page for
+more details.
+
+In the most general sense, LAMMPS integrates Newton's equations of
+motion for a collection of interacting particles.  A single particle
+can be an atom or molecule or electron, a coarse-grained cluster of
+atoms, or a mesoscopic or macroscopic clump of material.  The
+interaction models that LAMMPS includes are mostly short-range in
+nature; some long-range models are included as well.
+
+LAMMPS uses neighbor lists to keep track of nearby particles.  The
+lists are optimized for systems with particles that are repulsive at
+short distances, so that the local density of particles never becomes
+too large.  This is in contrast to methods used for modeling plasmas
+or gravitational bodies (e.g. galaxy formation).
+
+On parallel machines, LAMMPS uses spatial-decomposition techniques to
+partition the simulation domain into small sub-domains of equal
+computational cost, one of which is assigned to each processor.
+Processors communicate and store "ghost" atom information for atoms
+that border their sub-domain.
+
+
+

doc/src/Intro_website.txt

@@ -0,0 +1,42 @@
+"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Additional website links :h3
+
+The "LAMMPS website"_lws has a variety of additional info about
+LAMMPS, beyond what is in this manual.  Some of the other pages in
+this Intr are included in this list.
+
+"Brief intro and recently added significant features"_lws
+"List of features"_http://lammps.sandia.gov/features.html
+"List of non-features"_http://lammps.sandia.gov/non_features.html
+"Recent bug fixes and new features"_http://lammps.sandia.gov/bug.html :ul
+
+"Download info"_http://lammps.sandia.gov/download.html
+"GitHub site"_https://github.com/lammps/lammps
+"SourceForge site"_https://sourceforge.net/projects/lammps
+"LAMMPS open-source license"_http://lammps.sandia.gov/open_source.html :ul
+
+"Glossary of MD terms relevant to LAMMPS"_http://lammps.sandia.gov/glossary.html
+"LAMMPS highlights with images"_http://lammps.sandia.gov/pictures.html
+"LAMMPS highlights with movies"_http://lammps.sandia.gov/movies.html
+"Mail list"_http://lammps.sandia.gov/mail.html
+"Workshops"_http://lammps.sandia.gov/workshops.html
+"Tutorials"_http://lammps.sandia.gov/tutorials.html
+"Developer guide"_http://lammps.sandia.gov/Developer.pdf :ul
+
+"Pre- and post-processing tools for LAMMPS"_http://lammps.sandia.gov/prepost.html
+"Other software usable with LAMMPS"_http://lammps.sandia.gov/offsite.html
+"Viz tools usable with LAMMPS"_http://lammps.sandia.gov/viz.html :ul
+
+"Benchmark performance"_http://lammps.sandia.gov/bench.html
+"Publications that have cited LAMMPS"_http://lammps.sandia.gov/papers.html
+"Authors of LAMMPS"_http://lammps.sandia.gov/authors.html
+"History of LAMMPS development"_http://lammps.sandia.gov/history.html
+"Funding for LAMMPS"_http://lammps.sandia.gov/funding.html :ul

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
-<
+<HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="16 Jul 2018 version">
+<META NAME="docnumber" CONTENT="2 Aug 2018 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -14,91 +14,54 @@
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html#comm)
 
 :line
 
+<H1></H1>
+
 LAMMPS Documentation :c,h1
-16 Jul 2018 version :c,h2
+2 Aug 2018 version :c,h2
 
-Version info: :h3
+"What is a LAMMPS version?"_Manual_version.html
-
-The LAMMPS "version" is the date when it was released, such as 1 May
-2010. LAMMPS is updated continuously.  Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on "this page of
-the WWW site"_bug. Every 2-4 months one of the incremental releases
-is subjected to more thorough testing and labeled as a {stable} version.
-
-Each dated copy of LAMMPS contains all the
-features and bug-fixes up to and including that version date. The
-version date is printed to the screen and logfile every time you run
-LAMMPS. It is also in the file src/version.h and in the LAMMPS
-directory name created when you unpack a tarball, and at the top of
-the first page of the manual (this page).
-
-If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current [development] version of LAMMPS. :ulb,l
-
-If you browse the HTML doc pages included in your tarball, they
-describe the version you have. :l
-
-The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
-about once per month.  This is because it is large, and we don't want
-it to be part of every patch. :l
-
-There is also a "Developer.pdf"_Developer.pdf file in the doc
-directory, which describes the internal structure and algorithms of
-LAMMPS.  :l
-:ule
 
 LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
 Simulator.
 
-LAMMPS is a classical molecular dynamics simulation code designed to
+LAMMPS is a classical molecular dynamics simulation code with a focus
-run efficiently on parallel computers.  It was developed at Sandia
+on materials modeling.  It was designed to run efficiently on parallel
-National Laboratories, a US Department of Energy facility, with
+computers.  It was developed originally at Sandia National
-funding from the DOE.  It is an open-source code, distributed freely
+Laboratories, a US Department of Energy facility.  The majority of
-under the terms of the GNU Public License (GPL).
+funding for LAMMPS has come from the US Department of Energy (DOE).
+LAMMPS is an open-source code, distributed freely under the terms of
+the GNU Public License (GPL).
 
-The current core group of LAMMPS developers is at Sandia National
+The "LAMMPS website"_lws has a variety of information about the code.
-Labs and Temple University:
+It includes links to an on-line version of this manual, a "mail
-
+list"_http://lammps.sandia.gov/mail.html where users can post
-"Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
+questions, and a "GitHub site"https://github.com/lammps/lammps where
-Aidan Thompson, athomps at sandia.gov :l
+all LAMMPS development is coordinated.
-Stan Moore, stamoor at sandia.gov :l
-"Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
-:ule
-
-Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
-all at Sandia. The [LAMMPS home page] at
-"http://lammps.sandia.gov"_http://lammps.sandia.gov has more information
-about the code and its uses. Interaction with external LAMMPS developers,
-bug reports and feature requests are mainly coordinated through the
-"LAMMPS project on GitHub."_https://github.com/lammps/lammps
-The lammps.org domain, currently hosting "public continuous integration
-testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
-RPM and Windows installer packages"_http://packages.lammps.org is located
-at Temple University and managed by Richard Berger,
-richard.berger at temple.edu.
-
-:link(bug,http://lammps.sandia.gov/bug.html)
-:link(sjp,http://www.sandia.gov/~sjplimp)
-:link(ako,http://goo.gl/1wk0)
 
 :line
 
-The LAMMPS documentation is organized into the following sections.  If
-you find errors or omissions in this manual or have suggestions for
-useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.
-
-Once you are familiar with LAMMPS, you may want to bookmark "this
-page"_Section_commands.html#comm at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.
-
 "PDF file"_Manual.pdf of the entire manual, generated by
 "htmldoc"_http://freecode.com/projects/htmldoc
 
+The content for this manual is part of the LAMMPS distribution.
+You can build a local copy of the Manual as HTML pages or a PDF file,
+by following the steps on the "this page"_Build_manual.html.
+
+There is also a "Developer.pdf"_Developer.pdf document which gives
+a brief description of the basic code structure of LAMMPS.
+
+:line
+
+This manual is organized into the following sections.
+
+Once you are familiar with LAMMPS, you may want to bookmark "this
+page"_Commands.html since it gives quick access to a doc page for
+every LAMMPS command.
+
 <!-- RST
 
 .. toctree::
@@ -108,26 +71,23 @@ it gives quick access to documentation for all LAMMPS commands.
    :name: userdoc
    :includehidden:
 
-   Section_intro
+   Intro
    Section_start
-   Section_commands
+   Commands
-   Section_packages
+   Packages
-   Section_accelerate
+   Speed
-   Section_howto
+   Howto
    Examples
-   Section_perf
    Tools
    Modify
    Python
    Errors
-   Section_history
 
 .. toctree::
    :caption: Index
    :name: index
    :hidden:
 
-   tutorials
    commands
    fixes
    computes
@@ -146,12 +106,7 @@ Indices and tables
 END_RST -->
 
 <!-- HTML_ONLY -->
-"Introduction"_Section_intro.html :olb,l
+"Introduction"_Intro.html :olb,l
-  1.1 "What is LAMMPS"_intro_1 :ulb,b
-  1.2 "LAMMPS features"_intro_2 :b
-  1.3 "LAMMPS non-features"_intro_3 :b
-  1.4 "Open source distribution"_intro_4 :b
-  1.5 "Acknowledgments and citations"_intro_5 :ule,b
 "Getting started"_Section_start.html :l
   2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
   2.2 "Making LAMMPS"_start_2 :b
@@ -161,70 +116,17 @@ END_RST -->
   2.6 "Command-line options"_start_6 :b
   2.7 "Screen output"_start_7 :b
   2.8 "Tips for users of previous versions"_start_8 :ule,b
-"Commands"_Section_commands.html :l
+"Commands"_Commands.html :l
-  3.1 "LAMMPS input script"_cmd_1 :ulb,b
+"Optional packages"_Packages.html :l
-  3.2 "Parsing rules"_cmd_2 :b
+"Accelerate performance"_Speed.html :l
-  3.3 "Input script structure"_cmd_3 :b
+"How-to discussions"_Howto.html :l
-  3.4 "Commands listed by category"_cmd_4 :b
-  3.5 "Commands listed alphabetically"_cmd_5 :ule,b
-"Packages"_Section_packages.html :l
-  4.1 "Standard packages"_pkg_1 :ulb,b
-  4.2 "User packages"_pkg_2 :ule,b
-"Accelerating LAMMPS performance"_Section_accelerate.html :l
-  5.1 "Measuring performance"_acc_1 :ulb,b
-  5.2 "Algorithms and code options to boost performace"_acc_2 :b
-  5.3 "Accelerator packages with optimized styles"_acc_3 :b
-    5.3.1 "GPU package"_accelerate_gpu.html :b
-    5.3.2 "USER-INTEL package"_accelerate_intel.html :b
-    5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
-    5.3.4 "USER-OMP package"_accelerate_omp.html :b
-    5.3.5 "OPT package"_accelerate_opt.html :b
-  5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
-"How-to discussions"_Section_howto.html :l
-  6.1 "Restarting a simulation"_howto_1 :ulb,b
-  6.2 "2d simulations"_howto_2 :b
-  6.3 "CHARMM and AMBER force fields"_howto_3 :b
-  6.4 "Running multiple simulations from one input script"_howto_4 :b
-  6.5 "Multi-replica simulations"_howto_5 :b
-  6.6 "Granular models"_howto_6 :b
-  6.7 "TIP3P water model"_howto_7 :b
-  6.8 "TIP4P water model"_howto_8 :b
-  6.9 "SPC water model"_howto_9 :b
-  6.10 "Coupling LAMMPS to other codes"_howto_10 :b
-  6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
-  6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
-  6.13 "NEMD simulations"_howto_13 :b
-  6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
-  6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
-  6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
-  6.17 "Walls"_howto_17 :b
-  6.18 "Elastic constants"_howto_18 :b
-  6.19 "Library interface to LAMMPS"_howto_19 :b
-  6.20 "Calculating thermal conductivity"_howto_20 :b
-  6.21 "Calculating viscosity"_howto_21 :b
-  6.22 "Calculating a diffusion coefficient"_howto_22 :b
-  6.23 "Using chunks to calculate system properties"_howto_23 :b
-  6.24 "Setting parameters for pppm/disp"_howto_24 :b
-  6.25 "Polarizable models"_howto_25 :b
-  6.26 "Adiabatic core/shell model"_howto_26 :b
-  6.27 "Drude induced dipoles"_howto_27 :ule,b
 "Example scripts"_Examples.html :l
-"Performance & scalability"_Section_perf.html :l
 "Auxiliary tools"_Tools.html :l
 "Modify & extend LAMMPS"_Modify.html :l
 "Use Python with LAMMPS"_Python.html :l
 "Errors"_Errors.html :l
-"Future and history"_Section_history.html :l
-  13.1 "Coming attractions"_hist_1 :ulb,b
-  13.2 "Past versions"_hist_2 :ule,b
 :ole
 
-:link(intro_1,Section_intro.html#intro_1)
-:link(intro_2,Section_intro.html#intro_2)
-:link(intro_3,Section_intro.html#intro_3)
-:link(intro_4,Section_intro.html#intro_4)
-:link(intro_5,Section_intro.html#intro_5)
-
 :link(start_1,Section_start.html#start_1)
 :link(start_2,Section_start.html#start_2)
 :link(start_3,Section_start.html#start_3)
@@ -234,50 +136,6 @@ END_RST -->
 :link(start_7,Section_start.html#start_7)
 :link(start_8,Section_start.html#start_8)
 
-:link(cmd_1,Section_commands.html#cmd_1)
-:link(cmd_2,Section_commands.html#cmd_2)
-:link(cmd_3,Section_commands.html#cmd_3)
-:link(cmd_4,Section_commands.html#cmd_4)
-:link(cmd_5,Section_commands.html#cmd_5)
-
-:link(pkg_1,Section_packages.html#pkg_1)
-:link(pkg_2,Section_packages.html#pkg_2)
-
-:link(acc_1,Section_accelerate.html#acc_1)
-:link(acc_2,Section_accelerate.html#acc_2)
-:link(acc_3,Section_accelerate.html#acc_3)
-:link(acc_4,Section_accelerate.html#acc_4)
-
-:link(howto_1,Section_howto.html#howto_1)
-:link(howto_2,Section_howto.html#howto_2)
-:link(howto_3,Section_howto.html#howto_3)
-:link(howto_4,Section_howto.html#howto_4)
-:link(howto_5,Section_howto.html#howto_5)
-:link(howto_6,Section_howto.html#howto_6)
-:link(howto_7,Section_howto.html#howto_7)
-:link(howto_8,Section_howto.html#howto_8)
-:link(howto_9,Section_howto.html#howto_9)
-:link(howto_10,Section_howto.html#howto_10)
-:link(howto_11,Section_howto.html#howto_11)
-:link(howto_12,Section_howto.html#howto_12)
-:link(howto_13,Section_howto.html#howto_13)
-:link(howto_14,Section_howto.html#howto_14)
-:link(howto_15,Section_howto.html#howto_15)
-:link(howto_16,Section_howto.html#howto_16)
-:link(howto_17,Section_howto.html#howto_17)
-:link(howto_18,Section_howto.html#howto_18)
-:link(howto_19,Section_howto.html#howto_19)
-:link(howto_20,Section_howto.html#howto_20)
-:link(howto_21,Section_howto.html#howto_21)
-:link(howto_22,Section_howto.html#howto_22)
-:link(howto_23,Section_howto.html#howto_23)
-:link(howto_24,Section_howto.html#howto_24)
-:link(howto_25,Section_howto.html#howto_25)
-:link(howto_26,Section_howto.html#howto_26)
-:link(howto_27,Section_howto.html#howto_27)
-
-:link(hist_1,Section_history.html#hist_1)
-:link(hist_2,Section_history.html#hist_2)
 <!-- END_HTML_ONLY -->
 
 </BODY>

doc/src/Manual_version.txt

@@ -0,0 +1,33 @@
+"Higher level section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+What does a LAMMPS version mean: :h3
+
+The LAMMPS "version" is the date when it was released, such as 1 May
+2014. LAMMPS is updated continuously.  Whenever we fix a bug or add a
+feature, we release it in the next {patch} release, which are
+typically made every couple of weeks.  Info on patch releases are on
+"this website page"_http://lammps.sandia.gov/bug.html. Every few
+months, the latest patch release is subjected to more thorough testing
+and labeled as a {stable} version.
+
+Each version of LAMMPS contains all the features and bug-fixes up to
+and including its version date.
+
+The version date is printed to the screen and logfile every time you
+run LAMMPS. It is also in the file src/version.h and in the LAMMPS
+directory name created when you unpack a tarball.  And it is on the
+first page of the "manual"_Manual.html.
+
+If you browse the HTML doc pages on the LAMMPS WWW site, they always
+describe the most current patch release of LAMMPS. :ulb,l
+
+If you browse the HTML doc pages included in your tarball, they
+describe the version you have, which may be older. :l,ule
+

doc/src/Modify.txt

@@ -4,7 +4,7 @@ Section"_Python.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_atom.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_body.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -14,10 +14,9 @@ Body particles can represent complex entities, such as surface meshes
 of discrete points, collections of sub-particles, deformable objects,
 etc.
 
-See "Section 6.14"_Section_howto.html#howto_14 of the manual for
+See the "Howto body"_Howto_body.html doc page for an overview of using
-an overview of using body particles and the "body"_body.html doc page
+body particles and the various body styles LAMMPS supports.  New
-for details on the various body styles LAMMPS supports.  New styles
+styles can be created to add new kinds of body particles to LAMMPS.
-can be created to add new kinds of body particles to LAMMPS.
 
 Body_nparticle.cpp is an example of a body particle that is treated as
 a rigid body containing N sub-particles.

doc/src/Modify_bond.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_command.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_compute.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_contribute.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -32,14 +32,14 @@ How quickly your contribution will be integrated depends largely on
 how much effort it will cause to integrate and test it, how much it
 requires changes to the core codebase, and of how much interest it is
 to the larger LAMMPS community.  Please see below for a checklist of
-typical requirements. Once you have prepared everything, see "this
+typical requirements. Once you have prepared everything, see the
-tutorial"_tutorial_github.html for instructions on how to submit your
+"Howto github"_Howto_github.html doc page for instructions on how to
-changes or new files through a GitHub pull request. If you prefer to
+submit your changes or new files through a GitHub pull request. If you
-submit patches or full files, you should first make certain, that your
+prefer to submit patches or full files, you should first make certain,
-code works correctly with the latest patch-level version of LAMMPS and
+that your code works correctly with the latest patch-level version of
-contains all bugfixes from it. Then create a gzipped tar file of all
+LAMMPS and contains all bugfixes from it. Then create a gzipped tar
-changed or added files or a corresponding patch file using 'diff -u'
+file of all changed or added files or a corresponding patch file using
-or 'diff -c' and compress it with gzip. Please only use gzip
+'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
 compression, as this works well on all platforms.
 
 If the new features/files are broadly useful we may add them as core
@@ -54,8 +54,9 @@ packages by typing "make package" in the LAMMPS src directory.
 
 Note that by providing us files to release, you are agreeing to make
 them open-source, i.e. we can release them under the terms of the GPL,
-used as a license for the rest of LAMMPS.  See "Section
+used as a license for the rest of LAMMPS.  See the "Open
-1.4"_Section_intro.html#intro_4 for details.
+source"_http://lammps.sandia.gov/open_source.html page on the LAMMPS
+website for details.
 
 With user packages and files, all we are really providing (aside from
 the fame and fortune that accompanies having your name in the source

doc/src/Modify_dump.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_fix.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_kspace.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_min.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_overview.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_pair.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_region.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_thermo.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Modify_variable.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Packages.txt

@@ -0,0 +1,39 @@
+"Previous Section"_Commands.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Speed.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Optional packages :h2
+
+This section gives an overview of the optional packages that extend
+LAMMPS functionality.  Packages are groups of files that enable a
+specific set of features.  For example, force fields for molecular
+systems or rigid-body constraint are in packages.  You can see the
+list of all packages and "make" commands to manage them by typing
+"make package" from within the src directory of the LAMMPS
+distribution.  "Section 2.3"_Section_start.html#start_3 gives general
+info on how to install and un-install packages as part of the LAMMPS
+build process.
+
+<!-- RST
+
+.. toctree::
+
+   Packages_standard
+   Packages_user
+   Packages_details
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Standard packages"_Packages_standard.html
+"User packages"_Packages_user.html
+"Details on each package"_Packages_details.html :ul
+
+<!-- END_HTML_ONLY -->

doc/src/Packages_details.txt

@@ -1,159 +1,96 @@
-"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Documentation"_ld - "LAMMPS Commands"_lc :c
-Section"_Section_accelerate.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
-4. Packages :h2
+Package details :h3
 
-This section gives an overview of the optional packages that extend
+Here is a brief description of all the standard and user packages in
-LAMMPS functionality with instructions on how to build LAMMPS with
+LAMMPS.  It lists authors (if applicable) and summarizes the package
-each of them.  Packages are groups of files that enable a specific set
+contents.  It has specific instructions on how to install the package,
-of features.  For example, force fields for molecular systems or
+including, if necessary, info on how to download or build any extra
-granular systems are in packages.  You can see the list of all
+library it requires.  It also gives links to documentation, example
-packages and "make" commands to manage them by typing "make package"
+scripts, and pictures/movies (if available) that illustrate use of the
-from within the src directory of the LAMMPS distribution.  "Section
+package.
-2.3"_Section_start.html#start_3 gives general info on how to install
-and un-install packages as part of the LAMMPS build process.
-
-There are two kinds of packages in LAMMPS, standard and user packages:
-
-"Table of standard packages"_#table_standard
-"Table of user packages"_#table_user :ul
-
-Either of these kinds of packages may work as is, may require some
-additional code compiled located in the lib folder, or may require
-an external library to be downloaded, compiled, installed, and LAMMPS
-configured to know about its location and additional compiler flags.
-You can often do the build of the internal or external libraries
-in one step by typing "make lib-name args='...'" from the src dir,
-with appropriate arguments included in args='...'. If you just type
-"make lib-name" you should see a help message about supported flags
-and some examples. For more details about this, please study the
-tables below and the sections about the individual packages.
-
-Standard packages are supported by the LAMMPS developers and are
-written in a syntax and style consistent with the rest of LAMMPS.
-This means the developers will answer questions about them, debug and
-fix them if necessary, and keep them compatible with future changes to
-LAMMPS.
-
-User packages have been contributed by users, and begin with the
-"user" prefix.  If they are a single command (single file), they are
-typically in the user-misc package.  User packages don't necessarily
-meet the requirements of the standard packages. This means the
-developers will try to keep things working and usually can answer
-technical questions about compiling the package. If you have problems
-using a feature provided in a user package, you may need to contact
-the contributor directly to get help.  Information on how to submit
-additions you make to LAMMPS as single files or as a standard or user
-package are given in the "Modify contribute"_Modify.html doc page.
-
-Following the next two tables is a sub-section for each package.  It
-lists authors (if applicable) and summarizes the package contents.  It
-has specific instructions on how to install the package, including (if
-necessary) downloading or building any extra library it requires. It
-also gives links to documentation, example scripts, and
-pictures/movies (if available) that illustrate use of the package.
 
 NOTE: To see the complete list of commands a package adds to LAMMPS,
-just look at the files in its src directory, e.g. "ls src/GRANULAR".
+you can examine the files in its src directory, e.g. "ls
-Files with names that start with fix, compute, atom, pair, bond,
+src/GRANULAR".  Files with names that start with fix, compute, atom,
-angle, etc correspond to commands with the same style names.
+pair, bond, angle, etc correspond to commands with the same style name
+as contained in the file name.
 
-In these two tables, the "Example" column is a sub-directory in the
+"ASPHERE"_#ASPHERE,
-examples directory of the distribution which has an input script that
+"BODY"_#BODY,
-uses the package.  E.g. "peptide" refers to the examples/peptide
+"CLASS2"_#CLASS2,
-directory; USER/atc refers to the examples/USER/atc directory.  The
+"COLLOID"_#COLLOID,
-"Library" column indicates whether an extra library is needed to build
+"COMPRESS"_#COMPRESS,
-and use the package:
+"CORESHELL"_#CORESHELL,
+"DIPOLE"_#DIPOLE,
+"GPU"_#GPU,
+"GRANULAR"_#GRANULAR,
+"KIM"_#KIM,
+"KOKKOS"_#KOKKOS,
+"KSPACE"_#KSPACE,
+"LATTE"_#LATTE,
+"MANYBODY"_#MANYBODY,
+"MC"_#MC,
+"MEAM"_#MEAM,
+"MISC"_#MISC,
+"MOLECULE"_#MOLECULE,
+"MPIIO"_#MPIIO,
+"MSCG"_#MSCG,
+"OPT"_#OPT,
+"PERI"_#PERI,
+"POEMS"_#POEMS,
+"PYTHON"_#PYTHON,
+"QEQ"_#QEQ,
+"REAX"_#REAX,
+"REPLICA"_#REPLICA,
+"RIGID"_#RIGID,
+"SHOCK"_#SHOCK,
+"SNAP"_#SNAP,
+"SPIN"_#SPIN,
+"SRD"_#SRD,
+"VORONOI"_#VORONOI :tb(c=6,ea=c)
 
-dash = no library
+"USER-ATC"_#USER-ATC,
-sys = system library: you likely have it on your machine
+"USER-AWPMD"_#USER-AWPMD,
-int = internal library: provided with LAMMPS, but you may need to build it
+"USER-BOCS"_#USER-BOCS,
-ext = external library: you will need to download and install it on your machine :ul
+"USER-CGDNA"_#USER-CGDNA,
-
+"USER-CGSDK"_#USER-CGSDK,
-:line
+"USER-COLVARS"_#USER-COLVARS,
-:line
+"USER-DIFFRACTION"_#USER-DIFFRACTION,
-
+"USER-DPD"_#USER-DPD,
-[Standard packages] :link(table_standard),p
+"USER-DRUDE"_#USER-DRUDE,
-
+"USER-EFF"_#USER-EFF,
-Package, Description, Doc page, Example, Library
+"USER-FEP"_#USER-FEP,
-"ASPHERE"_#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
+"USER-H5MD"_#USER-H5MD,
-"BODY"_#BODY, body-style particles, "body"_body.html, body, -
+"USER-INTEL"_#USER-INTEL,
-"CLASS2"_#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
+"USER-LB"_#USER-LB,
-"COLLOID"_#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
+"USER-MANIFOLD"_#USER-MANIFOLD,
-"COMPRESS"_#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
+"USER-MEAMC"_#USER-MEAMC,
-"CORESHELL"_#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
+"USER-MESO"_#USER-MESO,
-"DIPOLE"_#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
+"USER-MGPT"_#USER-MGPT,
-"GPU"_#GPU, GPU-enabled styles, "Section 5.3.1"_accelerate_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
+"USER-MISC"_#USER-MISC,
-"GRANULAR"_#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
+"USER-MOFFF"_#USER-MOFFF,
-"KIM"_#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
+"USER-MOLFILE"_#USER-MOLFILE,
-"KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-NETCDF"_#USER-NETCDF,
-"KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
+"USER-OMP"_#USER-OMP,
-"LATTE"_#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
+"USER-PHONON"_#USER-PHONON,
-"MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
+"USER-QMMM"_#USER-QMMM,
-"MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
+"USER-QTB"_#USER-QTB,
-"MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
+"USER-QUIP"_#USER-QUIP,
-"MISC"_#MISC, miscellanous single-file commands, -, -, -
+"USER-REAXC"_#USER-REAXC,
-"MOLECULE"_#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
+"USER-SMD"_#USER-SMD,
-"MPIIO"_#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
+"USER-SMTBQ"_#USER-SMTBQ,
-"MSCG"_#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
+"USER-SPH"_#USER-SPH,
-"OPT"_#OPT, optimized pair styles, "Section 5.3.5"_accelerate_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-TALLY"_#USER-TALLY,
-"PERI"_#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
+"USER-UEF"_#USER-UEF,
-"POEMS"_#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
+"USER-VTK"_#USER-VTK :tb(c=6,ea=c)
-"PYTHON"_#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
-"QEQ"_#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
-"REAX"_#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
-"REPLICA"_#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
-"RIGID"_#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
-"SHOCK"_#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
-"SNAP"_#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
-"SPIN"_#SPIN, magnetic atomic spin dynamics, "Section 6.6.28"_Section_howto.html#howto_28, SPIN, -
-"SRD"_#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
-"VORONOI"_#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
-
-[USER packages] :link(table_user),p
-
-Package, Description, Doc page, Example, Library
-"USER-ATC"_#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
-"USER-AWPMD"_#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
-"USER-BOCS"_#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
-"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
-"USER-CGSDK"_#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
-"USER-COLVARS"_#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
-"USER-DIFFRACTION"_#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
-"USER-DPD"_#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
-"USER-DRUDE"_#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
-"USER-EFF"_#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
-"USER-FEP"_#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
-"USER-H5MD"_#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
-"USER-INTEL"_#USER-INTEL, optimized Intel CPU and KNL styles,"Section 5.3.2"_accelerate_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-LB"_#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
-"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
-"USER-MEAMC"_#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
-"USER-MESO"_#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
-"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
-"USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
-"USER-MOFFF"_#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
-"USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
-"USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
-"USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-PHONON"_#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
-"USER-QMMM"_#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
-"USER-QTB"_#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
-"USER-QUIP"_#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
-"USER-REAXC"_#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
-"USER-SMD"_#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
-"USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
-"USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
-"USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
-"USER-UEF"_#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
-"USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
 
 :line
 :line
@@ -176,7 +113,7 @@ make machine :pre
 [Supporting info:]
 
 src/ASPHERE: filenames -> commands
-"Section 6.14"_Section_howto.html#howto_14
+"Howto spherical"_Howto_spherical.html
 "pair_style gayberne"_pair_gayberne.html
 "pair_style resquared"_pair_resquared.html
 "doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf
@@ -194,7 +131,8 @@ BODY package :link(BODY),h4
 
 Body-style particles with internal structure.  Computes,
 time-integration fixes, pair styles, as well as the body styles
-themselves.  See the "body"_body.html doc page for an overview.
+themselves.  See the "Howto body"_Howto_body.html doc page for an
+overview.
 
 [Install or un-install:]
 
@@ -207,10 +145,10 @@ make machine :pre
 [Supporting info:]
 
 src/BODY filenames -> commands
-"body"_body.html
+"Howto_body"_Howto_body.html
 "atom_style body"_atom_style.html
 "fix nve/body"_fix_nve_body.html
-"pair_style body"_pair_body.html
+"pair_style body/nparticle"_pair_body_nparticle.html
 examples/body :ul
 
 :line
@@ -322,9 +260,9 @@ Compute and pair styles that implement the adiabatic core/shell model
 for polarizability.  The pair styles augment Born, Buckingham, and
 Lennard-Jones styles with core/shell capabilities.  The "compute
 temp/cs"_compute_temp_cs.html command calculates the temperature of a
-system with core/shell particles.  See "Section
+system with core/shell particles.  See the "Howto
-6.26"_Section_howto.html#howto_26 for an overview of how to use this
+coreshell"_Howto_coreshell.html doc page for an overview of how to use
-package.
+this package.
 
 [Author:] Hendrik Heenen (Technical U of Munich).
 
@@ -339,8 +277,8 @@ make machine :pre
 [Supporting info:]
 
 src/CORESHELL: filenames -> commands
-"Section 6.26"_Section_howto.html#howto_26
+"Howto coreshell"_Howto_coreshell.html
-"Section 6.25"_Section_howto.html#howto_25
+"Howto polarizable"_Howto_polarizable.html
 "compute temp/cs"_compute_temp_cs.html
 "pair_style born/coul/long/cs"_pair_cs.html
 "pair_style buck/coul/long/cs"_pair_cs.html
@@ -380,14 +318,14 @@ GPU package :link(GPU),h4
 [Contents:]
 
 Dozens of pair styles and a version of the PPPM long-range Coulombic
-solver optimized for GPUs.  All such styles have a "gpu" as a
+solver optimized for GPUs.  All such styles have a "gpu" as a suffix
-suffix in their style name. The GPU code can be compiled with either
+in their style name. The GPU code can be compiled with either CUDA or
-CUDA or OpenCL, however the OpenCL variants are no longer actively
+OpenCL, however the OpenCL variants are no longer actively maintained
-maintained and only the CUDA versions are regularly tested.
+and only the CUDA versions are regularly tested.  The "Speed
-"Section 5.3.1"_accelerate_gpu.html gives details of what
+gpu"_Speed_gpu.html doc page gives details of what hardware and GPU
-hardware and GPU software is required on your system,
+software is required on your system, and details on how to build and
-and details on how to build and use this package.  Its styles can be
+use this package.  Its styles can be invoked at run time via the "-sf
-invoked at run time via the "-sf gpu" or "-suffix gpu" "command-line
+gpu" or "-suffix gpu" "command-line
 switches"_Section_start.html#start_6.  See also the "KOKKOS"_#KOKKOS
 package, which has GPU-enabled styles.
 
@@ -453,12 +391,12 @@ GPU library.
 src/GPU: filenames -> commands
 src/GPU/README
 lib/gpu/README
-"Section 5.3"_Section_accelerate.html#acc_3
+"Speed packages"_Speed_packages.html
-"Section 5.3.1"_accelerate_gpu.html
+"Speed gpu"_Speed_gpu.html.html
 "Section 2.6 -sf gpu"_Section_start.html#start_6
 "Section 2.6 -pk gpu"_Section_start.html#start_6
 "package gpu"_package.html
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (g)
+"Commands all"_Commands_all.html pages (pair,kspace) for styles followed by (g)
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
 
 :line
@@ -482,7 +420,7 @@ make machine :pre
 [Supporting info:]
 
 src/GRANULAR: filenames -> commands
-"Section 6.6"_Section_howto.html#howto_6,
+"Howto granular"_Howto_granular.html
 "fix pour"_fix_pour.html
 "fix wall/gran"_fix_wall_gran.html
 "pair_style gran/hooke"_pair_gran.html
@@ -549,8 +487,8 @@ See the list of all KIM models here:
 https://openkim.org/kim-items/models/by-model-drivers
 
 See the list of example KIM models included by default here:
-https://openkim.org/kim-api in the "What is in the KIM API source
+https://openkim.org/kim-api on the "What is in the KIM API source
-package?" section
+package?" page.
 
 You can then install/un-install the package and build LAMMPS in the
 usual manner:
@@ -579,10 +517,10 @@ Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
 styles adapted to compile using the Kokkos library which can convert
 them to OpenMP or CUDA code so that they run efficiently on multicore
 CPUs, KNLs, or GPUs.  All the styles have a "kk" as a suffix in their
-style name.  "Section 5.3.3"_accelerate_kokkos.html gives details of
+style name.  The "Speed kokkos"_Speed_kokkos.html doc page gives
-what hardware and software is required on your system, and how to
+details of what hardware and software is required on your system, and
-build and use this package.  Its styles can be invoked at run time via
+how to build and use this package.  Its styles can be invoked at run
-the "-sf kk" or "-suffix kk" "command-line
+time via the "-sf kk" or "-suffix kk" "command-line
 switches"_Section_start.html#start_6.  Also see the "GPU"_#GPU,
 "OPT"_#OPT, "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP
 packages, which have styles optimized for CPUs, KNLs, and GPUs.
@@ -649,13 +587,13 @@ make machine :pre
 src/KOKKOS: filenames -> commands
 src/KOKKOS/README
 lib/kokkos/README
-"Section 5.3"_Section_accelerate.html#acc_3
+"Speed packages"_Speed_packages.html
-"Section 5.3.3"_accelerate_kokkos.html
+"Speed kokkos"_Speed_kokkos.html
 "Section 2.6 -k on ..."_Section_start.html#start_6
 "Section 2.6 -sf kk"_Section_start.html#start_6
 "Section 2.6 -pk kokkos"_Section_start.html#start_6
 "package kokkos"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (k)
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (k)
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
 
 :line
@@ -689,11 +627,11 @@ make machine :pre
 src/KSPACE: filenames -> commands
 "kspace_style"_kspace_style.html
 "doc/PDF/kspace.pdf"_PDF/kspace.pdf
-"Section 6.7"_Section_howto.html#howto_7
+"Howto tip3p"_Howto_tip3p.html
-"Section 6.8"_Section_howto.html#howto_8
+"Howto tip4p"_Howto_tip4p.html
-"Section 6.9"_Section_howto.html#howto_9
+"Howto spc"_Howto_spc.html
 "pair_style coul"_pair_coul.html
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 with "long" or "msm" in pair style name
+"Commands pair"_Commands_pair.html page for styles with "long" or "msm" in name
 examples/peptide
 bench/in.rhodo :ul
 
@@ -777,7 +715,7 @@ make machine :pre
 [Supporting info:]
 
 src/MANYBODY: filenames -> commands
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
+"Commands pair"_Commands_pair.html page
 examples/comb
 examples/eim
 examples/nb3d
@@ -940,7 +878,7 @@ src/MOLECULE: filenames -> commands
 "improper_style"_improper_style.html
 "pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html
 "pair_style lj/charmm/coul/charmm"_pair_charmm.html
-"Section 6.3"_Section_howto.html#howto_3
+"Howto bioFF"_Howto_bioFF.html
 examples/cmap
 examples/dreiding
 examples/micelle,
@@ -1048,9 +986,9 @@ OPT package :link(OPT),h4
 A handful of pair styles which are optimized for improved CPU
 performance on single or multiple cores.  These include EAM, LJ,
 CHARMM, and Morse potentials.  The styles have an "opt" suffix in
-their style name.  "Section 5.3.5"_accelerate_opt.html gives details
+their style name.  The "Speed opt"_Speed_opt.html doc page gives
-of how to build and use this package.  Its styles can be invoked at
+details of how to build and use this package.  Its styles can be
-run time via the "-sf opt" or "-suffix opt" "command-line
+invoked at run time via the "-sf opt" or "-suffix opt" "command-line
 switches"_Section_start.html#start_6.  See also the "KOKKOS"_#KOKKOS,
 "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP packages, which
 have styles optimized for CPU performance.
@@ -1076,10 +1014,10 @@ CCFLAGS: add -restrict for Intel compilers :ul
 [Supporting info:]
 
 src/OPT: filenames -> commands
-"Section 5.3"_Section_accelerate.html#acc_3
+"Speed packages"_Speed_packages.html
-"Section 5.3.5"_accelerate_opt.html
+"Speed opt"_Speed_opt.html
 "Section 2.6 -sf opt"_Section_start.html#start_6
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (t)
+"Commands pair"_Commands_pair.html for styles followed by (t)
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
 
 :line
@@ -1180,8 +1118,8 @@ A "python"_python.html command which allow you to execute Python code
 from a LAMMPS input script.  The code can be in a separate file or
 embedded in the input script itself.  See the "Python
 call"_Python_call.html doc page for an overview of using Python from
-LAMMPS in this manner and the "Python"_Python.html doc page for other
+LAMMPS in this manner and all the "Python"_Python.html doc pages for
-ways to use LAMMPS and Python together.
+other ways to use LAMMPS and Python together.
 
 [Install or un-install:]
 
@@ -1202,7 +1140,7 @@ to Makefile.lammps) if the LAMMPS build fails.
 [Supporting info:]
 
 src/PYTHON: filenames -> commands
-"Python call"_Python_call.html
+"Python call"_Python.html
 lib/python/README
 examples/python :ul
 
@@ -1292,8 +1230,8 @@ REPLICA package :link(REPLICA),h4
 [Contents:]
 
 A collection of multi-replica methods which can be used when running
-multiple LAMMPS simulations (replicas).  See "Section
+multiple LAMMPS simulations (replicas).  See the "Howto
-6.5"_Section_howto.html#howto_5 for an overview of how to run
+replica"_Howto_replica.html doc page for an overview of how to run
 multi-replica simulations in LAMMPS.  Methods in the package include
 nudged elastic band (NEB), parallel replica dynamics (PRD),
 temperature accelerated dynamics (TAD), parallel tempering, and a
@@ -1312,7 +1250,7 @@ make machine :pre
 [Supporting info:]
 
 src/REPLICA: filenames -> commands
-"Section 6.5"_Section_howto.html#howto_5
+"Howto replica"_Howto_replica.html
 "neb"_neb.html
 "prd"_prd.html
 "tad"_tad.html
@@ -1435,7 +1373,7 @@ make machine :pre
 [Supporting info:]
 
 src/SPIN: filenames -> commands
-"Section 6.28"_Section_howto.html#howto_28
+"Howto spin"_Howto_spin.html
 "pair_style spin/dmi"_pair_spin_dmi.html
 "pair_style spin/exchange"_pair_spin_exchange.html
 "pair_style spin/magelec"_pair_spin_magelec.html
@@ -1894,10 +1832,10 @@ USER-DRUDE package :link(USER-DRUDE),h4
 [Contents:]
 
 Fixes, pair styles, and a compute to simulate thermalized Drude
-oscillators as a model of polarization.  See "Section
+oscillators as a model of polarization.  See the "Howto
-6.27"_Section_howto.html#howto_27 for an overview of how to use the
+drude"_Howto_drude.html and "Howto drude2"_Howto_drude2.html doc pages
-package.  There are auxiliary tools for using this package in
+for an overview of how to use the package.  There are auxiliary tools
-tools/drude.
+for using this package in tools/drude.
 
 [Authors:] Alain Dequidt (U Blaise Pascal Clermont-Ferrand), Julien
 Devemy (CNRS), and Agilio Padua (U Blaise Pascal).
@@ -1913,8 +1851,9 @@ make machine :pre
 [Supporting info:]
 
 src/USER-DRUDE: filenames -> commands
-"Section 6.27"_Section_howto.html#howto_27
+"Howto drude"_Howto_drude.html
-"Section 6.25"_Section_howto.html#howto_25
+"Howto drude2"_Howto_drude2.html
+"Howto polarizable"_Howto_polarizable.html
 src/USER-DRUDE/README
 "fix drude"_fix_drude.html
 "fix drude/transform/*"_fix_drude_transform.html
@@ -2065,8 +2004,8 @@ USER-INTEL package :link(USER-INTEL),h4
 
 Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
 styles which are optimized for Intel CPUs and KNLs (Knights Landing).
-All of them have an "intel" in their style name.  "Section
+All of them have an "intel" in their style name.  The "Speed
-5.3.2"_accelerate_intel.html gives details of what hardware and
+intel"_Speed_intel.html doc page gives details of what hardware and
 compilers are required on your system, and how to build and use this
 package.  Its styles can be invoked at run time via the "-sf intel" or
 "-suffix intel" "command-line switches"_Section_start.html#start_6.
@@ -2116,7 +2055,7 @@ hardware target, to produce a separate executable.
 
 You should also typically install the USER-OMP package, as it can be
 used in tandem with the USER-INTEL package to good effect, as
-explained in "Section 5.3.2"_accelerate_intel.html.
+explained on the "Speed intel"_Speed_intel.html doc page.
 
 make yes-user-intel yes-user-omp
 make machine :pre
@@ -2128,12 +2067,12 @@ make machine :pre
 
 src/USER-INTEL: filenames -> commands
 src/USER-INTEL/README
-"Section 5.3"_Section_accelerate.html#acc_3
+"Speed packages"_Speed_packages.html
-"Section 5.3.2"_accelerate_gpu.html
+"Speed intel"_Speed_intel.html
 "Section 2.6 -sf intel"_Section_start.html#start_6
 "Section 2.6 -pk intel"_Section_start.html#start_6
 "package intel"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (i)
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (i)
 src/USER-INTEL/TEST
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
 
@@ -2254,7 +2193,7 @@ make machine :pre
 
 src/USER-MANIFOLD: filenames -> commands
 src/USER-MANIFOLD/README
-"doc/manifolds"_manifolds.html
+"Howto manifold"_Howto_manifold.html
 "fix manifoldforce"_fix_manifoldforce.html
 "fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
 "fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
@@ -2475,10 +2414,10 @@ USER-OMP package :link(USER-OMP),h4
 Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
 kspace styles which are altered to enable threading on many-core CPUs
 via OpenMP directives.  All of them have an "omp" in their style name.
-"Section 5.3.4"_accelerate_omp.html gives details of what hardware and
+The "Speed omp"_Speed_omp.html doc page gives details of what hardware
-compilers are required on your system, and how to build and use this
+and compilers are required on your system, and how to build and use
-package.  Its styles can be invoked at run time via the "-sf omp" or
+this package.  Its styles can be invoked at run time via the "-sf omp"
-"-suffix omp" "command-line switches"_Section_start.html#start_6.
+or "-suffix omp" "command-line switches"_Section_start.html#start_6.
 Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and
 "USER-INTEL"_#USER-INTEL packages, which have styles optimized for
 CPUs.
@@ -2513,12 +2452,12 @@ LINKFLAGS: add -fopenmp :ul
 
 src/USER-OMP: filenames -> commands
 src/USER-OMP/README
-"Section 5.3"_Section_accelerate.html#acc_3
+"Speed packages"_Speed_packages.html
-"Section 5.3.4"_accelerate_omp.html
+"Speed omp"_Speed_omp.html
 "Section 2.6 -sf omp"_Section_start.html#start_6
 "Section 2.6 -pk omp"_Section_start.html#start_6
 "package omp"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (o)
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (o)
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
 
 :line

doc/src/Packages_standard.txt

@@ -0,0 +1,65 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Standard packages :h3
+
+This is the list of standard packages in LAMMPS.  The link for each
+package name gives more details.
+
+Standard packages are supported by the LAMMPS developers and are
+written in a syntax and style consistent with the rest of LAMMPS.
+This means the developers will answer questions about them, debug and
+fix them if necessary, and keep them compatible with future changes to
+LAMMPS.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory.  The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+dash = no library
+sys = system library: you likely have it on your machine
+int = internal library: provided with LAMMPS, but you may need to build it
+ext = external library: you will need to download and install it on your machine :ul
+
+Package, Description, Doc page, Example, Library
+"ASPHERE"_Packages_details.html#ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, -
+"BODY"_Packages_details.html#BODY, body-style particles, "Howto body"_Howto_body.html, body, -
+"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
+"COLLOID"_Packages_details.html#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
+"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
+"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, -
+"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
+"GPU"_Packages_details.html#GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
+"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, -
+"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
+"KOKKOS"_Packages_details.html#KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"KSPACE"_Packages_details.html#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
+"LATTE"_Packages_details.html#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
+"MANYBODY"_Packages_details.html#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
+"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
+"MEAM"_Packages_details.html#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
+"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
+"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, -
+"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
+"MSCG"_Packages_details.html#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
+"OPT"_Packages_details.html#OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"PERI"_Packages_details.html#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
+"POEMS"_Packages_details.html#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
+"PYTHON"_Packages_details.html#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
+"QEQ"_Packages_details.html#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
+"REAX"_Packages_details.html#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
+"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Howto replica"_Howto_replica.html, tad, -
+"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
+"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
+"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
+"SPIN"_#SPIN, magnetic atomic spin dynamics, "Howto spin"_Howto_spin.html, SPIN, -"SRD"_Packages_details.html#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
+"VORONOI"_Packages_details.html#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)

doc/src/Packages_user.txt

@@ -0,0 +1,74 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+User packages :h3
+
+This is a list of user packages in LAMMPS.  The link for each package
+name gives more details.
+
+User packages have been contributed by users, and begin with the
+"user" prefix.  If a contribution is a single command (single file),
+it is typically in the user-misc package.  User packages don't
+necessarily meet the requirements of the "standard
+packages"_Packages_standard.html. This means the developers will try
+to keep things working and usually can answer technical questions
+about compiling the package. If you have problems using a specific
+feature provided in a user package, you may need to contact the
+contributor directly to get help.  Information on how to submit
+additions you make to LAMMPS as single files or as a standard or user
+package is explained on the "Modify contribute"_Modify_contribute.html
+doc page.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory.  The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+dash = no library
+sys = system library: you likely have it on your machine
+int = internal library: provided with LAMMPS, but you may need to build it
+ext = external library: you will need to download and install it on your machine :ul
+
+Package, Description, Doc page, Example, Library
+"USER-ATC"_Packages_details.html#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
+"USER-AWPMD"_Packages_details.html#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
+"USER-BOCS"_Packages_details.html#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
+"USER-CGDNA"_Packages_details.html#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
+"USER-CGSDK"_Packages_details.html#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
+"USER-COLVARS"_Packages_details.html#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
+"USER-DIFFRACTION"_Packages_details.html#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
+"USER-DPD"_Packages_details.html#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
+"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, -
+"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
+"USER-FEP"_Packages_details.html#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
+"USER-H5MD"_Packages_details.html#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
+"USER-INTEL"_Packages_details.html#USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-LB"_Packages_details.html#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
+"USER-MANIFOLD"_Packages_details.html#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
+"USER-MEAMC"_Packages_details.html#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
+"USER-MESO"_Packages_details.html#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
+"USER-MGPT"_Packages_details.html#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
+"USER-MISC"_Packages_details.html#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
+"USER-MOFFF"_Packages_details.html#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
+"USER-MOLFILE"_Packages_details.html#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
+"USER-NETCDF"_Packages_details.html#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
+"USER-OMP"_Packages_details.html#USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-PHONON"_Packages_details.html#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
+"USER-QMMM"_Packages_details.html#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
+"USER-QTB"_Packages_details.html#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
+"USER-QUIP"_Packages_details.html#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
+"USER-REAXC"_Packages_details.html#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
+"USER-SMD"_Packages_details.html#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
+"USER-SMTBQ"_Packages_details.html#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
+"USER-SPH"_Packages_details.html#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
+"USER-TALLY"_Packages_details.html#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
+"USER-UEF"_Packages_details.html#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
+"USER-VTK"_Packages_details.html#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)

doc/src/Python.txt

@@ -4,7 +4,7 @@ Section"_Errors.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Python_call.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Python_examples.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line