forked from lijiext/lammps
Merge branch 'master' into restart-consistency
# Conflicts: # doc/src/fix_halt.rst
This commit is contained in:
commit
3e36acc533
|
@ -255,8 +255,9 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
|
|||
find_package(LAPACK)
|
||||
find_package(BLAS)
|
||||
if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
status(FATAL_ERROR "Cannot build internal linear algebra library with Ninja build tool due to lack for Fortran support")
|
||||
include(CheckGeneratorSupport)
|
||||
if(NOT CMAKE_GENERATOR_SUPPORT_FORTRAN)
|
||||
status(FATAL_ERROR "Cannot build internal linear algebra library as CMake build tool lacks Fortran support")
|
||||
endif()
|
||||
enable_language(Fortran)
|
||||
file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.[fF])
|
||||
|
@ -587,14 +588,14 @@ if(BUILD_TOOLS)
|
|||
add_executable(binary2txt ${LAMMPS_TOOLS_DIR}/binary2txt.cpp)
|
||||
install(TARGETS binary2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
|
||||
|
||||
# ninja-build currently does not support fortran. thus we skip building this tool
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(STATUS "Skipping building 'chain.x' with Ninja build tool due to lack of Fortran support")
|
||||
else()
|
||||
include(CheckGeneratorSupport)
|
||||
if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
|
||||
enable_language(Fortran)
|
||||
add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
|
||||
target_link_libraries(chain.x ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
|
||||
install(TARGETS chain.x DESTINATION ${CMAKE_INSTALL_BINDIR})
|
||||
else()
|
||||
message(WARNING "CMake build doesn't support fortran, skipping building 'chain.x'")
|
||||
endif()
|
||||
|
||||
enable_language(C)
|
||||
|
@ -686,6 +687,7 @@ feature_summary(DESCRIPTION "The following tools and libraries have been found a
|
|||
message(STATUS "<<< Build configuration >>>
|
||||
Build type ${CMAKE_BUILD_TYPE}
|
||||
Install path ${CMAKE_INSTALL_PREFIX}
|
||||
Generator ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}
|
||||
Compilers and Flags:
|
||||
C++ Compiler ${CMAKE_CXX_COMPILER}
|
||||
Type ${CMAKE_CXX_COMPILER_ID}
|
||||
|
@ -718,7 +720,7 @@ else()
|
|||
endif()
|
||||
message(STATUS "Link libraries: ${LAMMPS_LINK_LIBS}")
|
||||
if(BUILD_MPI)
|
||||
message(STATUS "Using MPI with headers in ${MPI_CXX_INCLUDE_PATH} and ${MPI_CXX_LIBRARIES}")
|
||||
message(STATUS "Using MPI with headers in ${MPI_CXX_INCLUDE_PATH} and these libraries: ${MPI_CXX_LIBRARIES};${MPI_Fortran_LIBRARIES}")
|
||||
endif()
|
||||
if(PKG_GPU)
|
||||
message(STATUS "GPU API: ${GPU_API}")
|
||||
|
|
|
@ -0,0 +1,21 @@
|
|||
# ninja-build<1.10 does not support fortran.
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
set(CMAKE_GENERATOR_SUPPORT_FORTRAN FALSE)
|
||||
execute_process(COMMAND "${CMAKE_MAKE_PROGRAM}" --version
|
||||
OUTPUT_VARIABLE NINJA_VERSION
|
||||
OUTPUT_STRIP_TRAILING_WHITESPACE
|
||||
RESULT_VARIABLE _Ninja_version_result
|
||||
)
|
||||
if(_Ninja_version_result)
|
||||
message(WARNING "Unable to determine ninja version: ${_Ninja_version_result}, assuming fortran isn't supported")
|
||||
elseif(NINJA_VERSION VERSION_LESS "1.10")
|
||||
message(WARNING "Ninja build tool too old, to compile Fortran code, please install ninja-1.10 or newer")
|
||||
else()
|
||||
set(CMAKE_GENERATOR_SUPPORT_FORTRAN TRUE)
|
||||
endif()
|
||||
else()
|
||||
set(CMAKE_GENERATOR_SUPPORT_FORTRAN TRUE)
|
||||
if(NOT CMAKE_GENERATOR STREQUAL "Unix Makefiles")
|
||||
message(WARNING "Assuming fortran is supported for ${CMAKE_GENERATOR}")
|
||||
endif()
|
||||
endif()
|
|
@ -34,26 +34,22 @@ if(PKG_KIM)
|
|||
endif()
|
||||
option(DOWNLOAD_KIM "Download KIM-API from OpenKIM instead of using an already installed one" ${DOWNLOAD_KIM_DEFAULT})
|
||||
if(DOWNLOAD_KIM)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded KIM-API library with Ninja build tool")
|
||||
endif()
|
||||
message(STATUS "KIM-API download requested - we will build our own")
|
||||
include(CheckLanguage)
|
||||
include(ExternalProject)
|
||||
enable_language(C)
|
||||
check_language(Fortran)
|
||||
if(NOT CMAKE_Fortran_COMPILER)
|
||||
message(FATAL_ERROR "Compiling the KIM-API library requires a Fortran compiler")
|
||||
endif()
|
||||
enable_language(Fortran)
|
||||
ExternalProject_Add(kim_build
|
||||
URL https://s3.openkim.org/kim-api/kim-api-2.1.3.txz
|
||||
URL_MD5 6ee829a1bbba5f8b9874c88c4c4ebff8
|
||||
BINARY_DIR build
|
||||
CMAKE_ARGS -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
|
||||
CMAKE_ARGS ${CMAKE_REQUEST_PIC}
|
||||
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
|
||||
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
|
||||
-DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
|
||||
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
|
||||
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
|
||||
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
|
||||
BUILD_BYPRODUCTS <INSTALL_DIR>/${CMAKE_INSTALL_LIBDIR}/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX}
|
||||
)
|
||||
ExternalProject_get_property(kim_build INSTALL_DIR)
|
||||
set(KIM-API_INCLUDE_DIRS ${INSTALL_DIR}/include/kim-api)
|
||||
|
|
|
@ -8,9 +8,6 @@ if(PKG_LATTE)
|
|||
endif()
|
||||
option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" ${DOWNLOAD_LATTE_DEFAULT})
|
||||
if(DOWNLOAD_LATTE)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded LATTE library with Ninja build tool")
|
||||
endif()
|
||||
message(STATUS "LATTE download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(latte_build
|
||||
|
@ -21,6 +18,8 @@ if(PKG_LATTE)
|
|||
-DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
|
||||
-DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER} -DCMAKE_Fortran_FLAGS=${CMAKE_Fortran_FLAGS}
|
||||
-DCMAKE_Fortran_FLAGS_${BTYPE}=${CMAKE_Fortran_FLAGS_${BTYPE}} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
|
||||
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
|
||||
BUILD_BYPRODUCTS <INSTALL_DIR>/${CMAKE_INSTALL_LIBDIR}/liblatte.a
|
||||
)
|
||||
ExternalProject_get_property(latte_build INSTALL_DIR)
|
||||
set(LATTE_LIBRARIES ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/liblatte.a)
|
||||
|
|
|
@ -8,9 +8,6 @@ if(PKG_MSCG)
|
|||
endif()
|
||||
option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" ${DOWNLOAD_MSCG_DEFAULT})
|
||||
if(DOWNLOAD_MSCG)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded MSCG library with Ninja build tool")
|
||||
endif()
|
||||
include(ExternalProject)
|
||||
if(NOT LAPACK_FOUND)
|
||||
set(EXTRA_MSCG_OPTS "-DLAPACK_LIBRARIES=${CMAKE_CURRENT_BINARY_DIR}/liblinalg.a")
|
||||
|
@ -19,8 +16,16 @@ if(PKG_MSCG)
|
|||
URL https://github.com/uchicago-voth/MSCG-release/archive/1.7.3.1.tar.gz
|
||||
URL_MD5 8c45e269ee13f60b303edd7823866a91
|
||||
SOURCE_SUBDIR src/CMake
|
||||
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
|
||||
BUILD_COMMAND make mscg INSTALL_COMMAND ""
|
||||
CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
|
||||
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
|
||||
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
|
||||
-DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
|
||||
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
|
||||
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
|
||||
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
|
||||
BUILD_COMMAND ${CMAKE_COMMAND} --build . --target mscg
|
||||
INSTALL_COMMAND ""
|
||||
BUILD_BYPRODUCTS <BINARY_DIR>/libmscg.a
|
||||
)
|
||||
ExternalProject_get_property(mscg_build BINARY_DIR)
|
||||
set(MSCG_LIBRARIES ${BINARY_DIR}/libmscg.a)
|
||||
|
|
|
@ -5,22 +5,7 @@ if(PKG_USER-COLVARS)
|
|||
file(GLOB COLVARS_SOURCES ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
|
||||
|
||||
# Build Lepton by default
|
||||
set(COLVARS_LEPTON_DEFAULT ON)
|
||||
# but not if C++11 is disabled per user request
|
||||
if(DEFINED DISABLE_CXX11_REQUIREMENT)
|
||||
if(DISABLE_CXX11_REQUIREMENT)
|
||||
set(COLVARS_LEPTON_DEFAULT OFF)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
option(COLVARS_LEPTON "Build and link the Lepton library" ${COLVARS_LEPTON_DEFAULT})
|
||||
|
||||
# Verify that the user's choice is consistent
|
||||
if(DEFINED DISABLE_CXX11_REQUIREMENT)
|
||||
if((DISABLE_CXX11_REQUIREMENT) AND (COLVARS_LEPTON))
|
||||
message(FATAL_ERROR "Building the Lepton library requires C++11 or later.")
|
||||
endif()
|
||||
endif()
|
||||
option(COLVARS_LEPTON "Build and link the Lepton library" ON)
|
||||
|
||||
if(COLVARS_LEPTON)
|
||||
set(LEPTON_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton)
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
if(PKG_USER-NETCDF)
|
||||
# USER-NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary.
|
||||
# NetCDF library enables dump sytle "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
|
||||
# NetCDF library enables dump style "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
|
||||
find_package(NetCDF)
|
||||
if(NETCDF_FOUND)
|
||||
find_package(PNetCDF)
|
||||
|
|
|
@ -29,9 +29,6 @@ if(PKG_USER-PLUMED)
|
|||
|
||||
option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
|
||||
if(DOWNLOAD_PLUMED)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded Plumed library with Ninja build tool")
|
||||
endif()
|
||||
if(BUILD_MPI)
|
||||
set(PLUMED_CONFIG_MPI "--enable-mpi")
|
||||
set(PLUMED_CONFIG_CC ${CMAKE_MPI_C_COMPILER})
|
||||
|
@ -47,6 +44,13 @@ if(PKG_USER-PLUMED)
|
|||
set(PLUMED_CONFIG_OMP "--disable-openmp")
|
||||
endif()
|
||||
message(STATUS "PLUMED download requested - we will build our own")
|
||||
if(PLUMED_MODE STREQUAL "STATIC")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed.a")
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
|
||||
endif()
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(plumed_build
|
||||
URL https://github.com/plumed/plumed2/releases/download/v2.6.0/plumed-src-2.6.0.tgz
|
||||
|
@ -59,6 +63,7 @@ if(PKG_USER-PLUMED)
|
|||
${PLUMED_CONFIG_OMP}
|
||||
CXX=${PLUMED_CONFIG_CXX}
|
||||
CC=${PLUMED_CONFIG_CC}
|
||||
BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS}
|
||||
)
|
||||
ExternalProject_get_property(plumed_build INSTALL_DIR)
|
||||
set(PLUMED_INSTALL_DIR ${INSTALL_DIR})
|
||||
|
|
|
@ -4,6 +4,7 @@ if(PKG_USER-SCAFACOS)
|
|||
|
||||
find_package(GSL REQUIRED)
|
||||
find_package(PkgConfig QUIET)
|
||||
find_package(MPI REQUIRED)
|
||||
set(DOWNLOAD_SCAFACOS_DEFAULT ON)
|
||||
if(PKG_CONFIG_FOUND)
|
||||
pkg_check_modules(SCAFACOS QUIET scafacos)
|
||||
|
@ -13,9 +14,6 @@ if(PKG_USER-SCAFACOS)
|
|||
endif()
|
||||
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
|
||||
if(DOWNLOAD_SCAFACOS)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded ScaFaCoS library with Ninja build tool")
|
||||
endif()
|
||||
message(STATUS "ScaFaCoS download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(scafacos_build
|
||||
|
@ -29,6 +27,22 @@ if(PKG_USER-SCAFACOS)
|
|||
CXX=${CMAKE_MPI_CXX_COMPILER}
|
||||
CC=${CMAKE_MPI_C_COMPILER}
|
||||
F77=
|
||||
BUILD_BYPRODUCTS
|
||||
<INSTALL_DIR>/lib/libfcs.a
|
||||
<INSTALL_DIR>/lib/libfcs_direct.a
|
||||
<INSTALL_DIR>/lib/libfcs_ewald.a
|
||||
<INSTALL_DIR>/lib/libfcs_fmm.a
|
||||
<INSTALL_DIR>/lib/libfcs_p2nfft.a
|
||||
<INSTALL_DIR>/lib/libfcs_p3m.a
|
||||
<INSTALL_DIR>/lib/libfcs_near.a
|
||||
<INSTALL_DIR>/lib/libfcs_gridsort.a
|
||||
<INSTALL_DIR>/lib/libfcs_resort.a
|
||||
<INSTALL_DIR>/lib/libfcs_redist.a
|
||||
<INSTALL_DIR>/lib/libfcs_common.a
|
||||
<INSTALL_DIR>/lib/libfcs_pnfft.a
|
||||
<INSTALL_DIR>/lib/libfcs_pfft.a
|
||||
<INSTALL_DIR>/lib/libfcs_fftw3_mpi.a
|
||||
<INSTALL_DIR>/lib/libfcs_fftw3.a
|
||||
)
|
||||
ExternalProject_get_property(scafacos_build INSTALL_DIR)
|
||||
set(SCAFACOS_BUILD_DIR ${INSTALL_DIR})
|
||||
|
|
|
@ -7,9 +7,6 @@ if(PKG_VORONOI)
|
|||
endif()
|
||||
option(DOWNLOAD_VORO "Download and compile the Voro++ library instead of using an already installed one" ${DOWNLOAD_VORO_DEFAULT})
|
||||
if(DOWNLOAD_VORO)
|
||||
if(CMAKE_GENERATOR STREQUAL "Ninja")
|
||||
message(FATAL_ERROR "Cannot build downloaded Voro++ library with Ninja build tool")
|
||||
endif()
|
||||
message(STATUS "Voro++ download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
|
||||
|
@ -29,6 +26,7 @@ if(PKG_VORONOI)
|
|||
URL https://download.lammps.org/thirdparty/voro++-0.4.6.tar.gz
|
||||
URL_MD5 2338b824c3b7b25590e18e8df5d68af9
|
||||
CONFIGURE_COMMAND "" BUILD_COMMAND make ${VORO_BUILD_OPTIONS} BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
|
||||
BUILD_BYPRODUCTS <SOURCE_DIR>/src/libvoro++.a
|
||||
)
|
||||
ExternalProject_get_property(voro_build SOURCE_DIR)
|
||||
set(VORO_LIBRARIES ${SOURCE_DIR}/src/libvoro++.a)
|
||||
|
|
|
@ -217,7 +217,7 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>CMAKE_VERBOSE_MAKEFILE</code></td>
|
||||
<td>Enable verbose output from Makefile builds (useful for debugging), the same can be achived by adding `VERBOSE=1` to the `make` call.</td>
|
||||
<td>Enable verbose output from Makefile builds (useful for debugging), the same can be achieved by adding `VERBOSE=1` to the `make` call.</td>
|
||||
<td>
|
||||
<dl>
|
||||
<dt><code>off</code> (default)</dt>
|
||||
|
@ -576,7 +576,7 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
|
|||
Several fixes and a pair style that have Monte Carlo (MC) or MC-like
|
||||
attributes. These include fixes for creating, breaking, and swapping bonds,
|
||||
for performing atomic swaps, and performing grand-canonical MC (GCMC) in
|
||||
conjuction with dynamics.
|
||||
conjunction with dynamics.
|
||||
</td>
|
||||
<td>
|
||||
<dl>
|
||||
|
@ -1383,8 +1383,8 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
|
|||
Some potentials that are also implemented in the Yet Another Force Field (YAFF) code.
|
||||
The expressions and their use are discussed in the following papers:
|
||||
<ul>
|
||||
<li><a href="http://dx.doi.org/10.1002/jcc.23877" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 36 (13), 1015-1027 (2015)</a></li>
|
||||
<li><a href="http://dx.doi.org/10.1002/jcc.25173" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 39 (16), 999-1011 (2018)</a></li>
|
||||
<li><a href="https://doi.org/10.1002/jcc.23877" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 36 (13), 1015-1027 (2015)</a></li>
|
||||
<li><a href="https://doi.org/10.1002/jcc.25173" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 39 (16), 999-1011 (2018)</a></li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
|
|
|
@ -7,11 +7,11 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
|||
SRD VORONOI
|
||||
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
|
||||
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
|
||||
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
|
||||
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
|
||||
USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
|
||||
USER-TALLY USER-UEF USER-VTK USER-YAFF)
|
||||
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
|
||||
USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)
|
||||
|
||||
foreach(PKG ${ALL_PACKAGES})
|
||||
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
|
||||
|
|
|
@ -9,11 +9,11 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
|||
SRD VORONOI
|
||||
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
|
||||
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
|
||||
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
|
||||
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
|
||||
USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
|
||||
USER-TALLY USER-UEF USER-VTK USER-YAFF)
|
||||
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
|
||||
USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)
|
||||
|
||||
foreach(PKG ${ALL_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
|
|
|
@ -2,13 +2,13 @@
|
|||
# external libraries. Compared to all_on.cmake some more unusual packages
|
||||
# are removed. The resulting binary should be able to run most inputs.
|
||||
|
||||
set(ALL_PACKAGES ASPHERE CLASS2 COLLOID CORESHELL DIPOLE
|
||||
GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
|
||||
PYTHON QEQ REPLICA RIGID SHOCK SNAP SRD VORONOI
|
||||
USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD
|
||||
USER-DRUDE USER-FEP USER-MEAMC USER-MESO
|
||||
USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REAXC
|
||||
USER-SPH USER-SMD USER-UEF USER-YAFF)
|
||||
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL
|
||||
DIPOLE GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
|
||||
POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
|
||||
USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
|
||||
USER-DPD USER-DRUDE USER-FEP USER-MEAMC USER-MESODPD
|
||||
USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REACTION
|
||||
USER-REAXC USER-SPH USER-SMD USER-UEF USER-YAFF)
|
||||
|
||||
foreach(PKG ${ALL_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
|
|
|
@ -78,7 +78,7 @@ html: $(ANCHORCHECK) $(MATHJAX)
|
|||
@cp -r src/PDF html/PDF
|
||||
@cp -r src/USER html/USER
|
||||
@mkdir -p html/JPG
|
||||
@cp `grep -A2 '\.\. image::' src/*.rst | grep ':target:' | sed -e 's,.*:target: JPG/,src/JPG/,' | sort | uniq` html/JPG/
|
||||
@cp `grep -A2 '\.\. .*image::' src/*.rst | grep ':target:' | sed -e 's,.*:target: JPG/,src/JPG/,' | sort | uniq` html/JPG/
|
||||
@rm -rf html/PDF/.[sg]*
|
||||
@rm -rf html/USER/.[sg]*
|
||||
@rm -rf html/USER/*/.[sg]*
|
||||
|
|
|
@ -31,7 +31,7 @@ of benzene, you have to provide the files 'benzene.car' and 'benzene.mdf'
|
|||
in the current working directory.
|
||||
.B msi2lmp
|
||||
will then read and process those files according to its remaining settings.
|
||||
All other settins are optional and have defaults as listed.
|
||||
All other settings are optional and have defaults as listed.
|
||||
.TP
|
||||
\fB\-c <I,1,II,2,O,0>\fR, \fB\-class <I,1,II,2,O,0>\fR
|
||||
The \-c or \-class option selects the force field class, i.e which pair
|
||||
|
|
|
@ -10,7 +10,7 @@ LAMMPS</H2>
|
|||
LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
|
||||
<P>
|
||||
This is the documentation for the LAMMPS 2001 version, written in F90,
|
||||
which has been superceded by more current versions. See the <A
|
||||
which has been superseded by more current versions. See the <A
|
||||
HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
|
||||
Site</A> for more information.
|
||||
<P>
|
||||
|
|
|
@ -47,7 +47,7 @@ directories: </P>
|
|||
<P>
|
||||
The src directory contains the F90 and C source files for LAMMPS as
|
||||
well as several sample Makefiles for different machines. To make LAMMPS
|
||||
for a specfic machine, you simply type</P>
|
||||
for a specific machine, you simply type</P>
|
||||
<P>
|
||||
make machine</P>
|
||||
<P>
|
||||
|
|
|
@ -1079,7 +1079,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
|
|||
to new total value -> has effect of applying same force to entire group
|
||||
of atoms
|
||||
thermostatting constraints (rescale, hoover/drag, langevin) cannot be used in
|
||||
conjuction with global "temp control", since they conflict and will
|
||||
conjunction with global "temp control", since they conflict and will
|
||||
cause atom velocities to be reset twice
|
||||
thermostatting constraints (rescale, hoover/drag, langevin) cannot be used
|
||||
when performing a minimization
|
||||
|
@ -1089,7 +1089,7 @@ meaning of rescale and Langevin thermostatting coefficients is same as in
|
|||
"temp control" command
|
||||
for rescale style, it can be used as a coarse temperature rescaler,
|
||||
for example "rescale 200.0 300.0 100 10.0 1.0" will ramp the temperature
|
||||
up during the simulation, resetting it to the target temperatue as needed
|
||||
up during the simulation, resetting it to the target temperature as needed
|
||||
for rescale style, it can be used to create an instantaneous
|
||||
drag force that slowly rescales the temperature without oscillation,
|
||||
for example "rescale 300.0 300.0 1 0.0 0.0001" will force (or keep)
|
||||
|
@ -1952,7 +1952,7 @@ for rescale style, the amount of rescaling is contfolled by the fractional
|
|||
to halfway between the current and target temperature
|
||||
for rescale style, it can be used as a coarse temperature rescaler,
|
||||
for example "rescale 200.0 300.0 100 10.0 1.0" will ramp the temperature
|
||||
up during the simulation, resetting it to the target temperatue as needed
|
||||
up during the simulation, resetting it to the target temperature as needed
|
||||
for rescale style, it can be used to create an instantaneous
|
||||
drag force that slowly rescales the temperature without oscillation,
|
||||
for example "rescale 300.0 300.0 1 0.0 0.0001" will force (or keep)
|
||||
|
|
|
@ -10,7 +10,7 @@ LAMMPS</H2>
|
|||
LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
|
||||
<P>
|
||||
This is the documentation for the LAMMPS 99 version, written in F77,
|
||||
which has been superceded by more current versions. See the <A
|
||||
which has been superseded by more current versions. See the <A
|
||||
HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
|
||||
Site</A> for more information.
|
||||
<P>
|
||||
|
|
|
@ -45,7 +45,7 @@ directories: </P>
|
|||
<P>
|
||||
The src directory contains the F77 and C source files for LAMMPS as
|
||||
well as several sample Makefiles for different machines. To make LAMMPS
|
||||
for a specfic machine, you simply type</P>
|
||||
for a specific machine, you simply type</P>
|
||||
<P>
|
||||
make machine</P>
|
||||
<P>
|
||||
|
|
|
@ -430,7 +430,7 @@ accuracy criterion effectively determines how many k-space vectors are used
|
|||
for PPPM, accuracy criterion determines mesh spacing (see "particle mesh"
|
||||
command)
|
||||
for PPPM, must be running on power-of-2 number of processors for FFTs
|
||||
must use periodic boundary conditions in conjuction with Ewald and PPPM
|
||||
must use periodic boundary conditions in conjunction with Ewald and PPPM
|
||||
cannot use any styles other than none with nonbond style = lj/shift or
|
||||
nonbond style = soft
|
||||
Coulomb style = smooth should be used with nonbond style = lj/switch,
|
||||
|
@ -772,7 +772,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
|
|||
to new total value -> has effect of applying same force to entire group
|
||||
of atoms
|
||||
thermostatting constraints (rescale, langevin, nose/hoover) cannot be used in
|
||||
conjuction with global "temp control", since they conflict and will
|
||||
conjunction with global "temp control", since they conflict and will
|
||||
cause atom velocities to be reset twice
|
||||
if multiple Langevin constraints are specified the Marsaglia RNG will
|
||||
only use the last RNG seed specified for initialization
|
||||
|
|
|
@ -8,7 +8,6 @@ for use with GNU make or gmake, or a build environment generated by CMake
|
|||
alternative you can download a package with pre-built executables
|
||||
as described on the :doc:`Install <Install>` doc page.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -10,10 +10,8 @@ CMake and make:
|
|||
* :ref:`Build the LAMMPS documentation <doc>`
|
||||
* :ref:`Install LAMMPS after a build <install>`
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _serial:
|
||||
|
||||
Serial vs parallel build
|
||||
|
@ -42,14 +40,14 @@ is below.
|
|||
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
|
||||
# no default value
|
||||
|
||||
The executable created by CMake (after running make) is named *lmp* unless
|
||||
the LAMMPS\_MACHINE option is set. When setting `LAMMPS_MACHINE=name`
|
||||
the executable will be named *lmp\_name*\. Using `BUILD\_MPI=no` will
|
||||
The executable created by CMake (after running make) is named ``lmp`` unless
|
||||
the LAMMPS_MACHINE option is set. When setting ``LAMMPS_MACHINE=name``
|
||||
the executable will be called ``lmp_name``. Using ``BUILD_MPI=no`` will
|
||||
enforce building a serial executable using the MPI STUBS library.
|
||||
|
||||
**Traditional make**\ :
|
||||
|
||||
The build with traditional makefiles has to be done inside the source folder `src`.
|
||||
The build with traditional makefiles has to be done inside the source folder ``src``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -57,19 +55,18 @@ The build with traditional makefiles has to be done inside the source folder `sr
|
|||
make serial # serial build, produces lmp_serial using Makefile/serial
|
||||
make mybox # uses Makefile.mybox to produce lmp_mybox
|
||||
|
||||
|
||||
Any "make machine" command will look up the make settings from a file
|
||||
Makefile.machine, create a folder Obj\_machine with all objects and
|
||||
generated files and an executable called *lmp\_machine*\ . The standard
|
||||
parallel build with `make mpi` assumes a standard MPI installation with
|
||||
Makefile.machine, create a folder Obj_machine with all objects and
|
||||
generated files and an executable called ``lmp_machine``\ . The standard
|
||||
parallel build with ``make mpi`` assumes a standard MPI installation with
|
||||
MPI compiler wrappers where all necessary compiler and linker flags to
|
||||
get access and link with the suitable MPI headers and libraries are set
|
||||
by the wrapper programs. For other cases or the serial build, you have
|
||||
to adjust the make file variables MPI\_INC, MPI\_PATH, MPI\_LIB as well
|
||||
as CC and LINK. To enable OpenMP threading usually a compiler specific
|
||||
flag needs to be added to the compile and link commands. For the GNU
|
||||
compilers, this is *-fopenmp*\ , which can be added to the CC and LINK
|
||||
makefile variables.
|
||||
to adjust the make file variables ``MPI_INC``, ``MPI_PATH``, ``MPI_LIB``
|
||||
as well as ``CC`` and ``LINK``\ . To enable OpenMP threading usually
|
||||
a compiler specific flag needs to be added to the compile and link
|
||||
commands. For the GNU compilers, this is ``-fopenmp``\ , which can be
|
||||
added to the ``CC`` and ``LINK`` makefile variables.
|
||||
|
||||
For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
|
||||
|
||||
|
@ -82,8 +79,8 @@ For the serial build the following make variables are set (see src/MAKE/Makefile
|
|||
MPI_LIB = -lmpi_stubs
|
||||
|
||||
You also need to build the STUBS library for your platform before making
|
||||
LAMMPS itself. A "make serial" build does this for you automatically,
|
||||
otherwise, type "make mpi-stubs" from the src directory, or "make" from
|
||||
LAMMPS itself. A ``make serial`` build does this for you automatically,
|
||||
otherwise, type ``make mpi-stubs`` from the src directory, or ``make`` from
|
||||
the src/STUBS dir. If the build fails, you will need to edit the
|
||||
STUBS/Makefile for your platform. The stubs library does not provide
|
||||
MPI/IO functions required by some LAMMPS packages, e.g. MPIIO or USER-LB,
|
||||
|
@ -91,8 +88,8 @@ and thus is not compatible with those packages.
|
|||
|
||||
.. note::
|
||||
|
||||
The file STUBS/mpi.c provides a CPU timer function called
|
||||
MPI\_Wtime() that calls gettimeofday() . If your operating system
|
||||
The file ``src/STUBS/mpi.c`` provides a CPU timer function called
|
||||
MPI_Wtime() that calls gettimeofday() . If your operating system
|
||||
does not support gettimeofday() , you will need to insert code to
|
||||
call another timer. Note that the ANSI-standard function clock()
|
||||
rolls over after an hour or so, and is therefore insufficient for
|
||||
|
@ -129,35 +126,33 @@ to: e.g. LATTE and USER-COLVARS. See the :doc:`Packages details
|
|||
<Packages_details>` doc page for more info on these packages and the doc
|
||||
pages for their respective commands for OpenMP threading info.
|
||||
|
||||
For CMake, if you use BUILD\_OMP=yes, you can use these packages and
|
||||
turn on their native OpenMP support and turn on their native OpenMP
|
||||
support at run time, by setting the OMP\_NUM\_THREADS environment
|
||||
For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
|
||||
and turn on their native OpenMP support and turn on their native OpenMP
|
||||
support at run time, by setting the ``OMP_NUM_THREADS`` environment
|
||||
variable before you launch LAMMPS.
|
||||
|
||||
For building via conventional make, the CCFLAGS and LINKFLAGS
|
||||
For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
|
||||
variables in Makefile.machine need to include the compiler flag that
|
||||
enables OpenMP. For GNU compilers it is -fopenmp. For (recent) Intel
|
||||
compilers it is -qopenmp. If you are using a different compiler,
|
||||
enables OpenMP. For GNU compilers it is ``-fopenmp``\ . For (recent) Intel
|
||||
compilers it is ``-qopenmp``\ . If you are using a different compiler,
|
||||
please refer to its documentation.
|
||||
|
||||
.. _default-none-issues:
|
||||
|
||||
**OpenMP Compiler compatibility info**\ :
|
||||
**OpenMP Compiler compatibility info**\ :
|
||||
|
||||
Some compilers do not fully support the 'default(none)' directive
|
||||
Some compilers do not fully support the ``default(none)`` directive
|
||||
and others (e.g. GCC version 9 and beyond) may implement OpenMP 4.0
|
||||
semantics, which are incompatible with the OpenMP 3.1 directives used
|
||||
semantics, which are incompatible with the OpenMP 3.1 semantics used
|
||||
in LAMMPS (for maximal compatibility with compiler versions in use).
|
||||
In those case, all 'default(none)' directives (which aid in detecting
|
||||
incorrect and unwanted sharing) can be replaced with 'default(shared)'
|
||||
while dropping all 'shared()' directives. The script
|
||||
'src/USER-OMP/hack\_openmp\_for\_pgi\_gcc9.sh' can be used to automate
|
||||
In those case, all ``default(none)`` directives (which aid in detecting
|
||||
incorrect and unwanted sharing) can be replaced with ``default(shared)``
|
||||
while dropping all ``shared()`` directives. The script
|
||||
'src/USER-OMP/hack_openmp_for_pgi_gcc9.sh' can be used to automate
|
||||
this conversion.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _compile:
|
||||
|
||||
Choice of compiler and compile/link options
|
||||
|
@ -188,11 +183,11 @@ optimization flags appropriate to that compiler and any
|
|||
build.
|
||||
|
||||
You can tell CMake to look for a specific compiler with these variable
|
||||
settings. Likewise you can specify the FLAGS variables if you want to
|
||||
experiment with alternate optimization flags. You should specify all
|
||||
3 compilers, so that the small number of LAMMPS source files written
|
||||
in C or Fortran are built with a compiler consistent with the one used
|
||||
for all the C++ files:
|
||||
settings. Likewise you can specify the corresponding ``CMAKE_*_FLAGS``
|
||||
variables if you want to experiment with alternate optimization flags.
|
||||
You should specify all 3 compilers, so that the small number of LAMMPS
|
||||
source files written in C or Fortran are built with a compiler consistent
|
||||
with the one used for all the C++ files:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -204,7 +199,6 @@ for all the C++ files:
|
|||
-D CMAKE_C_FLAGS=string # flags to use with C compiler
|
||||
-D CMAKE_Fortran_FLAGS=string # flags to use with Fortran compiler
|
||||
|
||||
|
||||
A few example command lines are:
|
||||
|
||||
.. code-block:: bash
|
||||
|
@ -306,33 +300,32 @@ are set, defaults are applied.
|
|||
-D LAMMPS_LIB_SUFFIX=name # name = mpi, serial, mybox, titan, laptop, etc
|
||||
# no default value
|
||||
|
||||
Setting BUILD\_EXE=no will not produce an executable. Setting
|
||||
BUILD\_LIB=yes will produce a static library named *liblammps.a*\ .
|
||||
Setting both BUILD\_LIB=yes and BUILD\_SHARED\_LIBS=yes will produce a
|
||||
shared library named *liblammps.so* instead. If LAMMPS\_LIB\_SUFFIX is
|
||||
set to *name* in addition, the name of the generated libraries will be
|
||||
changed to either *liblammps\_name.a* or *liblammps\_name.so*\ ,
|
||||
respectively.
|
||||
Setting ``BUILD_EXE=no`` will not produce an executable. Setting
|
||||
``BUILD_LIB=yes`` will produce a static library named ``liblammps.a``\ .
|
||||
Setting both ``BUILD_LIB=yes`` and ``BUILD_SHARED_LIBS=yes`` will produce a
|
||||
shared library named ``liblammps.so`` instead. If ``LAMMPS_LIB_SUFFIX=name``
|
||||
is set in addition, the name of the generated libraries will be changed to
|
||||
either ``liblammps_name.a`` or ``liblammps_name.so``\ , respectively.
|
||||
|
||||
**Traditional make**\ :
|
||||
|
||||
With the traditional makefile based build process, the choice of
|
||||
the generated executable or library depends on the "mode" setting.
|
||||
Several options are available and "mode=exe" is the default.
|
||||
Several options are available and ``mode=exe`` is the default.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make machine # build LAMMPS executable lmp_machine
|
||||
mkae mode=exe machine # same as "make machine"
|
||||
make mode=exe machine # same as "make machine"
|
||||
make mode=lib machine # build LAMMPS static lib liblammps_machine.a
|
||||
make mode=shlib machine # build LAMMPS shared lib liblammps_machine.so
|
||||
make mode=shexe machine # same as "mode=exe" but uses objects from "mode=shlib"
|
||||
|
||||
The two "exe" builds will generate and executable *lmp\_machine*\ ,
|
||||
while the two library builds will create a file *liblammps\_machine.a*
|
||||
or *liblammps\_machine.so*\ . They will also create generic soft links,
|
||||
named *liblammps.a* and *liblammps.so*\ , which point to the specific
|
||||
*liblammps\_machine.a/so* files.
|
||||
The two "exe" builds will generate and executable ``lmp_machine``\ ,
|
||||
while the two library builds will create a file ``liblammps_machine.a``
|
||||
or ``liblammps_machine.so``\ . They will also create generic soft links,
|
||||
named ``liblammps.a`` and ``liblammps.so``\ , which point to the specific
|
||||
``liblammps_machine.a/so`` files.
|
||||
|
||||
**CMake and make info**\ :
|
||||
|
||||
|
@ -341,13 +334,12 @@ the auxiliary libraries it depends on must also exist as shared
|
|||
libraries. This will be the case for libraries included with LAMMPS,
|
||||
such as the dummy MPI library in src/STUBS or any package libraries in
|
||||
the lib/packages directory, since they are always built in a shared
|
||||
library compatible way using the -fPIC switch. However, if a library
|
||||
library compatible way using the ``-fPIC`` switch. However, if a library
|
||||
like MPI or FFTW does not exist as a shared library, the shared library
|
||||
build may generate an error. This means you will need to install a
|
||||
shared library version of the auxiliary library. The build instructions
|
||||
for the library should tell you how to do this.
|
||||
|
||||
|
||||
As an example, here is how to build and install the `MPICH library
|
||||
<mpich_>`_, a popular open-source version of MPI, as a shared library
|
||||
in the default /usr/local/lib location:
|
||||
|
@ -360,10 +352,10 @@ in the default /usr/local/lib location:
|
|||
make
|
||||
make install
|
||||
|
||||
You may need to use "sudo make install" in place of the last line if you
|
||||
do not have write privileges for /usr/local/lib. The end result should
|
||||
be the file /usr/local/lib/libmpich.so. On many Linux installations the
|
||||
folder "${HOME}/.local" is an alternative to using /usr/local and does
|
||||
You may need to use ``sudo make install`` in place of the last line if you
|
||||
do not have write privileges for ``/usr/local/lib``. The end result should
|
||||
be the file ``/usr/local/lib/libmpich.so``. On many Linux installations the
|
||||
folder ``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
|
||||
not require superuser or sudo access. In that case the configuration
|
||||
step becomes:
|
||||
|
||||
|
@ -377,7 +369,6 @@ recommended to ensure the integrity of the system software installation.
|
|||
|
||||
----------
|
||||
|
||||
|
||||
.. _doc:
|
||||
|
||||
Build the LAMMPS documentation
|
||||
|
@ -412,7 +403,6 @@ LAMMPS source distribution.
|
|||
make package_check # check for complete and consistent package lists
|
||||
make spelling # spell-check the manual
|
||||
|
||||
|
||||
Thus "make html" will create a "doc/html" directory with the HTML format
|
||||
manual pages so that you can browse them with a web browser locally on
|
||||
your system.
|
||||
|
@ -421,8 +411,7 @@ your system.
|
|||
|
||||
You can also download a tarball of the documentation for the
|
||||
current LAMMPS version (HTML and PDF files), from the website
|
||||
`download page <http://lammps.sandia.gov/download.html>`_.
|
||||
|
||||
`download page <https://lammps.sandia.gov/download.html>`_.
|
||||
|
||||
**CMake build option**\ :
|
||||
|
||||
|
@ -430,16 +419,14 @@ It is also possible to create the HTML version of the manual within
|
|||
the :doc:`CMake build directory <Build_cmake>`. The reason for this
|
||||
option is to include the installation of the HTML manual pages into
|
||||
the "install" step when installing LAMMPS after the CMake build via
|
||||
"make install".
|
||||
``make install``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D BUILD_DOC=value # yes or no (default)
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _tools:
|
||||
|
||||
Build LAMMPS tools
|
||||
|
@ -450,7 +437,6 @@ using CMake or Make.
|
|||
|
||||
**CMake build3**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D BUILD_TOOLS=value # yes or no (default)
|
||||
|
@ -460,7 +446,6 @@ The generated binaries will also become part of the LAMMPS installation
|
|||
|
||||
**Traditional make**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd lammps/tools
|
||||
|
@ -470,10 +455,8 @@ The generated binaries will also become part of the LAMMPS installation
|
|||
make micelle2d # build only micelle2d tool
|
||||
make thermo_extract # build only thermo_extract tool
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _install:
|
||||
|
||||
Install LAMMPS after a build
|
||||
|
@ -487,7 +470,6 @@ you want to copy files to is protected.
|
|||
|
||||
**CMake build**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cmake -D CMAKE_INSTALL_PREFIX=path [options ...] ../cmake
|
||||
|
@ -496,6 +478,6 @@ you want to copy files to is protected.
|
|||
|
||||
**Traditional make**\ :
|
||||
|
||||
There is no "install" option in the src/Makefile for LAMMPS. If you
|
||||
wish to do this you will need to first build LAMMPS, then manually
|
||||
There is no "install" option in the ``src/Makefile`` for LAMMPS. If
|
||||
you wish to do this you will need to first build LAMMPS, then manually
|
||||
copy the desired LAMMPS files to the appropriate system directories.
|
||||
|
|
|
@ -9,17 +9,14 @@ Richard Berger (Temple U) has also written a `more comprehensive guide <https://
|
|||
for how to use CMake to build LAMMPS. If you are new to CMake it is a
|
||||
good place to start.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Building LAMMPS with CMake is a two-step process. First you use CMake
|
||||
to create a build environment in a new directory. On Linux systems,
|
||||
this will be based on makefiles for use with make. Then you use the
|
||||
make command to build LAMMPS, which uses the created
|
||||
this will be by default based on Unix-style makefiles for use with make.
|
||||
Then you use the *make* command to build LAMMPS, which uses the created
|
||||
Makefile(s). Example:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd lammps # change to the LAMMPS distribution directory
|
||||
|
@ -31,8 +28,8 @@ The cmake command will detect available features, enable selected
|
|||
packages and options, and will generate the build environment. By default
|
||||
this build environment will be created for "Unix Makefiles" on most
|
||||
platforms and particularly on Linux. However, alternate build tools
|
||||
(e.g. Ninja) and support files for Integrated Development Environments
|
||||
(IDE) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
|
||||
(e.g. Ninja) and project files for Integrated Development Environments
|
||||
(IDEs) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
|
||||
selected via the "-G" command line flag. For the rest of the documentation
|
||||
we will assume that the build environment is generated for makefiles
|
||||
and thus the make command will be used to compile and link LAMMPS as
|
||||
|
@ -51,7 +48,6 @@ even more.
|
|||
After compilation, you may optionally install the LAMMPS executable into
|
||||
your system with:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make install # optional, copy LAMMPS executable & library elsewhere
|
||||
|
@ -59,18 +55,17 @@ your system with:
|
|||
This will install the lammps executable and library (if requested), some
|
||||
tools (if configured) and additional files like library API headers,
|
||||
manpages, potential and force field files. The location of the installation
|
||||
tree is set by the CMake variable "CMAKE\_INSTALL\_PREFIX" which defaults
|
||||
tree is set by the CMake variable "CMAKE_INSTALL_PREFIX" which defaults
|
||||
to ${HOME}/.local
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
There are 3 variants of CMake: a command-line version (cmake), a text mode
|
||||
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
|
||||
any of them interchangeably to configure and create the LAMMPS build
|
||||
environment. On Linux all the versions produce a Makefile as their
|
||||
output. See more details on each below.
|
||||
There are 3 variants of the CMake command itself: a command-line version
|
||||
(*cmake* or *cmake3*), a text mode UI version (*ccmake* or *ccmake3*),
|
||||
and a graphical GUI version (*cmake-gui*). You can use any of them
|
||||
interchangeably to configure and create the LAMMPS build environment.
|
||||
On Linux all the versions produce a Makefile as their output by default.
|
||||
See more details on each below.
|
||||
|
||||
You can specify a variety of options with any of the 3 versions, which
|
||||
affect how the build is performed and what is included in the LAMMPS
|
||||
|
@ -88,12 +83,13 @@ this directory or sub-directories within it that CMake creates.
|
|||
|
||||
.. note::
|
||||
|
||||
To perform a CMake build, no packages can be installed or a
|
||||
build been previously attempted in the LAMMPS src directory by using
|
||||
"make" commands to :doc:`perform a conventional LAMMPS build <Build_make>`. CMake detects if this is the case and
|
||||
generates an error, telling you to type "make no-all purge" in the src
|
||||
directory to un-install all packages. The purge removes all the \*.h
|
||||
files auto-generated by make.
|
||||
To perform a CMake build, no packages can be installed or a build
|
||||
been previously attempted in the LAMMPS src directory by using "make"
|
||||
commands to :doc:`perform a conventional LAMMPS build <Build_make>`.
|
||||
CMake detects if this is the case and generates an error, telling you
|
||||
to type "make no-all purge" in the src directory to un-install all
|
||||
packages. The purge removes all the \*.h files auto-generated by
|
||||
make.
|
||||
|
||||
You must have CMake version 3.10 or later on your system to build
|
||||
LAMMPS. Installation instructions for CMake are below.
|
||||
|
@ -106,30 +102,28 @@ ccmake or cmake-gui) again from the same build directory and alter
|
|||
various options; see details below. Or you can remove the entire build
|
||||
folder, recreate the directory and start over.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Command-line version of CMake**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cmake [options ...] /path/to/lammps/cmake # build from any dir
|
||||
cmake [options ...] ../cmake # build from lammps/build
|
||||
cmake [options ...] /path/to/lammps/cmake # build from any dir
|
||||
cmake [options ...] ../cmake # build from lammps/build
|
||||
cmake3 [options ...] ../cmake # build from lammps/build
|
||||
|
||||
The cmake command takes one required argument, which is the LAMMPS
|
||||
cmake directory which contains the CMakeLists.txt file.
|
||||
|
||||
The argument can be preceeded or followed by various CMake
|
||||
The argument can be prefixed or followed by various CMake
|
||||
command-line options. Several useful ones are:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
|
||||
-D CMAKE_BUILD_TYPE=type # type = RelWithDebInfo (default), Release, MinSizeRel, or Debug
|
||||
-G output # style of output CMake generates
|
||||
-G output # style of output CMake generates (e.g. "Unix Makefiles" or "Ninja")
|
||||
-D CMAKE_MAKE_PROGRAM=builder # name of the builder executable (e.g. set to "gmake" instead of "make")
|
||||
-DVARIABLE=value # setting for a LAMMPS feature to enable
|
||||
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir
|
||||
-C path/to/preset/file # load some CMake settings before configuring
|
||||
|
@ -137,7 +131,7 @@ command-line options. Several useful ones are:
|
|||
All the LAMMPS-specific -D variables that a LAMMPS build supports are
|
||||
described on the pages linked to from the :doc:`Build <Build>` doc page.
|
||||
All of these variable names are upper-case and their values are
|
||||
lower-case, e.g. -D LAMMPS\_SIZES=smallbig. For boolean values, any of
|
||||
lower-case, e.g. -D LAMMPS_SIZES=smallbig. For boolean values, any of
|
||||
these forms can be used: yes/no, on/off, 1/0.
|
||||
|
||||
On Unix/Linux machines, CMake generates a Makefile by default to
|
||||
|
@ -168,13 +162,10 @@ In these cases it is usually better to first remove all the
|
|||
files/directories in the build directory, or start with a fresh build
|
||||
directory.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Curses version (terminal-style menu) of CMake**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ccmake ../cmake
|
||||
|
@ -186,13 +177,10 @@ required to edit some of the entries of CMake configuration variables
|
|||
in between. Please see the `ccmake manual <https://cmake.org/cmake/help/latest/manual/ccmake.1.html>`_ for
|
||||
more information.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**GUI version of CMake**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cmake-gui ../cmake
|
||||
|
@ -205,15 +193,12 @@ edit some of the entries of CMake configuration variables in between.
|
|||
Please see the `cmake-gui manual <https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html>`_
|
||||
for more information.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Installing CMake**
|
||||
|
||||
Check if your machine already has CMake installed:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
which cmake # do you have it?
|
||||
|
@ -223,7 +208,6 @@ Check if your machine already has CMake installed:
|
|||
On clusters or supercomputers which use environment modules to manage
|
||||
software packages, do this:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
module list # is a module for cmake already loaded?
|
||||
|
|
|
@ -4,10 +4,8 @@ Development build options (CMake only)
|
|||
The CMake build of LAMMPS has a few extra options which are useful during
|
||||
development, testing or debugging.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _compilation:
|
||||
|
||||
Verify compilation flags
|
||||
|
@ -17,22 +15,18 @@ Sometimes it is necessary to verify the complete sequence of compilation flags
|
|||
generated by the CMake build. To enable a more verbose output during
|
||||
compilation you can use the following option.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D CMAKE_VERBOSE_MAKEFILE=value # value = no (default) or yes
|
||||
|
||||
Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make VERBOSE=1
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _sanitizer:
|
||||
|
||||
Address, Undefined Behavior, and Thread Sanitizer Support
|
||||
|
@ -47,17 +41,14 @@ The following settings allow you enable these features if your compiler supports
|
|||
it. Please note that they come with a performance hit. However, they are
|
||||
usually faster than using tools like Valgrind.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D ENABLE_SANITIZE_ADDRESS=value # enable Address Sanitizer, value = no (default) or yes
|
||||
-D ENABLE_SANITIZE_UNDEFINED=value # enable Undefined Behaviour Sanitizer, value = no (default) or yes
|
||||
-D ENABLE_SANITIZE_UNDEFINED=value # enable Undefined Behavior Sanitizer, value = no (default) or yes
|
||||
-D ENABLE_SANITIZE_THREAD=value # enable Thread Sanitizer, value = no (default) or yes
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _testing:
|
||||
|
||||
Code Coverage and Testing
|
||||
|
@ -71,7 +62,6 @@ developers can run the tests directly on their workstation.
|
|||
|
||||
this is incomplete and only represents a small subset of tests that we run
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D ENABLE_TESTING=value # enable simple run tests of LAMMPS, value = no (default) or yes
|
||||
|
@ -80,7 +70,6 @@ developers can run the tests directly on their workstation.
|
|||
|
||||
If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make test
|
||||
|
@ -92,14 +81,12 @@ faster.
|
|||
You can also collect code coverage metrics while running the tests by enabling
|
||||
coverage support during building.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D ENABLE_COVERAGE=value # enable coverage measurements, value = no (default) or yes
|
||||
|
||||
This will also add the following targets to generate coverage reports after running the LAMMPS executable:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make test # run tests first!
|
||||
|
@ -108,7 +95,6 @@ This will also add the following targets to generate coverage reports after runn
|
|||
|
||||
These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install git+https://github.com/gcovr/gcovr.git
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -11,7 +11,7 @@ The :doc:`Build basics <Build_basics>` doc page explains how to build
|
|||
LAMMPS as either a shared or static library. This results in one of
|
||||
these 2 files:
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: bash
|
||||
|
||||
liblammps.so # shared library
|
||||
liblammps.a # static library
|
||||
|
@ -25,13 +25,12 @@ these 2 files:
|
|||
then its mpi.h file needs to be included. While it is technically
|
||||
possible to use a full MPI library in the calling code and link to
|
||||
a serial LAMMPS library compiled with MPI STUBS, it is recommended
|
||||
to use the *same* MPI library for both, and then use MPI\_Comm\_split()
|
||||
to use the *same* MPI library for both, and then use MPI_Comm_split()
|
||||
in the calling code to pass a suitable communicator with a subset
|
||||
of MPI ranks to the function creating the LAMMPS instance.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Link with LAMMPS as a static library**\ :
|
||||
|
||||
The calling application can link to LAMMPS as a static library with
|
||||
|
@ -44,7 +43,7 @@ executable code from the library is copied into the calling executable.
|
|||
*CMake build*\ :
|
||||
|
||||
This assumes that LAMMPS has been configured with "-D BUILD_LIB=yes"
|
||||
and installed with "make install" and the PKG\_CONFIG\_PATH environment
|
||||
and installed with "make install" and the PKG_CONFIG_PATH environment
|
||||
variable updated to include the *liblammps.pc* file installed into the
|
||||
configured destination folder, if needed. The commands to compile and
|
||||
link the coupled executable are then:
|
||||
|
@ -54,7 +53,6 @@ link the coupled executable are then:
|
|||
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
|
||||
mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
|
||||
|
||||
|
||||
*Traditional make*\ :
|
||||
|
||||
This assumes that LAMMPS has been compiled in the folder
|
||||
|
@ -101,7 +99,7 @@ change to:
|
|||
|
||||
gcc -c -O -I${HOME}/lammps/src/STUBS -I${HOME}/lammps/src -caller.c
|
||||
g++ -o caller caller.o -L${HOME}/lammps/lib/poems \
|
||||
-L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps -lpoems -lmpi_stubs
|
||||
-L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps -lpoems -lmpi_stubs
|
||||
|
||||
Note, that you need to link with "g++" instead of "gcc", since LAMMPS
|
||||
is C++ code. You can display the currently applied settings for building
|
||||
|
@ -115,15 +113,15 @@ Which should output something like:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
# Compiler:
|
||||
# Compiler:
|
||||
CXX=g++
|
||||
# Linker:
|
||||
# Linker:
|
||||
LD=g++
|
||||
# Compilation:
|
||||
# Compilation:
|
||||
CXXFLAGS=-g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I${HOME}/lammps/lib/poems -I${HOME}/lammps/src/STUBS
|
||||
# Linking:
|
||||
# Linking:
|
||||
LDFLAGS=-g -O
|
||||
# Libraries:
|
||||
# Libraries:
|
||||
LDLIBS=-L${HOME}/lammps/lib/poems -L${HOME}/lammps/src/STUBS -lpoems -lmpi_stubs
|
||||
|
||||
From this you can gather the necessary paths and flags. With
|
||||
|
@ -165,11 +163,11 @@ traditional make build using "make mode=shlib serial" becomes:
|
|||
g++ -o caller caller.o -L${HOME}/lammps/src -llammps
|
||||
|
||||
*Locating liblammps.so at runtime*\ :
|
||||
|
||||
|
||||
However, now the `liblammps.so` file is required at runtime and needs
|
||||
to be in a folder, where the shared linker program of the operating
|
||||
system can find it. This would be either a folder like "/usr/local/lib64"
|
||||
or "${HOME}/.local/lib64" or a folder pointed to by the LD\_LIBRARY\_PATH
|
||||
or "${HOME}/.local/lib64" or a folder pointed to by the LD_LIBRARY_PATH
|
||||
environment variable. You can type
|
||||
|
||||
.. code-block:: bash
|
||||
|
@ -179,7 +177,7 @@ environment variable. You can type
|
|||
to see what directories are in that list.
|
||||
|
||||
Or you can add the LAMMPS src directory (or the directory you performed
|
||||
a CMake style build in) to your LD\_LIBRARY\_PATH, so that the current
|
||||
a CMake style build in) to your LD_LIBRARY_PATH, so that the current
|
||||
version of the shared library is always available to programs that use it.
|
||||
|
||||
For the Bourne or Korn shells (/bin/sh, /bin/ksh, /bin/bash etc.), you
|
||||
|
@ -193,7 +191,6 @@ would add something like this to your ~/.profile file:
|
|||
For the csh or tcsh shells, you would equivalently add something like this
|
||||
to your ~/.cshrc file:
|
||||
|
||||
|
||||
.. code-block:: csh
|
||||
|
||||
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${HOME}/lammps/src
|
||||
|
@ -203,7 +200,7 @@ You can verify whether all required shared libraries are found with the
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
|
||||
$ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
|
||||
linux-vdso.so.1 (0x00007ffe729e0000)
|
||||
liblammps.so => /home/user/lammps/src/liblammps.so (0x00007fc91bb9e000)
|
||||
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc91b984000)
|
||||
|
@ -212,12 +209,11 @@ You can verify whether all required shared libraries are found with the
|
|||
libc.so.6 => /lib64/libc.so.6 (0x00007fc91b65b000)
|
||||
/lib64/ld-linux-x86-64.so.2 (0x00007fc91c094000)
|
||||
|
||||
|
||||
If a required library is missing, you would get a 'not found' entry:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ldd caller
|
||||
$ ldd caller
|
||||
linux-vdso.so.1 (0x00007ffd672fe000)
|
||||
liblammps.so => not found
|
||||
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb7c7e86000)
|
||||
|
@ -226,16 +222,14 @@ If a required library is missing, you would get a 'not found' entry:
|
|||
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
|
||||
/lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Calling the LAMMPS library**\ :
|
||||
|
||||
Either flavor of library (static or shared) allows one or more LAMMPS
|
||||
objects to be instantiated from the calling program. When used from a
|
||||
C++ program, most of the symbols and functions in LAMMPS are wrapped
|
||||
in a LAMMPS\_NS namespace; you can safely use any of its classes and
|
||||
in a LAMMPS_NS namespace; you can safely use any of its classes and
|
||||
methods from within the calling code, as needed, and you will not incur
|
||||
conflicts with functions and variables in your code that share the name.
|
||||
This, however, does not extend to all additional libraries bundled with
|
||||
|
|
|
@ -31,7 +31,7 @@ machines, especially workstations, desktops, and laptops, so we suggest
|
|||
you try it first when building LAMMPS in those cases.
|
||||
|
||||
The commands below perform a default LAMMPS build, producing the LAMMPS
|
||||
executable lmp\_serial and lmp\_mpi in lammps/src:
|
||||
executable lmp_serial and lmp_mpi in lammps/src:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -73,8 +73,7 @@ in the LAMMPS distribution. Typing "make machine" uses
|
|||
use Makefile.serial and Makefile.mpi, respectively. Other makefiles
|
||||
are in these directories:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: bash
|
||||
|
||||
OPTIONS # Makefiles which enable specific options
|
||||
MACHINES # Makefiles for specific machines
|
||||
|
@ -93,7 +92,6 @@ customized machine Makefile are contributed by users. Since both
|
|||
compilers, OS configurations, and LAMMPS itself keep changing, their
|
||||
settings may become outdated:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make mac # build serial LAMMPS on a Mac
|
||||
|
|
|
@ -47,15 +47,13 @@ versus make.
|
|||
|
||||
**CMake build**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: csh
|
||||
|
||||
-D PKG_NAME=value # yes or no (default)
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: csh
|
||||
|
||||
-D PKG_MANYBODY=yes
|
||||
-D PKG_USER-INTEL=yes
|
||||
|
@ -76,7 +74,6 @@ once with CMake.
|
|||
|
||||
**Traditional make**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd lammps/src
|
||||
|
@ -87,7 +84,6 @@ once with CMake.
|
|||
|
||||
Examples:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make no-rigid
|
||||
|
@ -132,10 +128,8 @@ src directory.
|
|||
That is no longer the case, so that CMake will build as-is without the
|
||||
need to un-install those packages.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**CMake shortcuts for installing many packages**\ :
|
||||
|
||||
Instead of specifying all the CMake options via the command-line,
|
||||
|
@ -169,7 +163,6 @@ one of them as a starting point and customize it to your needs.
|
|||
|
||||
**Example:**
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# build LAMMPS with most commonly used packages, but then remove
|
||||
|
@ -186,15 +179,13 @@ one of them as a starting point and customize it to your needs.
|
|||
# but leaving all other settings untouched. You can run:
|
||||
cmake -C ../cmake/presets/no_all.cmake .
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Make shortcuts for installing many packages**\ :
|
||||
|
||||
The following commands are useful for managing package source files
|
||||
and their installation when building LAMMPS via traditional make.
|
||||
Just type "make" in lammps/src to see a one-line summary.
|
||||
Just type ``make`` in lammps/src to see a one-line summary.
|
||||
|
||||
These commands install/un-install sets of packages:
|
||||
|
||||
|
@ -211,8 +202,8 @@ These commands install/un-install sets of packages:
|
|||
make yes-ext # install packages that require external libraries
|
||||
make no-ext # uninstall packages that require external libraries
|
||||
|
||||
which install/un-install various sets of packages. Typing "make
|
||||
package" will list all the these commands.
|
||||
which install/un-install various sets of packages. Typing ``make
|
||||
package`` will list all the these commands.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -221,7 +212,7 @@ package" will list all the these commands.
|
|||
directory src and the sub-directories with the package name (e.g.
|
||||
src/KSPACE, src/USER-ATC), so that the files are included or excluded
|
||||
when LAMMPS is built. Only source files in the src folder will be
|
||||
compiled.
|
||||
compiled.
|
||||
|
||||
The following make commands help manage files that exist in both the
|
||||
src directory and in package sub-directories. You do not normally
|
||||
|
@ -229,23 +220,23 @@ need to use these commands unless you are editing LAMMPS files or are
|
|||
:doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web
|
||||
site.
|
||||
|
||||
Type "make package-status" or "make ps" to show which packages are
|
||||
Type ``make package-status`` or ``make ps`` to show which packages are
|
||||
currently installed. For those that are installed, it will list any
|
||||
files that are different in the src directory and package
|
||||
sub-directory.
|
||||
|
||||
Type "make package-installed" or "make pi" to show which packages are
|
||||
Type ``make package-installed`` or ``make pi`` to show which packages are
|
||||
currently installed, without listing the status of packages that are
|
||||
not installed.
|
||||
|
||||
Type "make package-update" or "make pu" to overwrite src files with
|
||||
Type ``make package-update`` or ``make pu`` to overwrite src files with
|
||||
files from the package sub-directories if the package is installed.
|
||||
It should be used after a :doc:`patch has been applied <Install_patch>`,
|
||||
since patches only update the files in the package sub-directory, but
|
||||
not the src files.
|
||||
|
||||
Type "make package-overwrite" to overwrite files in the package
|
||||
Type ``make package-overwrite`` to overwrite files in the package
|
||||
sub-directories with src files.
|
||||
|
||||
Type "make package-diff" to list all differences between pairs of
|
||||
Type ``make package-diff`` to list all differences between pairs of
|
||||
files in both the source directory and the package directory.
|
||||
|
|
|
@ -12,12 +12,10 @@ explain how to do this for building both with CMake and make.
|
|||
* :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
|
||||
* :ref:`Memory allocation alignment <align>`
|
||||
* :ref:`Workaround for long long integers <longlong>`
|
||||
* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
|
||||
|
||||
* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _cxx11:
|
||||
|
||||
C++11 standard compliance
|
||||
|
@ -35,7 +33,6 @@ flags to enable C++11 compliance. Example for GNU c++ 4.8.x:
|
|||
|
||||
----------
|
||||
|
||||
|
||||
.. _fft:
|
||||
|
||||
FFT library
|
||||
|
@ -49,7 +46,6 @@ LAMMPS can use them if they are available on your system.
|
|||
|
||||
**CMake variables**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
|
||||
|
@ -69,7 +65,6 @@ OpenMP threads are enabled and a packages like KOKKOS or USER-OMP is
|
|||
used. If CMake cannot detect the FFT library, you can set these variables
|
||||
to assist:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D FFTW3_INCLUDE_DIRS=path # path to FFTW3 include files
|
||||
|
@ -81,7 +76,6 @@ to assist:
|
|||
|
||||
**Makefile.machine settings**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
|
||||
|
@ -91,8 +85,7 @@ to assist:
|
|||
FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries
|
||||
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
|
||||
|
||||
# default is FFT\_PACK\_ARRAY if not specified
|
||||
|
||||
# default is FFT_PACK_ARRAY if not specified
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
|
@ -102,14 +95,14 @@ to assist:
|
|||
FFT_LIB = -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
|
||||
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
|
||||
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler, serial interface
|
||||
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compier, serial interface
|
||||
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compiler, serial interface
|
||||
FFT_LIB = -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core # MKL with Intel compiler, threaded interface
|
||||
FFT_LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core # MKL with GNU compiler, threaded interface
|
||||
FFT_LIB = -lmkl_rt # MKL with automatic runtime selection of interface libs
|
||||
|
||||
As with CMake, you do not need to set paths in FFT\_INC or FFT\_PATH, if
|
||||
As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
|
||||
the compiler can find the FFT header and library files in its default search path.
|
||||
You must specify FFT\_LIB with the appropriate FFT libraries to include in the link.
|
||||
You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
|
||||
|
||||
**CMake and make info**\ :
|
||||
|
||||
|
@ -133,14 +126,15 @@ platform and can be faster than the KISS FFT library. You can
|
|||
download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
|
||||
version 3.X; the legacy version 2.1.X is no longer supported.
|
||||
|
||||
Building FFTW for your box should be as simple as ./configure; make;
|
||||
make install. The install command typically requires root privileges
|
||||
Building FFTW for your box should be as simple as ``./configure; make;
|
||||
make install``\ . The install command typically requires root privileges
|
||||
(e.g. invoke it via sudo), unless you specify a local directory with
|
||||
the "--prefix" option of configure. Type "./configure --help" to see
|
||||
the "--prefix" option of configure. Type ``./configure --help`` to see
|
||||
various options.
|
||||
|
||||
The Intel MKL math library is part of the Intel compiler suite. It
|
||||
can be used with the Intel or GNU compiler (see FFT\_LIB setting above).
|
||||
can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
|
||||
above).
|
||||
|
||||
Performing 3d FFTs in parallel can be time consuming due to data
|
||||
access and required communication. This cost can be reduced by
|
||||
|
@ -149,16 +143,15 @@ precision means the real and imaginary parts of a complex datum are
|
|||
4-byte floats. Double precision means they are 8-byte doubles. Note
|
||||
that Fourier transform and related PPPM operations are somewhat less
|
||||
sensitive to floating point truncation errors and thus the resulting
|
||||
error is less than the difference in precision. Using the -DFFT\_SINGLE
|
||||
error is less than the difference in precision. Using the ``-DFFT_SINGLE``
|
||||
setting trades off a little accuracy for reduced memory use and
|
||||
parallel communication costs for transposing 3d FFT data.
|
||||
|
||||
When using -DFFT\_SINGLE with FFTW3 you may need to build the FFTW
|
||||
When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
|
||||
library a second time with support for single-precision.
|
||||
|
||||
For FFTW3, do the following, which should produce the additional
|
||||
library libfftw3f.a or libfftw3f.so.
|
||||
|
||||
library ``libfftw3f.a`` or ``libfftw3f.so``\ .
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -167,15 +160,13 @@ library libfftw3f.a or libfftw3f.so.
|
|||
|
||||
Performing 3d FFTs requires communication to transpose the 3d FFT
|
||||
grid. The data packing/unpacking for this can be done in one of 3
|
||||
modes (ARRAY, POINTER, MEMCPY) as set by the FFT\_PACK syntax above.
|
||||
modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
|
||||
Depending on the machine, the size of the FFT grid, the number of
|
||||
processors used, one option may be slightly faster. The default is
|
||||
ARRAY mode.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _size:
|
||||
|
||||
Size of LAMMPS data types
|
||||
|
@ -187,19 +178,18 @@ adequate.
|
|||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
|
||||
|
||||
# default is LAMMPS\_SMALLBIG if not specified
|
||||
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
|
||||
|
||||
**CMake and make info**\ :
|
||||
|
||||
The default "smallbig" setting allows for simulations with:
|
||||
|
@ -247,12 +237,10 @@ than crashing randomly or corrupting data.
|
|||
Also note that the GPU package requires its lib/gpu library to be
|
||||
compiled with the same size setting, or the link will fail. A CMake
|
||||
build does this automatically. When building with make, the setting
|
||||
in whichever lib/gpu/Makefile is used must be the same as above.
|
||||
|
||||
in whichever ``lib/gpu/Makefile`` is used must be the same as above.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _graphics:
|
||||
|
||||
Output of JPG, PNG, and movie files
|
||||
|
@ -265,7 +253,6 @@ following settings:
|
|||
|
||||
**CMake variables**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D WITH_JPEG=value # yes or no
|
||||
|
@ -279,7 +266,6 @@ Usually these settings are all that is needed. If CMake cannot find
|
|||
the graphics header, library, executable files, you can set these
|
||||
variables:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D JPEG_INCLUDE_DIR=path # path to jpeglib.h header file
|
||||
|
@ -292,7 +278,6 @@ variables:
|
|||
|
||||
**Makefile.machine settings**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_JPEG
|
||||
|
@ -303,15 +288,16 @@ variables:
|
|||
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
|
||||
JPG_LIB = -ljpeg -lpng -lz # library names
|
||||
|
||||
As with CMake, you do not need to set JPG\_INC or JPG\_PATH, if make can
|
||||
find the graphics header and library files. You must specify JPG\_LIB
|
||||
As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
|
||||
if make can find the graphics header and library files. You must
|
||||
specify ``JPG_LIB``
|
||||
with a list of graphics libraries to include in the link. You must
|
||||
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
|
||||
that is a directory in your PATH environment variable.
|
||||
|
||||
**CMake and make info**\ :
|
||||
|
||||
Using ffmpeg to output movie files requires that your machine
|
||||
Using ``ffmpeg`` to output movie files requires that your machine
|
||||
supports the "popen" function in the standard runtime library.
|
||||
|
||||
.. note::
|
||||
|
@ -321,10 +307,8 @@ supports the "popen" function in the standard runtime library.
|
|||
communication library and lead to simulations using ffmpeg to hang or
|
||||
crash.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _gzip:
|
||||
|
||||
Read or write compressed files
|
||||
|
@ -336,7 +320,6 @@ gzip compression by several LAMMPS commands, including
|
|||
|
||||
**CMake variables**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D WITH_GZIP=value # yes or no
|
||||
|
@ -345,7 +328,6 @@ gzip compression by several LAMMPS commands, including
|
|||
|
||||
**Makefile.machine setting**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_GZIP
|
||||
|
@ -365,16 +347,14 @@ found by LAMMPS during a run.
|
|||
I/O is also available using a compression library instead, which is
|
||||
what the :ref:`COMPRESS package <PKG-COMPRESS>` enables.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _align:
|
||||
|
||||
Memory allocation alignment
|
||||
---------------------------------------
|
||||
|
||||
This setting enables the use of the posix\_memalign() call instead of
|
||||
This setting enables the use of the posix_memalign() call instead of
|
||||
malloc() when LAMMPS allocates large chunks or memory. This can make
|
||||
vector instructions on CPUs more efficient, if dynamically allocated
|
||||
memory is aligned on larger-than-default byte boundaries.
|
||||
|
@ -385,33 +365,29 @@ aligned on 64-byte boundaries.
|
|||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default)
|
||||
|
||||
Use a LAMMPS\_MEMALIGN value of 0 to disable using posix\_memalign()
|
||||
Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using posix_memalign()
|
||||
and revert to using the malloc() C-library function instead. When
|
||||
compiling LAMMPS for Windows systems, malloc() will always be used
|
||||
and this setting ignored.
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64
|
||||
|
||||
Do not set -DLAMMPS\_MEMALIGN, if you want to have memory allocated
|
||||
with the malloc() function call instead. -DLAMMPS\_MEMALIGN **cannot**
|
||||
Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory allocated
|
||||
with the malloc() function call instead. ``-DLAMMPS_MEMALIGN`` **cannot**
|
||||
be used on Windows, as it does use different function calls for
|
||||
allocating aligned memory, that are not compatible with how LAMMPS
|
||||
manages its dynamical memory.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _longlong:
|
||||
|
||||
Workaround for long long integers
|
||||
|
@ -424,22 +400,18 @@ those systems:
|
|||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default)
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _exceptions:
|
||||
|
||||
Exception handling when using LAMMPS as a library
|
||||
|
@ -453,14 +425,12 @@ e.g. to Python. Of course the calling code has to be set up to
|
|||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_EXCEPTIONS
|
||||
|
|
|
@ -6,10 +6,8 @@ Notes for building LAMMPS on Windows
|
|||
* :ref:`Using GNU GCC ported to Windows <gnu>`
|
||||
* :ref:`Using a cross-compiler <cross>`
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _generic:
|
||||
|
||||
General remarks
|
||||
|
@ -57,8 +55,8 @@ and the corresponding new code. A machine makefile for using cygwin for
|
|||
the old build system is provided. Using CMake for this mode of compilation
|
||||
is untested and not likely to work.
|
||||
|
||||
When compiling for Windows do **not** set the -DLAMMPS\_MEMALIGN define
|
||||
in the LMP\_INC makefile variable and add -lwsock32 -lpsapi to the linker
|
||||
When compiling for Windows do **not** set the -DLAMMPS_MEMALIGN define
|
||||
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
|
||||
flags in LIB makefile variable. Try adding -static-libgcc or -static or
|
||||
both to the linker flags when your resulting LAMMPS Windows executable
|
||||
complains about missing .dll files. The CMake configuration should set
|
||||
|
|
|
@ -4,7 +4,6 @@ Commands
|
|||
These pages describe how a LAMMPS input script is formatted and the
|
||||
commands in it are used to define a LAMMPS simulation.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -99,7 +99,6 @@ have accelerated versions. This is indicated by additional letters in
|
|||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
|
||||
.. table_from_list::
|
||||
:columns: 4
|
||||
|
||||
|
|
|
@ -16,7 +16,6 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
timestep 0.5
|
||||
|
@ -25,7 +24,6 @@ Thus this sequence of commands:
|
|||
|
||||
does something different than this sequence:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
run 100
|
||||
|
@ -48,7 +46,7 @@ is to have the desired effect. For example, the
|
|||
:doc:`read_data <read_data>` command initializes the system by setting
|
||||
up the simulation box and assigning atoms to processors. If default
|
||||
values are not desired, the :doc:`processors <processors>` and
|
||||
:doc:`boundary <boundary>` commands need to be used before read\_data to
|
||||
:doc:`boundary <boundary>` commands need to be used before read_data to
|
||||
tell LAMMPS how to map processors to the simulation box.
|
||||
|
||||
Many input script errors are detected by LAMMPS and an ERROR or
|
||||
|
|
|
@ -86,7 +86,6 @@ LAMMPS:
|
|||
|
||||
This can be useful for formatting print output to a desired precision:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
|
||||
|
@ -102,7 +101,7 @@ LAMMPS:
|
|||
print "B2 = ${b$a}"
|
||||
|
||||
Nor can you specify an expression like "$($x-1.0)" for an immediate
|
||||
variable, but you could use $(v\_x-1.0), since the latter is valid
|
||||
variable, but you could use $(v_x-1.0), since the latter is valid
|
||||
syntax for an :doc:`equal-style variable <variable>`.
|
||||
|
||||
See the :doc:`variable <variable>` command for more details of how
|
||||
|
@ -116,7 +115,7 @@ LAMMPS:
|
|||
underscores, or punctuation characters.
|
||||
|
||||
.. _five:
|
||||
|
||||
|
||||
5. The first word is the command name. All successive words in the line
|
||||
are arguments.
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ page.
|
|||
A LAMMPS input script typically has 4 parts:
|
||||
|
||||
1. :ref:`Initialization <init>`
|
||||
2. :ref:`System definition <system>`
|
||||
2. :ref:`System definition <system>`
|
||||
3. :ref:`Simulation settings <settings>`
|
||||
4. :ref:`Run a simulation <run>`
|
||||
|
||||
|
|
|
@ -7,7 +7,6 @@ and warnings doc pages give complete lists of all the messages the
|
|||
code may generate (except those generated by USER packages), with
|
||||
additional details for many of them.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Reporting bugs
|
|||
If you are confident that you have found a bug in LAMMPS, please follow the steps outlined below:
|
||||
|
||||
* Check the `New features and bug fixes
|
||||
<http://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site
|
||||
<https://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site
|
||||
<lws_>`_ to see if the bug has already been addressed in a patch.
|
||||
* Check that your issue can be reproduced with the latest development
|
||||
version of LAMMPS.
|
||||
|
@ -14,7 +14,7 @@ If you are confident that you have found a bug in LAMMPS, please follow the step
|
|||
if your issue has already been reported and if it is still open.
|
||||
* Check the `GitHub Pull Requests page <https://github.com/lammps/pulls>`_
|
||||
if there is already a fix for your bug pending.
|
||||
* Check the `mailing list archives <http://lammps.sandia.gov/mail.html>`_
|
||||
* Check the `mailing list archives <https://lammps.sandia.gov/mail.html>`_
|
||||
to see if the issue has been discussed before.
|
||||
|
||||
If none of these steps yields any useful information, please file
|
||||
|
@ -41,5 +41,5 @@ is overlooked and then forgotten. Issues on GitHub have to be explicitly
|
|||
closed, so that will *guarantee* that at least one LAMMPS developer will
|
||||
have looked at it.
|
||||
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
.. _gip: https://github.com/lammps/issues
|
||||
|
|
|
@ -39,7 +39,7 @@ figure out your physics or numerical mistakes, like choosing too big a
|
|||
timestep, specifying erroneous force field coefficients, or putting 2
|
||||
atoms on top of each other! If you run into errors that LAMMPS
|
||||
doesn't catch that you think it should flag, please send an email to
|
||||
the `developers <http://lammps.sandia.gov/authors.html>`_.
|
||||
the `developers <https://lammps.sandia.gov/authors.html>`_.
|
||||
|
||||
If you get an error message about an invalid command in your input
|
||||
script, you can determine what command is causing the problem by
|
||||
|
@ -63,25 +63,23 @@ is an integer or floating-point number, respectively, and reject the
|
|||
input with an error message (for instance, when an integer is required,
|
||||
but a floating-point number 1.0 is provided):
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
ERROR: Expected integer parameter instead of '1.0' in input script or data file
|
||||
|
||||
Some commands allow for using variable references in place of numeric
|
||||
constants so that the value can be evaluated and may change over the
|
||||
course of a run. This is typically done with the syntax *v\_name* for a
|
||||
course of a run. This is typically done with the syntax *v_name* for a
|
||||
parameter, where name is the name of the variable. On the other hand,
|
||||
immediate variable expansion with the syntax $\ *name* is performed while
|
||||
immediate variable expansion with the syntax ${name} is performed while
|
||||
reading the input and before parsing commands,
|
||||
|
||||
.. note::
|
||||
|
||||
Using a variable reference (i.e. *v\_name*) is only allowed if
|
||||
Using a variable reference (i.e. *v_name*) is only allowed if
|
||||
the documentation of the corresponding command explicitly says it is.
|
||||
Otherwise, you will receive an error message of this kind:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -7,7 +7,6 @@ documentation for the offending command may help. Warning messages
|
|||
also list the source file and line number where the warning was
|
||||
generated. For example, a message like this:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
WARNING: Bond atom missing in box size check (domain.cpp:187)
|
||||
|
@ -21,12 +20,8 @@ code or contact the author of the package.
|
|||
|
||||
Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
|
||||
|
||||
*Adjusting Coulombic cutoff for MSM, new cutoff = %g*
|
||||
The adjust/cutoff command is turned on and the Coulombic cutoff has been
|
||||
adjusted to match the user-specified accuracy.
|
||||
|
@ -42,7 +37,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
|
||||
*Angles are defined but no angle style is set*
|
||||
The topology contains angles, but there are no angle forces computed
|
||||
since there was no angle\_style command.
|
||||
since there was no angle_style command.
|
||||
|
||||
*Atom style in data file differs from currently defined atom style*
|
||||
Self-explanatory.
|
||||
|
@ -67,7 +62,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
|
||||
*Bonds are defined but no bond style is set*
|
||||
The topology contains bonds, but there are no bond forces computed
|
||||
since there was no bond\_style command.
|
||||
since there was no bond_style command.
|
||||
|
||||
*Bond/angle/dihedral extent > half of periodic box length*
|
||||
This is a restriction because LAMMPS can be confused about which image
|
||||
|
@ -88,8 +83,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
|
||||
Self-explanatory.
|
||||
|
||||
*Calling write\_dump before a full system init.*
|
||||
The write\_dump command is used before the system has been fully
|
||||
*Calling write_dump before a full system init.*
|
||||
The write_dump command is used before the system has been fully
|
||||
initialized as part of a 'run' or 'minimize' command. Not all dump
|
||||
styles and features are fully supported at this point and thus the
|
||||
command may fail or produce incomplete or incorrect output. Insert
|
||||
|
@ -136,11 +131,11 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
degrees-of-freedom for the atoms in those partial rigid bodies will
|
||||
not be accounted for.
|
||||
|
||||
*Create\_bonds max distance > minimum neighbor cutoff*
|
||||
*Create_bonds max distance > minimum neighbor cutoff*
|
||||
This means atom pairs for some atom types may not be in the neighbor
|
||||
list and thus no bond can be created between them.
|
||||
|
||||
*Delete\_atoms cutoff > minimum neighbor cutoff*
|
||||
*Delete_atoms cutoff > minimum neighbor cutoff*
|
||||
This means atom pairs for some atom types may not be in the neighbor
|
||||
list and thus an atom in that pair cannot be deleted.
|
||||
|
||||
|
@ -163,7 +158,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
|
||||
*Dihedrals are defined but no dihedral style is set*
|
||||
The topology contains dihedrals, but there are no dihedral forces computed
|
||||
since there was no dihedral\_style command.
|
||||
since there was no dihedral_style command.
|
||||
|
||||
*Dump dcd/xtc timestamp may be wrong with fix dt/reset*
|
||||
If the fix changes the timestep, the dump dcd file will not
|
||||
|
@ -177,7 +172,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
*Estimated error in splitting of dispersion coeffs is %g*
|
||||
Error is greater than 0.0001 percent.
|
||||
|
||||
*Ewald/disp Newton solver failed, using old method to estimate g\_ewald*
|
||||
*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
|
||||
Self-explanatory. Choosing a different cutoff value may help.
|
||||
|
||||
*FENE bond too long*
|
||||
|
@ -217,8 +212,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
This is probably an error, since you should not delete only one atom
|
||||
of a molecule.
|
||||
|
||||
*Fix gcmc using full\_energy option*
|
||||
Fix gcmc has automatically turned on the full\_energy option since it
|
||||
*Fix gcmc using full_energy option*
|
||||
Fix gcmc has automatically turned on the full_energy option since it
|
||||
is required for systems like the one specified by the user. User input
|
||||
included one or more of the following: kspace, triclinic, a hybrid
|
||||
pair style, an eam pair style, or no "single" function for the pair
|
||||
|
@ -273,19 +268,19 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
*Fixes cannot send data in Kokkos communication, switching to classic communication*
|
||||
This is current restriction with Kokkos.
|
||||
|
||||
*For better accuracy use 'pair\_modify table 0'*
|
||||
*For better accuracy use 'pair_modify table 0'*
|
||||
The user-specified force accuracy cannot be achieved unless the table
|
||||
feature is disabled by using 'pair\_modify table 0'.
|
||||
feature is disabled by using 'pair_modify table 0'.
|
||||
|
||||
*Geometric mixing assumed for 1/r\^6 coefficients*
|
||||
Self-explanatory.
|
||||
|
||||
*Group for fix\_modify temp != fix group*
|
||||
The fix\_modify command is specifying a temperature computation that
|
||||
*Group for fix_modify temp != fix group*
|
||||
The fix_modify command is specifying a temperature computation that
|
||||
computes a temperature on a different group of atoms than the fix
|
||||
itself operates on. This is probably not what you want to do.
|
||||
|
||||
*H matrix size has been exceeded: m\_fill=%d H.m=%d\n*
|
||||
*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
|
||||
This is the size of the matrix.
|
||||
|
||||
*Ignoring unknown or incorrect info command flag*
|
||||
|
@ -307,7 +302,7 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
|
||||
*Impropers are defined but no improper style is set*
|
||||
The topology contains impropers, but there are no improper forces computed
|
||||
since there was no improper\_style command.
|
||||
since there was no improper_style command.
|
||||
|
||||
*Inconsistent image flags*
|
||||
The image flags for a pair on bonded atoms appear to be inconsistent.
|
||||
|
@ -342,22 +337,22 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
*KIM Model does not provide 'particleVirial'; virial per atom will be zero*
|
||||
Self-explanatory.
|
||||
|
||||
*Kspace\_modify slab param < 2.0 may cause unphysical behavior*
|
||||
The kspace\_modify slab parameter should be larger to insure periodic
|
||||
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
|
||||
The kspace_modify slab parameter should be larger to insure periodic
|
||||
grids padded with empty space do not overlap.
|
||||
|
||||
*Less insertions than requested*
|
||||
The fix pour command was unsuccessful at finding open space
|
||||
for as many particles as it tried to insert.
|
||||
|
||||
*Library error in lammps\_gather\_atoms*
|
||||
*Library error in lammps_gather_atoms*
|
||||
This library function cannot be used if atom IDs are not defined
|
||||
or are not consecutively numbered.
|
||||
|
||||
*Library error in lammps\_scatter\_atoms*
|
||||
*Library error in lammps_scatter_atoms*
|
||||
This library function cannot be used if atom IDs are not defined or
|
||||
are not consecutively numbered, or if no atom map is defined. See the
|
||||
atom\_modify command for details about atom maps.
|
||||
atom_modify command for details about atom maps.
|
||||
|
||||
*Likewise 1-2 special neighbor interactions != 1.0*
|
||||
The topology contains bonds, but there is no bond style defined
|
||||
|
@ -380,15 +375,15 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
pairs in the neighbor list in expectation of interactions for
|
||||
those pairs being computed from the dihedral style.
|
||||
|
||||
*Lost atoms via change\_box: original %ld current %ld*
|
||||
*Lost atoms via change_box: original %ld current %ld*
|
||||
The command options you have used caused atoms to be lost.
|
||||
|
||||
*Lost atoms via displace\_atoms: original %ld current %ld*
|
||||
*Lost atoms via displace_atoms: original %ld current %ld*
|
||||
The command options you have used caused atoms to be lost.
|
||||
|
||||
*Lost atoms: original %ld current %ld*
|
||||
Lost atoms are checked for each time thermo output is done. See the
|
||||
thermo\_modify lost command for options. Lost atoms usually indicate
|
||||
thermo_modify lost command for options. Lost atoms usually indicate
|
||||
bad dynamics, e.g. atoms have been blown far out of the simulation
|
||||
box, or moved further than one processor's sub-domain away before
|
||||
reneighboring.
|
||||
|
@ -411,8 +406,8 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
This means the bonded atoms will not be excluded in pair-wise
|
||||
interactions.
|
||||
|
||||
*Molecule template for create\_atoms has multiple molecules*
|
||||
The create\_atoms command will only create molecules of a single type,
|
||||
*Molecule template for create_atoms has multiple molecules*
|
||||
The create_atoms command will only create molecules of a single type,
|
||||
i.e. the first molecule in the template.
|
||||
|
||||
*Molecule template for fix gcmc has multiple molecules*
|
||||
|
@ -477,21 +472,21 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
*Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
|
||||
This is because excluding specific pair interactions also excludes
|
||||
them from long-range interactions which may not be the desired effect.
|
||||
The special\_bonds command handles this consistently by insuring
|
||||
The special_bonds command handles this consistently by insuring
|
||||
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
|
||||
consistently by both the short-range pair style and the long-range
|
||||
solver. This is not done for exclusions of charged atom pairs via the
|
||||
neigh\_modify exclude command.
|
||||
neigh_modify exclude command.
|
||||
|
||||
*New thermo\_style command, previous thermo\_modify settings will be lost*
|
||||
If a thermo\_style command is used after a thermo\_modify command, the
|
||||
settings changed by the thermo\_modify command will be reset to their
|
||||
default values. This is because the thermo\_modify command acts on
|
||||
the currently defined thermo style, and a thermo\_style command creates
|
||||
*New thermo_style command, previous thermo_modify settings will be lost*
|
||||
If a thermo_style command is used after a thermo_modify command, the
|
||||
settings changed by the thermo_modify command will be reset to their
|
||||
default values. This is because the thermo_modify command acts on
|
||||
the currently defined thermo style, and a thermo_style command creates
|
||||
a new style.
|
||||
|
||||
*No Kspace calculation with verlet/split*
|
||||
The 2nd partition performs a kspace calculation so the kspace\_style
|
||||
The 2nd partition performs a kspace calculation so the kspace_style
|
||||
command must be used.
|
||||
|
||||
*No automatic unit conversion to XTC file format conventions possible for units lj*
|
||||
|
@ -515,7 +510,7 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
of two and the number of grid points in one or more directions have been
|
||||
adjusted to meet this requirement.
|
||||
|
||||
*OMP\_NUM\_THREADS environment is not set.*
|
||||
*OMP_NUM_THREADS environment is not set.*
|
||||
This environment variable must be set appropriately to use the
|
||||
USER-OMP package.
|
||||
|
||||
|
@ -549,10 +544,10 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
*Pair dpd needs newton pair on for momentum conservation*
|
||||
Self-explanatory.
|
||||
|
||||
*Pair dsmc: num\_of\_collisions > number\_of\_A*
|
||||
*Pair dsmc: num_of_collisions > number_of_A*
|
||||
Collision model in DSMC is breaking down.
|
||||
|
||||
*Pair dsmc: num\_of\_collisions > number\_of\_B*
|
||||
*Pair dsmc: num_of_collisions > number_of_B*
|
||||
Collision model in DSMC is breaking down.
|
||||
|
||||
*Pair style in data file differs from currently defined pair style*
|
||||
|
@ -577,15 +572,15 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
sub-domain before reneighboring is triggered.
|
||||
|
||||
*Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
|
||||
This may lead to a larger grid than desired. See the kspace\_modify overlap
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order.
|
||||
|
||||
*Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
|
||||
This may lead to a larger grid than desired. See the kspace\_modify overlap
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order.
|
||||
|
||||
*Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
|
||||
This may lead to a larger grid than desired. See the kspace\_modify overlap
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order.
|
||||
|
||||
*Replacing a fix, but new group != old group*
|
||||
|
@ -598,19 +593,19 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
dimension to be replicated; this may cause unwanted behavior.
|
||||
|
||||
*Resetting reneighboring criteria during PRD*
|
||||
A PRD simulation requires that neigh\_modify settings be delay = 0,
|
||||
A PRD simulation requires that neigh_modify settings be delay = 0,
|
||||
every = 1, check = yes. Since these settings were not in place,
|
||||
LAMMPS changed them and will restore them to their original values
|
||||
after the PRD simulation.
|
||||
|
||||
*Resetting reneighboring criteria during TAD*
|
||||
A TAD simulation requires that neigh\_modify settings be delay = 0,
|
||||
A TAD simulation requires that neigh_modify settings be delay = 0,
|
||||
every = 1, check = yes. Since these settings were not in place,
|
||||
LAMMPS changed them and will restore them to their original values
|
||||
after the PRD simulation.
|
||||
|
||||
*Resetting reneighboring criteria during minimization*
|
||||
Minimization requires that neigh\_modify settings be delay = 0, every =
|
||||
Minimization requires that neigh_modify settings be delay = 0, every =
|
||||
1, check = yes. Since these settings were not in place, LAMMPS
|
||||
changed them and will restore them to their original values after the
|
||||
minimization.
|
||||
|
@ -714,7 +709,7 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
which does operate on group all, so this may be inconsistent.
|
||||
|
||||
*Temperature for thermo pressure is not for group all*
|
||||
User-assigned temperature to thermo via the thermo\_modify command does
|
||||
User-assigned temperature to thermo via the thermo_modify command does
|
||||
not compute temperature for all atoms. Since thermo computes a global
|
||||
pressure, the kinetic energy contribution from the temperature is
|
||||
assumed to also be for all atoms. Thus the pressure printed by thermo
|
||||
|
@ -746,12 +741,12 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
LAMMPS simulation may be inefficient as a result.
|
||||
|
||||
*Use special bonds = 0,1,1 with bond style fene*
|
||||
Most FENE models need this setting for the special\_bonds command.
|
||||
Most FENE models need this setting for the special_bonds command.
|
||||
|
||||
*Use special bonds = 0,1,1 with bond style fene/expand*
|
||||
Most FENE models need this setting for the special\_bonds command.
|
||||
Most FENE models need this setting for the special_bonds command.
|
||||
|
||||
*Using a many-body potential with bonds/angles/dihedrals and special\_bond exclusions*
|
||||
*Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions*
|
||||
This is likely not what you want to do. The exclusion settings will
|
||||
eliminate neighbors in the neighbor list, which the many-body potential
|
||||
needs to calculated its terms correctly.
|
||||
|
@ -780,13 +775,13 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
*Using largest cutoff for lj/long/coul/long*
|
||||
Self-explanatory.
|
||||
|
||||
*Using largest cutoff for pair\_style lj/long/tip4p/long*
|
||||
*Using largest cutoff for pair_style lj/long/tip4p/long*
|
||||
Self-explanatory.
|
||||
|
||||
*Using package gpu without any pair style defined*
|
||||
Self-explanatory.
|
||||
|
||||
*Using pair potential shift with pair\_modify compute no*
|
||||
*Using pair potential shift with pair_modify compute no*
|
||||
The shift effects will thus not be computed.
|
||||
|
||||
*Using pair tail corrections with nonperiodic system*
|
||||
|
@ -794,8 +789,8 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
computed by integrating the density of a periodic system out to
|
||||
infinity.
|
||||
|
||||
*Using pair tail corrections with pair\_modify compute no*
|
||||
*Using pair tail corrections with pair_modify compute no*
|
||||
The tail corrections will thus not be computed.
|
||||
|
||||
*pair style reax is now deprecated and will soon be retired. Users should switch to pair\_style reax/c*
|
||||
*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
|
||||
Self-explanatory.
|
||||
|
|
|
@ -18,7 +18,7 @@ files and image files.
|
|||
|
||||
If you uncomment the :doc:`dump <dump>` command in the input script, a
|
||||
text dump file will be produced, which can be animated by various
|
||||
`visualization programs <http://lammps.sandia.gov/viz.html>`_.
|
||||
`visualization programs <https://lammps.sandia.gov/viz.html>`_.
|
||||
|
||||
If you uncomment the :doc:`dump image <dump>` command in the input
|
||||
script, and assuming you have built LAMMPS with a JPG library, JPG
|
||||
|
@ -38,10 +38,8 @@ particular quantity.
|
|||
|
||||
Lists of both kinds of directories are given below.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Lowercase directories
|
||||
---------------------
|
||||
|
||||
|
@ -134,7 +132,7 @@ Lowercase directories
|
|||
+-------------+------------------------------------------------------------------+
|
||||
| reax | RDX and TATB models using the ReaxFF |
|
||||
+-------------+------------------------------------------------------------------+
|
||||
| rerun | use of rerun and read\_dump commands |
|
||||
| rerun | use of rerun and read_dump commands |
|
||||
+-------------+------------------------------------------------------------------+
|
||||
| rigid | rigid bodies modeled as independent or coupled |
|
||||
+-------------+------------------------------------------------------------------+
|
||||
|
@ -157,8 +155,7 @@ Lowercase directories
|
|||
|
||||
Here is how you can run and visualize one of the sample problems:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: bash
|
||||
|
||||
cd indent
|
||||
cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
|
||||
|
@ -167,28 +164,25 @@ Here is how you can run and visualize one of the sample problems:
|
|||
Running the simulation produces the files *dump.indent* and
|
||||
*log.lammps*\ . You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
`Visualization <http://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
|
||||
`Visualization <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
|
||||
web site.
|
||||
|
||||
If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see the
|
||||
:doc:`Build\_settings <Build_settings>` doc page for details). These can
|
||||
:doc:`Build_settings <Build_settings>` doc page for details). These can
|
||||
be viewed individually or turned into a movie or animated by tools
|
||||
like ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
:doc:`dump image <dump_image>` doc page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
% convert -loop 1 \*.jpg foo.gif
|
||||
|
||||
% convert -loop 1 *.jpg foo.gif
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Uppercase directories
|
||||
---------------------
|
||||
|
||||
|
@ -201,7 +195,7 @@ Uppercase directories
|
|||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| ELASTIC | compute elastic constants at zero temperature |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| ELASTIC\_T | compute elastic constants at finite temperature |
|
||||
| ELASTIC_T | compute elastic constants at finite temperature |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| HEAT | compute thermal conductivity for LJ and water via fix ehex |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
|
@ -225,8 +219,8 @@ The USER directory has a large number of sub-directories which
|
|||
correspond by name to a USER package. They contain scripts that
|
||||
illustrate how to use the command(s) provided in that package. Many
|
||||
of the sub-directories have their own README files which give further
|
||||
instructions. See the :doc:`Packages\_details <Packages_details>` doc
|
||||
instructions. See the :doc:`Packages_details <Packages_details>` doc
|
||||
page for more info on specific USER packages.
|
||||
|
||||
.. _openkim: https://openkim.org
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
|
|
@ -3,7 +3,7 @@ Howto discussions
|
|||
|
||||
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
|
||||
`glossary <https://lammps.sandia.gov>`_ website page also lists MD
|
||||
terminology with links to corresponding LAMMPS manual pages. The
|
||||
example input scripts included in the examples directory of the LAMMPS
|
||||
distribution and highlighted on the :doc:`Examples <Examples>` doc page
|
||||
|
@ -12,7 +12,6 @@ also show how to setup and run various kinds of simulations.
|
|||
Tutorials howto
|
||||
===============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: tutorials
|
||||
:maxdepth: 1
|
||||
|
@ -24,7 +23,6 @@ Tutorials howto
|
|||
General howto
|
||||
=============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: general_howto
|
||||
:maxdepth: 1
|
||||
|
@ -40,7 +38,6 @@ General howto
|
|||
Settings howto
|
||||
==============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: settings_howto
|
||||
:maxdepth: 1
|
||||
|
@ -56,7 +53,6 @@ Settings howto
|
|||
Analysis howto
|
||||
==============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: analysis_howto
|
||||
:maxdepth: 1
|
||||
|
@ -72,7 +68,6 @@ Analysis howto
|
|||
Force fields howto
|
||||
==================
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: force_howto
|
||||
:maxdepth: 1
|
||||
|
@ -85,7 +80,6 @@ Force fields howto
|
|||
Packages howto
|
||||
==============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:name: packages_howto
|
||||
:maxdepth: 1
|
||||
|
|
|
@ -8,17 +8,16 @@ command. This is the default.
|
|||
|
||||
If using the :doc:`create box <create_box>` command to define a
|
||||
simulation box, set the z dimensions narrow, but finite, so that the
|
||||
create\_atoms command will tile the 3d simulation box with a single z
|
||||
create_atoms command will tile the 3d simulation box with a single z
|
||||
plane of atoms - e.g.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
:doc:`create box <create_box>` 1 -10 10 -10 10 -0.25 0.25
|
||||
|
||||
If using the :doc:`read data <read_data>` command to read in a file of
|
||||
atom coordinates, set the "zlo zhi" values to be finite but narrow,
|
||||
similar to the create\_box command settings just described. For each
|
||||
similar to the create_box command settings just described. For each
|
||||
atom in the file, assign a z coordinate so it falls inside the
|
||||
z-boundaries of the box - e.g. 0.0.
|
||||
|
||||
|
|
|
@ -3,10 +3,8 @@ Using LAMMPS with Bash on Windows
|
|||
|
||||
**written by Richard Berger**
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
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
|
||||
|
@ -82,10 +80,8 @@ Congratulations, you have installed **Bash on Ubuntu on Windows**\ .
|
|||
|
||||
.. image:: JPG/bow_tutorial_10.png
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Compiling LAMMPS in Bash on Windows
|
||||
-----------------------------------
|
||||
|
||||
|
@ -97,7 +93,6 @@ Installing prerequisite packages
|
|||
|
||||
First upgrade all existing packages using
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt update
|
||||
|
@ -106,7 +101,6 @@ First upgrade all existing packages using
|
|||
Next install the following packages, which include compilers and libraries
|
||||
needed for various LAMMPS features:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt install -y build-essential ccache gfortran openmpi-bin libopenmpi-dev libfftw3-dev libjpeg-dev libpng12-dev python-dev python-virtualenv libblas-dev liblapack-dev libhdf5-serial-dev hdf5-tools
|
||||
|
@ -126,17 +120,15 @@ Obtain a copy of the LAMMPS code and go into it using "cd"
|
|||
Option 1: Downloading LAMMPS tarball using wget
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
wget http://lammps.sandia.gov/tars/lammps-stable.tar.gz
|
||||
wget https://lammps.sandia.gov/tars/lammps-stable.tar.gz
|
||||
tar xvzf lammps-stable.tar.gz
|
||||
cd lammps-31Mar17
|
||||
|
||||
Option 2: Obtaining LAMMPS code from GitHub
|
||||
"""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git clone https://github.com/lammps/lammps.git
|
||||
|
@ -150,39 +142,33 @@ At this point you can compile LAMMPS like on Ubuntu Linux.
|
|||
Compiling serial version
|
||||
""""""""""""""""""""""""
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/
|
||||
make -j 4 serial
|
||||
|
||||
This will create an executable called lmp\_serial in the src/ directory
|
||||
This will create an executable called lmp_serial in the src/ directory
|
||||
|
||||
Compiling MPI version
|
||||
"""""""""""""""""""""
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/
|
||||
make -j 4 mpi
|
||||
|
||||
This will create an executable called lmp\_mpi in the src/ directory
|
||||
|
||||
This will create an executable called lmp_mpi in the src/ directory
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Finally, please note the absolute path of your src folder. You can get this using
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pwd
|
||||
|
||||
or
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
echo $PWD
|
||||
|
@ -190,43 +176,37 @@ or
|
|||
To run any examples you need the location of the executable. For now, let us
|
||||
save this location in a temporary variable
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
LAMMPS_DIR=$PWD
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Running an example script
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once compiled you can execute some of the LAMMPS examples. Switch into the
|
||||
examples/melt folder
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd ../examples/melt
|
||||
|
||||
The full path of the serial executable is $LAMMPS\_DIR/lmp\_serial, while the mpi
|
||||
version is $LAMMPS\_DIR/lmp\_mpi. You can run the melt example with either
|
||||
The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
|
||||
version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
|
||||
version as follows:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$LAMMPS_DIR/lmp_serial -in in.melt
|
||||
|
||||
or
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt
|
||||
|
||||
Note the use of our variable $LAMMPS\_DIR, which expands into the full path of
|
||||
Note the use of our variable $LAMMPS_DIR, which expands into the full path of
|
||||
the LAMMPS src folder we saved earlier.
|
||||
|
||||
Adding your executable directory to your PATH
|
||||
|
@ -235,21 +215,18 @@ Adding your executable directory to your PATH
|
|||
You can avoid having to type the full path of your LAMMPS binary by adding its
|
||||
parent folder to the PATH environment variable as follows:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export PATH=$LAMMPS_DIR:$PATH
|
||||
|
||||
Input scripts can then be run like this:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
lmp_serial -in in.melt
|
||||
|
||||
or
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpirun -np 4 lmp_mpi -in in.melt
|
||||
|
@ -258,15 +235,13 @@ However, this PATH variable will not persist if you close your bash window.
|
|||
To persist this setting edit the $HOME/.bashrc file using your favorite editor
|
||||
and add this line
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export PATH=/full/path/to/your/lammps/src:$PATH
|
||||
|
||||
**Example:**
|
||||
|
||||
For an executable lmp\_serial with a full path
|
||||
|
||||
For an executable lmp_serial with a full path
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -274,7 +249,6 @@ For an executable lmp\_serial with a full path
|
|||
|
||||
the PATH variable should be
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export PATH=/home/richard/lammps/src:$PATH
|
||||
|
|
|
@ -20,12 +20,8 @@ force field.
|
|||
|
||||
.. _charmm: http://www.scripps.edu/brooks
|
||||
|
||||
|
||||
|
||||
.. _amber: http://amber.scripps.edu
|
||||
|
||||
|
||||
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with common options in CHARMM or AMBER. See each
|
||||
command's documentation for the formula it computes.
|
||||
|
@ -114,33 +110,23 @@ documentation for the formula it computes.
|
|||
|
||||
* :doc:`special_bonds <special_bonds>` dreiding
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _howto-MacKerell:
|
||||
|
||||
|
||||
|
||||
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
.. _howto-Cornell:
|
||||
|
||||
|
||||
|
||||
**(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
|
||||
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
|
||||
|
||||
.. _howto-Sun:
|
||||
|
||||
|
||||
|
||||
**(Sun)** Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
|
||||
|
||||
.. _howto-Mayo:
|
||||
|
||||
|
||||
|
||||
**(Mayo)** Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
||||
|
|
|
@ -33,10 +33,8 @@ style are described below.
|
|||
More styles may be added in the future. See the :doc:`Modify body <Modify_body>` doc page for details on how to add a new body
|
||||
style to the code.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**When to use body particles:**
|
||||
|
||||
You should not use body particles to model a rigid body made of
|
||||
|
@ -104,10 +102,8 @@ particles of different styles
|
|||
The pair styles defined for use with specific body styles are listed
|
||||
in the sections below.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Specifics of body style nparticle:**
|
||||
|
||||
The *nparticle* body style represents body particles as a rigid body
|
||||
|
@ -116,10 +112,9 @@ vanilla, prototypical example of a body particle, although as
|
|||
mentioned above, the :doc:`fix rigid <fix_rigid>` command already
|
||||
duplicates its functionality.
|
||||
|
||||
The atom\_style body command for this body style takes two additional
|
||||
The atom_style body command for this body style takes two additional
|
||||
arguments:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom_style body nparticle Nmin Nmax
|
||||
|
@ -133,7 +128,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
|
|||
body style, the following information must be provided for each entry
|
||||
in the *Bodies* section of the data file:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom-ID 1 M
|
||||
|
@ -170,7 +164,6 @@ For output purposes via the :doc:`compute body/local <compute_body_local>` and :
|
|||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 = x position of sub-particle
|
||||
|
@ -188,26 +181,23 @@ collection of spheres, one for each sub-particle. The size of each
|
|||
sphere is determined by the *bflag1* parameter for the *body* keyword.
|
||||
The *bflag2* argument is ignored.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Specifics of body style rounded/polygon:**
|
||||
|
||||
The *rounded/polygon* body style represents body particles as a 2d
|
||||
polygon with a variable number of N vertices. This style can only be
|
||||
used for 2d models; see the :doc:`boundary <boundary>` command. See the
|
||||
"pair\_style body/rounded/polygon" doc page for a diagram of two
|
||||
"pair_style body/rounded/polygon" doc page for a diagram of two
|
||||
squares with rounded circles at the vertices. Special cases for N = 1
|
||||
(circle) and N = 2 (rod with rounded ends) can also be specified.
|
||||
|
||||
One use of this body style is for 2d discrete element models, as
|
||||
described in :ref:`Fraige <body-Fraige>`.
|
||||
|
||||
Similar to body style *nparticle*\ , the atom\_style body command for
|
||||
Similar to body style *nparticle*\ , the atom_style body command for
|
||||
this body style takes two additional arguments:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom_style body rounded/polygon Nmin Nmax
|
||||
|
@ -221,7 +211,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
|
|||
body style, the following information must be provided for each entry
|
||||
in the *Bodies* section of the data file:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom-ID 1 M
|
||||
|
@ -262,7 +251,6 @@ orientation of the square is aligned with the xy coordinate axes which
|
|||
is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
|
||||
1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
3 1 27
|
||||
|
@ -281,7 +269,6 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
|
|||
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 1 13
|
||||
|
@ -293,7 +280,6 @@ by circles of diameter 0.5, is specified as follows:
|
|||
|
||||
A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 1 10
|
||||
|
@ -308,16 +294,14 @@ interactions. The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
|
|||
command can be used with this body style to compute the interaction of
|
||||
body particles with a wall.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Specifics of body style rounded/polyhedron:**
|
||||
|
||||
The *rounded/polyhedron* body style represents body particles as a 3d
|
||||
polyhedron with a variable number of N vertices, E edges and F faces.
|
||||
This style can only be used for 3d models; see the
|
||||
:doc:`boundary <boundary>` command. See the "pair\_style
|
||||
:doc:`boundary <boundary>` command. See the "pair_style
|
||||
body/rounded/polygon" doc page for a diagram of a two 2d squares with
|
||||
rounded circles at the vertices. A 3d cube with rounded spheres at
|
||||
the 8 vertices and 12 rounded edges would be similar. Special cases
|
||||
|
@ -327,10 +311,9 @@ specified.
|
|||
This body style is for 3d discrete element models, as described in
|
||||
:ref:`Wang <body-Wang>`.
|
||||
|
||||
Similar to body style *rounded/polygon*\ , the atom\_style body command
|
||||
Similar to body style *rounded/polygon*\ , the atom_style body command
|
||||
for this body style takes two additional arguments:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom_style body rounded/polyhedron Nmin Nmax
|
||||
|
@ -344,7 +327,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
|
|||
body style, the following information must be provided for each entry
|
||||
in the *Bodies* section of the data file:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
atom-ID 3 M
|
||||
|
@ -401,7 +383,6 @@ The orientation of the cube is aligned with the xyz coordinate axes
|
|||
which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
|
||||
iyz = 0.667 0.667 0.667 0 0 0.
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 3 79
|
||||
|
@ -438,7 +419,6 @@ iyz = 0.667 0.667 0.667 0 0 0.
|
|||
A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 1 13
|
||||
|
@ -450,7 +430,6 @@ by circles of diameter 0.5, is specified as follows:
|
|||
|
||||
A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 1 10
|
||||
|
@ -465,15 +444,12 @@ be used with this body style to compute body/body interactions. The
|
|||
used with this body style to compute the interaction of body particles
|
||||
with a wall.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
For output purposes via the :doc:`compute body/local <compute_body_local>` and :doc:`dump local <dump>`
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
1 = x position of vertex
|
||||
|
@ -495,20 +471,14 @@ tangent to the spheres). The drawn diameter of each line segment is
|
|||
determined by the *bflag1* parameter for the *body* keyword. The
|
||||
*bflag2* argument is ignored.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _body-Fraige:
|
||||
|
||||
|
||||
|
||||
**(Fraige)** F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).
|
||||
|
||||
.. _body-Wang:
|
||||
|
||||
|
||||
|
||||
**(Wang)** J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
|
||||
Matter, 13, 1 (2011).
|
||||
|
|
|
@ -110,7 +110,7 @@ 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. The output can be used in
|
||||
output, with one or more values per chunk. The output can be used in
|
||||
various ways:
|
||||
|
||||
* As input to the :doc:`fix ave/time <fix_ave_time>` command, which can
|
||||
|
@ -150,7 +150,6 @@ properties:
|
|||
|
||||
(1) Average velocity in each of 1000 2d spatial bins:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
|
@ -159,7 +158,6 @@ properties:
|
|||
(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
|
@ -168,7 +166,6 @@ velocity:
|
|||
|
||||
(3) Center of mass of each molecule:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
|
@ -177,7 +174,6 @@ velocity:
|
|||
|
||||
(4) Total force on each molecule and ave/max across all molecules:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
|
@ -189,7 +185,6 @@ velocity:
|
|||
|
||||
(5) Histogram of cluster sizes:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute cluster all cluster/atom 1.0
|
||||
|
|
|
@ -62,7 +62,7 @@ below. The MESSAGE package also wraps a client/server library called
|
|||
CSlib which enables two codes to exchange messages in different ways,
|
||||
either via files, sockets, or MPI. The CSlib is provided with LAMMPS
|
||||
in the lib/message dir. The CSlib has its own
|
||||
`website <http://cslib.sandia.gov>`_ with documentation and test
|
||||
`website <https://cslib.sandia.gov>`_ with documentation and test
|
||||
programs.
|
||||
|
||||
.. note::
|
||||
|
@ -93,22 +93,22 @@ client or server code:
|
|||
|
||||
* examples/message
|
||||
* examples/COUPLE/README
|
||||
* examples/COUPLE/lammps\_mc
|
||||
* examples/COUPLE/lammps\_nwchem
|
||||
* examples/COUPLE/lammps\_vasp
|
||||
* examples/COUPLE/lammps_mc
|
||||
* examples/COUPLE/lammps_nwchem
|
||||
* examples/COUPLE/lammps_vasp
|
||||
|
||||
The examples/message directory couples a client instance of LAMMPS to a
|
||||
server instance of LAMMPS.
|
||||
|
||||
The files in the *lammps\_mc* folder show how to couple LAMMPS as
|
||||
The files in the *lammps_mc* folder show how to couple LAMMPS as
|
||||
a server to a simple Monte Carlo client code as the driver.
|
||||
|
||||
The files in the *lammps\_nwchem* folder show how to couple LAMMPS
|
||||
The files in the *lammps_nwchem* folder show how to couple LAMMPS
|
||||
as a client code running MD timestepping to NWChem acting as a
|
||||
server providing quantum DFT forces, through a Python wrapper script
|
||||
on NWChem.
|
||||
|
||||
The files in the *lammps\_vasp* folder show how to couple LAMMPS as
|
||||
The files in the *lammps_vasp* folder show how to couple LAMMPS as
|
||||
a client code running MD timestepping to VASP acting as a server
|
||||
providing quantum DFT forces, through a Python wrapper script on VASP.
|
||||
|
||||
|
@ -134,7 +134,6 @@ together to exchange MPI messages between them.
|
|||
|
||||
For message exchange in *file*\ , *zmq*\ , or *mpi/two* modes:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% mpirun -np 1 lmp_mpi -log log.client < in.client &
|
||||
|
@ -150,7 +149,6 @@ For message exchange in *mpi/one* mode:
|
|||
|
||||
Launch both codes in a single mpirun command:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server
|
||||
|
|
|
@ -24,7 +24,6 @@ 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:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
432 atoms # core and shell atoms
|
||||
|
@ -87,7 +86,6 @@ Ewald solvers can be used.
|
|||
For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_style born/coul/long/cs 20.0 20.0
|
||||
|
@ -131,7 +129,6 @@ this temperature be output for the overall system.
|
|||
|
||||
For the NaCl example, this can be done as follows:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
group cores type 1 2
|
||||
|
@ -150,7 +147,6 @@ the default :doc:`temperature <compute_temp>` and specifying it as a
|
|||
second argument in :doc:`fix modify <fix_modify>` and
|
||||
:doc:`thermo_modify <thermo_modify>` resulting in:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
(...)
|
||||
|
@ -174,7 +170,6 @@ the pairs. This can be done by using the *bias* keyword of the
|
|||
:doc:`velocity create <velocity>` command and assigning the :doc:`compute temp/cs <compute_temp_cs>` command to the *temp* keyword of the
|
||||
:doc:`velocity <velocity>` command, e.g.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
velocity all create 1427 134 bias yes temp CSequ
|
||||
|
@ -211,7 +206,6 @@ pairs as chunks.
|
|||
|
||||
For example if core/shell pairs are the only molecules:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
read_data NaCl_CS_x0.1_prop.data
|
||||
|
@ -222,7 +216,6 @@ For example if core/shell pairs are the only molecules:
|
|||
|
||||
For example if core/shell pairs and other molecules are present:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix csinfo all property/atom i_CSID # property/atom command
|
||||
|
@ -232,7 +225,6 @@ For example if core/shell pairs and other molecules are present:
|
|||
|
||||
The additional section in the date file would be formatted like this:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
CS-Info # header of additional section
|
||||
|
@ -247,20 +239,14 @@ The additional section in the date file would be formatted like this:
|
|||
8 4
|
||||
(...)
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _MitchellFincham:
|
||||
|
||||
|
||||
|
||||
**(Mitchell and Fincham)** Mitchell, Fincham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
|
||||
.. _MitchellFincham2:
|
||||
|
||||
|
||||
|
||||
**(Fincham)** Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
|
||||
6, 393-404 (1994).
|
||||
|
|
|
@ -12,10 +12,8 @@ LAMMPS can be coupled to other codes in at least 4 ways. Each has
|
|||
advantages and disadvantages, which you will have to think about in the
|
||||
context of your application.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
(1) Define a new :doc:`fix <fix>` command that calls the other code. In
|
||||
this scenario, LAMMPS is the driver code. During its timestepping,
|
||||
the fix is invoked, and can make library calls to the other code,
|
||||
|
@ -27,12 +25,8 @@ LAMMPS.
|
|||
|
||||
.. _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
|
||||
|
@ -53,10 +47,8 @@ command writes and reads.
|
|||
See the :doc:`Modify command <Modify_command>` 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.
|
||||
|
@ -72,21 +64,16 @@ examples/COUPLE/README for more details:
|
|||
library
|
||||
* plugin: simple driver program in C which invokes LAMMPS as a plugin
|
||||
from a shared library.
|
||||
* lammps\_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
|
||||
* lammps_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
|
||||
MD with quantum forces calculated by a density functional code
|
||||
* lammps\_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
|
||||
* lammps_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
|
||||
a kinetic Monte Carlo model for grain growth using MD to calculate
|
||||
strain induced across grain boundaries
|
||||
|
||||
|
||||
.. _quest: http://dft.sandia.gov/Quest
|
||||
|
||||
|
||||
|
||||
.. _spparks: http://www.sandia.gov/~sjplimp/spparks.html
|
||||
|
||||
|
||||
|
||||
The :doc:`Build basics <Build_basics>` doc page 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
|
||||
|
@ -102,7 +89,7 @@ The files src/library.cpp and library.h contain the C-style interface
|
|||
to LAMMPS. See the :doc:`Howto library <Howto_library>` doc page for a
|
||||
description of the interface and how to extend it for your needs.
|
||||
|
||||
Note that the lammps\_open() function that creates an instance of
|
||||
Note that the lammps_open() function that creates an instance of
|
||||
LAMMPS takes an MPI communicator as an argument. This means that
|
||||
instance of LAMMPS will run on the set of processors in the
|
||||
communicator. Thus the calling code can run LAMMPS on all or a subset
|
||||
|
@ -113,10 +100,8 @@ 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.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
(4) Couple LAMMPS with another code in a client/server mode. This is
|
||||
described on the :doc:`Howto client/server <Howto_client_server>` doc
|
||||
page.
|
||||
|
|
|
@ -29,7 +29,7 @@ that provide fast and accurate simulations, there are two approaches,
|
|||
which both have their up- and downsides.
|
||||
|
||||
The first approach is to set desired real-space an kspace accuracies
|
||||
via the *kspace\_modify force/disp/real* and *kspace\_modify
|
||||
via the *kspace_modify force/disp/real* and *kspace_modify
|
||||
force/disp/kspace* commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependent on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
|
@ -37,14 +37,14 @@ accurate and efficient computations for the real-space and kspace
|
|||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the *kspace\_modify diff
|
||||
ad* and *kspace\_modify diff ik* options. The downside of the method
|
||||
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
|
||||
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
|
||||
|
@ -60,12 +60,12 @@ To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
|||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the *kspace\_modify disp/auto yes*
|
||||
message can be suppressed using the *kspace_modify disp/auto yes*
|
||||
command.
|
||||
|
||||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the *kspace\_modify force/disp/real* and
|
||||
*kspace\_modify force/disp/kspace* commands, write down the PPPM
|
||||
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 output, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
@ -82,8 +82,8 @@ The second is that the mixing rule of the pair style has an impact on
|
|||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the *kspace\_modify
|
||||
mix/disp geom* and *kspace\_modify splittol* commands. The first
|
||||
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
|
||||
|
@ -94,7 +94,7 @@ command, but will usually also not provide an equally good increase of
|
|||
efficiency.
|
||||
|
||||
Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the *kspace\_modify mix/disp none* command.
|
||||
This can be achieved using the *kspace_modify mix/disp none* command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
||||
|
|
|
@ -48,7 +48,7 @@ for a Langevin thermostat, or :doc:`fix drude/transform/\* <fix_drude_transform>
|
|||
thermostat. The former requires use of the command :doc:`comm_modify vel yes <comm_modify>`. The latter requires two separate integration
|
||||
fixes like *nvt* or *npt*\ . The correct temperatures of the reduced
|
||||
degrees of freedom can be calculated using the :doc:`compute temp/drude <compute_temp_drude>`. This requires also to use the
|
||||
command *comm\_modify vel yes*.
|
||||
command *comm_modify vel yes*.
|
||||
|
||||
Short-range damping of the induced dipole interactions can be achieved
|
||||
using Thole functions through the :doc:`pair style thole <pair_thole>` in :doc:`pair_style hybrid/overlay <pair_hybrid>`
|
||||
|
@ -56,12 +56,8 @@ 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.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _howto-Lamoureux:
|
||||
|
||||
|
||||
|
||||
**(Lamoureux and Roux)** G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
|
||||
|
|
|
@ -30,7 +30,6 @@ zero. The (half-)stiffness of the :doc:`harmonic bond <bond_harmonic>`
|
|||
:math:`K_D = k_D/2` and the Drude charge :math:`q_D` are related to the atom
|
||||
polarizability :math:`\alpha` by
|
||||
|
||||
|
||||
.. math::
|
||||
|
||||
K_D = \frac 1 2\, \frac {q_D^2} \alpha
|
||||
|
@ -46,7 +45,6 @@ fields:
|
|||
* Alternately :ref:`Schroeder and Steinhauser <Schroeder>` suggest adopting a global charge :math:`q_D` = -1.0e and a global mass :math:`m_D` = 0.1 g/mol (or u) for all Drude particles, and to calculate the force constant for each type of core-Drude bond from equation (1). The timesteps used by these authors are between 0.5 and 2 fs, with the degrees of freedom of the Drude oscillators kept cold at 1 K.
|
||||
* In both these force fields hydrogen atoms are treated as non-polarizable.
|
||||
|
||||
|
||||
The motion of of the Drude particles can be calculated by minimizing
|
||||
the energy of the induced dipoles at each timestep, by an iterative,
|
||||
self-consistent procedure. The Drude particles can be massless and
|
||||
|
@ -78,15 +76,14 @@ important features:
|
|||
**Preparation of the data file**
|
||||
|
||||
The data file is similar to a standard LAMMPS data file for
|
||||
*atom\_style full*. The DPs and the *harmonic bonds* connecting them
|
||||
*atom_style full*. The DPs and the *harmonic bonds* connecting them
|
||||
to their DC should appear in the data file as normal atoms and bonds.
|
||||
|
||||
You can use the *polarizer* tool (Python script distributed with the
|
||||
USER-DRUDE package) to convert a non-polarizable data file (here
|
||||
*data.102494.lmp*\ ) to a polarizable data file (\ *data-p.lmp*\ )
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: bash
|
||||
|
||||
polarizer -q -f phenol.dff data.102494.lmp data-p.lmp
|
||||
|
||||
|
@ -96,7 +93,6 @@ from *phenol.dff*\ , as well as the DC-DP bond constants. The file
|
|||
*phenol.dff* contains the polarizabilities of the atom types
|
||||
and the mass of the Drude particles, for instance:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
# units: kJ/mol, A, deg
|
||||
|
@ -113,7 +109,6 @@ have to be specified as comments at the end of lines of the *Masses*
|
|||
section. You probably need to edit it to add these names. It should
|
||||
look like
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Masses
|
||||
|
@ -124,10 +119,8 @@ look like
|
|||
4 1.008 # HA
|
||||
5 1.008 # HO
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Basic input file**
|
||||
|
||||
The atom style should be set to (or derive from) *full*\ , so that you
|
||||
|
@ -138,7 +131,6 @@ script (the use of these lines will be explained below). In order for
|
|||
LAMMPS to recognize that you are using Drude oscillators, you should
|
||||
use the fix *drude*\ . The command is
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix DRUDE all drude C C C N N D D D
|
||||
|
@ -159,7 +151,6 @@ command. With our phenol, there is 1 more special neighbor for which
|
|||
space is required. Otherwise LAMMPS crashes and gives the required
|
||||
value.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
read_data data-p.lmp extra/special/per/atom 1
|
||||
|
@ -168,30 +159,27 @@ Let us assume we want to run a simple NVT simulation at 300 K. Note
|
|||
that Drude oscillators need to be thermalized at a low temperature in
|
||||
order to approximate a self-consistent field (SCF), therefore it is not
|
||||
possible to simulate an NVE ensemble with this package. Since dipoles
|
||||
are approximated by a charged DC-DP pair, the *pair\_style* must
|
||||
are approximated by a charged DC-DP pair, the *pair_style* must
|
||||
include Coulomb interactions, for instance *lj/cut/coul/long* with
|
||||
*kspace\_style pppm*. For example, with a cutoff of 10. and a precision
|
||||
*kspace_style pppm*. For example, with a cutoff of 10. and a precision
|
||||
1.e-4:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_style lj/cut/coul/long 10.0
|
||||
kspace_style pppm 1.0e-4
|
||||
|
||||
As compared to the non-polarizable input file, *pair\_coeff* lines need
|
||||
As compared to the non-polarizable input file, *pair_coeff* lines need
|
||||
to be added for the DPs. Since the DPs have no Lennard-Jones
|
||||
interactions, their :math:`\epsilon` is 0. so the only *pair\_coeff* line
|
||||
interactions, their :math:`\epsilon` is 0. so the only *pair_coeff* line
|
||||
that needs to be added is
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_coeff * 6* 0.0 0.0 # All-DPs
|
||||
|
||||
Now for the thermalization, the simplest choice is to use the :doc:`fix langevin/drude <fix_langevin_drude>`.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix LANG all langevin/drude 300. 100 12435 1. 20 13977
|
||||
|
@ -205,7 +193,6 @@ atoms need to be in this fix's group. LAMMPS will thermostat the DPs
|
|||
together with their DC. For this, ghost atoms need to know their
|
||||
velocities. Thus you need to add the following command:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
comm_modify vel yes
|
||||
|
@ -217,7 +204,6 @@ can add the *zero yes* option at the end of the fix line.
|
|||
If the fix *shake* is used to constrain the C-H bonds, it should be
|
||||
invoked after the fix *langevin/drude* for more accuracy.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix SHAKE ATOMS shake 0.0001 20 0 t 4 5
|
||||
|
@ -231,16 +217,14 @@ Since the fix *langevin/drude* does not perform time integration (just
|
|||
modification of forces but no position/velocity updates), the fix
|
||||
*nve* should be used in conjunction.
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix NVE all nve
|
||||
|
||||
Finally, do not forget to update the atom type elements if you use
|
||||
them in a *dump\_modify ... element ...* command, by adding the element
|
||||
them in a *dump_modify ... element ...* command, by adding the element
|
||||
type of the DPs. Here for instance
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
dump DUMP all custom 10 dump.lammpstrj id mol type element x y z ix iy iz
|
||||
|
@ -248,30 +232,26 @@ type of the DPs. Here for instance
|
|||
|
||||
The input file should now be ready for use!
|
||||
|
||||
You will notice that the global temperature *thermo\_temp* computed by
|
||||
You will notice that the global temperature *thermo_temp* computed by
|
||||
LAMMPS is not 300. K as wanted. This is because LAMMPS treats DPs as
|
||||
standard atoms in his default compute. If you want to output the
|
||||
temperatures of the DC-DP pair centers of mass and of the DPs relative
|
||||
to their DCs, you should use the :doc:`compute temp\_drude <compute_temp_drude>`
|
||||
|
||||
to their DCs, you should use the :doc:`compute temp_drude <compute_temp_drude>`
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute TDRUDE all temp/drude
|
||||
|
||||
And then output the correct temperatures of the Drude oscillators
|
||||
using *thermo\_style custom* with respectively *c\_TDRUDE[1]* and
|
||||
*c\_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
|
||||
|
||||
using *thermo_style custom* with respectively *c_TDRUDE[1]* and
|
||||
*c_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
thermo_style custom step temp c_TDRUDE[1] c_TDRUDE[2]
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Thole screening**
|
||||
|
||||
Dipolar interactions represented by point charges on springs may not
|
||||
|
@ -283,29 +263,27 @@ between nearby dipoles on the same molecule may be exaggerated. Often,
|
|||
special bond relations prevent bonded neighboring atoms to see the
|
||||
charge of each other's DP, so that the problem does not always appear.
|
||||
It is possible to use screened dipole-dipole interactions by using the
|
||||
:doc:`*pair\_style thole* <pair_thole>`. This is implemented as a
|
||||
correction to the Coulomb pair\_styles, which dampens at short distance
|
||||
:doc:`*pair_style thole* <pair_thole>`. This is implemented as a
|
||||
correction to the Coulomb pair_styles, which dampens at short distance
|
||||
the interactions between the charges representing the induced dipoles.
|
||||
It is to be used as *hybrid/overlay* with any standard *coul* pair
|
||||
style. In our example, we would use
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0
|
||||
|
||||
This tells LAMMPS that we are using two pair\_styles. The first one is
|
||||
This tells LAMMPS that we are using two pair_styles. The first one is
|
||||
as above (\ *lj/cut/coul/long 10.0*\ ). The second one is a *thole*
|
||||
pair\_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
|
||||
pair_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
|
||||
cutoff 10.0.
|
||||
|
||||
Since *hybrid/overlay* does not support mixing rules, the interaction
|
||||
coefficients of all the pairs of atom types with i < j should be
|
||||
explicitly defined. The output of the *polarizer* script can be used
|
||||
to complete the *pair\_coeff* section of the input file. In our
|
||||
to complete the *pair_coeff* section of the input file. In our
|
||||
example, this will look like:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_coeff 1 1 lj/cut/coul/long 0.0700 3.550
|
||||
|
@ -346,31 +324,27 @@ For the *thole* pair style the coefficients are
|
|||
|
||||
#. the atom polarizability in units of cubic length
|
||||
#. the screening factor of the Thole function (optional, default value
|
||||
specified by the pair\_style command)
|
||||
#. the cutoff (optional, default value defined by the pair\_style command)
|
||||
|
||||
specified by the pair_style command)
|
||||
#. the cutoff (optional, default value defined by the pair_style command)
|
||||
|
||||
The special neighbors have charge-charge and charge-dipole
|
||||
interactions screened by the *coul* factors of the *special\_bonds*
|
||||
interactions screened by the *coul* factors of the *special_bonds*
|
||||
command (0.0, 0.0, and 0.5 in the example above). Without using the
|
||||
pair\_style *thole*\ , dipole-dipole interactions are screened by the
|
||||
same factor. By using the pair\_style *thole*\ , dipole-dipole
|
||||
pair_style *thole*\ , dipole-dipole interactions are screened by the
|
||||
same factor. By using the pair_style *thole*\ , dipole-dipole
|
||||
interactions are screened by Thole's function, whatever their special
|
||||
relationship (except within each DC-DP pair of course). Consider for
|
||||
example 1-2 neighbors: using the pair\_style *thole*\ , their dipoles
|
||||
example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
|
||||
will see each other (despite the *coul* factor being 0.) and the
|
||||
interactions between these dipoles will be damped by Thole's function.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Thermostats and barostats**
|
||||
|
||||
Using a Nose-Hoover barostat with the *langevin/drude* thermostat is
|
||||
straightforward using fix *nph* instead of *nve*\ . For example:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix NPH all nph iso 1. 1. 500
|
||||
|
@ -385,7 +359,6 @@ with respect to their DC. The *fix drude/transform/inverse* performs
|
|||
the reverse transformation. For a NVT simulation, with the DCs and
|
||||
atoms at 300 K and the DPs at 1 K relative to their DC one would use
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix DIRECT all drude/transform/direct
|
||||
|
@ -395,7 +368,6 @@ atoms at 300 K and the DPs at 1 K relative to their DC one would use
|
|||
|
||||
For our phenol example, the groups would be defined as
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
group ATOMS type 1 2 3 4 5 # DCs and non-polarizable atoms
|
||||
|
@ -403,13 +375,12 @@ For our phenol example, the groups would be defined as
|
|||
group DRUDES type 6 7 8 # DPs
|
||||
|
||||
Note that with the fixes *drude/transform*\ , it is not required to
|
||||
specify *comm\_modify vel yes* because the fixes do it anyway (several
|
||||
specify *comm_modify vel yes* because the fixes do it anyway (several
|
||||
times and for the forces also). To avoid the flying ice cube artifact
|
||||
:ref:`(Lamoureux) <Lamoureux2>`, where the atoms progressively freeze and the
|
||||
center of mass of the whole system drifts faster and faster, the *fix
|
||||
momentum* can be used. For instance:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix MOMENTUM all momentum 100 linear 1 1 1
|
||||
|
@ -421,10 +392,9 @@ DPs should be *nvt* (or vice versa). Second, the *fix npt* computes a
|
|||
global pressure and thus a global temperature whatever the fix group.
|
||||
We do want the pressure to correspond to the whole system, but we want
|
||||
the temperature to correspond to the fix group only. We must then use
|
||||
the *fix\_modify* command for this. In the end, the block of
|
||||
the *fix_modify* command for this. In the end, the block of
|
||||
instructions for thermostatting and barostatting will look like
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute TATOMS ATOMS temp
|
||||
|
@ -434,10 +404,8 @@ instructions for thermostatting and barostatting will look like
|
|||
fix NVT DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Rigid bodies**
|
||||
|
||||
You may want to simulate molecules as rigid bodies (but polarizable).
|
||||
|
@ -448,7 +416,6 @@ review the different thermostats and ensemble combinations.
|
|||
|
||||
NVT ensemble using Langevin thermostat:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
comm_modify vel yes
|
||||
|
@ -458,7 +425,6 @@ NVT ensemble using Langevin thermostat:
|
|||
|
||||
NVT ensemble using Nose-Hoover thermostat:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix DIRECT all drude/transform/direct
|
||||
|
@ -468,7 +434,6 @@ NVT ensemble using Nose-Hoover thermostat:
|
|||
|
||||
NPT ensemble with Langevin thermostat:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
comm_modify vel yes
|
||||
|
@ -478,7 +443,6 @@ NPT ensemble with Langevin thermostat:
|
|||
|
||||
NPT ensemble using Nose-Hoover thermostat:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
compute TATOM ATOMS temp
|
||||
|
@ -488,45 +452,31 @@ NPT ensemble using Nose-Hoover thermostat:
|
|||
fix NVT DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Lamoureux2:
|
||||
|
||||
|
||||
|
||||
**(Lamoureux)** Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003)
|
||||
|
||||
.. _Schroeder:
|
||||
|
||||
|
||||
|
||||
**(Schroeder)** Schroeder and Steinhauser, J Chem Phys, 133,
|
||||
154511 (2010).
|
||||
|
||||
.. _Jiang2:
|
||||
|
||||
|
||||
|
||||
**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
|
||||
J Phys Chem Lett, 2, 87-92 (2011).
|
||||
|
||||
.. _Thole2:
|
||||
|
||||
|
||||
|
||||
**(Thole)** Chem Phys, 59, 341 (1981).
|
||||
|
||||
.. _Noskov2:
|
||||
|
||||
|
||||
|
||||
**(Noskov)** Noskov, Lamoureux and Roux, J Phys Chem B, 109, 6705 (2005).
|
||||
|
||||
.. _SWM4-NDP:
|
||||
|
||||
|
||||
|
||||
**(SWM4-NDP)** Lamoureux, Harder, Vorobyov, Roux, MacKerell, Chem Phys
|
||||
Let, 418, 245-249 (2006)
|
||||
|
|
|
@ -4,14 +4,14 @@ Calculate elastic constants
|
|||
Elastic constants characterize the stiffness of a material. The formal
|
||||
definition is provided by the linear relation that holds between the
|
||||
stress and strain tensors in the limit of infinitesimal deformation.
|
||||
In tensor notation, this is expressed as s\_ij = C\_ijkl \* e\_kl, where
|
||||
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
|
||||
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
|
||||
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
|
||||
|
@ -33,12 +33,8 @@ 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 :ref:`(Shinoda) <Shinoda1>`
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Shinoda1:
|
||||
|
||||
|
||||
|
||||
**(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
||||
|
|
|
@ -22,10 +22,8 @@ and will reduce the time until the integration is complete. For more
|
|||
information on the requirements to have your code included into LAMMPS
|
||||
please see the :doc:`Modify contribute <Modify_contribute>` doc page.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Making an account**
|
||||
|
||||
First of all, you need a GitHub account. This is fairly simple, just
|
||||
|
@ -34,10 +32,8 @@ the "Sign up for GitHub" button. Once your account is created, you
|
|||
can sign in by clicking the button in the top left and filling in your
|
||||
username or e-mail address and password.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Forking the repository**
|
||||
|
||||
To get changes into LAMMPS, you need to first fork the `lammps/lammps`
|
||||
|
@ -63,10 +59,8 @@ At the same time, you can set things up, so you can include changes from
|
|||
upstream into your repository and thus keep it in sync with the ongoing
|
||||
LAMMPS development.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Adding changes to your own fork**
|
||||
|
||||
Additions to the upstream version of LAMMPS are handled using *feature
|
||||
|
@ -81,14 +75,12 @@ explained in more detail here: `feature branch workflow <https://www.atlassian.c
|
|||
First of all, create a clone of your version on github on your local
|
||||
machine via HTTPS:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone https://github.com/<your user name>/lammps.git <some name>
|
||||
|
||||
or, if you have set up your GitHub account for using SSH keys, via SSH:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone git@github.com:<your user name>/lammps.git
|
||||
|
@ -108,7 +100,6 @@ test them without interfering with the repository on GitHub.
|
|||
To pull changes from upstream into this copy, you can go to the directory
|
||||
and use git pull:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd mylammps
|
||||
|
@ -117,7 +108,6 @@ and use git pull:
|
|||
|
||||
You can also add this URL as a remote:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git remote add lammps_upstream https://www.github.com/lammps/lammps
|
||||
|
@ -127,7 +117,6 @@ branch for the feature you want to work on. This tutorial contains the
|
|||
workflow that updated this tutorial, and hence we will call the branch
|
||||
"github-tutorial-update":
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout -b github-tutorial-update master
|
||||
|
@ -140,7 +129,6 @@ unrelated feature, you should switch branches!
|
|||
|
||||
After everything is done, add the files to the branch and commit them:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add doc/src/Howto_github.txt
|
||||
|
@ -165,14 +153,12 @@ After everything is done, add the files to the branch and commit them:
|
|||
After adding all files, the change set can be committed with some
|
||||
useful message that explains the change.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git commit -m 'Finally updated the github tutorial'
|
||||
|
||||
After the commit, the changes can be pushed to the same branch on GitHub:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push
|
||||
|
@ -181,7 +167,6 @@ Git will ask you for your user name and password on GitHub if you have
|
|||
not configured anything. If your local branch is not present on GitHub yet,
|
||||
it will ask you to add it by running
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push --set-upstream origin github-tutorial-update
|
||||
|
@ -192,22 +177,18 @@ password, the feature branch should be added to your fork on GitHub.
|
|||
If you want to make really sure you push to the right repository
|
||||
(which is good practice), you can provide it explicitly:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push origin
|
||||
|
||||
or using an explicit URL:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push git@github.com:Pakketeretet2/lammps.git
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**Filing a pull request**
|
||||
|
||||
Up to this point in the tutorial, all changes were to *your* clones of
|
||||
|
@ -255,10 +236,8 @@ Now just write some nice comments and click on "Create pull request".
|
|||
.. image:: JPG/tutorial_create_new_pull_request2.png
|
||||
:align: center
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**After filing a pull request**
|
||||
|
||||
.. note::
|
||||
|
@ -308,10 +287,10 @@ After each push, the automated checks are run again.
|
|||
|
||||
LAMMPS developers may add labels to your pull request to assign it to
|
||||
categories (mostly for bookkeeping purposes), but a few of them are
|
||||
important: needs\_work, work\_in\_progress, test-for-regression, and
|
||||
important: needs_work, work_in_progress, test-for-regression, and
|
||||
full-regression-test. The first two indicate, that your pull request
|
||||
is not considered to be complete. With "needs\_work" the burden is on
|
||||
exclusively on you; while "work\_in\_progress" can also mean, that a
|
||||
is not considered to be complete. With "needs_work" the burden is on
|
||||
exclusively on you; while "work_in_progress" can also mean, that a
|
||||
LAMMPS developer may want to add changes. Please watch the comments
|
||||
to the pull requests. The two "test" labels are used to trigger
|
||||
extended tests before the code is merged. This is sometimes done by
|
||||
|
@ -408,7 +387,6 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add Howto_github.txt
|
||||
|
@ -425,7 +403,6 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add Howto_github.txt
|
||||
|
@ -438,10 +415,8 @@ This merge also shows up on the lammps GitHub page:
|
|||
.. image:: JPG/tutorial_reverse_pull_request7.png
|
||||
:align: center
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
**After a merge**
|
||||
|
||||
When everything is fine, the feature branch is merged into the master branch:
|
||||
|
@ -456,7 +431,6 @@ It is in principle safe to delete them from your own fork. This helps
|
|||
keep it a bit more tidy. Note that you first have to switch to another
|
||||
branch!
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout master
|
||||
|
@ -472,7 +446,6 @@ first delete and then pull, everything should still be fine.
|
|||
Finally, if you delete the branch locally, you might want to push this
|
||||
to your remote(s) as well:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push origin :github-tutorial-update
|
||||
|
@ -485,7 +458,7 @@ should be submitted, there is now also an "unstable" and a "stable"
|
|||
branch; these have the same content as "master", but are only updated
|
||||
after a patch release or stable release was made.
|
||||
Furthermore, the naming of the patches now follow the pattern
|
||||
"patch\_<Day><Month><Year>" to simplify comparisons between releases.
|
||||
"patch_<Day><Month><Year>" to simplify comparisons between releases.
|
||||
Finally, all patches and submissions are subject to automatic testing
|
||||
and code checks to make sure they at the very least compile.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Use one of these 3 pair potentials, which compute forces and torques
|
|||
between interacting pairs of particles:
|
||||
|
||||
* :doc:`pair_style <pair_style>` gran/history
|
||||
* :doc:`pair_style <pair_style>` gran/no\_history
|
||||
* :doc:`pair_style <pair_style>` gran/no_history
|
||||
* :doc:`pair_style <pair_style>` gran/hertzian
|
||||
|
||||
These commands implement fix options specific to granular systems:
|
||||
|
|
|
@ -56,26 +56,20 @@ two preceding non-equilibrium methods, where energy flows continuously
|
|||
between hot and cold regions of the simulation box.
|
||||
|
||||
The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
|
||||
the needed heat flux and describes how to implement the Green\_Kubo
|
||||
the needed heat flux and describes how to implement the Green_Kubo
|
||||
formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
|
||||
auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
|
||||
that calculates the thermal conductivity of solid Ar via the GK
|
||||
formalism.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _howto-Ikeshoji:
|
||||
|
||||
|
||||
|
||||
**(Ikeshoji)** Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
|
||||
(1994).
|
||||
|
||||
.. _howto-Wirnsberger:
|
||||
|
||||
|
||||
|
||||
**(Wirnsberger)** Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
|
||||
(2015).
|
||||
|
|
|
@ -12,7 +12,7 @@ functions therein have a C-style argument list, but contain C++ code
|
|||
you could write yourself in a C++ application that was invoking LAMMPS
|
||||
directly. The C++ code in the functions illustrates how to invoke
|
||||
internal LAMMPS operations. Note that LAMMPS classes are defined
|
||||
within a LAMMPS namespace (LAMMPS\_NS) if you use them from another C++
|
||||
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
|
||||
application.
|
||||
|
||||
The examples/COUPLE and python/examples directories have example C++
|
||||
|
@ -34,7 +34,7 @@ interface LAMMPS to Fortran libraries, or the code uses static variables
|
|||
|
||||
Another major issue to deal with is to correctly handle MPI. Creating
|
||||
a LAMMPS instance requires passing an MPI communicator, or it assumes
|
||||
the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
|
||||
the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
|
||||
When creating multiple LAMMPS object instances from different threads,
|
||||
this communicator has to be different for each thread or else collisions
|
||||
can happen, or it has to be guaranteed, that only one thread at a time
|
||||
|
@ -58,7 +58,6 @@ details.
|
|||
The added functions can access or change any internal LAMMPS data you
|
||||
wish.
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void lammps_open(int, char **, MPI_Comm, void **)
|
||||
|
@ -71,11 +70,11 @@ details.
|
|||
void lammps_commands_string(void *, char *)
|
||||
void lammps_free(void *)
|
||||
|
||||
The lammps\_open() function is used to initialize LAMMPS, passing in a
|
||||
The lammps_open() function is used to initialize LAMMPS, passing in a
|
||||
list of strings as if they were :doc:`command-line arguments <Run_options>` when LAMMPS is run in stand-alone mode
|
||||
from the command line, and a MPI communicator for LAMMPS to run under.
|
||||
It returns a ptr to the LAMMPS object that is created, and which is
|
||||
used in subsequent library calls. The lammps\_open() function can be
|
||||
used in subsequent library calls. The lammps_open() function can be
|
||||
called multiple times, to create multiple instances of LAMMPS.
|
||||
|
||||
LAMMPS will run on the set of processors in the communicator. This
|
||||
|
@ -87,14 +86,14 @@ half to the other code and run both codes simultaneously before
|
|||
syncing them up periodically. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
|
||||
The lammps\_open\_no\_mpi() function is similar except that no MPI
|
||||
communicator is passed from the caller. Instead, MPI\_COMM\_WORLD is
|
||||
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
|
||||
The lammps_close() function is used to shut down an instance of LAMMPS
|
||||
and free all its memory.
|
||||
|
||||
The lammps\_version() function can be used to determined the specific
|
||||
The lammps_version() function can be used to determined the specific
|
||||
version of the underlying LAMMPS code. This is particularly useful
|
||||
when loading LAMMPS as a shared library via dlopen(). The code using
|
||||
the library interface can than use this information to adapt to
|
||||
|
@ -102,8 +101,8 @@ changes to the LAMMPS command syntax between versions. The returned
|
|||
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
|
||||
20150902) that grows with every new LAMMPS version.
|
||||
|
||||
The lammps\_file(), lammps\_command(), lammps\_commands\_list(), and
|
||||
lammps\_commands\_string() functions are used to pass one or more
|
||||
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.
|
||||
|
||||
|
@ -114,19 +113,19 @@ can interleave the command function calls with operations it performs,
|
|||
calls to extract information from or set information within LAMMPS, or
|
||||
calls to another code's library.
|
||||
|
||||
The lammps\_file() function passes the filename of an input script.
|
||||
The lammps\_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(),
|
||||
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
|
||||
lammps_commands_string() function passes multiple commands
|
||||
concatenated into one long string, separated by newline characters.
|
||||
In both lammps\_commands\_list() and lammps\_commands\_string(), a single
|
||||
In both lammps_commands_list() and lammps_commands_string(), a single
|
||||
command can be spread across multiple lines, if the last printable
|
||||
character of all but the last line is "&", the same as if the lines
|
||||
appeared in an input script.
|
||||
|
||||
The lammps\_free() function is a clean-up function to free memory that
|
||||
The lammps_free() function is a clean-up function to free memory that
|
||||
the library allocated previously via other function calls. See
|
||||
comments in src/library.cpp file for which other functions need this
|
||||
clean-up.
|
||||
|
@ -136,7 +135,6 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int lammps_extract_setting(void *, char *)
|
||||
|
@ -148,22 +146,21 @@ which quantities can be queried by name:
|
|||
void *lammps_extract_fix(void *, char *, int, int, int, int)
|
||||
void *lammps_extract_variable(void *, char *, char *)
|
||||
|
||||
The extract\_setting() function returns info on the size
|
||||
The extract_setting() function returns info on the size
|
||||
of data types (e.g. 32-bit or 64-bit atom IDs) used
|
||||
by the LAMMPS executable (a compile-time choice).
|
||||
|
||||
The other extract functions return a pointer to various global or
|
||||
per-atom quantities stored in LAMMPS or to values calculated by a
|
||||
compute, fix, or variable. The pointer returned by the
|
||||
extract\_global() function can be used as a permanent reference to a
|
||||
value which may change. For the extract\_atom() method, see 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).
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
double lammps_get_thermo(void *, char *)
|
||||
|
@ -172,22 +169,21 @@ function to assure a current pointer or returned value(s).
|
|||
int lammps_set_variable(void *, char *, char *)
|
||||
void lammps_reset_box(void *, double *, double *, double, double, double)
|
||||
|
||||
The lammps\_get\_thermo() function returns the current value of a thermo
|
||||
The lammps_get_thermo() function returns the current value of a thermo
|
||||
keyword as a double precision value.
|
||||
|
||||
The lammps\_get\_natoms() function returns the total number of atoms in
|
||||
The lammps_get_natoms() function returns the total number of atoms in
|
||||
the system and can be used by the caller to allocate memory for the
|
||||
lammps\_gather\_atoms() and lammps\_scatter\_atoms() functions.
|
||||
lammps_gather_atoms() and lammps_scatter_atoms() functions.
|
||||
|
||||
The lammps\_set\_variable() function can set an existing string-style
|
||||
The lammps_set_variable() function can set an existing string-style
|
||||
variable to a new string value, so that subsequent LAMMPS commands can
|
||||
access the variable.
|
||||
|
||||
The lammps\_reset\_box() function resets the size and shape of the
|
||||
The lammps_reset_box() function resets the size and shape of the
|
||||
simulation box, e.g. as part of restoring a previously extracted and
|
||||
saved state of a simulation.
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void lammps_gather_atoms(void *, char *, int, int, void *)
|
||||
|
@ -206,17 +202,17 @@ owned by different processors.
|
|||
.. warning::
|
||||
|
||||
These functions are not compatible with the
|
||||
-DLAMMPS\_BIGBIG setting when compiling LAMMPS. Dummy functions
|
||||
-DLAMMPS_BIGBIG setting when compiling LAMMPS. Dummy functions
|
||||
that result in an error message and abort will be substituted
|
||||
instead of resulting in random crashes and memory corruption.
|
||||
|
||||
The lammps\_gather\_atoms() function does this for all N atoms in the
|
||||
The lammps_gather_atoms() function does this for all N atoms in the
|
||||
system, ordered by atom ID, from 1 to N. The
|
||||
lammps\_gather\_atoms\_concat() function does it for all N atoms, but
|
||||
lammps_gather_atoms_concat() function does it for all N atoms, but
|
||||
simply concatenates the subset of atoms owned by each processor. The
|
||||
resulting vector is not ordered by atom ID. Atom IDs can be requested
|
||||
by the same function if the caller needs to know the ordering. The
|
||||
lammps\_gather\_subset() function allows the caller to request values
|
||||
lammps_gather_subset() function allows the caller to request values
|
||||
for only a subset of atoms (identified by ID).
|
||||
For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
|
||||
If the count is specified as 1, they are returned
|
||||
|
@ -224,24 +220,23 @@ in a packed format with all three image flags stored in a single integer.
|
|||
If the count is specified as 3, the values are unpacked into xyz flags
|
||||
by the library before returning them.
|
||||
|
||||
The lammps\_scatter\_atoms() function takes a list of values for all N
|
||||
The lammps_scatter_atoms() function takes a list of values for all N
|
||||
atoms in the system, ordered by atom ID, from 1 to N, and assigns
|
||||
those values to each atom in the system. The
|
||||
lammps\_scatter\_atoms\_subset() function takes a subset of IDs as an
|
||||
lammps_scatter_atoms_subset() function takes a subset of IDs as an
|
||||
argument and only scatters those values to the owning atoms.
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
|
||||
imageint *, int)
|
||||
|
||||
The lammps\_create\_atoms() function takes a list of N atoms as input
|
||||
The lammps_create_atoms() function takes a list of N atoms as input
|
||||
with atom types and coords (required), an optionally atom IDs and
|
||||
velocities and image flags. It uses the coords of each atom to assign
|
||||
it as a new atom to the processor that owns it. This function is
|
||||
useful to add atoms to a simulation or (in tandem with
|
||||
lammps\_reset\_box()) to restore a previously extracted and saved state
|
||||
lammps_reset_box()) to restore a previously extracted and saved state
|
||||
of a simulation. Additional properties for the new atoms can then be
|
||||
assigned via the lammps\_scatter\_atoms() or lammps\_extract\_atom()
|
||||
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
|
||||
functions.
|
||||
|
|
|
@ -19,17 +19,17 @@ to the relevant fixes.
|
|||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| cylinder | R | x\^2 + y\^2 - R\^2 = 0 | Cylinder along z-axis, axis going through (0,0,0) |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| cylinder\_dent | R l a | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise | A cylinder with a dent around z = 0 |
|
||||
| cylinder_dent | R l a | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise | A cylinder with a dent around z = 0 |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| dumbbell | a A B c | -( x\^2 + y\^2 ) + (a\^2 - z\^2/c\^2) \* ( 1 + (A\*sin(B\*z\^2))\^4) = 0 | A dumbbell |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| ellipsoid | a b c | (x/a)\^2 + (y/b)\^2 + (z/c)\^2 = 0 | An ellipsoid |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| gaussian\_bump | A l rc1 rc2 | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0. |
|
||||
| gaussian_bump | A l rc1 rc2 | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0. |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| plane | a b c x0 y0 z0 | a\*(x-x0) + b\*(y-y0) + c\*(z-z0) = 0 | A plane with normal (a,b,c) going through point (x0,y0,z0) |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| plane\_wiggle | a w | z - a\*sin(w\*x) = 0 | A plane with a sinusoidal modulation on z along x. |
|
||||
| plane_wiggle | a w | z - a\*sin(w\*x) = 0 | A plane with a sinusoidal modulation on z along x. |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| sphere | R | x\^2 + y\^2 + z\^2 - R\^2 = 0 | A sphere of radius R |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
|
@ -37,7 +37,7 @@ to the relevant fixes.
|
|||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| spine | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | An approximation to a dendritic spine |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| spine\_two | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine |
|
||||
| spine_two | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| thylakoid | wB LB lB | Various, see :ref:`(Paquay) <Paquay1>` | A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB |
|
||||
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
|
||||
|
@ -46,7 +46,5 @@ to the relevant fixes.
|
|||
|
||||
.. _Paquay1:
|
||||
|
||||
|
||||
|
||||
**(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016).
|
||||
preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
|
||||
|
|
|
@ -8,7 +8,6 @@ If "multiple simulations" means continue a previous simulation for
|
|||
more timesteps, then you simply use the :doc:`run <run>` command
|
||||
multiple times. For example, this script
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
units lj
|
||||
|
@ -27,7 +26,6 @@ If you wish to run totally different simulations, one after the other,
|
|||
the :doc:`clear <clear>` command can be used in between them to
|
||||
re-initialize LAMMPS. For example, this script
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
units lj
|
||||
|
@ -48,7 +46,6 @@ For large numbers of independent simulations, you can use
|
|||
multiple times with different settings. For example, this
|
||||
script, named in.polymer
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
variable d index run1 run2 run3 run4 run5 run6 run7 run8
|
||||
|
@ -65,7 +62,6 @@ 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
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
variable a loop 8
|
||||
|
|
|
@ -43,13 +43,9 @@ 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 :doc:`fix flow/gauss <fix_flow_gauss>` command.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Daivis-nemd:
|
||||
|
||||
|
||||
|
||||
**(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -12,7 +12,6 @@ There are four basic kinds of LAMMPS output:
|
|||
screen.
|
||||
* :doc:`Restart files <restart>`.
|
||||
|
||||
|
||||
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 :doc:`dump <dump>` and :doc:`fix <fix>`
|
||||
|
@ -69,11 +68,11 @@ notation, where ID in this case is the ID of a compute. The leading
|
|||
"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
|
||||
|
||||
+-------------+--------------------------------------------+
|
||||
| c\_ID | entire scalar, vector, or array |
|
||||
| c_ID | entire scalar, vector, or array |
|
||||
+-------------+--------------------------------------------+
|
||||
| c\_ID[I] | one element of vector, one column of array |
|
||||
| c_ID[I] | one element of vector, one column of array |
|
||||
+-------------+--------------------------------------------+
|
||||
| c\_ID[I][J] | one element of array |
|
||||
| c_ID[I][J] | one element of array |
|
||||
+-------------+--------------------------------------------+
|
||||
|
||||
In other words, using one bracket reduces the dimension of the data
|
||||
|
@ -93,7 +92,7 @@ The frequency and format of thermodynamic output is set by the
|
|||
:doc:`thermo_style <thermo_style>` command also specifies what values
|
||||
are calculated and written out. Pre-defined keywords can be specified
|
||||
(e.g. press, etotal, etc). Three additional kinds of keywords can
|
||||
also be specified (c\_ID, f\_ID, v\_name), where a :doc:`compute <compute>`
|
||||
also be specified (c_ID, f_ID, v_name), where a :doc:`compute <compute>`
|
||||
or :doc:`fix <fix>` or :doc:`variable <variable>` provides the value to be
|
||||
output. In each case, the compute, fix, or variable must generate
|
||||
global values for input to the :doc:`thermo_style custom <dump>`
|
||||
|
@ -122,7 +121,7 @@ pre-defined formats (dump atom, dump xtc, etc).
|
|||
There is also a :doc:`dump custom <dump>` format where the user
|
||||
specifies what values are output with each atom. Pre-defined atom
|
||||
attributes can be specified (id, x, fx, etc). Three additional kinds
|
||||
of keywords can also be specified (c\_ID, f\_ID, v\_name), where a
|
||||
of keywords can also be specified (c_ID, f_ID, v_name), where a
|
||||
:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
|
||||
provides the values to be output. In each case, the compute, fix, or
|
||||
variable must generate per-atom values for input to the :doc:`dump custom <dump>` command.
|
||||
|
@ -130,7 +129,7 @@ variable must generate per-atom values for input to the :doc:`dump custom <dump>
|
|||
There is also a :doc:`dump local <dump>` format where the user specifies
|
||||
what local values to output. A pre-defined index keyword can be
|
||||
specified to enumerate the local values. Two additional kinds of
|
||||
keywords can also be specified (c\_ID, f\_ID), where a
|
||||
keywords can also be specified (c_ID, f_ID), where a
|
||||
:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
|
||||
provides the values to be output. In each case, the compute or fix
|
||||
must generate local values for input to the :doc:`dump local <dump>`
|
||||
|
|
|
@ -56,7 +56,6 @@ output support enabled.
|
|||
|
||||
Step 1a: For the CMake based build system, the steps are:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mkdir $LAMMPS_DIR/build-shared
|
||||
|
@ -68,7 +67,6 @@ Step 1a: For the CMake based build system, the steps are:
|
|||
|
||||
Step 1b: For the legacy, make based build system, the steps are:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd $LAMMPS_DIR/src
|
||||
|
@ -85,7 +83,6 @@ Step 2: Installing the LAMMPS Python package
|
|||
PyLammps is part of the lammps Python package. To install it simply install
|
||||
that package into your current Python installation with:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make install-python
|
||||
|
@ -110,7 +107,6 @@ Benefits of using a virtualenv
|
|||
|
||||
**Prerequisite (e.g. on Ubuntu)**
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
apt-get install python-virtualenv
|
||||
|
@ -118,7 +114,6 @@ Benefits of using a virtualenv
|
|||
Creating a virtualenv with lammps installed
|
||||
"""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# create virtualenv named 'testing'
|
||||
|
@ -132,7 +127,6 @@ When using CMake and the shared library has already been build, you
|
|||
need to re-run CMake to update the location of the python executable
|
||||
to the location in the virtual environment with:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cmake . -DPYTHON_EXECUTABLE=$(which python)
|
||||
|
@ -154,7 +148,6 @@ Creating a new instance of PyLammps
|
|||
To create a PyLammps object you need to first import the class from the lammps
|
||||
module. By using the default constructor, a new *lammps* instance is created.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
from lammps import PyLammps
|
||||
|
@ -162,7 +155,6 @@ module. By using the default constructor, a new *lammps* instance is created.
|
|||
|
||||
You can also initialize PyLammps on top of this existing *lammps* object:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
from lammps import lammps, PyLammps
|
||||
|
@ -177,7 +169,6 @@ the command method of the lammps object instance.
|
|||
|
||||
For instance, let's take the following LAMMPS command:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
region box block 0 10 0 5 -0.5 0.5
|
||||
|
@ -185,7 +176,6 @@ For instance, let's take the following LAMMPS command:
|
|||
In the original interface this command can be executed with the following
|
||||
Python code if *L* was a lammps instance:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.command("region box block 0 10 0 5 -0.5 0.5")
|
||||
|
@ -193,7 +183,6 @@ Python code if *L* was a lammps instance:
|
|||
With the PyLammps interface, any command can be split up into arbitrary parts
|
||||
separated by white-space, passed as individual arguments to a region method.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
|
||||
|
@ -206,7 +195,6 @@ The benefit of this approach is avoiding redundant command calls and easier
|
|||
parameterization. In the original interface parameterization needed to be done
|
||||
manually by creating formatted strings.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
|
||||
|
@ -214,7 +202,6 @@ manually by creating formatted strings.
|
|||
In contrast, methods of PyLammps accept parameters directly and will convert
|
||||
them automatically to a final command string.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
|
||||
|
@ -225,8 +212,6 @@ System state
|
|||
In addition to dispatching commands directly through the PyLammps object, it
|
||||
also provides several properties which allow you to query the system state.
|
||||
|
||||
|
||||
|
||||
L.system
|
||||
Is a dictionary describing the system such as the bounding box or number of atoms
|
||||
|
||||
|
@ -260,8 +245,6 @@ L.dump
|
|||
L.groups
|
||||
List of groups present in the current system
|
||||
|
||||
|
||||
|
||||
Working with LAMMPS variables
|
||||
-----------------------------
|
||||
|
||||
|
@ -269,7 +252,6 @@ LAMMPS variables can be both defined and accessed via the PyLammps interface.
|
|||
|
||||
To define a variable you can use the :doc:`variable <variable>` command:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.variable("a index 2")
|
||||
|
@ -279,7 +261,6 @@ A dictionary of all variables is returned by L.variables
|
|||
you can access an individual variable by retrieving a variable object from the
|
||||
L.variables dictionary by name
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
a = L.variables['a']
|
||||
|
@ -287,7 +268,6 @@ L.variables dictionary by name
|
|||
The variable value can then be easily read and written by accessing the value
|
||||
property of this object.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
print(a.value)
|
||||
|
@ -300,7 +280,6 @@ LAMMPS expressions can be immediately evaluated by using the eval method. The
|
|||
passed string parameter can be any expression containing global thermo values,
|
||||
variables, compute or fix data.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
result = L.eval("ke") # kinetic energy
|
||||
|
@ -315,7 +294,6 @@ All atoms in the current simulation can be accessed by using the L.atoms list.
|
|||
Each element of this list is an object which exposes its properties (id, type,
|
||||
position, velocity, force, etc.).
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
# access first atom
|
||||
|
@ -329,7 +307,6 @@ position, velocity, force, etc.).
|
|||
|
||||
Some properties can also be used to set:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
# set position in 2D simulation
|
||||
|
@ -347,7 +324,6 @@ after a run via the L.runs list. This list contains a growing list of run data.
|
|||
The first element is the output of the first run, the second element that of
|
||||
the second run.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.run(1000)
|
||||
|
@ -359,7 +335,6 @@ the second run.
|
|||
Each run contains a dictionary of all trajectories. Each trajectory is
|
||||
accessible through its thermo name:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
L.runs[0].thermo.Step # list of time steps in first run
|
||||
|
@ -367,7 +342,6 @@ accessible through its thermo name:
|
|||
|
||||
Together with matplotlib plotting data out of LAMMPS becomes simple:
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
import matplotlib.plot as plt
|
||||
|
@ -406,7 +380,6 @@ tutorials and showcasing your latest research.
|
|||
To launch an instance of Jupyter simply run the following command inside your
|
||||
Python environment (this assumes you followed the Quick Start instructions):
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
jupyter notebook
|
||||
|
@ -429,7 +402,6 @@ Four atoms are placed in the simulation and the dihedral potential is applied on
|
|||
them using a datafile. Then one of the atoms is rotated along the central axis by
|
||||
setting its position from Python, which changes the dihedral angle.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
phi = [d \* math.pi / 180 for d in range(360)]
|
||||
|
@ -463,7 +435,6 @@ Initially, a 2D system is created in a state with minimal energy.
|
|||
|
||||
It is then disordered by moving each atom by a random delta.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
random.seed(27848)
|
||||
|
@ -483,7 +454,6 @@ It is then disordered by moving each atom by a random delta.
|
|||
Finally, the Monte Carlo algorithm is implemented in Python. It continuously
|
||||
moves random atoms by a random delta and only accepts certain moves.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
estart = L.eval("pe")
|
||||
|
@ -536,7 +506,6 @@ Using PyLammps and mpi4py (Experimental)
|
|||
|
||||
PyLammps can be run in parallel using mpi4py. This python package can be installed using
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install mpi4py
|
||||
|
@ -544,7 +513,6 @@ PyLammps can be run in parallel using mpi4py. This python package can be install
|
|||
The following is a short example which reads in an existing LAMMPS input file and
|
||||
executes it in parallel. You can find in.melt in the examples/melt folder.
|
||||
|
||||
|
||||
.. code-block:: Python
|
||||
|
||||
from mpi4py import MPI
|
||||
|
@ -561,7 +529,6 @@ executes it in parallel. You can find in.melt in the examples/melt folder.
|
|||
To run this script (melt.py) in parallel using 4 MPI processes we invoke the
|
||||
following mpirun command:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpirun -np 4 python melt.py
|
||||
|
|
|
@ -37,7 +37,6 @@ replica. The processors assigned to each replica are determined at
|
|||
run-time by using the :doc:`-partition command-line switch <Run_options>` to launch LAMMPS on multiple partitions,
|
||||
which in this context are the same as replicas. E.g. these commands:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
|
||||
|
|
|
@ -21,7 +21,6 @@ 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
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
restart 50 tmp.restart
|
||||
|
@ -32,7 +31,6 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
read_restart tmp.restart.50
|
||||
|
@ -48,8 +46,8 @@ last 50 timesteps:
|
|||
run 50
|
||||
|
||||
Note that the following commands do not need to be repeated because
|
||||
their settings are included in the restart file: *units, atom\_style,
|
||||
special\_bonds, pair\_style, bond\_style*. However these commands do
|
||||
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*\ .
|
||||
|
||||
|
@ -62,14 +60,12 @@ 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:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
lmp_g++ -r tmp.restart.50 tmp.restart.data
|
||||
|
||||
Then, this script could be used to re-run the last 50 steps:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
units lj
|
||||
|
@ -93,7 +89,7 @@ Then, this script could be used to re-run the last 50 steps:
|
|||
run 50
|
||||
|
||||
Note that nearly all the settings specified in the original *in.chain*
|
||||
script must be repeated, except the *pair\_coeff* and *bond\_coeff*
|
||||
script must be repeated, except the *pair_coeff* and *bond_coeff*
|
||||
commands since the new data file lists the force field coefficients.
|
||||
Also, the :doc:`reset_timestep <reset_timestep>` command is used to tell
|
||||
LAMMPS the current timestep. This value is stored in restart files,
|
||||
|
|
|
@ -15,38 +15,34 @@ atoms and the water molecule to run a rigid SPC model.
|
|||
| 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
|
||||
|
|
||||
| LJ :math:`\epsilon` of OO = 0.1553
|
||||
| LJ :math:`\sigma` of OO = 3.166
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
| :math:`r_0` of OH bond = 1.0
|
||||
| :math:`\theta` of HOH angle = 109.47\ :math:`^{\circ}`
|
||||
|
|
||||
|
||||
Note that as originally proposed, the SPC model was run with a 9
|
||||
Angstrom cutoff for both LJ and Coulombic 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.
|
||||
Angstrom cutoff for both LJ and Coulomb terms. It can also be used
|
||||
with long-range electrostatic solvers (e.g. Ewald or PPPM in LAMMPS)
|
||||
without changing any of the parameters above, although 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
|
||||
|
|
||||
|
|
||||
|
||||
See the :ref:`(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>`_.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _howto-Berendsen:
|
||||
|
||||
|
||||
|
||||
**(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91,
|
||||
6269-6271 (1987).
|
||||
|
|
|
@ -38,7 +38,6 @@ The dipole style does not actually define finite-size particles, but
|
|||
is often used in conjunction with spherical particles, via a command
|
||||
like
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
atom_style hybrid sphere dipole
|
||||
|
@ -116,7 +115,7 @@ such interactions. These are the various :doc:`pair styles <pair_style>` that g
|
|||
|
||||
* :doc:`pair_style gran/history <pair_gran>`
|
||||
* :doc:`pair_style gran/hertzian <pair_gran>`
|
||||
* :doc:`pair_style gran/no\_history <pair_gran>`
|
||||
* :doc:`pair_style gran/no_history <pair_gran>`
|
||||
* :doc:`pair_style dipole/cut <pair_dipole>`
|
||||
* :doc:`pair_style gayberne <pair_gayberne>`
|
||||
* :doc:`pair_style resquared <pair_resquared>`
|
||||
|
|
|
@ -56,13 +56,9 @@ the magnetic energy. The second command is :doc:`compute property/atom <compute_
|
|||
per atom magnetic quantities. Typically, the orientation of a given
|
||||
magnetic spin, or the magnetic force acting on this spin.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Tranchida:
|
||||
|
||||
|
||||
|
||||
**(Tranchida)** Tranchida, Plimpton, Thibaudeau and Thompson,
|
||||
Journal of Computational Physics, 372, 406-425, (2018).
|
||||
|
|
|
@ -82,13 +82,9 @@ specify them explicitly via the :doc:`thermo_style custom <thermo_style>` comman
|
|||
:doc:`thermo_modify <thermo_modify>` command to re-define what
|
||||
temperature compute is used for default thermodynamic output.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Daivis-thermostat:
|
||||
|
||||
|
||||
|
||||
**(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -20,19 +20,19 @@ set to 0.0, it corresponds to the original 1983 TIP3P model
|
|||
| 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
|
||||
| LJ :math:`\epsilon` of OO = 0.1521
|
||||
| LJ :math:`\sigma` of OO = 3.1507
|
||||
| LJ :math:`\epsilon` of HH = 0.0460
|
||||
| LJ :math:`\sigma` of HH = 0.4000
|
||||
| LJ :math:`\epsilon` of OH = 0.0836
|
||||
| LJ :math:`\sigma` of OH = 1.7753
|
||||
| K of OH bond = 450
|
||||
| r0 of OH bond = 0.9572
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| K of HOH angle = 55
|
||||
| theta of HOH angle = 104.52
|
||||
|
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
|
|
||||
|
||||
These are the parameters to use for TIP3P with a long-range Coulombic
|
||||
These are the parameters to use for TIP3P with a long-range Coulomb
|
||||
solver (e.g. Ewald or PPPM in LAMMPS), see :ref:`(Price) <Price1>` for
|
||||
details:
|
||||
|
||||
|
@ -40,37 +40,29 @@ details:
|
|||
| 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
|
||||
| LJ :math:`\epsilon` of OO = 0.102
|
||||
| LJ :math:`\sigma` of OO = 3.188
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
| K of OH bond = 450
|
||||
| r0 of OH bond = 0.9572
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| K of HOH angle = 55
|
||||
| theta of HOH angle = 104.52
|
||||
|
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
|
|
||||
|
||||
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _howto-tip3p:
|
||||
|
||||
|
||||
|
||||
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
.. _Jorgensen1:
|
||||
|
||||
|
||||
|
||||
**(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
||||
.. _Price1:
|
||||
|
||||
|
||||
|
||||
**(Price)** Price and Brooks, J Chem Phys, 121, 10096 (2004).
|
||||
|
|
|
@ -11,7 +11,7 @@ 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:
|
||||
|
||||
:doc:`pair_style lj/cut/tip4p/cut <pair_lj>`
|
||||
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj>`
|
||||
|
||||
or these two commands for a long-range model:
|
||||
|
||||
|
@ -31,46 +31,46 @@ coefficients.
|
|||
| H mass = 1.008
|
||||
| O charge = -1.040
|
||||
| H charge = 0.520
|
||||
| r0 of OH bond = 0.9572
|
||||
| theta of HOH angle = 104.52
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
| 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
|
||||
|
|
||||
| LJ :math:`\epsilon` of O-O = 0.1550
|
||||
| LJ :math:`\sigma` of O-O = 3.1536
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
| Coulomb cutoff = 8.5
|
||||
|
|
||||
|
||||
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
|
||||
http://dx.doi.org/10.1063/1.1931662) these values can be used:
|
||||
https://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
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
| 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
|
||||
|
|
||||
| LJ :math:`\epsilon` of O-O = 0.21084
|
||||
| LJ :math:`\sigma` of O-O = 3.1668
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
| Coulomb cutoff = 8.5
|
||||
|
|
||||
|
||||
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
|
||||
http://dx.doi.org/10.1063/1.2121687), these values can be used:
|
||||
https://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
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
| 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
|
||||
|
|
||||
| LJ :math:`\epsilon` of O-O = 0.1852
|
||||
| LJ :math:`\sigma` of O-O = 3.1589
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
| Coulomb cutoff = 8.5
|
||||
|
|
||||
|
||||
These are the parameters to use for TIP4P with a long-range Coulombic
|
||||
solver (e.g. Ewald or PPPM in LAMMPS):
|
||||
|
@ -79,13 +79,13 @@ solver (e.g. Ewald or PPPM in LAMMPS):
|
|||
| H mass = 1.008
|
||||
| O charge = -1.0484
|
||||
| H charge = 0.5242
|
||||
| r0 of OH bond = 0.9572
|
||||
| theta of HOH angle = 104.52
|
||||
| :math:`r_0` of OH bond = 0.9572
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
| 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
|
||||
|
|
||||
| LJ :math:`\epsilon` of O-O = 0.16275
|
||||
| LJ :math:`\sigma` of O-O = 3.16435
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
|
|
||||
|
||||
Note that the when using the TIP4P pair style, the neighbor list
|
||||
cutoff for Coulomb interactions is effectively extended by a distance
|
||||
|
@ -99,13 +99,9 @@ and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj
|
|||
|
||||
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Jorgensen5:
|
||||
|
||||
|
||||
|
||||
**(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
|
|
@ -78,7 +78,7 @@ The transformation is given by the following equation:
|
|||
\begin{pmatrix}
|
||||
\mathbf{B \times C} \\
|
||||
\mathbf{C \times A} \\
|
||||
\mathbf{A \times B}
|
||||
\mathbf{A \times B}
|
||||
\end{pmatrix} \cdot \mathbf{X}
|
||||
|
||||
where *V* is the volume of the box, **X** is the original vector quantity and
|
||||
|
@ -200,7 +200,6 @@ 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:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
ITEM: BOX BOUNDS xy xz yz
|
||||
|
@ -212,7 +211,6 @@ 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:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
|
||||
|
@ -223,7 +221,7 @@ calculated from the 9 triclinic box parameters
|
|||
zhi_bound = zhi
|
||||
|
||||
These formulas can be inverted if you need to convert the bounding box
|
||||
back into the triclinic box parameters, e.g. xlo = xlo\_bound -
|
||||
back into the triclinic box parameters, e.g. xlo = xlo_bound -
|
||||
MIN(0.0,xy,xz,xy+xz).
|
||||
|
||||
One use of triclinic simulation boxes is to model solid-state crystals
|
||||
|
|
|
@ -62,7 +62,6 @@ simulation box.
|
|||
Here is an example input script that calculates the viscosity of
|
||||
liquid Ar via the GK formalism:
|
||||
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
# Sample LAMMPS input script for viscosity of liquid Ar
|
||||
|
@ -131,13 +130,9 @@ time-integrated momentum fluxes play the role of Cartesian
|
|||
coordinates, whose mean-square displacement increases linearly
|
||||
with time at sufficiently long times.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _Daivis-viscosity:
|
||||
|
||||
|
||||
|
||||
**(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -25,12 +25,8 @@ RasMol visualization programs. Pizza.py has tools that do interactive
|
|||
3d OpenGL visualization and one that creates SVG images of dump file
|
||||
snapshots.
|
||||
|
||||
.. _pizza: http://www.sandia.gov/~sjplimp/pizza.html
|
||||
.. _pizza: https://pizza.sandia.gov
|
||||
|
||||
.. _ensight: https://daac.hpc.mil/software/EnSight/
|
||||
|
||||
|
||||
.. _ensight: http://www.ensight.com
|
||||
|
||||
|
||||
|
||||
.. _atomeye: http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
|
||||
|
|
|
@ -8,7 +8,6 @@ have more flexibility as to what features to include or exclude in the
|
|||
build. If you plan to :doc:`modify or extend LAMMPS <Modify>`, then you
|
||||
need the source code.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -16,8 +16,7 @@ commands explained below to communicate with the git servers on
|
|||
GitHub. For people still using subversion (svn), GitHub also
|
||||
provides `limited support for subversion clients <svn_>`_.
|
||||
|
||||
|
||||
.. warning::
|
||||
.. note::
|
||||
|
||||
As of October 2016, the official home of public LAMMPS development is
|
||||
on GitHub. The previously advertised LAMMPS git repositories on
|
||||
|
@ -35,7 +34,6 @@ You can follow LAMMPS development on 3 different git branches:
|
|||
To access the git repositories on your box, use the clone command to
|
||||
create a local copy of the LAMMPS repository with a command like:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone -b unstable https://github.com/lammps/lammps.git mylammps
|
||||
|
@ -57,7 +55,6 @@ LAMMPS, as listed on :doc:`this page <Errors_bugs>`, you can stay
|
|||
up-to-date by typing the following git commands from within the
|
||||
"mylammps" directory:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout unstable # not needed if you always stay in this branch
|
||||
|
@ -92,7 +89,6 @@ Once you have updated your local files with a "git pull" (or "git
|
|||
checkout"), you still need to re-build LAMMPS if any source files have
|
||||
changed. To do this, you should cd to the src directory and type:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ make purge # remove any deprecated src files
|
||||
|
|
|
@ -38,7 +38,7 @@ To install LAMMPS do the following once:
|
|||
|
||||
$ sudo apt-get install lammps-daily
|
||||
|
||||
This downloads an executable named "lmp\_daily" to your box, which
|
||||
This downloads an executable named "lmp_daily" to your box, which
|
||||
can then be used in the usual way to run input scripts:
|
||||
|
||||
.. code-block:: bash
|
||||
|
@ -103,10 +103,10 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
|
|||
lammps-openmpi-devel), the header for compiling programs using
|
||||
the C library interface (lammps-headers), and the LAMMPS python
|
||||
module for Python 3. All packages can be installed at the same
|
||||
time and the name of the LAMMPS executable is *lmp* and *lmp\_openmpi*
|
||||
or *lmp\_mpich* respectively. By default, *lmp* will refer to the
|
||||
time and the name of the LAMMPS executable is *lmp* and *lmp_openmpi*
|
||||
or *lmp_mpich* respectively. By default, *lmp* will refer to the
|
||||
serial executable, unless one of the MPI environment modules is loaded
|
||||
("module load mpi/mpich-x86\_64" or "module load mpi/openmpi-x86\_64").
|
||||
("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
|
||||
Then the corresponding parallel LAMMPS executable can be used.
|
||||
The same mechanism applies when loading the LAMMPS python module.
|
||||
|
||||
|
@ -206,7 +206,6 @@ Gentoo Linux executable
|
|||
LAMMPS is part of Gentoo's main package tree and can be installed by
|
||||
typing:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% emerge --ask lammps
|
||||
|
@ -216,7 +215,6 @@ built on the your machine.
|
|||
|
||||
Certain LAMMPS packages can be enable via USE flags, type
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% equery uses lammps
|
||||
|
|
|
@ -10,18 +10,16 @@ GPU, KOKKOS, LATTE, MSCG, MESSAGE, MPIIO POEMS VORONOI.
|
|||
After installing Homebrew, you can install LAMMPS on your system with
|
||||
the following commands:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% brew install lammps
|
||||
|
||||
This will install the executables "lammps\_serial" and "lammps\_mpi", as well as
|
||||
This will install the executables "lammps_serial" and "lammps_mpi", as well as
|
||||
the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
|
||||
|
||||
Once LAMMPS is installed, you can test the installation with the
|
||||
Lennard-Jones benchmark file:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% brew test lammps -v
|
||||
|
@ -31,7 +29,6 @@ results in Homebrew also installing the `kim-api` binaries when LAMMPS is
|
|||
installed. In order to use potentials from `openkim.org <openkim_>`_, you can
|
||||
install the `openkim-models` package
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% brew install openkim-models
|
||||
|
@ -44,5 +41,4 @@ If you have problems with the installation you can post issues to
|
|||
Thanks to Derek Thomas (derekt at cello.t.u-tokyo.ac.jp) for setting
|
||||
up the Homebrew capability.
|
||||
|
||||
|
||||
.. _openkim: https://openkim.org
|
||||
|
|
|
@ -8,7 +8,7 @@ how to stay current are on the
|
|||
|
||||
If you prefer to download a tarball, as described on the :doc:`Install git <Install_tarball>` doc page, you can stay current by
|
||||
downloading "patch files" when new patch releases are made. A link to
|
||||
a patch file is posted on the `bug and feature page <http://lammps.sandia.gov/bug.html>`_ of the LAMMPS website, along
|
||||
a patch file is posted on the `bug and feature page <https://lammps.sandia.gov/bug.html>`_ of the LAMMPS website, along
|
||||
with a list of changed files and details about what is in the new patch
|
||||
release. This page explains how to apply the patch file to your local
|
||||
LAMMPS directory.
|
||||
|
@ -32,9 +32,9 @@ up to date.
|
|||
* Apply the patch by typing the following command from your top-level
|
||||
LAMMPS directory, where the redirected file is the name of the patch
|
||||
file.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
$ patch -bp1 < patch.12Dec16
|
||||
|
||||
* A list of updated files print out to the screen. The -b switch
|
||||
|
@ -46,9 +46,9 @@ up to date.
|
|||
successively, you only need to type this once at the end. The purge
|
||||
command removes deprecated src files if any were removed by the patch
|
||||
from package sub-directories.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
$ make purge
|
||||
$ make package-update
|
||||
|
||||
|
|
|
@ -4,10 +4,10 @@ Download source and documentation as a tarball
|
|||
You can download a current LAMMPS tarball from the `download page <download_>`_
|
||||
of the `LAMMPS website <lws_>`_.
|
||||
|
||||
.. _download: http://lammps.sandia.gov/download.html
|
||||
.. _bug: http://lammps.sandia.gov/bug.html
|
||||
.. _older: http://lammps.sandia.gov/tars
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _download: https://lammps.sandia.gov/download.html
|
||||
.. _bug: https://lammps.sandia.gov/bug.html
|
||||
.. _older: https://lammps.sandia.gov/tars
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
You have two choices of tarballs, either the most recent stable
|
||||
release or the most current patch release. Stable releases occur a
|
||||
|
@ -26,7 +26,7 @@ command:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ tar -xzvf lammps\*.tar.gz
|
||||
$ tar -xzvf lammps*.tar.gz
|
||||
|
||||
This will create a LAMMPS directory with the version date
|
||||
in its name, e.g. lammps-23Jun18.
|
||||
|
@ -40,7 +40,7 @@ a lammps-master dir:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ unzip lammps\*.zip
|
||||
$ unzip lammps*.zip
|
||||
|
||||
This version is the most up-to-date LAMMPS development version. It
|
||||
will have the date of the most recent patch release (see the file
|
||||
|
@ -52,7 +52,6 @@ the next patch release tarball.
|
|||
|
||||
----------
|
||||
|
||||
|
||||
If you download a current LAMMPS tarball, one way to stay current as
|
||||
new patch tarballs are released, is to download a patch file which you
|
||||
can apply to your local directory to update it for each new patch
|
||||
|
|
|
@ -4,7 +4,9 @@ Download an executable for Windows
|
|||
Pre-compiled Windows installers which install LAMMPS executables on a
|
||||
Windows system can be downloaded from this site:
|
||||
|
||||
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
|
||||
.. parsed-literal::
|
||||
|
||||
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
|
||||
|
||||
Note that each installer package has a date in its name, which
|
||||
corresponds to the LAMMPS version of the same date. Installers for
|
||||
|
@ -26,7 +28,7 @@ When you download the installer package, you run it on your Windows
|
|||
machine. It will then prompt you with a dialog, where you can choose
|
||||
the installation directory, unpack and copy several executables,
|
||||
potential files, documentation pdfs, selected example files, etc. It
|
||||
will then update a few system settings (e.g. PATH, LAMMPS\_POTENTIALS)
|
||||
will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
|
||||
and add an entry into the Start Menu (with references to the
|
||||
documentation, LAMMPS homepage and more). From that menu, there is
|
||||
also a link to an uninstaller that removes the files and undoes the
|
||||
|
|
|
@ -3,7 +3,6 @@ Introduction
|
|||
|
||||
These pages provide a brief introduction to LAMMPS.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -11,25 +11,20 @@ University:
|
|||
* Richard Berger, richard.berger at temple.edu
|
||||
|
||||
.. _sjp: http://www.cs.sandia.gov/~sjplimp
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
Past developers include Paul Crozier and Mark Stevens, both at Sandia,
|
||||
and Ray Shan, now at Materials Design.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
The `Authors page <http://lammps.sandia.gov/authors.html>`_ of the
|
||||
The `Authors page <https://lammps.sandia.gov/authors.html>`_ of the
|
||||
`LAMMPS website <lws_>`_ has a comprehensive list of all the individuals
|
||||
who have contributed code for a new feature or command or tool to
|
||||
LAMMPS.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
The following folks deserve special recognition. Many of the packages
|
||||
they have written are unique for an MD code and LAMMPS would not be as
|
||||
general-purpose as it is without their expertise and efforts.
|
||||
|
@ -49,11 +44,9 @@ general-purpose as it is without their expertise and efforts.
|
|||
* Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
|
||||
* Greg Wagner (Northwestern U), MEAM package for MEAM potential
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
As discussed on the `History page <http://lammps.sandia.gov/history.html>`_ of the website, LAMMPS
|
||||
As discussed on the `History page <https://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:
|
||||
|
|
|
@ -16,10 +16,8 @@ classes of functionality:
|
|||
10. :ref:`Pre- and post-processing <prepost>`
|
||||
11. :ref:`Specialized features (beyond MD itself) <special>`
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
.. _general:
|
||||
|
||||
General features
|
||||
|
@ -189,14 +187,10 @@ Pre- and post-processing
|
|||
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_>`_.
|
||||
|
||||
.. _pizza: http://www.sandia.gov/~sjplimp/pizza.html
|
||||
|
||||
|
||||
.. _pizza: https://pizza.sandia.gov
|
||||
|
||||
.. _python: http://www.python.org
|
||||
|
||||
|
||||
|
||||
.. _special:
|
||||
|
||||
Specialized features
|
||||
|
|
|
@ -66,7 +66,7 @@ Here are suggestions on how to perform these tasks:
|
|||
on-the-fly via its :doc:`dump image <dump_image>` command and pass
|
||||
them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
|
||||
movies from them. 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
|
||||
many excellent and free tools available. See the `Other Codes page <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS website for
|
||||
visualization packages that can use LAMMPS output data.
|
||||
* **Plotting:** See the next bullet about Pizza.py as well as the
|
||||
:doc:`Python <Python_head>` doc page for examples of plotting LAMMPS
|
||||
|
@ -75,7 +75,7 @@ Here are suggestions on how to perform these tasks:
|
|||
it easier to analyze and plot. See the :doc:`Tools <Tools>` doc page
|
||||
for more discussion of the various tools.
|
||||
* **Pizza.py:** Our group has also written a separate toolkit called
|
||||
`Pizza.py <http://pizza.sandia.gov>`_ which can do certain kinds of
|
||||
`Pizza.py <https://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>`_
|
||||
|
|
|
@ -15,16 +15,10 @@ distribution.
|
|||
|
||||
.. _gnu: http://www.gnu.org/copyleft/gpl.html
|
||||
|
||||
|
||||
|
||||
.. _gnuorg: http://www.gnu.org
|
||||
|
||||
|
||||
|
||||
.. _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
|
||||
|
|
|
@ -16,10 +16,10 @@ shared-memory boxes and distributed-memory clusters and
|
|||
supercomputers.
|
||||
|
||||
.. _mpi: http://www-unix.mcs.anl.gov/mpi
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
LAMMPS is written in C++. Earlier versions were written in F77 and
|
||||
F90. See the `History page <http://lammps.sandia.gov/history.html>`_ of
|
||||
F90. See the `History page <https://lammps.sandia.gov/history.html>`_ of
|
||||
the website for details. All versions can be downloaded from the
|
||||
`LAMMPS website <lws_>`_.
|
||||
|
||||
|
|
|
@ -5,32 +5,32 @@ 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.
|
||||
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
* `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>`_
|
||||
* `List of features <https://lammps.sandia.gov/features.html>`_
|
||||
* `List of non-features <https://lammps.sandia.gov/non_features.html>`_
|
||||
* `Recent bug fixes and new features <https://lammps.sandia.gov/bug.html>`_
|
||||
|
||||
* `Download info <http://lammps.sandia.gov/download.html>`_
|
||||
* `Download info <https://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>`_
|
||||
* `LAMMPS open-source license <https://lammps.sandia.gov/open_source.html>`_
|
||||
|
||||
* `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>`_
|
||||
* `Glossary of MD terms relevant to LAMMPS <https://lammps.sandia.gov/glossary.html>`_
|
||||
* `LAMMPS highlights with images <https://lammps.sandia.gov/pictures.html>`_
|
||||
* `LAMMPS highlights with movies <https://lammps.sandia.gov/movies.html>`_
|
||||
* `Mail list <https://lammps.sandia.gov/mail.html>`_
|
||||
* `Workshops <https://lammps.sandia.gov/workshops.html>`_
|
||||
* `Tutorials <https://lammps.sandia.gov/tutorials.html>`_
|
||||
* `Developer guide <https://lammps.sandia.gov/Developer.pdf>`_
|
||||
|
||||
* `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>`_
|
||||
* `Pre- and post-processing tools for LAMMPS <https://lammps.sandia.gov/prepost.html>`_
|
||||
* `Other software usable with LAMMPS <https://lammps.sandia.gov/offsite.html>`_
|
||||
* `Viz tools usable with LAMMPS <https://lammps.sandia.gov/viz.html>`_
|
||||
|
||||
* `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>`_
|
||||
* `Benchmark performance <https://lammps.sandia.gov/bench.html>`_
|
||||
* `Publications that have cited LAMMPS <https://lammps.sandia.gov/papers.html>`_
|
||||
* `Authors of LAMMPS <https://lammps.sandia.gov/authors.html>`_
|
||||
* `History of LAMMPS development <https://lammps.sandia.gov/history.html>`_
|
||||
* `Funding for LAMMPS <https://lammps.sandia.gov/funding.html>`_
|
||||
|
|
|
@ -18,7 +18,7 @@ LAMMPS is an open-source code, distributed freely under the terms of
|
|||
the GNU Public License (GPL).
|
||||
|
||||
The `LAMMPS website <lws_>`_ has a variety of information about the code.
|
||||
It includes links to an on-line version of this manual, a `mailing list <http://lammps.sandia.gov/mail.html>`_ where users can post
|
||||
It includes links to an on-line version of this manual, a `mailing list <https://lammps.sandia.gov/mail.html>`_ where users can post
|
||||
questions, and a `GitHub site <https://github.com/lammps/lammps>`_ where
|
||||
all LAMMPS development is coordinated.
|
||||
|
||||
|
@ -35,7 +35,7 @@ a brief description of the basic code structure of LAMMPS.
|
|||
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands>` since it gives quick access to a doc page for
|
||||
every LAMMPS command.
|
||||
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
@ -5,8 +5,7 @@ Depending on how you obtained LAMMPS, the doc directory has up
|
|||
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
|
||||
plus 2 e-book format files:
|
||||
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: bash
|
||||
|
||||
src # content files for LAMMPS documentation
|
||||
html # HTML version of the LAMMPS manual (see html/Manual.html)
|
||||
|
@ -29,8 +28,8 @@ and PDF files are not included. Instead you need to create them, in one
|
|||
of two ways:
|
||||
|
||||
a. You can "fetch" the current HTML and PDF files from the LAMMPS web
|
||||
site. Just type "make fetch". This should download a html\_www
|
||||
directory and Manual\_www.pdf/Developer\_www.pdf files. Note that if
|
||||
site. Just type "make fetch". This should download a html_www
|
||||
directory and Manual_www.pdf/Developer_www.pdf files. Note that if
|
||||
new LAMMPS features have been added more recently than the date of
|
||||
your LAMMPS version, the fetched documentation will include those
|
||||
changes (but your source code will not, unless you update your local
|
||||
|
@ -49,11 +48,9 @@ b. You can build the HTML or PDF files yourself, by typing "make html"
|
|||
|
||||
----------
|
||||
|
||||
|
||||
The generation of all documentation is managed by the Makefile in
|
||||
the doc directory.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Documentation Build Options:
|
||||
|
@ -74,7 +71,6 @@ the doc directory.
|
|||
|
||||
----------
|
||||
|
||||
|
||||
Installing prerequisites for HTML build
|
||||
=======================================
|
||||
|
||||
|
@ -84,7 +80,6 @@ have to be installed. Here are instructions for common setups:
|
|||
Ubuntu
|
||||
------
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt-get install python-virtualenv
|
||||
|
@ -92,7 +87,6 @@ Ubuntu
|
|||
Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version 7.x)
|
||||
------------------------------------------------------------------------------------
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo yum install python3-virtualenv
|
||||
|
@ -100,7 +94,6 @@ Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version
|
|||
Fedora (since version 22)
|
||||
-------------------------
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo dnf install python3-virtualenv
|
||||
|
@ -121,17 +114,14 @@ virtualenv
|
|||
|
||||
Once Python 3 is installed, open a Terminal and type
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip3 install virtualenv
|
||||
|
||||
This will install virtualenv from the Python Package Index.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Installing prerequisites for epub build
|
||||
=======================================
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ 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
|
||||
`this website page <https://lammps.sandia.gov/bug.html>`_. Every few
|
||||
months, the latest patch release is subjected to more thorough testing
|
||||
and labeled as a *stable* version.
|
||||
|
||||
|
|
|
@ -10,7 +10,6 @@ If you add a new feature to LAMMPS and think it will be of interest to
|
|||
general users, we encourage you to submit it for inclusion in LAMMPS
|
||||
as a pull request on our `GitHub site <https://github.com/lammps/lammps>`_, after reading the :doc:`Modify contribute <Modify_contribute>` doc page.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -8,78 +8,78 @@ style can be created if one of the existing atom styles does not
|
|||
define all the attributes you need to store and communicate with
|
||||
atoms.
|
||||
|
||||
Atom\_vec\_atomic.cpp is a simple example of an atom style.
|
||||
Atom_vec_atomic.cpp is a simple example of an atom style.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See atom\_vec.h for details.
|
||||
class. See atom_vec.h for details.
|
||||
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| init | one time setup (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| grow | re-allocate atom arrays to longer lengths (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| grow\_reset | make array pointers in Atom and AtomVec classes consistent (required) |
|
||||
| grow_reset | make array pointers in Atom and AtomVec classes consistent (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| copy | copy info for one atom to another atom's array locations (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_comm | store an atom's info in a buffer communicated every timestep (required) |
|
||||
| pack_comm | store an atom's info in a buffer communicated every timestep (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_comm\_vel | add velocity info to communication buffer (required) |
|
||||
| pack_comm_vel | add velocity info to communication buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_comm\_hybrid | store extra info unique to this atom style (optional) |
|
||||
| pack_comm_hybrid | store extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_comm | retrieve an atom's info from the buffer (required) |
|
||||
| unpack_comm | retrieve an atom's info from the buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_comm\_vel | also retrieve velocity info (required) |
|
||||
| unpack_comm_vel | also retrieve velocity info (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_comm\_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
| unpack_comm_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_reverse | store an atom's info in a buffer communicating partial forces (required) |
|
||||
| pack_reverse | store an atom's info in a buffer communicating partial forces (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_reverse\_hybrid | store extra info unique to this atom style (optional) |
|
||||
| pack_reverse_hybrid | store extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_reverse | retrieve an atom's info from the buffer (required) |
|
||||
| unpack_reverse | retrieve an atom's info from the buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_reverse\_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
| unpack_reverse_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_border | store an atom's info in a buffer communicated on neighbor re-builds (required) |
|
||||
| pack_border | store an atom's info in a buffer communicated on neighbor re-builds (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_border\_vel | add velocity info to buffer (required) |
|
||||
| pack_border_vel | add velocity info to buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_border\_hybrid | store extra info unique to this atom style (optional) |
|
||||
| pack_border_hybrid | store extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_border | retrieve an atom's info from the buffer (required) |
|
||||
| unpack_border | retrieve an atom's info from the buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_border\_vel | also retrieve velocity info (required) |
|
||||
| unpack_border_vel | also retrieve velocity info (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_border\_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
| unpack_border_hybrid | retrieve extra info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_exchange | store all an atom's info to migrate to another processor (required) |
|
||||
| pack_exchange | store all an atom's info to migrate to another processor (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_exchange | retrieve an atom's info from the buffer (required) |
|
||||
| unpack_exchange | retrieve an atom's info from the buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| size\_restart | number of restart quantities associated with proc's atoms (required) |
|
||||
| size_restart | number of restart quantities associated with proc's atoms (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| pack\_restart | pack atom quantities into a buffer (required) |
|
||||
| pack_restart | pack atom quantities into a buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| unpack\_restart | unpack atom quantities from a buffer (required) |
|
||||
| unpack_restart | unpack atom quantities from a buffer (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| create\_atom | create an individual atom of this style (required) |
|
||||
| create_atom | create an individual atom of this style (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| data\_atom | parse an atom line from the data file (required) |
|
||||
| data_atom | parse an atom line from the data file (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| data\_atom\_hybrid | parse additional atom info unique to this atom style (optional) |
|
||||
| data_atom_hybrid | parse additional atom info unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| data\_vel | parse one line of velocity information from data file (optional) |
|
||||
| data_vel | parse one line of velocity information from data file (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| data\_vel\_hybrid | parse additional velocity data unique to this atom style (optional) |
|
||||
| data_vel_hybrid | parse additional velocity data unique to this atom style (optional) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
| memory\_usage | tally memory allocated by atom arrays (required) |
|
||||
| memory_usage | tally memory allocated by atom arrays (required) |
|
||||
+-------------------------+--------------------------------------------------------------------------------+
|
||||
|
||||
The constructor of the derived class sets values for several variables
|
||||
that you must set when defining a new atom style, which are documented
|
||||
in atom\_vec.h. New atom arrays are defined in atom.cpp. Search for
|
||||
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
|
||||
the word "customize" and you will find locations you will need to
|
||||
modify.
|
||||
|
||||
|
@ -95,13 +95,12 @@ modify.
|
|||
New :doc:`pair styles <pair_style>`, :doc:`fixes <fix>`, or
|
||||
:doc:`computes <compute>` can be added to LAMMPS, as discussed below.
|
||||
The code for these classes can use the per-atom properties defined by
|
||||
fix property/atom. The Atom class has a find\_custom() method that is
|
||||
fix property/atom. The Atom class has a find_custom() method that is
|
||||
useful in this context:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
int index = atom->find_custom(char \*name, int &flag);
|
||||
int index = atom->find_custom(char *name, int &flag);
|
||||
|
||||
The "name" of a custom attribute, as specified in the :doc:`fix property/atom <fix_property_atom>` command, is checked to verify
|
||||
that it exists and its index is returned. The method also sets flag =
|
||||
|
@ -109,11 +108,10 @@ that it exists and its index is returned. The method also sets flag =
|
|||
The vector of values associated with the attribute can then be
|
||||
accessed using the returned index as
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
int \*ivector = atom->ivector[index];
|
||||
double \*dvector = atom->dvector[index];
|
||||
int *ivector = atom->ivector[index];
|
||||
double *dvector = atom->dvector[index];
|
||||
|
||||
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
|
||||
which store the attributes of individual atoms.
|
||||
|
|
|
@ -10,14 +10,14 @@ See the :doc:`Howto body <Howto_body>` doc page for an overview of using
|
|||
body particles and the various body styles LAMMPS supports. New
|
||||
styles can be created to add new kinds of body particles to LAMMPS.
|
||||
|
||||
Body\_nparticle.cpp is an example of a body particle that is treated as
|
||||
Body_nparticle.cpp is an example of a body particle that is treated as
|
||||
a rigid body containing N sub-particles.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See body.h for details.
|
||||
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| data\_body | process a line from the Bodies section of a data file |
|
||||
| data_body | process a line from the Bodies section of a data file |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| noutrow | number of sub-particles output is generated for |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
|
@ -25,11 +25,11 @@ class. See body.h for details.
|
|||
+----------------------+-----------------------------------------------------------+
|
||||
| output | output values for the Mth sub-particle |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| pack\_comm\_body | body attributes to communicate every timestep |
|
||||
| pack_comm_body | body attributes to communicate every timestep |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| unpack\_comm\_body | unpacking of those attributes |
|
||||
| unpack_comm_body | unpacking of those attributes |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| pack\_border\_body | body attributes to communicate when reneighboring is done |
|
||||
| pack_border_body | body attributes to communicate when reneighboring is done |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
| unpack\_border\_body | unpacking of those attributes |
|
||||
| unpack_border_body | unpacking of those attributes |
|
||||
+----------------------+-----------------------------------------------------------+
|
||||
|
|
|
@ -5,7 +5,7 @@ Classes that compute molecular interactions are derived from the Bond,
|
|||
Angle, Dihedral, and Improper classes. New styles can be created to
|
||||
add new potentials to LAMMPS.
|
||||
|
||||
Bond\_harmonic.cpp is the simplest example of a bond style. Ditto for
|
||||
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
|
||||
the harmonic forms of the angle, dihedral, and improper style
|
||||
commands.
|
||||
|
||||
|
@ -14,9 +14,9 @@ new derived class. See bond.h, angle.h, dihedral.h, and improper.h
|
|||
for details and specific additional methods.
|
||||
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| init | check if all coefficients are set, calls *init\_style* (optional) |
|
||||
| init | check if all coefficients are set, calls *init_style* (optional) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| init\_style | check if style specific conditions are met (optional) |
|
||||
| init_style | check if style specific conditions are met (optional) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| compute | compute the molecular interactions (required) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
|
@ -24,13 +24,13 @@ for details and specific additional methods.
|
|||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| coeff | set coefficients for one type (required) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| equilibrium\_distance | length of bond, used by SHAKE (required, bond only) |
|
||||
| equilibrium_distance | length of bond, used by SHAKE (required, bond only) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| equilibrium\_angle | opening of angle, used by SHAKE (required, angle only) |
|
||||
| equilibrium_angle | opening of angle, used by SHAKE (required, angle only) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| write & read\_restart | writes/reads coeffs to restart files (required) |
|
||||
| write & read_restart | writes/reads coeffs to restart files (required) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| single | force and energy of a single bond or angle (required, bond or angle only) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
| memory\_usage | tally memory allocated by the style (optional) |
|
||||
| memory_usage | tally memory allocated by the style (optional) |
|
||||
+-----------------------+---------------------------------------------------------------------------+
|
||||
|
|
|
@ -2,8 +2,8 @@ Input script command style
|
|||
==========================
|
||||
|
||||
New commands can be added to LAMMPS input scripts by adding new
|
||||
classes that have a "command" method. For example, the create\_atoms,
|
||||
read\_data, velocity, and run commands are all implemented in this
|
||||
classes that have a "command" method. For example, the create_atoms,
|
||||
read_data, velocity, and run commands are all implemented in this
|
||||
fashion. When such a command is encountered in the LAMMPS input
|
||||
script, LAMMPS simply creates a class with the corresponding name,
|
||||
invokes the "command" method of the class, and passes it the arguments
|
||||
|
|
|
@ -7,8 +7,8 @@ quantities like kinetic energy and the centro-symmetry parameter
|
|||
are derived from the Compute class. New styles can be created
|
||||
to add new calculations to LAMMPS.
|
||||
|
||||
Compute\_temp.cpp is a simple example of computing a scalar
|
||||
temperature. Compute\_ke\_atom.cpp is a simple example of computing
|
||||
Compute_temp.cpp is a simple example of computing a scalar
|
||||
temperature. Compute_ke_atom.cpp is a simple example of computing
|
||||
per-atom kinetic energy.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
|
@ -17,41 +17,41 @@ class. See compute.h for details.
|
|||
+-----------------------+------------------------------------------------------------------+
|
||||
| init | perform one time setup (required) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| init\_list | neighbor list setup, if needed (optional) |
|
||||
| init_list | neighbor list setup, if needed (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| compute\_scalar | compute a scalar quantity (optional) |
|
||||
| compute_scalar | compute a scalar quantity (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| compute\_vector | compute a vector of quantities (optional) |
|
||||
| compute_vector | compute a vector of quantities (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| compute\_peratom | compute one or more quantities per atom (optional) |
|
||||
| compute_peratom | compute one or more quantities per atom (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| compute\_local | compute one or more quantities per processor (optional) |
|
||||
| compute_local | compute one or more quantities per processor (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| pack\_comm | pack a buffer with items to communicate (optional) |
|
||||
| pack_comm | pack a buffer with items to communicate (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| unpack\_comm | unpack the buffer (optional) |
|
||||
| unpack_comm | unpack the buffer (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| pack\_reverse | pack a buffer with items to reverse communicate (optional) |
|
||||
| pack_reverse | pack a buffer with items to reverse communicate (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| unpack\_reverse | unpack the buffer (optional) |
|
||||
| unpack_reverse | unpack the buffer (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| remove\_bias | remove velocity bias from one atom (optional) |
|
||||
| remove_bias | remove velocity bias from one atom (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| remove\_bias\_all | remove velocity bias from all atoms in group (optional) |
|
||||
| remove_bias_all | remove velocity bias from all atoms in group (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| restore\_bias | restore velocity bias for one atom after remove\_bias (optional) |
|
||||
| restore_bias | restore velocity bias for one atom after remove_bias (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| restore\_bias\_all | same as before, but for all atoms in group (optional) |
|
||||
| restore_bias_all | same as before, but for all atoms in group (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| pair\_tally\_callback | callback function for *tally*\ -style computes (optional). |
|
||||
| pair_tally_callback | callback function for *tally*\ -style computes (optional). |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
| memory\_usage | tally memory usage (optional) |
|
||||
| memory_usage | tally memory usage (optional) |
|
||||
+-----------------------+------------------------------------------------------------------+
|
||||
|
||||
Tally-style computes are a special case, as their computation is done
|
||||
in two stages: the callback function is registered with the pair style
|
||||
and then called from the Pair::ev\_tally() function, which is called for
|
||||
and then called from the Pair::ev_tally() function, which is called for
|
||||
each pair after force and energy has been computed for this pair. Then
|
||||
the tallied values are retrieved with the standard compute\_scalar or
|
||||
compute\_vector or compute\_peratom methods. The USER-TALLY package
|
||||
provides *examples*\ \_compute\_tally.html for utilizing this mechanism.
|
||||
the tallied values are retrieved with the standard compute_scalar or
|
||||
compute_vector or compute_peratom methods. The USER-TALLY package
|
||||
provides *examples*\ _compute_tally.html for utilizing this mechanism.
|
||||
|
|
|
@ -2,7 +2,7 @@ Submitting new features for inclusion in LAMMPS
|
|||
===============================================
|
||||
|
||||
We encourage users to submit new features or modifications for LAMMPS
|
||||
to `the core developers <http://lammps.sandia.gov/authors.html>`_ so they
|
||||
to `the core developers <https://lammps.sandia.gov/authors.html>`_ so they
|
||||
can be added to the LAMMPS distribution. The preferred way to manage
|
||||
and coordinate this is as of Fall 2016 via the LAMMPS project on
|
||||
`GitHub <https://github.com/lammps/lammps>`_. An alternative is to
|
||||
|
@ -44,12 +44,12 @@ are listed and described on the :doc:`Packages details <Packages_details>` doc p
|
|||
|
||||
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 the `Open source <http://lammps.sandia.gov/open_source.html>`_ page on the LAMMPS
|
||||
used as a license for the rest of LAMMPS. See the `Open source <https://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
|
||||
code and on the `Authors page <http://lammps.sandia.gov/authors.html>`_
|
||||
code and on the `Authors page <https://lammps.sandia.gov/authors.html>`_
|
||||
of the `LAMMPS WWW site <lws_>`_), is a means for you to distribute your
|
||||
work to the LAMMPS user community, and a mechanism for others to
|
||||
easily try out your new feature. This may help you find bugs or make
|
||||
|
@ -63,13 +63,13 @@ unusual event).
|
|||
If you prefer to actively develop and support your add-on
|
||||
feature yourself, then you may wish to make it available for download
|
||||
from your own website, as a user package that LAMMPS users can add to
|
||||
their copy of LAMMPS. See the `Offsite LAMMPS packages and tools <http://lammps.sandia.gov/offsite.html>`_ page of the LAMMPS web
|
||||
their copy of LAMMPS. See the `Offsite LAMMPS packages and tools <https://lammps.sandia.gov/offsite.html>`_ page of the LAMMPS web
|
||||
site for examples of groups that do this. We are happy to advertise
|
||||
your package and web site from that page. Simply email the
|
||||
`developers <http://lammps.sandia.gov/authors.html>`_ with info about
|
||||
`developers <https://lammps.sandia.gov/authors.html>`_ with info about
|
||||
your package and we will post it there.
|
||||
|
||||
.. _lws: http://lammps.sandia.gov
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
The previous sections of this doc page describe how to add new "style"
|
||||
files of various kinds to LAMMPS. Packages are simply collections of
|
||||
|
@ -78,7 +78,7 @@ LAMMPS input script. If designed correctly, these additions typically
|
|||
do not require changes to the main core of LAMMPS; they are simply
|
||||
add-on files. If you think your new feature requires non-trivial
|
||||
changes in core LAMMPS files, you should `communicate with the
|
||||
developers <http://lammps.sandia.gov/authors.html>`_, since we may or
|
||||
developers <https://lammps.sandia.gov/authors.html>`_, since we may or
|
||||
may not want to include those changes for some reason. An example of a
|
||||
trivial change is making a parent-class method "virtual" when you derive
|
||||
a new child class from it.
|
||||
|
@ -90,8 +90,8 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
|||
|
||||
* All source files you provide must compile with the most current
|
||||
version of LAMMPS with multiple configurations. In particular you
|
||||
need to test compiling LAMMPS from scratch with -DLAMMPS\_BIGBIG
|
||||
set in addition to the default -DLAMMPS\_SMALLBIG setting. Your code
|
||||
need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
|
||||
set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
|
||||
will need to work correctly in serial and in parallel using MPI.
|
||||
|
||||
* For consistency with the rest of LAMMPS and especially, if you want
|
||||
|
@ -106,7 +106,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
|||
(<cstdlib>, <cstdio>, or <cstring>) instead of the C-style names
|
||||
<stdlib.h>, <stdio.h>, or <string.h>), and forward declarations
|
||||
used where possible or needed to avoid including headers.
|
||||
All added code should be placed into the LAMMPS\_NS namespace or a
|
||||
All added code should be placed into the LAMMPS_NS namespace or a
|
||||
sub-namespace; global or static variables should be avoided, as they
|
||||
conflict with the modular nature of LAMMPS and the C++ class structure.
|
||||
Header files must **not** import namespaces with *using*\ .
|
||||
|
@ -164,7 +164,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
|||
mathematical expression or figures (see doc/JPG for examples).
|
||||
Additional PDF files with further details (see doc/PDF for examples)
|
||||
may also be included. The doc page should also include literature
|
||||
citations as appropriate; see the bottom of doc/fix\_nh.rst for
|
||||
citations as appropriate; see the bottom of doc/fix_nh.rst for
|
||||
examples and the earlier part of the same file for how to format the
|
||||
cite itself. Citation labels must be unique across all .rst files.
|
||||
The "Restrictions" section of the doc page should indicate if your
|
||||
|
@ -191,7 +191,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
|||
* If there is a paper of yours describing your feature (either the
|
||||
algorithm/science behind the feature itself, or its initial usage, or
|
||||
its implementation in LAMMPS), you can add the citation to the \*.cpp
|
||||
source file. See src/USER-EFF/atom\_vec\_electron.cpp for an example.
|
||||
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
|
||||
A LaTeX citation is stored in a variable at the top of the file and a
|
||||
single line of code that references the variable is added to the
|
||||
constructor of the class. Whenever a user invokes your feature from
|
||||
|
@ -203,7 +203,6 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
|||
usage. That kind of citation should just be in the doc page you
|
||||
provide.
|
||||
|
||||
|
||||
Finally, as a general rule-of-thumb, the more clear and
|
||||
self-explanatory you make your documentation and README files, and the
|
||||
easier you make it for people to get started, e.g. by providing example
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue