ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge with current develop

Browse Source
This commit is contained in:
Steve Plimpton
2023-10-20 13:31:32 -06:00
parent 201f8cda9a f641d88f86
commit 1c4ab13f01
370 changed files with 13017 additions and 4088 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/codeql-analysis.yml vendored
View File

@ -25,7 +25,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2

2
.github/workflows/compile-msvc.yml vendored
View File

@ -19,7 +19,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2

2
.github/workflows/coverity.yml vendored
View File

@ -16,7 +16,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2

2
.github/workflows/unittest-macos.yml vendored
View File

@ -21,7 +21,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2

4
cmake/Modules/Packages/ML-PACE.cmake
View File

@ -1,6 +1,6 @@
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.01.3.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.10.04.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "4f0b3b5b14456fe9a73b447de3765caa" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
set(PACELIB_MD5 "70ff79f4e59af175e55d24f3243ad1ff" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)

BIN
cmake/packaging/LAMMPS_DMG_Background.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 85 KiB

After

Width:  |  Height:  |  Size: 86 KiB

2
cmake/packaging/MacOSXBundleInfo.plist.in
View File

@ -17,7 +17,7 @@
<key>CFBundleLongVersionString</key>
<string>${MACOSX_BUNDLE_LONG_VERSION_STRING}</string>
<key>CFBundleName</key>
<string>LAMMPS</string>
<string>LAMMPS_GUI</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>

26
cmake/packaging/README.macos
View File

@ -9,7 +9,7 @@ of the available packages.
The following individual commands are included:
binary2txt lammps-gui lmp msi2lmp phana stl_bin2txt
After copying the lammps-gui folder into your Applications folder, please follow
After copying the LAMMPS_GUI folder into your Applications folder, please follow
these steps:
1. Open the Terminal app
@ -23,7 +23,7 @@ these steps:
3. Add the following lines to the end of the file, save it, and close the editor
LAMMPS_INSTALL_DIR=/Applications/LAMMPS.app/Contents
LAMMPS_INSTALL_DIR=/Applications/LAMMPS_GUI.app/Contents
LAMMPS_POTENTIALS=${LAMMPS_INSTALL_DIR}/share/lammps/potentials
LAMMPS_BENCH_DIR=${LAMMPS_INSTALL_DIR}/share/lammps/bench
MSI2LMP_LIBRARY=${LAMMPS_INSTALL_DIR}/share/lammps/frc_files
@ -38,9 +38,9 @@ these steps:
the changes from .zprofile automatically.
Note: the above assumes you use the default shell (zsh) that comes with
MacOS. If you customized MacOS to use a different shell, you'll need to modify
that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
to modify the same environment variables.
MacOS. If you customized MacOS to use a different shell, you'll need to
modify that shell's init file (.cshrc, .bashrc, etc.) instead with
appropiate commands to modify the same environment variables.
5. Try running LAMMPS (which might fail, see step 7)
@ -50,10 +50,10 @@ these steps:
lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
Depending on the size and resolution of your screen, the fonts may
be too small to read. This can be adjusted by setting the environment
variable QT_FONT_DPI. The default value would be 72, so to increase
the fonts by a third one can add to the .zprofile file the line
Depending on the size and resolution of your screen, the fonts may be too
small to read. This can be adjusted by setting the environment variable
QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
third, one can add to the .zprofile file the line
export QT_FONT_DPI=96
@ -61,9 +61,9 @@ these steps:
7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
MacOS will likely block the initial run of the executables, since they
were downloaded from the internet and are missing a known signature from an
identified developer. Go to "Settings" and search for "Security settings". It
should display a message that an executable like "lmp" was blocked. Press
MacOS will likely block the initial run of the executables, since they were
downloaded from the internet and are missing a known signature from an
identified developer. Go to "Settings" and search for "Security settings".
It should display a message that an executable like "lmp" was blocked. Press
"Open anyway", which might prompt you for your admin credentials. Afterwards
"lmp" and the other executables should work as expected.

4
cmake/packaging/build_linux_tgz.sh
View File

@ -4,7 +4,7 @@ APP_NAME=lammps-gui
DESTDIR=${PWD}/../LAMMPS_GUI
echo "Delete old files, if they exist"
rm -rf ${DESTDIR} ../LAMMPS-Linux-amd64.tar.gz
rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz
echo "Create staging area for deployment and populate"
DESTDIR=${DESTDIR} cmake --install . --prefix "/"
@ -69,7 +69,7 @@ do \
done
pushd ..
tar -czvvf LAMMPS-Linux-amd64.tar.gz LAMMPS_GUI
tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI
popd
echo "Cleanup dir"

14
cmake/packaging/build_macos_dmg.sh
View File

@ -3,7 +3,7 @@
APP_NAME=lammps-gui
echo "Delete old files, if they exist"
rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS-macOS-multiarch.dmg
rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg
echo "Create initial dmg file with macdeployqt"
macdeployqt lammps-gui.app -dmg
@ -22,8 +22,8 @@ ln -s /Applications .
mv ${APP_NAME}.app/Contents/Resources/README.txt .
mkdir .background
mv ${APP_NAME}.app/Contents/Resources/LAMMPS_DMG_Background.png .background/background.png
mv ${APP_NAME}.app LAMMPS.app
cd LAMMPS.app/Contents
mv ${APP_NAME}.app LAMMPS_GUI.app
cd LAMMPS_GUI.app/Contents
echo "Attach icons to LAMMPS console and GUI executables"
echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
@ -75,7 +75,7 @@ echo '
set statusbar visible to false
set toolbar visible to false
set the bounds to { 100, 40, 868, 640 }
set position of item "'LAMMPS'.app" to { 190, 216 }
set position of item "'LAMMPS_GUI'.app" to { 190, 216 }
set position of item "Applications" to { 576, 216 }
set position of item "README.txt" to { 190, 400 }
end tell
@ -96,12 +96,12 @@ sync
echo "Unmount modified disk image and convert to compressed read-only image"
hdiutil detach "${DEVICE}"
hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
echo "Attach icon to .dmg file"
echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
SetFile -a C LAMMPS-macOS-multiarch.dmg
Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
rm icon.rsrc
echo "Delete temporary disk images"

11
cmake/packaging/build_windows_vs.cmake
View File

@ -1,7 +1,7 @@
# CMake script to be run post installation to build zipped package
# clean up old zipfile and deployment tree
file(REMOVE LAMMPS-Win10-amd64.zip)
file(REMOVE LAMMPS_GUI-Win10-amd64.zip)
file(REMOVE_RECURSE LAMMPS_GUI)
file(RENAME ${INSTNAME} LAMMPS_GUI)
@ -21,8 +21,15 @@ file(WRITE qtdeploy.bat "@ECHO OFF\r\nset VSCMD_DEBUG=0\r\nCALL ${VC_INIT} x64\r
execute_process(COMMAND cmd.exe /c qtdeploy.bat COMMAND_ECHO STDERR)
file(REMOVE qtdeploy.bat)
# download and uncompress static FFMpeg and gzip binaries
file(DOWNLOAD "https://download.lammps.org/thirdparty/ffmpeg-gzip.zip" ffmpeg-gzip.zip)
file(WRITE unpackzip.ps1 "Expand-Archive -Path ffmpeg-gzip.zip -DestinationPath LAMMPS_GUI")
execute_process(COMMAND powershell -ExecutionPolicy Bypass -File unpackzip.ps1)
file(REMOVE unpackzip.ps1)
file(REMOVE ffmpeg-gzip.zip)
# create zip archive
file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS-Win10-amd64.zip")
file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS_GUI-Win10-amd64.zip")
execute_process(COMMAND powershell -ExecutionPolicy Bypass -File makearchive.ps1)
file(REMOVE makearchive.ps1)
file(REMOVE_RECURSE LAMMPS_GUI)

2
cmake/presets/macos-multiarch.cmake
View File

@ -10,5 +10,3 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(BUILD_MPI FALSE CACHE BOOL "" FORCE)
set(BUILD_SHARED_LIBS FALSE CACHE BOOL "" FORCE)
set(LAMMPS_EXCEPTIONS TRUE CACHE BOOL "" FORCE)

6
doc/src/Build_basics.rst
View File

@ -488,8 +488,9 @@ using CMake or Make.
.. code-block:: bash
-D BUILD_TOOLS=value # yes or no (default)
-D BUILD_LAMMPS_SHELL=value # yes or no (default)
-D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
-D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell
-D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui
The generated binaries will also become part of the LAMMPS installation
(see below).
@ -503,7 +504,6 @@ using CMake or Make.
make binary2txt # build only binary2txt tool
make chain # build only chain tool
make micelle2d # build only micelle2d tool
make thermo_extract # build only thermo_extract tool
cd lammps/tools/lammps-shell
make # build LAMMPS shell

14
doc/src/Build_cmake.rst
View File

@ -177,13 +177,13 @@ configuration is selected with the *-C* flag:
ctest -C Debug
The CMake scripts in LAMMPS have basic support for being compiled using a
multi-config build system, but not all of it has been ported. This is in
particular applicable to compiling packages that require additional libraries
that would be downloaded and compiled by CMake. The "windows" preset file
tries to keep track of which packages can be compiled natively with the
MSVC compilers out-of-the box. Not all of those external libraries are
portable to Windows, either.
The CMake scripts in LAMMPS have basic support for being compiled using
a multi-config build system, but not all of it has been ported. This is
in particular applicable to compiling packages that require additional
libraries that would be downloaded and compiled by CMake. The
``windows.cmake`` preset file tries to keep track of which packages can
be compiled natively with the MSVC compilers out-of-the box. Not all of
the external libraries are portable to Windows, either.
Installing CMake

193
doc/src/Build_extras.rst
View File

@ -722,9 +722,10 @@ This list was last updated for version 4.0.1 of the Kokkos library.
``cmake/presets`` folder, ``kokkos-serial.cmake``,
``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable
the KOKKOS package and enable some hardware choice. So to compile
with CUDA device parallelization (for GPUs with CC 5.0 and up)
with some common packages enabled, you can do the following:
the KOKKOS package and enable some hardware choices. For GPU
support those preset files must be customized to match the
hardware used. So to compile with CUDA device parallelization with
some common packages enabled, you can do the following:
.. code-block:: bash
@ -886,6 +887,50 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
----------
.. _machdyn:
MACHDYN package
-------------------------------
To build with this package, you must download the Eigen3 library.
Eigen3 is a template library, so you do not need to build it.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
downloaded and inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: Traditional make
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/machdyn/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invokes the ``lib/machdyn/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-machdyn # print help message
make lib-machdyn args="-b" # download to lib/machdyn/eigen3
make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
Note that a symbolic (soft) link named ``includelink`` is created
in ``lib/machdyn`` to point to the Eigen dir. When LAMMPS builds it
will use this link. You should not need to edit the
``lib/machdyn/Makefile.lammps`` file.
----------
.. _mliap:
ML-IAP package
@ -1431,6 +1476,55 @@ ML-POD package
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``lib/quip/README`` file requires setting two environment
variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
the ``lib/quip/Makefile.lammps`` file which is used when you
compile and link LAMMPS with this package. You should only need
to edit ``Makefile.lammps`` if the LAMMPS build can not use its
settings to successfully build on your system.
----------
.. _plumed:
PLUMED package
@ -1952,55 +2046,6 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``lib/quip/README`` file requires setting two environment
variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
the ``lib/quip/Makefile.lammps`` file which is used when you
compile and link LAMMPS with this package. You should only need
to edit ``Makefile.lammps`` if the LAMMPS build can not use its
settings to successfully build on your system.
----------
.. _scafacos:
SCAFACOS package
@ -2048,50 +2093,6 @@ To build with this package, you must download and build the
----------
.. _machdyn:
MACHDYN package
-------------------------------
To build with this package, you must download the Eigen3 library.
Eigen3 is a template library, so you do not need to build it.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
downloaded and inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: Traditional make
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/smd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invokes the ``lib/smd/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-smd # print help message
make lib-smd args="-b" # download to lib/smd/eigen3
make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
Note that a symbolic (soft) link named ``includelink`` is created
in ``lib/smd`` to point to the Eigen dir. When LAMMPS builds it
will use this link. You should not need to edit the
``lib/smd/Makefile.lammps`` file.
----------
.. _vtk:
VTK package

1
doc/src/Build_package.rst
View File

@ -182,6 +182,7 @@ make a copy of one of them and modify it to suit your needs.
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers
cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and

5
doc/src/Commands_fix.rst
View File

@ -69,7 +69,7 @@ OPT.
* :doc:`drude/transform/inverse <fix_drude_transform>`
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`efield (k) <fix_efield>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode>`
@ -181,6 +181,7 @@ OPT.
* :doc:`pour <fix_pour>`
* :doc:`precession/spin <fix_precession_spin>`
* :doc:`press/berendsen <fix_press_berendsen>`
* :doc:`press/langevin <fix_press_langevin>`
* :doc:`print <fix_print>`
* :doc:`propel/self <fix_propel_self>`
* :doc:`property/atom (k) <fix_property_atom>`
@ -232,7 +233,7 @@ OPT.
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
* :doc:`spring/self <fix_spring_self>`
* :doc:`spring/self (k) <fix_spring_self>`
* :doc:`srd <fix_srd>`
* :doc:`store/force <fix_store_force>`
* :doc:`store/state <fix_store_state>`

4
doc/src/Commands_pair.rst
View File

@ -265,7 +265,7 @@ OPT.
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :doc:`snap (ik) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
@ -305,5 +305,5 @@ OPT.
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

686
doc/src/Howto_lammps_gui.rst
View File

@ -1,111 +1,310 @@
Using the LAMMPS GUI
====================
LAMMPS GUI is a simple graphical text editor that is linked to the
:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
directly using the contents of the editor's text buffer as input.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
commands, possibly including the text editor, too, from a command line
terminal window. That is quite effective when running LAMMPS on
high-performance computing facilities and when you are very proficient
in using the command line. The main benefit of a GUI application is
that this integrates well with graphical desktop environments and many
basic tasks can be done directly from within the GUI without switching
to a text console or requiring external programs or scripts to extract
data from the generated output. This makes it easier for beginners to
get started running simple LAMMPS simulations and thus very suitable for
tutorials on LAMMPS. But also makes it easier to switch to a full
featured text editor and more sophisticated visualization and analysis
tools.
This document describes **LAMMPS GUI version 1.5**.
-----
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
.. note::
Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (Ubuntu
20.04LTS or later and compatible), macOS (version 11 aka Big Sur or
later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. They may be linked to a
development version of LAMMPS in case they need features not yet
available in a released version. Serial LAMMPS executables of the
same LAMMPS version are included as well. The source code for the
LAMMPS GUI is included in the LAMMPS source code and can be found in
the ``tools/lammps-gui`` folder. It can be compiled alongside LAMMPS
when :doc:`compiling with CMake <Build_cmake>`.
LAMMPS GUI tries to provide an experience similar to what people
traditionally would do to run LAMMPS using a command line window:
- editing inputs with a text editor
- run LAMMPS on the input with selected command line flags
- and then use or extract data from the created files and visualize it
That procedure is quite effective for people proficient in using the
command line, as that allows them to use tools for the individual steps
which they are most comfortable with. It is often required when running
LAMMPS on high-performance computing facilities.
The main benefit of using the LAMMPS GUI application instead is that
many basic tasks can be done directly from the GUI without switching to
a text console window or using external programs, let alone writing
scripts to extract data from the generated output. It also integrates
well with graphical desktop environments.
LAMMPS GUI thus makes it easier for beginners to get started running
simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
since you only need to learn how to use a single program for most tasks
and thus time can be saved and people can focus on learning LAMMPS. It
is also designed to keep the barrier low when you decide to switch to a
full featured, standalone programming editor and more sophisticated
visualization and analysis tools and run LAMMPS from a command line.
The following text provides a detailed tour of the features and
functionality of the LAMMPS GUI. This document describes LAMMPS GUI
version 1.2.
functionality of the LAMMPS GUI.
Suggestions for new features and reports of bugs are always welcome.
You can use the :doc:`the same channels as for LAMMPS itself
<Errors_bugs>` for that purpose.
-----
Main window
-----------
When LAMMPS GUI starts, it will show the main window with either an
empty buffer, or have a file loaded. In the latter case it may look like
the following:
When LAMMPS GUI starts, it will show a main window with either an
empty buffer or the contents of a loaded file. In the latter case it
may look like the following:
.. image:: JPG/lammps-gui-main.png
:align: center
:scale: 50%
There is the menu bar at the top, then the main editor buffer with the
input file contents in the center with line numbers on the left and the
input colored according to the LAMMPS input file syntax. At the bottom
is the status bar, which shows the status of LAMMPS execution on the
left ("Ready." when idle) and the current working directory on the
right. The size of the main window will be stored when exiting and
restored when starting again. The name of the current file in the
buffer is shown in the window title and the text `*modified*` is added
in case the buffer has modifications that are not yet saved to a file.
There is the typical menu bar at the top, then the main editor buffer,
and a status bar at the bottom. The input file contents are shown
with line numbers on the left and the input is colored according to
the LAMMPS input file syntax. The status bar shows the status of
LAMMPS execution on the left (e.g. "Ready." when idle) and the current
working directory on the right. The name of the current file in the
buffer is shown in the window title; the word `*modified*` is added if
the buffer edits have not yet saved to a file. The size of the main
window will be stored when exiting and restored when starting again.
Opening Files
^^^^^^^^^^^^^
The LAMMPS GUI application will try to open the first command line
argument as input file, further arguments are ignored. When no
argument is given LAMMPS GUI will start with an empty buffer.
Files can also be opened via the ``File`` menu or by drag-and-drop
of a file from a file manager to the editor window. Only one
file can be open at a time, so opening a new file with a filled
buffer will close this buffer and in case the buffer has unsaved
modifications will ask to either cancel the load, discard the
changes or save them.
argument as a LAMMPS input script, further arguments are ignored.
When no argument is given, LAMMPS GUI will start with an empty buffer.
Files can also be opened via the ``File`` menu or by drag-and-drop of
a file from a graphical file manager into the editor window. Only one
file can be open at a time, so opening a new file with a filled buffer
will close the buffer. If the buffer has unsaved modifications, you
will be asked to either cancel the operation, discard the changes, or
save them.
Running LAMMPS
^^^^^^^^^^^^^^
From within the LAMMPS GUI main window LAMMPS can be started either from
the ``Run`` menu, by the hotkey `Ctrl-Enter` (`Command-Enter` on macOS),
or by clicking on the green button in the status bar. LAMMPS runs in a
separate thread, so the GUI stays responsive and thus it is able to
interact with the calculation and access its data. It is important to
note, that LAMMPS is using the contents of the input buffer for the run,
**not** the file it was read from. If there are unsaved changes in the
buffer, they *will* be used.
the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by
the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by
clicking on the green "Run" button in the status bar. All of these
operations will cause LAMMPS to process the entire input script, which
may contain multiple :doc:`run <run>` or :doc:`minimize <minimize>`
commands.
LAMMPS runs in a separate thread, so the GUI stays responsive and is
able to interact with the running calculation and access data it
produces. It is important to note that running LAMMPS this way is
using the contents of the input buffer for the run (via the
:cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
interface), and **not** the original file it was read from. Thus, if
there are unsaved changes in the buffer, they *will* be used. As an
alternative, it is also possible to run LAMMPS by reading the contents
of a file from the ``Run LAMMPS from File`` menu entry or with
`Ctrl-Shift-Enter`. This option may be required in some rare cases
where the input uses some functionality that is not compatible with
running LAMMPS from a string buffer. For consistency, any unsaved
changes in the buffer must be either saved to the file or undone
before LAMMPS can be run from a file.
.. image:: JPG/lammps-gui-running.png
:align: center
:scale: 75%
While LAMMPS is running, the contents of the status bar change: on the
left side there is a text indicating that LAMMPS is running, which will
contain the selected number of threads, if thread-parallel acceleration
was selected in the ``Preferences`` dialog. On the right side, a
progress bar is shown that displays the estimated progress on the
current :doc:`run command <run>`. Additionally, two windows will open:
the log window with the captured screen output and the chart window with
a line graph created from the thermodynamic output of the run.
While LAMMPS is running, the contents of the status bar change. On
the left side there is a text indicating that LAMMPS is running, which
will also show the number of active threads, if thread-parallel
acceleration was selected in the ``Preferences`` dialog. On the right
side, a progress bar is shown that displays the estimated progress for
the current :doc:`run command <run>`.
The run can be stopped cleanly by using either the ``Stop LAMMPS`` entry
in the ``Run`` menu, the hotkey `Ctrl-/` (`Command-/` on macOS), or
clicking on the red button in the status bar. This will cause that the
running LAMMPS process will complete the current iteration and then
stop. This is equivalent to the command :doc:`timer timeout 0 <timer>`
and implemented by calling the :cpp:func:`lammps_force_timeout()`
function of the LAMMPS C-library interface.
Also, the line number of the currently executed command will be
highlighted in green.
.. image:: JPG/lammps-gui-run-highlight.png
:align: center
:scale: 75%
If an error occurs (in the example below the command :doc:`label
<label>` was incorrectly capitalized as "Label"), an error message
dialog will be shown and the line of the input which triggered the
error will be highlighted. The state of LAMMPS in the status bar will
be set to "Failed." instead of "Ready."
.. image:: JPG/lammps-gui-run-error.png
:align: center
:scale: 75%
Up to three additional windows will open during a run:
- a log window with the captured screen output
- a chart window with a line graph created from the thermodynamic output of the run
- a slide show window with images created by a :doc:`dump image command <dump_image>`
More information on those windows and how to adjust their behavior and
contents is given below.
An active LAMMPS run can be stopped cleanly by using either the ``Stop
LAMMPS`` entry in the ``Run`` menu, the keyboard shortcut `Ctrl-/`
(`Command-/` on macOS), or by clicking on the red button in the status
bar. This will cause the running LAMMPS process to complete the current
timestep (or iteration for energy minimization) and then complete the
processing of the buffer while skipping all run or minimize commands.
This is equivalent to the input script command :doc:`timer timeout 0
<timer>` and is implemented by calling the
:cpp:func:`lammps_force_timeout()` function of the LAMMPS C-library
interface. Please see the corresponding documentation pages to
understand the implications of this operation.
Log Window
----------
By default, when starting a run, a "Log Window" will open that displays
the current screen output of the LAMMPS calculation, that would normally
be seen in the command line window, as shown below.
.. image:: JPG/lammps-gui-log.png
:align: center
:scale: 50%
LAMMPS GUI captures the screen output as it is generated and updates
the log window regularly during a run.
By default, the log window will be replaced each time a run is started.
The runs are counted and the run number for the current run is displayed
in the window title. It is possible to change the behavior of LAMMPS
GUI in the preferences dialog to create a *new* log window for every run
or to not show the current log window. It is also possible to show or
hide the *current* log window from the ``View`` menu.
The text in the log window is read-only and cannot be modified, but
keyboard shortcuts to select and copy all or parts of the text can be
used to transfer text to another program. Also, the keyboard shortcut
`Ctrl-S` (`Command-S` on macOS) is available to save the log buffer to a
file. The "Select All" and "Copy" functions, as well as a "Save Log to
File" option are also available from a context menu by clicking with the
right mouse button into the log window text area.
Chart Window
------------
By default, when starting a run, a "Chart Window" will open that
displays a plot of thermodynamic output of the LAMMPS calculation as
shown below.
.. image:: JPG/lammps-gui-chart.png
:align: center
:scale: 50%
The drop down menu on the top right allows selection of different
properties that are computed and written to thermo output. Only one
property can be shown at a time. The plots will be updated with new
data as the run progresses, so they can be used to visually monitor the
evolution of available properties. The window title will show the
current run number that this chart window corresponds to. Same as
explained for the log window above, by default, the chart window will
be replaced on each new run, but the behavior can be changed in the
preferences dialog.
From the ``File`` menu on the top left, it is possible to save an image
of the currently displayed plot or export the data in either plain text
columns (for use by plotting tools like `gnuplot
<http://www.gnuplot.info/>`_ or `grace
<https://plasma-gate.weizmann.ac.il/Grace/>`_), or as CSV data which can
be imported for further processing with Microsoft Excel or `pandas
<https://pandas.pydata.org/>`_
Thermo output data from successive run commands in the input script will
be combined into a single data set unless the format, number, or names
of output columns are changed with a :doc:`thermo_style <thermo_style>`
or a :doc:`thermo_modify <thermo_modify>` command, or the current time
step is reset with :doc:`reset_timestep <reset_timestep>`, or if a
:doc:`clear <clear>` command is issued.
Image Slide Show
----------------
By default, if the LAMMPS input contains a :doc:`dump image
<dump_image>` command, a "Slide Show" window will open which loads and
displays the images created by LAMMPS as they are written.
.. image:: JPG/lammps-gui-slideshow.png
:align: center
:scale: 50%
The various buttons at the bottom right of the window allow single
stepping through the sequence of images or playing an animation (as a
continuous loop or once from first to last). It is also possible to
zoom in or zoom out of the displayed images, and to export the slide
show animation to a movie file, if `ffmpeg <https://ffmpeg.org/>`_ is
installed.
Variable Info
-------------
During a run, it may be of interest to monitor the value of input script
variables, for example to monitor the progress of loops. This can be
done by enabling the "Variables Window" in the ``View`` menu or by using
the `Ctrl-Shift-W` keyboard shortcut. This will show info similar to
the :doc:`info variables <info>` command in a separate window as shown
below.
.. image:: JPG/lammps-gui-variable-info.png
:align: center
:scale: 75%
Like the log and chart windows, its content is continuously updated
during a run. It will show "(none)" if there are no variables
defined. Note that it is also possible to *set* :doc:`index style
variables <variable>`, that would normally be set via command line
flags, via the "Set Variables..." dialog from the ``Run`` menu.
LAMMPS GUI will automatically set the variable "gui_run" to the
current value of the run counter. That way it would be possible
to automatically record a log for each run attempt by using the
command
.. code-block:: LAMMPS
log logfile-${gui_run}.txt
at the beginning of an input file. That would record logs to files
``logfile-1.txt``, ``logfile-2.txt``, and so on for successive runs.
Viewing Snapshot Images
^^^^^^^^^^^^^^^^^^^^^^^
-----------------------
By selecting the ``View Image`` entry in the ``Run`` menu, by hitting
the `Ctrl-I` (`Command-I` on macOS) hotkey or by clicking on the
"palette" button in the status bar, LAMMPS GUI will issue a
:doc:`write_dump image <dump_image>` command and read the resulting
snapshot image into an image viewer window. When possible, LAMMPS
GUI will try to detect which elements the atoms correspond to (via
their mass) and then colorize them accordingly. Otherwise just some
predefined sequence of colors are assigned to different atom types.
By selecting the ``Create Image`` entry in the ``Run`` menu, or by
hitting the `Ctrl-I` (`Command-I` on macOS) keyboard shortcut, or by
clicking on the "palette" button in the status bar, LAMMPS GUI will send
a custom :doc:`write_dump image <dump_image>` command to LAMMPS and read
the resulting snapshot image with the current state of the system into
an image viewer window. This functionality is not available *during* an
ongoing run. When LAMMPS is not yet initialized, LAMMPS GUI will try to
identify the line with the first run or minimize command and execute all
command up to that line from the input buffer and then add a "run 0"
command. This will initialize the system so an image of the initial
state of the system can be rendered. If there was an error, the
snapshot image viewer will not appear.
When possible, LAMMPS GUI will try to detect which elements the atoms
correspond to (via their mass) and then colorize them in the image
accordingly. Otherwise the default predefined sequence of colors is
assigned to the different atom types.
.. image:: JPG/lammps-gui-image.png
:align: center
@ -114,28 +313,68 @@ predefined sequence of colors are assigned to different atom types.
The default image size, some default image quality settings, the view
style and some colors can be changed in the ``Preferences`` dialog
window. From the image viewer window further adjustments can be made:
actual image size, high-quality rendering, anti-aliasing, view style,
display of box or axes, zoom factor. The the image can be rotated
horizontally and vertically and it is possible to only display the atoms
within a predefined group (default is "all"). After each change, the
image is rendered again and the display updated. The small palette icon
on the top left will be colored while LAMMPS is running to render the
image and it will be grayed out again, when it is done. When there are
many items to show and high quality images with anti-aliasing are
requested, re-rendering can take several seconds. From the ``File``
menu, the shown image can be saved to a file permanently or copied into
the cut-n-paste buffer for pasting into another application.
actual image size, high-quality (SSAO) rendering, anti-aliasing, view
style, display of box or axes, zoom factor. The view of the system
can be rotated horizontally and vertically. It is also possible to
only display the atoms within a group defined in the input script
(default is "all"). After each change, the image is rendered again
and the display updated. The small palette icon on the top left will
be colored while LAMMPS is running to render the new image; it will be
grayed out when it is finished. When there are many atoms to render
and high quality images with anti-aliasing are requested, re-rendering
may take several seconds. From the ``File`` menu of the image window,
the current image can be saved to a file or copied into the
cut-n-paste buffer for pasting into another application.
Editor Functions
^^^^^^^^^^^^^^^^
----------------
The editor has most the usual functionality that similar programs have:
text selection via mouse or with cursor moves while holding the Shift
key, Cut, Copy, Paste, Undo, Redo. All of these editing functions are
available via hotkeys. When trying to exit the editor with a modified
buffer, a dialog will pop up asking whether to cancel the quit, or don't
save or save the buffer's contents to a file.
The editor has most of the usual functionality that similar programs
have: text selection via mouse or with cursor moves while holding the
Shift key, Cut (`Ctrl-X`), Copy (`Ctrl-C`), Paste (`Ctrl-V`), Undo
(`Ctrl-Z`), Redo (`Ctrl-Shift-Z`), Select All (`Ctrl-A`). When trying
to exit the editor with a modified buffer, a dialog will pop up asking
whether to cancel the exit operation, or to save or not save the buffer
contents to a file.
Context Specific Word Completion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default, LAMMPS GUI will display a small pop-up frame with possible
choices for LAMMPS input script commands or styles after 2 characters of
a word have been typed.
.. image:: JPG/lammps-gui-complete.png
:align: center
:scale: 75%
The word can then be completed through selecting an entry by scrolling
up and down with the cursor keys and selecting with the 'Enter' key or
by clicking on the entry with the mouse. The automatic completion
pop-up can be disabled in the ``Preferences`` dialog, but the completion
can still be requested manually by either hitting the 'Shift-TAB' key or
by right-clicking with the mouse and selecting the option from the
context menu. Most of the completion information is taken from the
LAMMPS instance and thus it will be adjusted to only show available
options that have been enabled while compiling LAMMPS. That, however,
excludes accelerated styles and commands; for improved clarity, only the
non-suffix version of styles are shown.
Line Reformatting
^^^^^^^^^^^^^^^^^
The editor supports reformatting lines according to the syntax in order
to have consistently aligned lines. This primarily means adding
whitespace padding to commands, type specifiers, IDs and names. This
reformatting is performed by default when hitting the 'Enter' key to
start a new line. This feature can be turned on or off in the
``Preferences`` dialog, but it can still be manually performed by
hitting the 'TAB' key. The amount of padding can also be changed in the
``Preferences`` dialog.
Internally this functionality is achieved by splitting the line into
"words" and then putting it back together with padding added where the
context can be detected; otherwise a single space is used between words.
Context Specific Help
^^^^^^^^^^^^^^^^^^^^^
@ -145,22 +384,23 @@ Context Specific Help
:scale: 50%
A unique feature of the LAMMPS GUI is the option to look up the
documentation for the command in the current line. This can be achieved
by either clicking the right mouse button or by using the `Ctrl-?`
hotkey. When clicking the mouse there are additional entries in the
documentation for the command in the current line. This can be done by
either clicking the right mouse button or by using the `Ctrl-?` keyboard
shortcut. When clicking the mouse there are additional entries in the
context menu that will open the corresponding documentation page in the
online LAMMPS documentation. When using the hotkey, the first of those
entries will be chosen directly.
online LAMMPS documentation. When using the keyboard, the first of
those entries will be chosen directly.
Menu
----
The menu bar the entries ``File``, ``Edit``, ``Run``, ``View``, and ``About``.
Instead of using the mouse to click on them, the individual menus can also
be activated by hitting the `Alt` key together with the corresponding underlined
letter, that is `Alt-f` will activate the ``File`` menu. For the corresponding
activated sub-menus, also the underlined letter, together with the `Alt` key can
be used to select instead of the mouse.
The menu bar has entries ``File``, ``Edit``, ``Run``, ``View``, and
``About``. Instead of using the mouse to click on them, the individual
menus can also be activated by hitting the `Alt` key together with the
corresponding underlined letter, that is `Alt-F` will activate the
``File`` menu. For the corresponding activated sub-menus, the key
corresponding the underlined letters can again be used to select entries
instead of using the mouse.
File
^^^^
@ -174,104 +414,121 @@ The ``File`` menu offers the usual options:
- ``Save As`` will open a dialog to select and new file name and save
the buffer to it
- ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
will appear to either cancel the quit, save or don't save the file.
will appear to either cancel the operation, or to save or not save the
edited file.
In addition, up to 5 recent file names will be listed after the ``Open``
entry that allows to re-open recent files. This list is stored when
quitting and recovered when starting again.
In addition, up to 5 recent file names will be listed after the
``Open`` entry that allows re-opening recent files. This list is
stored when quitting and recovered when starting again.
Edit
^^^^
The ``Edit`` menu offers the usual editor functions like ``Undo``,
``Redo``, ``Cut``, ``Copy``, ``Paste``, but also offers to open the
``Preferences`` dialog and to delete all stored preferences so they
will be reset to their defaults.
``Redo``, ``Cut``, ``Copy``, ``Paste``. It can also open a
``Preferences`` dialog (keyboard shortcut `Ctrl-P`) and allows deletion
of all stored preferences so they will be reset to default values.
Run
^^^
The ``Run`` menu allows to start and stop a LAMMPS process. Rather than
calling the LAMMPS executable as a separate executable, the LAMMPS GUI
is linked to the LAMMPS library and thus can run LAMMPS internally
through the :ref:`LAMMPS C-library interface <lammps_c_api>`.
The ``Run`` menu has options to start and stop a LAMMPS process.
Rather than calling the LAMMPS executable as a separate executable,
the LAMMPS GUI is linked to the LAMMPS library and thus can run LAMMPS
internally through the :ref:`LAMMPS C-library interface
<lammps_c_api>`.
Specifically, a LAMMPS instance will be created by calling
:cpp:func:`lammps_open_no_mpi` and then the buffer contents run by
:cpp:func:`lammps_open_no_mpi`. The buffer contents then executed by
calling :cpp:func:`lammps_commands_string`. Certain commands and
features are only available, after a LAMMPS instance is created. Its
presence is indicated by a small LAMMPS ``L`` logo in the status bar at
the bottom left of the main window.
features are only available after a LAMMPS instance is created. Its
presence is indicated by a small LAMMPS ``L`` logo in the status bar
at the bottom left of the main window. As an alternative, it is also
possible to run LAMMPS using the contents of the edited file by
reading the file. This is mainly provided as a fallback option in
case the input uses some feature that is not available when running
from a string buffer.
The LAMMPS calculation will be run in a concurrent thread so that the
GUI will stay responsive and will be updated during the run. This can
be used to tell the running LAMMPS instance to stop at the next
timestep. The ``Stop LAMMPS`` entry will do this by calling
GUI can stay responsive and be updated during the run. This can be
used to tell the running LAMMPS instance to stop at the next timestep.
The ``Stop LAMMPS`` entry will do this by calling
:cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
timeout 0 <timer>` command.
The ``Set Variables`` entry will open a dialog box where :doc:`index style variables <variable>`
can be set. Those variables will be passed to the LAMMPS instance when
it is created and are thus set *before* a run is started.
The ``Set Variables...`` entry will open a dialog box where
:doc:`index style variables <variable>` can be set. Those variables
will be passed to the LAMMPS instance when it is created and are thus
set *before* a run is started.
.. image:: JPG/lammps-gui-variables.png
:align: center
:scale: 75%
The ``Set Variables`` dialog will be pre-populated with entries that are
set as index variables in the input and any variables that are used but
not defined as far as the built-in parser can detect them. New rows for
additional variables can be added through the ``Add Row`` button and
existing rows deleted by clicking on the ``X`` icons on the right.
The ``Set Variables`` dialog will be pre-populated with entries that
are set as index variables in the input and any variables that are
used but not defined, if the built-in parser can detect them. New
rows for additional variables can be added through the ``Add Row``
button and existing rows can be deleted by clicking on the ``X`` icons
on the right.
The ``View Image`` entry will send a :doc:`dump image <dump_image>`
command to the LAMMPS instance, read the resulting file, and show it in
an ``Image Viewer`` window.
The ``Create Image`` entry will send a :doc:`dump image <dump_image>`
command to the LAMMPS instance, read the resulting file, and show it
in an ``Image Viewer`` window.
The ``View in OVITO`` entry will launch `OVITO <https://ovito.org>`_
with a :doc:`data file <write_data>` of the current state of the system.
This option is only available, if the LAMMPS GUI can find the OVITO
executable in the system path.
with a :doc:`data file <write_data>` containing the current state of
the system. This option is only available if the LAMMPS GUI can find
the OVITO executable in the system path.
The ``View in VMD`` entry will instead launch VMD, also to load a
:doc:`data file <write_data>` of the current state of the system. This
option is only available, if the LAMMPS GUI can find the VMD executable
in the system path.
The ``View in VMD`` entry will launch VMD with a :doc:`data file
<write_data>` containing the current state of the system. This option
is only available if the LAMMPS GUI can find the VMD executable in the
system path.
View
^^^^
The ``View`` menu offers to show or hide the three optional windows
with log output, graphs, or images. The default settings for those
can be changed in the ``Preferences dialog``.
The ``View`` menu offers to show or hide additional windows with log
output, charts, slide show, variables, or snapshot images. The
default settings for their visibility can be changed in the
``Preferences dialog``.
About
^^^^^
The ``About`` menu finally offers a couple of dialog windows and an
option to launch the LAMMPS online documentation in a web browser. The
``About LAMMPS GUI`` entry displays a dialog with a summary of the
option to launch the LAMMPS online documentation in a web browser.
The ``About LAMMPS`` entry displays a dialog with a summary of the
configuration settings of the LAMMPS library in use and the version
number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog with
a minimal description of LAMMPS GUI. And ``LAMMPS Manual`` will open
the main page of this LAMMPS documentation at https://docs.lammps.org/.
number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog
with a minimal description of LAMMPS GUI. The ``LAMMPS GUI Howto``
entry will open this documentation page from the online documentation
in a web browser window. The ``LAMMPS Manual`` entry will open the
main page of the LAMMPS documentation in the web browser.
-----
Preferences
-----------
The ``Preferences`` dialog allows to customize some of the behavior
and looks of the LAMMPS GUI application. The settings are grouped
and each group is displayed within a tab.
The ``Preferences`` dialog allows customization of the behavior and
look of the LAMMPS GUI application. The settings are grouped and each
group is displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
:width: 25%
:width: 24%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
:width: 25%
:width: 24%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
:width: 25%
:width: 24%
|guiprefs1| |guiprefs2| |guiprefs3|
.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
:width: 24%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
General Settings:
^^^^^^^^^^^^^^^^^
@ -279,7 +536,7 @@ General Settings:
- *Echo input to log:* when checked, all input commands, including
variable expansions, will be echoed to the log window. This is
equivalent to using `-echo screen` at the command line. There is no
log *file* produced since it always uses `-log none`.
log *file* produced by default, since LAMMPS GUI uses `-log none`.
- *Include citation details:* when checked full citation info will be
included to the log window. This is equivalent to using `-cite
screen` on the command line.
@ -288,6 +545,9 @@ General Settings:
- *Show chart window by default:* when checked, the thermodynamic
output of a LAMMPS run will be collected and displayed in a chart
window as line graphs.
- *Show slide show window by default:* when checked, a slide show
window will be shown with images from a dump image command, if
present, in the LAMMPS input.
- *Replace log window on new run:* when checked, an existing log
window will be replaced on a new LAMMPS run, otherwise each run will
create a new log window.
@ -297,7 +557,7 @@ General Settings:
- *Replace image window on new render:* when checked, an existing
chart window will be replaced when a new snapshot image is requested,
otherwise each command will create a new image window.
- *Path to LAMMPS Shared Library File:* this options is only available
- *Path to LAMMPS Shared Library File:* this option is only visible
when LAMMPS GUI was compiled to load the LAMMPS library at run time
instead of being linked to it directly. With the ``Browse..`` button
or by changing the text, a different shared library file with a
@ -309,94 +569,132 @@ General Settings:
log) of the application can be set.
- *Select Text Font:* Opens a font selection dialog where the type and
size for the text editor and log font of the application can be set.
- *GUI update interval:* Allows to set the time interval between GUI
and data updates during a LAMMPS run in milliseconds. The default is
to update the GUI every 100 milliseconds. This is good for most cases.
For LAMMPS runs that run very fast, however, data may be missed and
through lowering this interval, this can be corrected. However, this
will make the GUI use more resources, which may be a problem on some
computers with slower CPUs. The default value is 100 milliseconds.
Accelerators:
^^^^^^^^^^^^^
This tab enables to select which accelerator package is used and is
equivalent to using the `-suffix` and `-package` flags on the command
line. Only settings supported by the LAMMPS library and local hardware
are available. The `Number of threads` field allows to set the maximum
number of threads for the accelerator packages that use threads.
This tab enables selection of an accelerator package for LAMMPS to use
and is equivalent to using the `-suffix` and `-package` flags on the
command line. Only settings supported by the LAMMPS library and local
hardware are available. The `Number of threads` field allows setting
the maximum number of threads for the accelerator packages that use
threads.
Snapshot Image:
^^^^^^^^^^^^^^^
This tab allows to set some defaults for the snapshot images displayed
in the ``Image Viewer`` window, like its dimensions and the zoom factor
applied. The *Antialias* switch requests to render images with twice
the number of pixels for width and height and then smoothly scales the
This tab allows setting defaults for the snapshot images displayed in
the ``Image Viewer`` window, such as its dimensions and the zoom
factor applied. The *Antialias* switch will render images with twice
the number of pixels for width and height and then smoothly scale the
image back to the requested size. This produces higher quality images
with smoother edges at the expense of requiring more CPU time to render
the image. The *HQ Image mode* option turns on using a screen space
ambient occlusion mode (SSAO) when rendering images. This is also more
time consuming, but produces a more 'spatial' representation of the
system. The *VDW Style* checkbox selects whether atoms are represented
by space filling spheres when checked or by smaller spheres and stick.
Finally there are a couple of drop down lists to select the background
and box color.
with smoother edges at the expense of requiring more CPU time to
render the image. The *HQ Image mode* option turns on screen space
ambient occlusion (SSAO) mode when rendering images. This is also
more time consuming, but produces a more 'spatial' representation of
the system shading of atoms by their depth. The *VDW Style* checkbox
selects whether atoms are represented by space filling spheres when
checked or by smaller spheres and sticks. Finally there are a couple
of drop down lists to select the background and box colors.
Editor Settings:
^^^^^^^^^^^^^^^^
Hotkeys
-------
This tab allows tweaking settings of the editor window. Specifically
the amount of padding to be added to LAMMPS commands, types or type
ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
set is the minimum width for the text element and it can be chosen in
the range between 1 and 32.
Almost all functionality is accessible from the menu or via hotkeys.
The following hotkeys are available (On macOS use the Command key
instead of Ctrl/Control).
The two settings which follow enable or disable the automatic
reformatting when hitting the 'Enter' key and the automatic display of
the completion pop-up window.
-----------
Keyboard Shortcuts
------------------
Almost all functionality is accessible from the menu of the editor
window or through keyboard shortcuts. The following shortcuts are
available (On macOS use the Command key instead of Ctrl/Control).
.. list-table::
:header-rows: 1
:widths: auto
* - Hotkey
* - Shortcut
- Function
- Hotkey
- Shortcut
- Function
- Hotkey
- Function
- Hotkey
- Shortcut
- Function
* - Ctrl+N
- New File
- Ctrl+Z
- Undo edit
- Ctrl+Enter
- Run LAMMPS
- Ctrl+Shift+A
- About LAMMPS GUI
- Run Input
* - Ctrl+O
- Open File
- Ctrl+Shift+Z
- Redo edit
- Ctrl+/
- Stop Active Run
- Ctrl+Shift+H
- Quick Help
* - CTRL+S
* - Ctrl+S
- Save File
- Ctrl+C
- Copy text
- Ctrl+Shift+V
- Set Variables
- Ctrl+Shift+G
- LAMMPS GUI Howto
* - Ctrl+Shift+S
- Save File As
- Ctrl+X
- Cut text
- Ctrl+I
- Create Snapshot Image
- Ctrl+Shift+M
- LAMMPS Manual
- Snapshot Image
* - Ctrl+Q
- Quit
- Quit Application
- Ctrl+V
- Paste text
- Ctrl+L
- Slide Show
* - Ctrl+W
- Close Window
- Ctrl+A
- Select All
- Ctrl+P
- Preferences
* - Ctrl+Shift+A
- About LAMMPS
- Ctrl+Shift+H
- Quick Help
- Ctrl+Shift+G
- LAMMPS GUI Howto
* - Ctrl+Shift+M
- LAMMPS Manual
- Ctrl+?
- Context Help
- Ctrl+Shift+W
- Show Variables
* - Ctrl+Shift+Enter
- Run File
- TAB
- Reformat line
- Shift+TAB
- Show Completions
Further editing keybindings `are documented with the Qt documentation
<https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_. In
case of conflicts the list above takes precedence.
All other windows only support a subset of keyboard shortcuts listed
above. Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
Window), and `Ctrl-Q` (Quit Application) are supported.

140
doc/src/Howto_output.rst
View File

@ -1,7 +1,7 @@
Output from LAMMPS (thermo, dumps, computes, fixes, variables)
==============================================================
There are four basic kinds of LAMMPS output:
There are four basic forms of LAMMPS output:
* :doc:`Thermodynamic output <thermo_style>`, which is a list of
quantities printed every few timesteps to the screen and logfile.
@ -20,18 +20,17 @@ output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
what quantities are calculated and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also :doc:`add their own computes and
fixes to LAMMPS <Modify>` which can then generate values that can then
be output with these commands.
fixes to LAMMPS <Modify>` which can generate values that can then be
output with these commands.
The following subsections discuss different LAMMPS commands related
to output and the kind of data they operate on and produce:
* :ref:`Global/per-atom/local/per-grid data <global>`
* :ref:`Scalar/vector/array data <scalar>`
* :ref:`Per-grid data <grid>`
* :ref:`Disambiguation <disambiguation>`
* :ref:`Thermodynamic output <thermo>`
* :ref:`Dump file output <dump>`
@ -48,34 +47,65 @@ to output and the kind of data they operate on and produce:
Global/per-atom/local/per-grid data
-----------------------------------
Various output-related commands work with four different styles of
Various output-related commands work with four different "styles" of
data: global, per-atom, local, and per-grid. A global datum is one or
more system-wide values, e.g. the temperature of the system. A
per-atom datum is one or more values per atom, e.g. the kinetic energy
of each atom. Local datums are calculated by each processor based on
the atoms it owns, but there may be zero or more per atom, e.g. a list
the atoms it owns, and there may be zero or more per atom, e.g. a list
of bond distances.
A per-grid datum is one or more values per grid cell, for a grid which
overlays the simulation domain. The grid cells and the data they
store are distributed across processors; each processor owns the grid
cells whose center point falls within its subdomain.
overlays the simulation domain. Similar to atoms and per-atom data,
the grid cells and the data they store are distributed across
processors; each processor owns the grid cells whose center points
fall within its subdomain.
.. _scalar:
Scalar/vector/array data
------------------------
Global, per-atom, and local datums can come in three kinds: a single
scalar value, a vector of values, or a 2d array of values. The doc
page for a "compute" or "fix" or "variable" that generates data will
specify both the style and kind of data it produces, e.g. a per-atom
vector.
Global, per-atom, local, and per-grid datums can come in three
"kinds": a single scalar value, a vector of values, or a 2d array of
values. More specifically these are the valid kinds for each style:
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
* global scalar
* global vector
* global array
* per-atom vector
* per-atom array
* local vector
* local array
* per-grid vector
* per-grid array
A per-atom vector means a single value per atom; the "vector" is the
length of the number of atoms. A per-atom array means multiple values
per atom. Similarly a local vector or array means one or multiple
values per entity (e.g. per bond in the system). And a per-grid
vector or array means one or multiple values per grid cell.
The doc page for a compute or fix or variable that generates data will
specify both the styles and kinds of data it produces, e.g. a per-atom
vector. Note that a compute or fix may generate multiple styles and
kinds of output. However, for per-atom data only a vector or array is
output, never both. Likewise for per-local and per-grid data. An
example of a fix which generates multiple styles and kinds of data is
the :doc:`fix mdi/qm <fix_mdi_qm>` command. It outputs a global
scalar, global vector, and per-atom array for the quantum mechanical
energy and virial of the system and forces on each atom.
By contrast, different variable styles generate only a single kind of
data: a global scalar for an equal-style variable, global vector for a
vector-style variable, and a per-atom vector for an atom-style
variable.
When data is accessed by another command, as in many of the output
commands discussed below, it can be referenced via the following
bracket notation, where ID in this case is the ID of a compute. The
leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
variable (and ID would be the name of the variable):
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -85,40 +115,56 @@ notation, where ID in this case is the ID of a compute. The leading
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Note that using one bracket reduces the dimension of the data once
(vector -> scalar, array -> vector). Using two brackets reduces the
dimension twice (array -> scalar). Thus a command that uses scalar
values as input can also conceptually operate on an element of a
vector or array.
.. _grid:
Per-grid data
------------------------
Per-grid data can come in two kinds: a vector of values (one per grid
cekk), or a 2d array of values (multiple values per grid ckk). The
doc page for a "compute" or "fix" that generates data will specify
names for both the grid(s) and datum(s) it produces, e.g. per-grid
vectors or arrays, which can be referenced by other commands. See the
:doc:`Howto grid <Howto_grid>` doc page for more details.
Per-grid vectors or arrays are accessed similarly, except that the ID
for the compute or fix includes a grid name and a data name. This is
because a fix or compute can create multiple grids (of different
sizes) and multiple sets of data (for each grid). The fix or compute
defines names for each grid and for each data set, so that all of them
can be accessed by other commands. See the :doc:`Howto grid
<Howto_grid>` doc page for more details.
.. _disambiguation:
Disambiguation
--------------
Some computes and fixes produce data in multiple styles, e.g. a global
scalar and a per-atom vector. Usually the context in which the input
script references the data determines which style is meant. Example:
if a compute provides both a global scalar and a per-atom vector, the
former will be accessed by using ``c_ID`` in an equal-style variable,
while the latter will be accessed by using ``c_ID`` in an atom-style
variable. Note that atom-style variable formulas can also access
global scalars, but in this case it is not possible to do this
directly because of the ambiguity. Instead, an equal-style variable
can be defined which accesses the global scalar, and that variable can
be used in the atom-style variable formula in place of ``c_ID``.
When a compute or fix produces data in multiple styles, e.g. global
and per-atom, a reference to the data can sometimes be ambiguous.
Usually the context in which the input script references the data
determines which style is meant.
For example, if a compute outputs a global vector and a per-atom
array, an element of the global vector will be accessed by using
``c_ID[I]`` in :doc:`thermodynamic output <thermo_style>`, while a
column of the per-atom array will be accessed by using ``c_ID[I]`` in
a :doc:`dump custom <dump>` command.
However, if a :doc:`atom-style variable <variable>` references
``c_ID[I]``, then it could be intended to refer to a single element of
the global vector or a column of the per-atom array. The doc page for
any command that has a potential ambiguity (variables are the most
common) will explain how to resolve the ambiguity.
In this case, an atom-style variables references per-atom data if it
exists. If access to an element of a global vector is needed (as in
this example), an equal-style variable which references the value can
be defined and used in the atom-style variable formula instead.
Similarly, :doc:`thermodynamic output <thermo_style>` can only
reference global data from a compute or fix. But you can indirectly
access per-atom data as follows. The reference ``c_ID[245][2]`` for
the ID of a :doc:`compute displace/atom <compute_displace_atom>`
command, refers to the y-component of displacement for the atom with
ID 245. While you cannot use that reference directly in the
:doc:`thermo_style <thermo_style>` command, you can use it an
equal-style variable formula, and then reference the variable in
thermodynamic output.
.. _thermo:
@ -389,7 +435,7 @@ output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
input, that could also be an element of a vector or array. Likewise a
vector input could be a column of an array.
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

14
doc/src/Intro_nonfeatures.rst
View File

@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
Specifically, LAMMPS was not conceived and designed for:
Originally, LAMMPS was not conceived and designed for:
* being run through a GUI
* building molecular systems, or building molecular topologies
@ -14,9 +14,10 @@ Specifically, LAMMPS was not conceived and designed for:
* visualize your MD simulation interactively
* plot your output data
Over the years some of these limitations have been reduced or
removed, through features added to LAMMPS or external tools
that either closely interface with LAMMPS or extend LAMMPS.
Over the years many of these limitations have been reduced or
removed. In part through features added to LAMMPS and in part
through external tools that either closely interface with LAMMPS
or extend LAMMPS.
Here are suggestions on how to perform these tasks:
@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
wraps the library interface is provided. Thus, GUI interfaces can be
written in Python or C/C++ that run LAMMPS and visualize or plot its
output. Examples of this are provided in the python directory and
described on the :doc:`Python <Python_head>` doc page. Also, there
are several external wrappers or GUI front ends.
described on the :doc:`Python <Python_head>` doc page. As of version
2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS.
Some of them convert input files in formats produced by other MD codes
such as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of

BIN
doc/src/JPG/lammps-gui-chart.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 73 KiB

After

Width:  |  Height:  |  Size: 105 KiB

BIN
doc/src/JPG/lammps-gui-complete.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/src/JPG/lammps-gui-log.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 185 KiB

After

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/src/JPG/lammps-gui-main.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 91 KiB

After

Width:  |  Height:  |  Size: 90 KiB

BIN
doc/src/JPG/lammps-gui-popup-help.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 119 KiB

After

Width:  |  Height:  |  Size: 130 KiB

BIN
doc/src/JPG/lammps-gui-prefs-accel.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/src/JPG/lammps-gui-prefs-editor.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/src/JPG/lammps-gui-prefs-general.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 81 KiB

BIN
doc/src/JPG/lammps-gui-prefs-image.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/src/JPG/lammps-gui-run-error.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/src/JPG/lammps-gui-run-highlight.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/src/JPG/lammps-gui-slideshow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

BIN
doc/src/JPG/lammps-gui-variable-info.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

6
doc/src/Library_objects.rst
View File

@ -9,6 +9,7 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
- :cpp:func:`lammps_variable_info`
-----------------------
@ -37,6 +38,11 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_variable_info
:project: progguide
-----------------------
.. doxygenenum:: _LMP_DATATYPE_CONST
.. doxygenenum:: _LMP_STYLE_CONST

21
doc/src/Manual.rst
View File

@ -23,10 +23,23 @@ coordinated.
----------
The content for this manual is part of the LAMMPS distribution. The
online version always corresponds to the latest feature release version.
If needed, you can build a local copy of the manual as HTML pages or a
PDF file by following the steps on the :doc:`Build_manual` page. If you
The content for this manual is part of the LAMMPS distribution in its
doc directory.
* The version of the manual on the LAMMPS website corresponds to the
latest LAMMPS feature release. It is available at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
* A version of the manual corresponding to the latest LAMMPS stable
release (state of the *stable* branch on GitHub) is available online
at: `https://docs.lammps.org/stable/
<https://docs.lammps.org/stable/>`_
* A version of the manual with the features most recently added to
LAMMPS (state of the *develop* branch on GitHub) is available at:
`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
If needed, you can build a copy on your local machine of the manual
(HTML pages or PDF file) for the version of LAMMPS you have
downloaded. Follow the steps on the :doc:`Build_manual` page. If you
have difficulties viewing the pages, please :ref:`see this note
<webbrowser>`.

41
doc/src/Tools.rst
View File

@ -645,9 +645,14 @@ LAMMPS GUI
Overview
^^^^^^^^
LAMMPS GUI is a simple graphical text editor that is linked to the
:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
directly using the contents of the editor's text buffer as input.
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS C-library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
@ -656,9 +661,9 @@ terminal window. This similarity is a design goal. While making it easy
for beginners to start with LAMMPS, it is also the intention to simplify
the transition to workflows like most experienced LAMMPS users do.
All features have been extensively exposed to hotkeys, so that there is
also appeal for experienced LAMMPS users, too, especially for
prototyping and testing simulations setups.
All features have been extensively exposed to keyboard shortcuts, so
that there is also appeal for experienced LAMMPS users for prototyping
and testing simulations setups.
Features
^^^^^^^^
@ -673,11 +678,13 @@ Here are a few highlights of LAMMPS GUI
- Text editor will remember up to 5 recent files
- Context specific LAMMPS command help via online documentation
- LAMMPS is running in a concurrent thread, so the GUI remains responsive
- Support for accelerator packages
- Progress bar indicates that LAMMPS is running
- Support for most accelerator packages
- Progress bar indicates how far a run command is completed
- LAMMPS can be started and stopped with a hotkey
- Screen output is captured in a Log Window
- Thermodynamic output is captured and displayed as line graph in a Chart Window
- Indicator for currently executed command
- Indicator for line that caused an error
- Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
- Many adjustable settings and preferences that are persistent
- Dialog to set variables from the LAMMPS command line
@ -695,19 +702,26 @@ Prerequisites and portability
LAMMPS GUI is programmed in C++ based on the C++11 standard and using
the `Qt GUI framework <https://www.qt.io/product/framework>`_.
Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
recommended; Qt 6.x not (yet) supported. Building LAMMPS with CMake is
required. The LAMMPS GUI has been successfully compiled and tested on:
recommended; support for Qt version 6.x is under active development and
thus far only tested with Qt 6.5LTS on Linux. Building LAMMPS with
CMake is required.
The LAMMPS GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
.. _lammps_gui_install:
Pre-compiled executables
^^^^^^^^^^^^^^^^^^^^^^^^
Pre-compiled LAMMPS executables including the GUI are currently
Pre-compiled LAMMPS executable packages that include the GUI are currently
available from https://download.lammps.org/static or
https://github.com/lammps/lammps/releases. You can unpack the archives
(or mount the macOS disk image) and run the GUI directly in place. The
@ -732,7 +746,10 @@ stored in a location where CMake can find them without additional help.
Otherwise, the location of the Qt library installation must be indicated
by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
a folder inside the Qt installation that contains the file
``Qt5Config.cmake``.
``Qt5Config.cmake``. Similarly, for Qt6 the location of the Qt library
installation can be indicated by setting ``-D Qt6_DIR=/path/to/qt6/lib/cmake/Qt6``,
if necessary. When both, Qt5 and Qt6 are available, Qt6 will be preferred
unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
It should be possible to build the LAMMPS GUI as a standalone
compilation (e.g. when LAMMPS has been compiled with traditional make),

5
doc/src/atom_modify.rst
View File

@ -65,6 +65,11 @@ switch. This is described on the :doc:`Build_settings <Build_settings>`
doc page. If atom IDs are not used, they must be specified as 0 for
all atoms, e.g. in a data or restart file.
.. note::
If a :doc:`triclinic simulation box <Howto_triclinic>` is used,
atom IDs are required, due to how neighbor lists are built.
The *map* keyword determines how atoms with specific IDs are found
when required. An example are the bond (angle, etc) methods which
need to find the local index of an atom with a specific global ID

114
doc/src/compute.rst
View File

@ -27,58 +27,62 @@ Examples
Description
"""""""""""
Define a computation that will be performed on a group of atoms.
Quantities calculated by a compute are instantaneous values, meaning
they are calculated from information about atoms on the current
timestep or iteration, though a compute may internally store some
information about a previous state of the system. Defining a compute
does not perform a computation. Instead computes are invoked by other
LAMMPS commands as needed (e.g., to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output).
See the :doc:`Howto output <Howto_output>` page for a summary of
various LAMMPS output options, many of which involve computes.
Define a diagnostic computation that will be performed on a group of
atoms. Quantities calculated by a compute are instantaneous values,
meaning they are calculated from information about atoms on the
current timestep or iteration, though internally a compute may store
some information about a previous state of the system. Defining a
compute does not perform the computation. Instead computes are
invoked by other LAMMPS commands as needed (e.g., to calculate a
temperature needed for a thermostat fix or to generate thermodynamic
or dump file output). See the :doc:`Howto output <Howto_output>` page
for a summary of various LAMMPS output options, many of which involve
computes.
The ID of a compute can only contain alphanumeric characters and
underscores.
----------
Computes calculate one or more of four styles of quantities: global,
per-atom, local, or per-atom. A global quantity is one or more
system-wide values, e.g. the temperature of the system. A per-atom
quantity is one or more values per atom, e.g. the kinetic energy of
each atom. Per-atom values are set to 0.0 for atoms not in the
specified compute group. Local quantities are calculated by each
processor based on the atoms it owns, but there may be zero or more
per atom, e.g. a list of bond distances. Per-grid quantities are
calculated on a regular 2d or 3d grid which overlays a 2d or 3d
simulation domain. The grid points and the data they store are
distributed across processors; each processor owns the grid points
which fall within its subdomain.
Computes calculate and store any of four *styles* of quantities:
global, per-atom, local, or per-grid.
Computes that produce per-atom quantities have the word "atom" at the
end of their style, e.g. *ke/atom*\ . Computes that produce local
quantities have the word "local" at the end of their style,
e.g. *bond/local*\ . Computes that produce per-grid quantities have
the word "grid" at the end of their style, e.g. *property/grid*\ .
Styles with neither "atom" or "local" or "grid" at the end of their
style name produce global quantities.
A global quantity is one or more system-wide values, e.g. the
temperature of the system. A per-atom quantity is one or more values
per atom, e.g. the kinetic energy of each atom. Per-atom values are
set to 0.0 for atoms not in the specified compute group. Local
quantities are calculated by each processor based on the atoms it
owns, but there may be zero or more per atom, e.g. a list of bond
distances. Per-grid quantities are calculated on a regular 2d or 3d
grid which overlays a 2d or 3d simulation domain. The grid points and
the data they store are distributed across processors; each processor
owns the grid points which fall within its subdomain.
Note that a single compute typically produces either global or
per-atom or local or per-grid values. It does not compute both global
and per-atom values. It can produce local values or per-grid values
in tandem with global or per-atom quantities. The compute doc page
will explain the details.
As a general rule of thumb, computes that produce per-atom quantities
have the word "atom" at the end of their style, e.g. *ke/atom*\ .
Computes that produce local quantities have the word "local" at the
end of their style, e.g. *bond/local*\ . Computes that produce
per-grid quantities have the word "grid" at the end of their style,
e.g. *property/grid*\ . And styles with neither "atom" or "local" or
"grid" at the end of their style name produce global quantities.
Global, per-atom, local, and per-grid quantities come in three kinds:
a single scalar value, a vector of values, or a 2d array of values.
The doc page for each compute describes the style and kind of values
it produces, e.g. a per-atom vector. Some computes produce more than
one kind of a single style, e.g. a global scalar and a global vector.
Global, per-atom, local, and per-grid quantities can also be of three
*kinds*: a single scalar value (global only), a vector of values, or a
2d array of values. For per-atom, local, and per-grid quantities, a
"vector" means a single value for each atom, each local entity
(e.g. bond), or grid cell. Likewise an "array", means multiple values
for each atom, each local entity, or each grid cell.
When a compute quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the compute:
Note that a single compute can produce any combination of global,
per-atom, local, or per-grid values. Likewise it can prouduce any
combination of scalar, vector, or array output for each style. The
exception is that for per-atom, local, and per-grid output, either a
vector or array can be produced, but not both. The doc page for each
compute explains the values it produces.
When a compute output is accessed by another input script command it
is referenced via the following bracket notation, where ID is the ID
of the compute:
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -89,17 +93,23 @@ notation, where ID is the ID of the compute:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
brackets reduces the dimension twice (array :math:`\to` scalar). Thus a
command that uses scalar compute values as input can also process elements of a
vector or array.
quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
Using two brackets reduces the dimension twice (array :math:`\to`
scalar). Thus, for example, a command that uses global scalar compute
values as input can also process elements of a vector or array.
Depending on the command, this can either be done directly using the
syntax in the table, or by first defining a :doc:`variable <variable>`
of the appropriate style to store the quantity, then using the
variable as an input to the command.
Note that commands and :doc:`variables <variable>` which use compute
quantities typically do not allow for all kinds (e.g., a command may
require a vector of values, not a scalar). This means there is no
ambiguity about referring to a compute quantity as c_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
Note that commands and :doc:`variables <variable>` which take compute
outputs as input typically do not allow for all styles and kinds of
data (e.g., a command may require global but not per-atom values, or
it may require a vector of values, not a scalar). This means there is
typically no ambiguity about referring to a compute output as c_ID
even if it produces, for example, both a scalar and vector. The doc
pages for various commands explain the details, including how any
ambiguities are resolved.
----------

158
doc/src/compute_reduce.rst
View File

@ -37,13 +37,16 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/args pairs may be appended
* keyword = *replace*
* keyword = *replace* or *inputs*
.. parsed-literal::
*replace* args = vec1 vec2
vec1 = reduced value from this input vector will be replaced
vec2 = replace it with vec1[N] where N is index of max/min value from vec2
*inputs* arg = peratom or local
peratom = all inputs are per-atom quantities (default)
local = all input are local quantities
Examples
""""""""
@ -60,38 +63,44 @@ Description
"""""""""""
Define a calculation that "reduces" one or more vector inputs into
scalar values, one per listed input. The inputs can be per-atom or
local quantities; they cannot be global quantities. Atom attributes
are per-atom quantities, :doc:`computes <compute>` and :doc:`fixes <fix>`
may generate any of the three kinds of quantities, and :doc:`atom-style variables <variable>` generate per-atom quantities. See the
:doc:`variable <variable>` command and its special functions which can
perform the same operations as the compute reduce command on global
vectors.
scalar values, one per listed input. For the compute reduce command,
the inputs can be either per-atom or local quantities and must all be
of the same kind (per-atom or local); see discussion of the optional
*inputs* keyword below. The compute reduce/region command can only be
used with per-atom inputs.
Atom attributes are per-atom quantities, :doc:`computes <compute>` and
:doc:`fixes <fix>` can generate either per-atom or local quantities,
and :doc:`atom-style variables <variable>` generate per-atom
quantities. See the :doc:`variable <variable>` command and its
special functions which can perform the same reduction operations as
the compute reduce command on global vectors.
The reduction operation is specified by the *mode* setting. The *sum*
option adds the values in the vector into a global total. The *min*
or *max* options find the minimum or maximum value across all vector
values. The *minabs* or *maxabs* options find the minimum or maximum
value across all absolute vector values. The *ave* setting adds the
vector values into a global total, then divides by the number of values
in the vector. The *sumsq* option sums the square of the values in the
vector into a global total. The *avesq* setting does the same as *sumsq*,
then divides the sum of squares by the number of values. The last two options
can be useful for calculating the variance of some quantity (e.g., variance =
sumsq :math:`-` ave\ :math:`^2`). The *sumabs* option sums the absolute
values in the vector into a global total. The *aveabs* setting does the same
as *sumabs*, then divides the sum of absolute values by the number of
vector values into a global total, then divides by the number of
values in the vector. The *sumsq* option sums the square of the
values in the vector into a global total. The *avesq* setting does
the same as *sumsq*, then divides the sum of squares by the number of
values. The last two options can be useful for calculating the
variance of some quantity (e.g., variance = sumsq :math:`-` ave\
:math:`^2`). The *sumabs* option sums the absolute values in the
vector into a global total. The *aveabs* setting does the same as
*sumabs*, then divides the sum of absolute values by the number of
values.
Each listed input is operated on independently. For per-atom inputs,
the group specified with this command means only atoms within the
group contribute to the result. For per-atom inputs, if the compute
reduce/region command is used, the atoms must also currently be within
the region. Note that an input that produces per-atom quantities may
define its own group which affects the quantities it returns. For
example, if a compute is used as an input which generates a per-atom
vector, it will generate values of 0.0 for atoms that are not in the
group specified for that compute.
group contribute to the result. Likewise for per-atom inputs, if the
compute reduce/region command is used, the atoms must also currently
be within the region. Note that an input that produces per-atom
quantities may define its own group which affects the quantities it
returns. For example, if a compute is used as an input which
generates a per-atom vector, it will generate values of 0.0 for atoms
that are not in the group specified for that compute.
Each listed input can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute <compute>` or
@ -123,52 +132,54 @@ array with six columns:
----------
The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
*fz*) are self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the
:doc:`compute property/atom <compute_property_atom>` command and then specifying
an input value from that compute.
The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*,
*fy*, and *fz*) are self-explanatory. Note that other atom attributes
can be used as inputs to this fix by using the :doc:`compute
property/atom <compute_property_atom>` command and then specifying an
input value from that compute.
If a value begins with "c\_", a compute ID must follow which has been
previously defined in the input script. Computes can generate
per-atom or local quantities. See the individual
:doc:`compute <compute>` page for details. If no bracketed integer
is appended, the vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the array calculated
by the compute is used. Users can also write code for their own
compute styles and :doc:`add them to LAMMPS <Modify>`. See the
discussion above for how :math:`I` can be specified with a wildcard asterisk
to effectively specify multiple values.
previously defined in the input script. Valid computes can generate
per-atom or local quantities. See the individual :doc:`compute
<compute>` page for details. If no bracketed integer is appended, the
vector calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the array calculated by the compute is
used. Users can also write code for their own compute styles and
:doc:`add them to LAMMPS <Modify>`. See the discussion above for how
:math:`I` can be specified with a wildcard asterisk to effectively
specify multiple values.
If a value begins with "f\_", a fix ID must follow which has been
previously defined in the input script. Fixes can generate per-atom
or local quantities. See the individual :doc:`fix <fix>` page for
details. Note that some fixes only produce their values on certain
timesteps, which must be compatible with when compute reduce
previously defined in the input script. Valid fixes can generate
per-atom or local quantities. See the individual :doc:`fix <fix>`
page for details. Note that some fixes only produce their values on
certain timesteps, which must be compatible with when compute reduce
references the values, else an error results. If no bracketed integer
is appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and
:doc:`add them to LAMMPS <Modify>`. See the discussion above for how
:math:`I` can be specified with a wildcard asterisk to effectively specify
multiple values.
:math:`I` can be specified with a wildcard asterisk to effectively
specify multiple values.
If a value begins with "v\_", a variable name must follow which has
been previously defined in the input script. It must be an
:doc:`atom-style variable <variable>`. Atom-style variables can
reference thermodynamic keywords and various per-atom attributes, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of generating per-atom quantities to reduce.
this is a very general means of generating per-atom quantities to
reduce.
----------
If the *replace* keyword is used, two indices *vec1* and *vec2* are
specified, where each index ranges from 1 to the number of input values.
The replace keyword can only be used if the *mode* is *min* or *max*\ .
It works as follows. A min/max is computed as usual on the *vec2*
input vector. The index :math:`N` of that value within *vec2* is also stored.
Then, instead of performing a min/max on the *vec1* input vector, the
stored index is used to select the :math:`N`\ th element of the *vec1* vector.
specified, where each index ranges from 1 to the number of input
values. The replace keyword can only be used if the *mode* is *min*
or *max*\ . It works as follows. A min/max is computed as usual on
the *vec2* input vector. The index :math:`N` of that value within
*vec2* is also stored. Then, instead of performing a min/max on the
*vec1* input vector, the stored index is used to select the :math:`N`\
th element of the *vec1* vector.
Thus, for example, if you wish to use this compute to find the bond
with maximum stretch, you can do it as follows:
@ -190,6 +201,16 @@ information in this context, the *replace* keywords will extract the
atom IDs for the two atoms in the bond of maximum stretch. These atom
IDs and the bond stretch will be printed with thermodynamic output.
.. versionadded:: TBD
The *inputs* keyword allows selection of whether all the inputs are
per-atom or local quantities. As noted above, all the inputs must be
the same kind (per-atom or local). Per-atom is the default setting.
If a compute or fix is specified as an input, it must produce per-atom
or local data to match this setting. If it produces both, e.g. for
the :doc:`compute voronoi/atom <compute_voronoi_atom>` command, then
this keyword selects between them.
----------
If a single input is specified this compute produces a global scalar
@ -197,38 +218,41 @@ value. If multiple inputs are specified, this compute produces a
global vector of values, the length of which is equal to the number of
inputs specified.
As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the value(s)
produced by this compute are all "extensive", meaning their value
scales linearly with the number of atoms involved. If normalized
values are desired, this compute can be accessed by the
As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the
value(s) produced by this compute are all "extensive", meaning their
value scales linearly with the number of atoms involved. If
normalized values are desired, this compute can be accessed by the
:doc:`thermo_style custom <thermo_style>` command with
:doc:`thermo_modify norm yes <thermo_modify>` set as an option.
Or it can be accessed by a
:doc:`variable <variable>` that divides by the appropriate atom count.
:doc:`thermo_modify norm yes <thermo_modify>` set as an option. Or it
can be accessed by a :doc:`variable <variable>` that divides by the
appropriate atom count.
----------
Output info
"""""""""""
This compute calculates a global scalar if a single input value is specified
or a global vector of length :math:`N`, where :math:`N` is the number of
inputs, and which can be accessed by indices 1 to :math:`N`. These values can
be used by any command that uses global scalar or vector values from a
compute as input. See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.
This compute calculates a global scalar if a single input value is
specified or a global vector of length :math:`N`, where :math:`N` is
the number of inputs, and which can be accessed by indices 1 to
:math:`N`. These values can be used by any command that uses global
scalar or vector values from a compute as input. See the :doc:`Howto
output <Howto_output>` doc page for an overview of LAMMPS output
options.
All the scalar or vector values calculated by this compute are
"intensive", except when the *sum*, *sumabs*, or *sumsq* modes are used on
per-atom or local vectors, in which case the calculated values are
"extensive".
The scalar or vector values will be in whatever :doc:`units <units>` the
quantities being reduced are in.
The scalar or vector values will be in whatever :doc:`units <units>`
the quantities being reduced are in.
Restrictions
""""""""""""
none
As noted above, the compute reduce/region command can only be used
with per-atom inputs.
Related commands
""""""""""""""""
@ -238,4 +262,4 @@ Related commands
Default
"""""""
none
The default value for the *inputs* keyword is peratom.

2
doc/src/compute_stress_atom.rst
View File

@ -223,7 +223,7 @@ result. I.e. the last 2 columns of thermo output will be the same:
system pressure.
The compute stress/atom can be used in a number of ways. Here is an
example to compute a 1-d pressure profile in z-direction across the
example to compute a 1-d pressure profile in x-direction across the
complete simulation box. You will need to adjust the number of bins and the
selections for time averaging to your specific simulation. This assumes
that the dimensions of the simulation cell does not change.

130
doc/src/compute_voronoi_atom.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* voronoi/atom = style name of this compute command
* zero or more keyword/value pairs may be appended
* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors* or *peratom*
* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors*
.. parsed-literal::
@ -31,7 +31,6 @@ Syntax
*face_threshold* arg = minarea
minarea = minimum area for a face to be counted
*neighbors* value = *yes* or *no* = store list of all neighbors or no
*peratom* value = *yes* or *no* = per-atom quantities accessible or no
Examples
""""""""
@ -53,14 +52,12 @@ atoms in the simulation box. The tessellation is calculated using all
atoms in the simulation, but non-zero values are only stored for atoms
in the group.
By default two per-atom quantities are calculated by this compute.
The first is the volume of the Voronoi cell around each atom. Any
point in an atom's Voronoi cell is closer to that atom than any other.
The second is the number of faces of the Voronoi cell. This is
equal to the number of nearest neighbors of the central atom,
plus any exterior faces (see note below). If the *peratom* keyword
is set to "no", the per-atom quantities are still calculated,
but they are not accessible.
Two per-atom quantities are calculated by this compute. The first is
the volume of the Voronoi cell around each atom. Any point in an
atom's Voronoi cell is closer to that atom than any other. The second
is the number of faces of the Voronoi cell. This is equal to the
number of nearest neighbors of the central atom, plus any exterior
faces (see note below).
----------
@ -97,13 +94,13 @@ present in atom_style sphere for granular models.
The *edge_histo* keyword activates the compilation of a histogram of
number of edges on the faces of the Voronoi cells in the compute
group. The argument *maxedge* of the this keyword is the largest number
of edges on a single Voronoi cell face expected to occur in the
sample. This keyword adds the generation of a global vector with
*maxedge*\ +1 entries. The last entry in the vector contains the number of
faces with more than *maxedge* edges. Since the polygon with the
smallest amount of edges is a triangle, entries 1 and 2 of the vector
will always be zero.
group. The argument *maxedge* of the this keyword is the largest
number of edges on a single Voronoi cell face expected to occur in the
sample. This keyword generates output of a global vector by this
compute with *maxedge*\ +1 entries. The last entry in the vector
contains the number of faces with more than *maxedge* edges. Since the
polygon with the smallest amount of edges is a triangle, entries 1 and
2 of the vector will always be zero.
The *edge_threshold* and *face_threshold* keywords allow the
suppression of edges below a given minimum length and faces below a
@ -127,8 +124,8 @@ to locate vacancies (the coordinates are given by the atom coordinates
at the time step when the compute was first invoked), while column two
data can be used to identify interstitial atoms.
If the *neighbors* value is set to yes, then this compute creates a
local array with 3 columns. There is one row for each face of each
If the *neighbors* value is set to yes, then this compute also creates
a local array with 3 columns. There is one row for each face of each
Voronoi cell. The 3 columns are the atom ID of the atom that owns the
cell, the atom ID of the atom in the neighboring cell (or zero if the
face is external), and the area of the face. The array can be
@ -143,8 +140,8 @@ containing all the Voronoi neighbors in a system:
compute 6 all voronoi/atom neighbors yes
dump d2 all local 1 dump.neighbors index c_6[1] c_6[2] c_6[3]
If the *face_threshold* keyword is used, then only faces
with areas greater than the threshold are stored.
If the *face_threshold* keyword is used, then only faces with areas
greater than the threshold are stored.
----------
@ -158,48 +155,52 @@ Voro++ software in the src/VORONOI/README file.
.. note::
The calculation of Voronoi volumes is performed by each processor for
the atoms it owns, and includes the effect of ghost atoms stored by
the processor. This assumes that the Voronoi cells of owned atoms
are not affected by atoms beyond the ghost atom cut-off distance.
This is usually a good assumption for liquid and solid systems, but
may lead to underestimation of Voronoi volumes in low density
systems. By default, the set of ghost atoms stored by each processor
is determined by the cutoff used for :doc:`pair_style <pair_style>`
interactions. The cutoff can be set explicitly via the
:doc:`comm_modify cutoff <comm_modify>` command. The Voronoi cells
for atoms adjacent to empty regions will extend into those regions up
to the communication cutoff in :math:`x`, :math:`y`, or :math:`z`.
In that situation, an exterior face is created at the cutoff distance
normal to the :math:`x`, :math:`y`, or :math:`z` direction. For
triclinic systems, the exterior face is parallel to the corresponding
reciprocal lattice vector.
The calculation of Voronoi volumes is performed by each processor
for the atoms it owns, and includes the effect of ghost atoms
stored by the processor. This assumes that the Voronoi cells of
owned atoms are not affected by atoms beyond the ghost atom cut-off
distance. This is usually a good assumption for liquid and solid
systems, but may lead to underestimation of Voronoi volumes in low
density systems. By default, the set of ghost atoms stored by each
processor is determined by the cutoff used for :doc:`pair_style
<pair_style>` interactions. The cutoff can be set explicitly via
the :doc:`comm_modify cutoff <comm_modify>` command. The Voronoi
cells for atoms adjacent to empty regions will extend into those
regions up to the communication cutoff in :math:`x`, :math:`y`, or
:math:`z`. In that situation, an exterior face is created at the
cutoff distance normal to the :math:`x`, :math:`y`, or :math:`z`
direction. For triclinic systems, the exterior face is parallel to
the corresponding reciprocal lattice vector.
.. note::
The Voro++ package performs its calculation in 3d. This will
still work for a 2d LAMMPS simulation, provided all the atoms have the
same :math:`z`-coordinate. The Voronoi cell of each atom will be a columnar
polyhedron with constant cross-sectional area along the :math:`z`-direction
and two exterior faces at the top and bottom of the simulation box. If
the atoms do not all have the same :math:`z`-coordinate, then the columnar
cells will be accordingly distorted. The cross-sectional area of each
Voronoi cell can be obtained by dividing its volume by the :math:`z` extent
of the simulation box. Note that you define the :math:`z` extent of the
simulation box for 2d simulations when using the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
The Voro++ package performs its calculation in 3d. This will still
work for a 2d LAMMPS simulation, provided all the atoms have the
same :math:`z`-coordinate. The Voronoi cell of each atom will be a
columnar polyhedron with constant cross-sectional area along the
:math:`z`-direction and two exterior faces at the top and bottom of
the simulation box. If the atoms do not all have the same
:math:`z`-coordinate, then the columnar cells will be accordingly
distorted. The cross-sectional area of each Voronoi cell can be
obtained by dividing its volume by the :math:`z` extent of the
simulation box. Note that you define the :math:`z` extent of the
simulation box for 2d simulations when using the :doc:`create_box
<create_box>` or :doc:`read_data <read_data>` commands.
Output info
"""""""""""
By default, this compute calculates a per-atom array with two
columns. In regular dynamic tessellation mode the first column is the
Voronoi volume, the second is the neighbor count, as described above
(read above for the output data in case the *occupation* keyword is
specified). These values can be accessed by any command that uses
per-atom values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options. If the *peratom* keyword is set to "no", the per-atom array
is still created, but it is not accessible.
.. deprecated:: TBD
The *peratom* keyword was removed as it is no longer required.
This compute calculates a per-atom array with two columns. In regular
dynamic tessellation mode the first column is the Voronoi volume, the
second is the neighbor count, as described above (read above for the
output data in case the *occupation* keyword is specified). These
values can be accessed by any command that uses per-atom values from a
compute as input. See the :doc:`Howto output <Howto_output>` page for
an overview of LAMMPS output options.
If the *edge_histo* keyword is used, then this compute generates a
global vector of length *maxedge*\ +1, containing a histogram of the
@ -209,17 +210,6 @@ If the *neighbors* value is set to *yes*, then this compute calculates a
local array with three columns. There is one row for each face of each
Voronoi cell.
.. note::
Some LAMMPS commands such as the :doc:`compute reduce <compute_reduce>`
command can accept either a per-atom or local quantity. If this compute
produces both quantities, the command
may access the per-atom quantity, even if you want to access the local
quantity. This effect can be eliminated by using the *peratom*
keyword to turn off the production of the per-atom quantities. For
the default value *yes* both quantities are produced. For the value
*no*, only the local array is produced.
The Voronoi cell volume will be in distance :doc:`units <units>` cubed.
The Voronoi face area will be in distance :doc:`units <units>` squared.
@ -227,7 +217,8 @@ Restrictions
""""""""""""
This compute is part of the VORONOI package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
It also requires you have a copy of the Voro++ library built and
installed on your system. See instructions on obtaining and
@ -241,5 +232,4 @@ Related commands
Default
"""""""
*neighbors* no, *peratom* yes
The default for the neighobrs keyword is no.

90
doc/src/fix.rst
View File

@ -77,35 +77,44 @@ for individual fixes for info on which ones can be restarted.
----------
Some fixes calculate one or more of four styles of quantities: global,
per-atom, local, or per-grid, which can be used by other commands or
output as described below. A global quantity is one or more
system-wide values, e.g. the energy of a wall interacting with
particles. A per-atom quantity is one or more values per atom,
e.g. the displacement vector for each atom since time 0. Per-atom
values are set to 0.0 for atoms not in the specified fix group. Local
quantities are calculated by each processor based on the atoms it
owns, but there may be zero or more per atoms. Per-grid quantities
are calculated on a regular 2d or 3d grid which overlays a 2d or 3d
simulation domain. The grid points and the data they store are
distributed across processors; each processor owns the grid points
which fall within its subdomain.
Some fixes calculate and store any of four *styles* of quantities:
global, per-atom, local, or per-grid.
Note that a single fix typically produces either global or per-atom or
local or per-grid values (or none at all). It does not produce both
global and per-atom. It can produce local or per-grid values in
tandem with global or per-atom values. The fix doc page will explain
the details.
A global quantity is one or more system-wide values, e.g. the energy
of a wall interacting with particles. A per-atom quantity is one or
more values per atom, e.g. the original coordinates of each atom at
time 0. Per-atom values are set to 0.0 for atoms not in the specified
fix group. Local quantities are calculated by each processor based on
the atoms it owns, but there may be zero or more per atom, e.g. values
for each bond. Per-grid quantities are calculated on a regular 2d or
3d grid which overlays a 2d or 3d simulation domain. The grid points
and the data they store are distributed across processors; each
processor owns the grid points which fall within its subdomain.
Global, per-atom, local, and per-grid quantities come in three kinds:
a single scalar value, a vector of values, or a 2d array of values.
The doc page for each fix describes the style and kind of values it
produces, e.g. a per-atom vector. Some fixes produce more than one
kind of a single style, e.g. a global scalar and a global vector.
As a general rule of thumb, fixes that produce per-atom quantities
have the word "atom" at the end of their style, e.g. *ave/atom*\ .
Fixes that produce local quantities have the word "local" at the end
of their style, e.g. *store/local*\ . Fixes that produce per-grid
quantities have the word "grid" at the end of their style,
e.g. *ave/grid*\ .
When a fix quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the fix:
Global, per-atom, local, and per-grid quantities can also be of three
*kinds*: a single scalar value (global only), a vector of values, or a
2d array of values. For per-atom, local, and per-grid quantities, a
"vector" means a single value for each atom, each local entity
(e.g. bond), or grid cell. Likewise an "array", means multiple values
for each atom, each local entity, or each grid cell.
Note that a single fix can produce any combination of global,
per-atom, local, or per-grid values. Likewise it can prouduce any
combination of scalar, vector, or array output for each style. The
exception is that for per-atom, local, and per-grid output, either a
vector or array can be produced, but not both. The doc page for each
fix explains the values it produces, if any.
When a fix output is accessed by another input script command it is
referenced via the following bracket notation, where ID is the ID of
the fix:
+-------------+--------------------------------------------+
| f_ID | entire scalar, vector, or array |
@ -116,19 +125,23 @@ notation, where ID is the ID of the fix:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
brackets reduces the dimension twice (array :math:`\to` scalar). Thus, a
command that uses scalar fix values as input can also process elements of a
vector or array.
quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
Using two brackets reduces the dimension twice (array :math:`\to`
scalar). Thus, for example, a command that uses global scalar fix
values as input can also process elements of a vector or array.
Depending on the command, this can either be done directly using the
syntax in the table, or by first defining a :doc:`variable <variable>`
of the appropriate style to store the quantity, then using the
variable as an input to the command.
Note that commands and :doc:`variables <variable>` that use fix
quantities typically do not allow for all kinds (e.g., a command may
require a vector of values, not a scalar), and even if they do, the context
in which they are called can be used to resolve which output is being
requested. This means there is no
ambiguity about referring to a fix quantity as f_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
Note that commands and :doc:`variables <variable>` which take fix
outputs as input typically do not allow for all styles and kinds of
data (e.g., a command may require global but not per-atom values, or
it may require a vector of values, not a scalar). This means there is
typically no ambiguity about referring to a fix output as c_ID even if
it produces, for example, both a scalar and vector. The doc pages for
various commands explain the details, including how any ambiguities
are resolved.
----------
@ -333,6 +346,7 @@ accelerated styles exist.
* :doc:`pour <fix_pour>` - pour new atoms/molecules into a granular simulation domain
* :doc:`precession/spin <fix_precession_spin>` - apply a precession torque to each magnetic spin
* :doc:`press/berendsen <fix_press_berendsen>` - pressure control by Berendsen barostat
* :doc:`press/langevin <fix_press_langevin>` - pressure control by Langevin barostat
* :doc:`print <fix_print>` - print text and variables during a simulation
* :doc:`propel/self <fix_propel_self>` - model self-propelled particles
* :doc:`property/atom <fix_property_atom>` - add customized per-atom values

42
doc/src/fix_ave_histo.rst
View File

@ -79,9 +79,10 @@ Description
Use one or more values as inputs every few timesteps to create a
single histogram. The histogram can then be averaged over longer
timescales. The resulting histogram can be used by other :doc:`output commands <Howto_output>`, and can also be written to a file. The
fix ave/histo/weight command has identical syntax to fix ave/histo,
except that exactly two values must be specified. See details below.
timescales. The resulting histogram can be used by other :doc:`output
commands <Howto_output>`, and can also be written to a file. The fix
ave/histo/weight command has identical syntax to fix ave/histo, except
that exactly two values must be specified. See details below.
The group specified with this command is ignored for global and local
input values. For per-atom input values, only atoms in the group
@ -96,14 +97,18 @@ different ways; see the discussion of the *beyond* keyword below.
Each input value can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute <compute>` or
:doc:`fix <fix>` or the evaluation of an equal-style or vector-style or
atom-style :doc:`variable <variable>`. The set of input values can be
either all global, all per-atom, or all local quantities. Inputs of
different kinds (e.g. global and per-atom) cannot be mixed. Atom
attributes are per-atom vector values. See the page for
individual "compute" and "fix" commands to see what kinds of
quantities they generate. See the optional *kind* keyword below for
how to force the fix ave/histo command to disambiguate if necessary.
:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
or atom-style :doc:`variable <variable>`. The set of input values can
be either all global, all per-atom, or all local quantities. Inputs
of different kinds (e.g. global and per-atom) cannot be mixed. Atom
attributes are per-atom vector values. See the page for individual
"compute" and "fix" commands to see what kinds of quantities they
generate.
Note that a compute or fix can produce multiple kinds of data (global,
per-atom, local). If LAMMPS cannot unambiguosly determine which kind
of data to use, the optional *kind* keyword discussed below can force
the desired disambiguation.
Note that the output of this command is a single histogram for all
input values combined together, not one histogram per input value.
@ -258,13 +263,14 @@ keyword is set to *vector*, then all input values must be global or
per-atom or local vectors, or columns of global or per-atom or local
arrays.
The *kind* keyword only needs to be set if a compute or fix produces
more than one kind of output (global, per-atom, local). If this is
not the case, then LAMMPS will determine what kind of input is
provided and whether all the input arguments are consistent. If a
compute or fix produces more than one kind of output, the *kind*
keyword should be used to specify which output will be used. The
remaining input arguments must still be consistent.
The *kind* keyword only needs to be used if any of the specfied input
computes or fixes produce more than one kind of output (global,
per-atom, local). If not, LAMMPS will determine the kind of data all
the inputs produce and verify it is all the same kind. If not, an
error will be triggered. If a compute or fix produces more than one
kind of output, the *kind* keyword should be used to specify which
output will be used. The other input arguments must still be
consistent.
The *beyond* keyword determines how input values that fall outside the
*lo* to *hi* bounds are treated. Values such that *lo* :math:`\le` value

7
doc/src/fix_efield.rst
View File

@ -1,4 +1,5 @@
.. index:: fix efield
.. index:: fix efield/kk
.. index:: fix efield/tip4p
fix efield command
@ -210,6 +211,12 @@ the iteration count during the minimization.
system (the quantity being minimized), you MUST enable the
:doc:`fix_modify <fix_modify>` *energy* option for this fix.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""

2
doc/src/fix_plumed.rst
View File

@ -24,7 +24,7 @@ Examples
.. code-block:: LAMMPS
fix pl all plumed all plumed plumedfile plumed.dat outfile p.log
fix pl all plumed plumedfile plumed.dat outfile p.log
Description
"""""""""""

301
doc/src/fix_press_langevin.rst Normal file
View File

@ -0,0 +1,301 @@
.. index:: fix press/langevin
fix press/langevin command
===========================
Syntax
""""""
.. parsed-literal::
fix ID group-ID press/langevin keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* press/langevin = style name of this fix command
.. parsed-literal::
one or more keyword value pairs may be appended
keyword = *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *xz* or *yz* or *couple* or *dilate* or *modulus* or *temp* or *flip*
*iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
*x* or *y* or *z* or *xy* or *xz* or *yz* values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = pressure damping parameter
*flip* value = *yes* or *no* = allow or disallow box flips when it becomes highly skewed
*couple* = *none* or *xyz* or *xy* or *yz* or *xz*
*friction* value = Friction coefficient for the barostat (time units)
*temp* values = Tstart, Tstop, seed
Tstart, Tstop = target temperature used for the barostat at start/end of run
seed = seed of the random number generator
*dilate* value = *all* or *partial*
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all press/langevin iso 0.0 0.0 1000.0 temp 300 300 487374
fix 2 all press/langevin aniso 0.0 0.0 1000.0 temp 100 300 238 dilate partial
Description
"""""""""""
Adjust the pressure of the system by using a Langevin stochastic barostat
:ref:`(Gronbech) <Gronbech>`, which rescales the system volume and
(optionally) the atoms coordinates within the simulation box every
timestep.
The Langevin barostat couple each direction *L* with a pseudo-particle that obeys
the Langevin equation such as:
.. math::
f_P = & \frac{N k_B T_{target}}{V} + \frac{1}{V d}\sum_{i=1}^{N} \vec r_i \cdot \vec f_i - P_{target} \\
Q\ddot{L} + \alpha{}\dot{L} = & f_P + \beta(t)\\
L^{n+1} = & L^{n} + bdt\dot{L}^{n} \frac{bdt^{2}}{2Q} \\
\dot{L}^{n+1} = & \alpha\dot{L}^{n} + \frac{dt}{2Q}\left(a f^{n}_{P} + f^{n+1}_{P}\right) + \frac{b}{Q}\beta^{n+1} \\
a = & \frac{1-\frac{\alpha{}dt}{2Q}}{1+\frac{\alpha{}dt}{2Q}} \\
b = & \frac{1}{1+\frac{\alpha{}dt}{2Q}} \\
\left< \beta(t)\beta(t') \right> = & 2\alpha k_B Tdt
Where :math:`dt` is the timestep :math:`\dot{L}` and :math:`\ddot{L}` the first
and second derivatives of the coupled direction with regard to time,
:math:`\alpha` is a friction coefficient, :math:`\beta` is a random gaussian
variable and :math:`Q` the effective mass of the coupled pseudoparticle. The
two first terms on the right-hand side of the first equation are the virial
expression of the canonical pressure. It is to be noted that the temperature
used to compute the pressure is not based on the atom velocities but rather on
the canonical
target temperature directly. This temperature is specified using the *temp*
keyword parameter and should be close to the expected target temperature of the
system.
Regardless of what atoms are in the fix group, a global pressure is
computed for all atoms. Similarly, when the size of the simulation
box is changed, all atoms are re-scaled to new positions, unless the
keyword *dilate* is specified with a value of *partial*, in which case
only the atoms in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of atoms in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
.. note::
Unlike the :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` commands which
perform Nose-Hoover barostatting AND time integration, this fix does NOT
perform time integration of the atoms but only of the barostat coupled
coordinate. It then only modifies the box size and atom coordinates to
effect barostatting. Thus you must use a separate time integration fix,
like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>` to actually update
the positions and velocities of atoms. This fix can be used in conjunction
with thermostatting fixes to control the temperature, such as :doc:`fix nvt
<fix_nh>` or :doc:`fix langevin <fix_langevin>` or :doc:`fix temp/berendsen
<fix_temp_berendsen>`.
See the :doc:`Howto barostat <Howto_barostat>` page for a
discussion of different ways to perform barostatting.
----------
The barostat is specified using one or more of the *iso*, *aniso*, *tri* *x*,
*y*, *z*, *xy*, *xz*, *yz*, and *couple* keywords. These keywords give you the
ability to specify the 3 diagonal components of an external stress tensor, and
to couple various of these components together so that the dimensions they
represent are varied together during a constant-pressure simulation.
The target pressures for each of the 6 diagonal components of the stress tensor
can be specified independently via the *x*, *y*, *z*, keywords, which
correspond to the 3 simulation box dimensions, and the *xy*, *xz* and *yz*
keywords which corresponds to the 3 simulation box tilt factors. For each
component, the external pressure or tensor component at each timestep is a
ramped value during the run from *Pstart* to *Pstop*\ . If a target pressure is
specified for a component, then the corresponding box dimension will change
during a simulation. For example, if the *y* keyword is used, the y-box length
will change. A box dimension will not change if that component is not
specified, although you have the option to change that dimension via the
:doc:`fix deform <fix_deform>` command.
The *Pdamp* parameter can be seen in the same way as a Nose-Hoover parameter as
it is used to compute the mass of the fictitious particle. Without friction,
the barostat can be compared to a single particle Nose-Hoover barostat and
should follow a similar decay in time. The mass of the barostat is
linked to *Pdamp* by the relation
:math:`Q=(N_{at}+1)\cdot{}k_BT_{target}\cdot{}P_{damp}^2`. Note that *Pdamp*
should be expressed in time units.
.. note::
As for Berendsen barostat, a Langevin barostat will not work well for
arbitrary values of *Pdamp*\ . If *Pdamp* is too small, the pressure and
volume can fluctuate wildly; if it is too large, the pressure will take a
very long time to equilibrate. A good choice for many models is a *Pdamp*
of around 1000 timesteps. However, note that *Pdamp* is specified in time
units, and that timesteps are NOT the same as time units for most
:doc:`units <units>` settings.
----------
The *temp* keyword sets the temperature to use in the equation of motion of the
barostat. This value is used to compute the value of the force :math:`f_P` in
the equation of motion. It is important to note that this value is not the
instantaneous temperature but a target temperature that ramps from *Tstart* to
*Tstop*. Also the required argument *seed* sets the seed for the random
number generator used in the generation of the random forces.
----------
The *couple* keyword allows two or three of the diagonal components of
the pressure tensor to be "coupled" together. The value specified
with the keyword determines which are coupled. For example, *xz*
means the *Pxx* and *Pzz* components of the stress tensor are coupled.
*Xyz* means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
*Pstart*, *Pstop*, *Pdamp* parameters for any coupled dimensions must
be identical. *Couple xyz* can be used for a 2d simulation; the *z*
dimension is simply ignored.
----------
The *iso*, *aniso* and *tri* keywords are simply shortcuts that are
equivalent to specifying several other keywords together.
The keyword *iso* means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
specifying these 4 keywords:
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple xyz
The keyword *aniso* means *x*, *y*, and *z* dimensions are controlled
independently using the *Pxx*, *Pyy*, and *Pzz* components of the
stress tensor as the driving forces, and the specified scalar external
pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
these 4 keywords:
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple none
The keyword *tri* is the same as *aniso* but also adds the control on the
shear pressure coupled with the tilt factors.
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
xy Pstart Pstop Pdamp
xz Pstart Pstop Pdamp
yz Pstart Pstop Pdamp
couple none
----------
The *flip* keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
below. If the *flip* value is set to *yes*, the bound is enforced by
flipping the box when it is exceeded. If the *flip* value is set to
*no*, the tilt will continue to change without flipping. Note that if
applied stress induces large deformations (e.g. in a liquid), this
means the box shape can tilt dramatically and LAMMPS will run less
efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped subdomain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
----------
The *friction* keyword sets the friction parameter :math:`\alpha` in the
equations of motion of the barostat. For each barostat direction, the value of
:math:`\alpha` depends on both *Pdamp* and *friction*. The value given as a
parameter is the Langevin characteristic time
:math:`\tau_{L}=\frac{Q}{\alpha}` in time units. The langevin time can be understood as a
decorrelation time for the pressure. A long Langevin time value will make the
barostat act as an underdamped oscillator while a short value will make it
act as an overdamped oscillator. The ideal configuration would be to find
the critical parameter of the barostat. Empirically this is observed to
occur for :math:`\tau_{L}\approx{}P_{damp}`. For this reason, if the *friction*
keyword is not used, the default value *Pdamp* is used for each barostat direction.
----------
This fix computes pressure each timestep. To do
this, the fix creates its own computes of style "pressure",
as if this command had been issued:
.. code-block:: LAMMPS
compute fix-ID_press group-ID pressure NULL virial
The kinetic contribution to the pressure is taken as the ensemble value
:math:`\frac{Nk_bT}{V}` and computed by the fix itself.
See the :doc:`compute pressure <compute_pressure>` command for details. Note
that the IDs of the new compute is the fix-ID + underscore + "press" and the
group for the new computes is the same as the fix group.
Note that this is NOT the compute used by thermodynamic output (see the
:doc:`thermo_style <thermo_style>` command) with ID = *thermo_press*. This
means you can change the attributes of this fix's pressure via the
:doc:`compute_modify <compute_modify>` command or print this temperature or
pressure during thermodynamic output via the :doc:`thermo_style custom
<thermo_style>` command using the appropriate compute-ID. It also means that
changing attributes of *thermo_temp* or *thermo_press* will have no effect on
this fix.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`.
The :doc:`fix_modify <fix_modify>` *press* option is
supported by this fix. You can use it to assign a
:doc:`compute <compute>` you have defined to this fix which will be used
in its pressure calculations.
No global or per-atom quantities are stored by this fix for access by
various :doc:`output commands <Howto_output>`.
This fix can ramp its target pressure and temperature over multiple runs, using
the *start* and *stop* keywords of the :doc:`run <run>` command. See the
:doc:`run <run>` command for details of how to do this. It is recommended that
the ramped temperature is the same as the effective temperature of the
thermostatted system. That is, if the system's temperature is ramped by other
commands, it is recommended to do the same with this pressure control.
This fix is not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
Any dimension being adjusted by this fix must be periodic.
Related commands
""""""""""""""""
:doc:`fix press/berendsen <fix_press_berendsen>`,
:doc:`fix nve <fix_nve>`, :doc:`fix nph <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix langevin <fix_langevin>`,
:doc:`fix_modify <fix_modify>`
Default
"""""""
The keyword defaults are *dilate* = all, *flip* = yes, and *friction* = *Pdamp*.
----------
.. _Gronbech:
**(Gronbech)** Gronbech-Jensen, Farago, J Chem Phys, 141, 194108 (2014).

5
doc/src/fix_rigid.rst
View File

@ -843,7 +843,7 @@ stress/atom <compute_stress_atom>` commands. The former can be
accessed by :doc:`thermodynamic output <thermo_style>`. The default
setting for this fix is :doc:`fix_modify virial yes <fix_modify>`.
All of the *rigid* styles (not the *rigid/small* styles) compute a
All of the *rigid* styles (but not the *rigid/small* styles) compute a
global array of values which can be accessed by various :doc:`output
commands <Howto_output>`. Similar information about the bodies
defined by the *rigid/small* styles can be accessed via the
@ -887,7 +887,8 @@ Restrictions
""""""""""""
These fixes are all part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Assigning a temperature via the :doc:`velocity create <velocity>`
command to a system with :doc:`rigid bodies <fix_rigid>` may not have

7
doc/src/fix_spring_self.rst
View File

@ -1,4 +1,5 @@
.. index:: fix spring/self
.. index:: fix spring/self/kk
fix spring/self command
=======================
@ -80,6 +81,12 @@ invoked by the :doc:`minimize <minimize>` command.
you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
this fix.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""
none

49
doc/src/fix_srd.rst
View File

@ -71,14 +71,15 @@ imbue the SRD particles with fluid-like properties, including an
effective viscosity. Thus simulations with large solute particles can
be run more quickly, to measure solute properties like diffusivity
and viscosity in a background fluid. The usual LAMMPS fixes for such
simulations, such as :doc:`fix deform <fix_deform>`, :doc:`fix viscosity <fix_viscosity>`, and :doc:`fix nvt/sllod <fix_nvt_sllod>`,
simulations, such as :doc:`fix deform <fix_deform>`,
:doc:`fix viscosity <fix_viscosity>`, and :doc:`fix nvt/sllod <fix_nvt_sllod>`,
can be used in conjunction with the SRD model.
For more details on how the SRD model is implemented in LAMMPS, :ref:`this paper <Petersen1>` describes the implementation and usage of pure SRD
fluids. :ref:`This paper <Lechman>`, which is nearly complete, describes
the implementation and usage of mixture systems (solute particles in
an SRD fluid). See the examples/srd directory for sample input
scripts using SRD particles in both settings.
For more details on how the SRD model is implemented in LAMMPS,
:ref:`(Petersen) <Petersen1>` describes the implementation and usage of
pure SRD fluids. See the ``examples/srd`` directory for sample input
scripts using SRD particles for that and for mixture systems (solute
particles in an SRD fluid).
This fix does two things:
@ -357,28 +358,28 @@ These are the 12 quantities. All are values for the current timestep,
except for quantity 5 and the last three, each of which are
cumulative quantities since the beginning of the run.
* (1) # of SRD/big collision checks performed
* (2) # of SRDs which had a collision
* (3) # of SRD/big collisions (including multiple bounces)
* (4) # of SRD particles inside a big particle
* (5) # of SRD particles whose velocity was rescaled to be < Vmax
* (6) # of bins for collision searching
* (7) # of bins for SRD velocity rotation
* (8) # of bins in which SRD temperature was computed
* (9) SRD temperature
* (10) # of SRD particles which have undergone max # of bounces
* (11) max # of bounces any SRD particle has had in a single step
* (12) # of reneighborings due to SRD particles moving too far
(1) # of SRD/big collision checks performed
(2) # of SRDs which had a collision
(3) # of SRD/big collisions (including multiple bounces)
(4) # of SRD particles inside a big particle
(5) # of SRD particles whose velocity was rescaled to be < Vmax
(6) # of bins for collision searching
(7) # of bins for SRD velocity rotation
(8) # of bins in which SRD temperature was computed
(9) SRD temperature
(10) # of SRD particles which have undergone max # of bounces
(11) max # of bounces any SRD particle has had in a single step
(12) # of reneighborings due to SRD particles moving too far
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This command can only be used if LAMMPS was built with the SRD
package. See the :doc:`Build package <Build_package>` doc
page for more info.
This command can only be used if LAMMPS was built with the SRD package.
See the :doc:`Build package <Build_package>` doc page for more info.
Related commands
""""""""""""""""
@ -403,7 +404,3 @@ no, and rescale = yes.
**(Petersen)** Petersen, Lechman, Plimpton, Grest, in' t Veld, Schunk, J
Chem Phys, 132, 174106 (2010).
.. _Lechman:
**(Lechman)** Lechman, et al, in preparation (2010).

12
doc/src/pair_ilp_tmd.rst
View File

@ -22,12 +22,12 @@ Examples
.. code-block:: LAMMPS
pair_style hybrid/overlay ilp/tmd 16.0 1
pair_coeff * * ilp/tmd TMD.ILP Mo S S
pair_coeff * * ilp/tmd MoS2.ILP Mo S S
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
pair_coeff * * ilp/tmd TMD.ILP Mo S S Mo S S
pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
Description
"""""""""""
@ -69,7 +69,7 @@ calculating the normals.
each atom `i`, its six nearest neighboring atoms belonging to the same
sub-layer are chosen to define the normal vector `{\bf n}_i`.
The parameter file (e.g. TMD.ILP), is intended for use with *metal*
The parameter file (e.g. MoS2.ILP), is intended for use with *metal*
:doc:`units <units>`, with energies in meV. Two additional parameters,
*S*, and *rcut* are included in the parameter file. *S* is designed to
facilitate scaling of energies. *rcut* is designed to build the neighbor
@ -77,7 +77,7 @@ list for calculating the normals for each atom pair.
.. note::
The parameters presented in the parameter file (e.g. TMD.ILP),
The parameters presented in the parameter file (e.g. MoS2.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
These parameters provide a good description in both short- and long-range
@ -133,10 +133,10 @@ if LAMMPS was built with that package. See the :doc:`Build package
This pair style requires the newton setting to be *on* for pair
interactions.
The TMD.ILP potential file provided with LAMMPS (see the potentials
The MoS2.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for *metal* units. You can use this
potential with any LAMMPS units, but you would need to create your own
custom TMD.ILP potential file with coefficients listed in the appropriate
custom MoS2.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use *metal* units.
Related commands

16
doc/src/pair_reaxff.rst
View File

@ -43,18 +43,18 @@ Examples
Description
"""""""""""
Style *reaxff* computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
Pair style *reaxff* computes the ReaxFF potential of van Duin, Goddard
and co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper:
:ref:`(Chenoweth et al., 2008) <Chenoweth_20082>`. The version integrated
into LAMMPS matches the version of ReaxFF From Summer 2010. For more
technical details about the pair reaxff implementation of ReaxFF, see
the :ref:`(Aktulga) <Aktulga>` paper. The *reaxff* style was initially
implemented as a stand-alone C code and is now converted to C++ and
integrated into LAMMPS as a package.
:ref:`(Chenoweth et al., 2008) <Chenoweth_20082>` and matches the
version of the reference ReaxFF implementation from Summer 2010. For
more technical details about the implementation of ReaxFF in pair style
*reaxff*, see the :ref:`(Aktulga) <Aktulga>` paper. The *reaxff* style
was initially implemented as a stand-alone C code and is now converted
to C++ and integrated into LAMMPS as a package.
The *reaxff/kk* style is a Kokkos version of the ReaxFF potential that
is derived from the *reaxff* style. The Kokkos version can run on GPUs

11
doc/src/pair_snap.rst
View File

@ -1,10 +1,11 @@
.. index:: pair_style snap
.. index:: pair_style snap/intel
.. index:: pair_style snap/kk
pair_style snap command
=======================
Accelerator Variants: *snap/kk*
Accelerator Variants: *snap/intel*, *snap/kk*
Syntax
""""""
@ -260,6 +261,14 @@ This style is part of the ML-SNAP package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
The *snap/intel* accelerator variant will *only* be available if LAMMPS
is built with Intel *compilers* and for CPUs with AVX-512 support.
While the INTEL package in general allows multiple floating point
precision modes to be selected, *snap/intel* will currently always use
full double precision regardless of the precision mode selected.
Additionally, the *intel* variant of snap will **NOT** use multiple
threads with OpenMP.
Related commands
""""""""""""""""

9
doc/src/pair_yukawa_colloid.rst
View File

@ -1,11 +1,12 @@
.. index:: pair_style yukawa/colloid
.. index:: pair_style yukawa/colloid/gpu
.. index:: pair_style yukawa/colloid/kk
.. index:: pair_style yukawa/colloid/omp
pair_style yukawa/colloid command
=================================
Accelerator Variants: *yukawa/colloid/gpu*, *yukawa/colloid/omp*
Accelerator Variants: *yukawa/colloid/gpu*, *yukawa/colloid/kk*, *yukawa/colloid/omp*
Syntax
""""""
@ -131,6 +132,12 @@ per-type polydispersity is allowed. This means all particles of the
same type must have the same diameter. Each type can have a different
diameter.
----------
.. include:: accel_styles.rst
----------
Related commands
""""""""""""""""

53
doc/src/thermo_style.rst
View File

@ -385,19 +385,20 @@ creates a global vector with 6 values.
The *c_ID* and *c_ID[I]* and *c_ID[I][J]* keywords allow global values
calculated by a compute to be output. As discussed on the
:doc:`compute <compute>` doc page, computes can calculate global,
per-atom, or local values. Only global values can be referenced by
this command. However, per-atom compute values for an individual atom
can be referenced in a :doc:`variable <variable>` and the variable
referenced by thermo_style custom, as discussed below. See the
discussion above for how the I in *c_ID[I]* can be specified with a
wildcard asterisk to effectively specify multiple values from a global
compute vector.
per-atom, local, and per-grid values. Only global values can be
referenced by this command. However, per-atom compute values for an
individual atom can be referenced in a :doc:`equal-style variable
<variable>` and the variable referenced by thermo_style custom, as
discussed below. See the discussion above for how the I in *c_ID[I]*
can be specified with a wildcard asterisk to effectively specify
multiple values from a global compute vector.
The ID in the keyword should be replaced by the actual ID of a compute
that has been defined elsewhere in the input script. See the
:doc:`compute <compute>` command for details. If the compute calculates
a global scalar, vector, or array, then the keyword formats with 0, 1,
or 2 brackets will reference a scalar value from the compute.
:doc:`compute <compute>` command for details. If the compute
calculates a global scalar, vector, or array, then the keyword formats
with 0, 1, or 2 brackets will reference a scalar value from the
compute.
Note that some computes calculate "intensive" global quantities like
temperature; others calculate "extensive" global quantities like
@ -410,13 +411,14 @@ norm <thermo_modify>` option being used.
The *f_ID* and *f_ID[I]* and *f_ID[I][J]* keywords allow global values
calculated by a fix to be output. As discussed on the :doc:`fix
<fix>` doc page, fixes can calculate global, per-atom, or local
values. Only global values can be referenced by this command.
However, per-atom fix values can be referenced for an individual atom
in a :doc:`variable <variable>` and the variable referenced by
thermo_style custom, as discussed below. See the discussion above for
how the I in *f_ID[I]* can be specified with a wildcard asterisk to
effectively specify multiple values from a global fix vector.
<fix>` doc page, fixes can calculate global, per-atom, local, and
per-grid values. Only global values can be referenced by this
command. However, per-atom fix values can be referenced for an
individual atom in a :doc:`equal-style variable <variable>` and the
variable referenced by thermo_style custom, as discussed below. See
the discussion above for how the I in *f_ID[I]* can be specified with
a wildcard asterisk to effectively specify multiple values from a
global fix vector.
The ID in the keyword should be replaced by the actual ID of a fix
that has been defined elsewhere in the input script. See the
@ -438,14 +440,15 @@ output. The name in the keyword should be replaced by the variable
name that has been defined elsewhere in the input script. Only
equal-style and vector-style variables can be referenced; the latter
requires a bracketed term to specify the Ith element of the vector
calculated by the variable. However, an atom-style variable can be
referenced for an individual atom by an equal-style variable and that
variable referenced. See the :doc:`variable <variable>` command for
details. Variables of style *equal* and *vector* and *atom* define a
formula which can reference per-atom properties or thermodynamic
keywords, or they can invoke other computes, fixes, or variables when
evaluated, so this is a very general means of creating thermodynamic
output.
calculated by the variable. However, an equal-style variable can use
an atom-style variable in its formula indexed by the ID of an
individual atom. This is a way to output a speciic atom's per-atom
coordinates or other per-atom properties in thermo output. See the
:doc:`variable <variable>` command for details. Note that variables
of style *equal* and *vector* and *atom* define a formula which can
reference per-atom properties or thermodynamic keywords, or they can
invoke other computes, fixes, or variables when evaluated, so this is
a very general means of creating thermodynamic output.
Note that equal-style and vector-style variables are assumed to
produce "intensive" global quantities, which are thus printed as-is,

251
doc/src/variable.rst
View File

@ -550,12 +550,11 @@ variables.
Most of the formula elements produce a scalar value. Some produce a
global or per-atom vector of values. Global vectors can be produced
by computes or fixes or by other vector-style variables. Per-atom
vectors are produced by atom vectors, compute references that
represent a per-atom vector, fix references that represent a per-atom
vector, and variables that are atom-style variables. Math functions
that operate on scalar values produce a scalar value; math function
that operate on global or per-atom vectors do so element-by-element
and produce a global or per-atom vector.
vectors are produced by atom vectors, computes or fixes which output a
per-atom vector or array, and variables that are atom-style variables.
Math functions that operate on scalar values produce a scalar value;
math function that operate on global or per-atom vectors do so
element-by-element and produce a global or per-atom vector.
A formula for equal-style variables cannot use any formula element
that produces a global or per-atom vector. A formula for a
@ -564,12 +563,13 @@ scalar value or a global vector value, but cannot use a formula
element that produces a per-atom vector. A formula for an atom-style
variable can use formula elements that produce either a scalar value
or a per-atom vector, but not one that produces a global vector.
Atom-style variables are evaluated by other commands that define a
:doc:`group <group>` on which they operate, e.g. a :doc:`dump <dump>` or
:doc:`compute <compute>` or :doc:`fix <fix>` command. When they invoke
the atom-style variable, only atoms in the group are included in the
formula evaluation. The variable evaluates to 0.0 for atoms not in
the group.
:doc:`group <group>` on which they operate, e.g. a :doc:`dump <dump>`
or :doc:`compute <compute>` or :doc:`fix <fix>` command. When they
invoke the atom-style variable, only atoms in the group are included
in the formula evaluation. The variable evaluates to 0.0 for atoms
not in the group.
----------
@ -1138,69 +1138,74 @@ only defined if an :doc:`atom_style <atom_style>` is being used that
defines molecule IDs.
Note that many other atom attributes can be used as inputs to a
variable by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
a quantity from that compute.
variable by using the :doc:`compute property/atom
<compute_property_atom>` command and then specifying a quantity from
that compute.
----------
Compute References
------------------
Compute references access quantities calculated by a
:doc:`compute <compute>`. The ID in the reference should be replaced by
the ID of a compute defined elsewhere in the input script. As
discussed in the page for the :doc:`compute <compute>` command,
computes can produce global, per-atom, or local values. Only global
and per-atom values can be used in a variable. Computes can also
produce a scalar, vector, or array.
Compute references access quantities calculated by a :doc:`compute
<compute>`. The ID in the reference should be replaced by the ID of a
compute defined elsewhere in the input script.
An equal-style variable can only use scalar values, which means a
global scalar, or an element of a global or per-atom vector or array.
A vector-style variable can use scalar values or a global vector of
values, or a column of a global array of values. Atom-style variables
can use global scalar values. They can also use per-atom vector
values, or a column of a per-atom array. See the doc pages for
individual computes to see what kind of values they produce.
As discussed on the page for the :doc:`compute <compute>` command,
computes can produce global, per-atom, local, and per-grid values.
Only global and per-atom values can be used in a variable. Computes
can also produce scalars (global only), vectors, and arrays. See the
doc pages for individual computes to see what different kinds of data
they produce.
Examples of different kinds of compute references are as follows.
There is typically no ambiguity (see exception below) as to what a
reference means, since computes only produce either global or per-atom
quantities, never both.
An equal-style variable can only use scalar values, either from global
or per-atom data. In the case of per-atom data, this would be a value
for a specific atom.
+-------------+-------------------------------------------------------------------------------------------------------+
| c_ID | global scalar, or per-atom vector |
+-------------+-------------------------------------------------------------------------------------------------------+
| c_ID[I] | Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array |
+-------------+-------------------------------------------------------------------------------------------------------+
| c_ID[I][J] | I,J element of global array, or atom I's Jth value in per-atom array |
+-------------+-------------------------------------------------------------------------------------------------------+
A vector-style variable can use scalar values (same as for equal-style
variables), or global vectors of values. The latter can also be a
column of a global array.
For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
Atom-style variables can use scalar values (same as for equal-style
varaibles), or per-atom vectors of values. The latter can also be a
column of a per-atom array.
One source of ambiguity for compute references is when a vector-style
variable refers to a compute that produces both a global scalar and a
global vector. Consider a compute with ID "foo" that does this,
referenced as follows by variable "a", where "myVec" is another
vector-style variable:
The various allowed compute references in the variable formulas for
equal-, vector-, and atom-style variables are listed in the following
table:
.. code-block:: LAMMPS
+--------+------------+------------------------------------------+
| equal | c_ID | global scalar |
| equal | c_ID[I] | element of global vector |
| equal | c_ID[I][J] | element of global array |
| equal | C_ID[I] | element of per-atom vector (I = atom ID) |
| equal | C_ID[I][J] | element of per-atom array (I = atom ID) |
+--------+------------+------------------------------------------+
| vector | c_ID | global vector |
| vector | c_ID[I] | column of global array |
---------+------------+------------------------------------------+
| atom | c_ID | per-atom vector |
| atom | c_ID[I] | column of per-atom array |
+--------+------------+------------------------------------------+
variable a vector c_foo*v_myVec
Note that if an equal-style variable formula wishes to access per-atom
data from a compute, it must use capital "C" as the ID prefix and not
lower-case "c".
The reference "c_foo" could refer to either the global scalar or
global vector produced by compute "foo". In this case, "c_foo" will
always refer to the global scalar, and "C_foo" can be used to
reference the global vector. Similarly if the compute produces both a
global vector and global array, then "c_foo[I]" will always refer to
an element of the global vector, and "C_foo[I]" can be used to
reference the Ith column of the global array.
Also note that if a vector- or atom-style variable formula needs to
access a scalar value from a compute (i.e. the 5 kinds of values in
the first 5 lines of the table), it can not do so directly. Instead,
it can use a reference to an equal-style variable which stores the
scalar value from the compute.
Note that if a variable containing a compute is evaluated directly in
an input script (not during a run), then the values accessed by the
compute must be current. See the discussion below about "Variable
The I and J indices in these compute references can be integers or can
be a variable name, specified as v_name, where name is the name of the
variable. The rules for this syntax are the same as for indices in
the "Atom Values and Vectors" discussion above.
If a variable containing a compute is evaluated directly in an input
script (not during a run), then the values accessed by the compute
should be current. See the discussion below about "Variable
Accuracy".
----------
@ -1208,51 +1213,59 @@ Accuracy".
Fix References
--------------
Fix references access quantities calculated by a :doc:`fix <compute>`.
Fix references access quantities calculated by a :doc:`fix <fix>`.
The ID in the reference should be replaced by the ID of a fix defined
elsewhere in the input script. As discussed in the page for the
:doc:`fix <fix>` command, fixes can produce global, per-atom, or local
values. Only global and per-atom values can be used in a variable.
Fixes can also produce a scalar, vector, or array. An equal-style
variable can only use scalar values, which means a global scalar, or
an element of a global or per-atom vector or array. Atom-style
variables can use the same scalar values. They can also use per-atom
vector values. A vector value can be a per-atom vector itself, or a
column of an per-atom array. See the doc pages for individual fixes
to see what kind of values they produce.
elsewhere in the input script.
The different kinds of fix references are exactly the same as the
compute references listed in the above table, where "c\_" is replaced
by "f\_". Again, there is typically no ambiguity (see exception below)
as to what a reference means, since fixes only produce either global
or per-atom quantities, never both.
As discussed on the page for the :doc:`fix <fix>` command, fixes can
produce global, per-atom, local, and per-grid values. Only global and
per-atom values can be used in a variable. Fixes can also produce
scalars (global only), vectors, and arrays. See the doc pages for
individual fixes to see what different kinds of data they produce.
+-------------+-------------------------------------------------------------------------------------------------------+
| f_ID | global scalar, or per-atom vector |
+-------------+-------------------------------------------------------------------------------------------------------+
| f_ID[I] | Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array |
+-------------+-------------------------------------------------------------------------------------------------------+
| f_ID[I][J] | I,J element of global array, or atom I's Jth value in per-atom array |
+-------------+-------------------------------------------------------------------------------------------------------+
An equal-style variable can only use scalar values, either from global
or per-atom data. In the case of per-atom data, this would be a value
for a specific atom.
For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
A vector-style variable can use scalar values (same as for equal-style
variables), or global vectors of values. The latter can also be a
column of a global array.
One source of ambiguity for fix references is the same ambiguity
discussed for compute references above. Namely when a vector-style
variable refers to a fix that produces both a global scalar and a
global vector. The solution is the same as for compute references.
For a fix with ID "foo", "f_foo" will always refer to the global
scalar, and "F_foo" can be used to reference the global vector. And
similarly for distinguishing between a fix's global vector versus
global array with "f_foo[I]" versus "F_foo[I]".
Atom-style variables can use scalar values (same as for equal-style
varaibles), or per-atom vectors of values. The latter can also be a
column of a per-atom array.
Note that if a variable containing a fix is evaluated directly in an
input script (not during a run), then the values accessed by the fix
should be current. See the discussion below about "Variable
Accuracy".
The allowed fix references in variable formulas for equal-, vector-,
and atom-style variables are listed in the following table:
+--------+------------+------------------------------------------+
| equal | f_ID | global scalar |
| equal | f_ID[I] | element of global vector |
| equal | f_ID[I][J] | element of global array |
| equal | F_ID[I] | element of per-atom vector (I = atom ID) |
| equal | F_ID[I][J] | element of per-atom array (I = atom ID) |
+--------+------------+------------------------------------------+
| vector | f_ID | global vector |
| vector | f_ID[I] | column of global array |
---------+------------+------------------------------------------+
| atom | f_ID | per-atom vector |
| atom | f_ID[I] | column of per-atom array |
+--------+------------+------------------------------------------+
Note that if an equal-style variable formula wishes to access per-atom
data from a fix, it must use capital "F" as the ID prefix and not
lower-case "f".
Also note that if a vector- or atom-style variable formula needs to
access a scalar value from a fix (i.e. the 5 kinds of values in the
first 5 lines of the table), it can not do so directly. Instead, it
can use a reference to an equal-style variable which stores the scalar
value from the fix.
The I and J indices in these fix references can be integers or can be
a variable name, specified as v_name, where name is the name of the
variable. The rules for this syntax are the same as for indices in
the "Atom Values and Vectors" discussion above.
Note that some fixes only generate quantities on certain timesteps.
If a variable attempts to access the fix on non-allowed timesteps, an
@ -1260,6 +1273,10 @@ error is generated. For example, the :doc:`fix ave/time <fix_ave_time>`
command may only generate averaged quantities every 100 steps. See
the doc pages for individual fix commands for details.
If a variable containing a fix is evaluated directly in an input
script (not during a run), then the values accessed by the fix should
be current. See the discussion below about "Variable Accuracy".
----------
Variable References
@ -1294,26 +1311,32 @@ including other atom-style or atomfile-style variables. If it uses a
vector-style variable, a subscript must be used to access a single
value from the vector-style variable.
Examples of different kinds of variable references are as follows.
There is no ambiguity as to what a reference means, since variables
produce only a global scalar or global vector or per-atom vector.
The allowed variable references in variable formulas for equal-,
vector-, and atom-style variables are listed in the following table.
Note that there is no ambiguity as to what a reference means, since
referenced variables produce only a global scalar or global vector or
per-atom vector.
+------------+----------------------------------------------------------------------+
| v_name | global scalar from equal-style variable |
+------------+----------------------------------------------------------------------+
| v_name | global vector from vector-style variable |
+------------+----------------------------------------------------------------------+
| v_name | per-atom vector from atom-style or atomfile-style variable |
+------------+----------------------------------------------------------------------+
| v_name[I] | Ith element of a global vector from vector-style variable |
+------------+----------------------------------------------------------------------+
| v_name[I] | value of atom with ID = I from atom-style or atomfile-style variable |
+------------+----------------------------------------------------------------------+
+--------+-----------+-----------------------------------------------------------------------------------+
| equal | v_name | global scalar from an equal-style variable |
| equal | v_name[I] | element of global vector from a vector-style variable |
| equal | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| vector | v_name | global scalar from an equal-style variable |
| vector | v_name | global vector from a vector-style variable |
| vector | v_name[I] | element of global vector from a vector-style variable |
| vector | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| atom | v_name | global scalar from an equal-style variable |
| atom | v_name | per-atom vector from an atom-style or atomfile-style variable |
| atom | v_name[I] | element of global vector from a vector-style variable |
| atom | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
For the I index, an integer can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
rules for this syntax are the same as for indices in the "Atom Values
and Vectors" discussion above.
----------

2
doc/utils/requirements.txt
View File

@ -1,4 +1,4 @@
Sphinx >= 5.3.0, <7.2.0
Sphinx >= 5.3.0, <8.0
sphinxcontrib-spelling
sphinxcontrib-jquery
git+https://github.com/akohlmey/sphinx-fortran@parallel-read

4
doc/utils/sphinx-config/false_positives.txt
View File

@ -1506,6 +1506,7 @@ Im
imageint
Imageint
Imagemagick
imagename
imd
Impey
impl
@ -2587,6 +2588,7 @@ Nurdin
Nvalue
nvaluelast
Nvalues
nvar
nvc
nvcc
nve
@ -2890,6 +2892,7 @@ pscrozi
pseudocode
Pseudocode
pseudodynamics
pseudoparticle
pseudopotential
psllod
pSp
@ -3753,6 +3756,7 @@ uncomment
uncommented
uncompress
uncompute
underdamped
underprediction
undump
uniaxial

1
examples/COUPLE/plugin/liblammpsplugin.c
View File

@ -110,6 +110,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(extract_variable);
ADDSYM(extract_variable_datatype);
ADDSYM(set_variable);
ADDSYM(variable_info);
ADDSYM(gather_atoms);
ADDSYM(gather_atoms_concat);

5
examples/COUPLE/plugin/liblammpsplugin.h
View File

@ -106,7 +106,7 @@ typedef void (*FixExternalFnPtr)(void *, int, int, int *, double **, double **);
typedef void (*FixExternalFnPtr)(void *, int64_t, int, int *, double **, double **);
#endif
#define LAMMPSPLUGIN_ABI_VERSION 1
#define LAMMPSPLUGIN_ABI_VERSION 2
struct _liblammpsplugin {
int abiversion;
int has_exceptions;
@ -127,7 +127,7 @@ struct _liblammpsplugin {
void (*error)(void *, int, const char *);
void (*file)(void *, char *);
void (*file)(void *, const char *);
char *(*command)(void *, const char *);
void (*commands_list)(void *, int, const char **);
void (*commands_string)(void *, const char *);
@ -155,6 +155,7 @@ struct _liblammpsplugin {
void *(*extract_variable)(void *, const char *, char *);
int (*extract_variable_datatype)(void *, const char *);
int (*set_variable)(void *, char *, char *);
int (*variable_info)(void *, int, char *, int);
void (*gather_atoms)(void *, const char *, int, int, void *);
void (*gather_atoms_concat)(void *, const char *, int, int, void *);

2
examples/mliap/in.mliap.quadratic.compute
View File

@ -65,7 +65,7 @@ compute bsum2 snapgroup2 reduce sum c_b[*]
# fix bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
compute vbsum all reduce sum c_vb[*]
# fix vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
variable db_2_100 equal c_db[2][100]
variable db_2_100 equal C_db[2][100]
# test output: 1: total potential energy
# 2: xy component of stress tensor

2
examples/mliap/in.mliap.snap.compute
View File

@ -65,7 +65,7 @@ compute bsum2 snapgroup2 reduce sum c_b[*]
# fix bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
compute vbsum all reduce sum c_vb[*]
# fix vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
variable db_2_25 equal c_db[2][25]
variable db_2_25 equal C_db[2][25]
thermo 100

12
examples/snap/in.grid.snap
View File

@ -67,18 +67,18 @@ compute mygridlocal all sna/grid/local grid ${ngrid} ${ngrid} ${ngrid} &
# define output
variable B5atom equal c_b[2][5]
variable B5atom equal C_b[2][5]
variable B5grid equal c_mygrid[8][8]
variable rmse_global equal "sqrt( &
(c_mygrid[8][1] - x[2])^2 + &
(c_mygrid[8][2] - y[2])^2 + &
(c_mygrid[8][3] - z[2])^2 + &
(c_mygrid[8][4] - c_b[2][1])^2 + &
(c_mygrid[8][5] - c_b[2][2])^2 + &
(c_mygrid[8][6] - c_b[2][3])^2 + &
(c_mygrid[8][7] - c_b[2][4])^2 + &
(c_mygrid[8][8] - c_b[2][5])^2 &
(c_mygrid[8][4] - C_b[2][1])^2 + &
(c_mygrid[8][5] - C_b[2][2])^2 + &
(c_mygrid[8][6] - C_b[2][3])^2 + &
(c_mygrid[8][7] - C_b[2][4])^2 + &
(c_mygrid[8][8] - C_b[2][5])^2 &
)"
thermo_style custom step v_B5atom v_B5grid v_rmse_global

12
examples/snap/in.grid.tri
View File

@ -87,18 +87,18 @@ compute mygridlocal all sna/grid/local grid ${ngridx} ${ngridy} ${ngridz} &
# define output
variable B5atom equal c_b[7][5]
variable B5atom equal C_b[7][5]
variable B5grid equal c_mygrid[13][8]
# do not compare x,y,z because assignment of ids
# to atoms is not unnique for different processor grids
variable rmse_global equal "sqrt( &
(c_mygrid[13][4] - c_b[7][1])^2 + &
(c_mygrid[13][5] - c_b[7][2])^2 + &
(c_mygrid[13][6] - c_b[7][3])^2 + &
(c_mygrid[13][7] - c_b[7][4])^2 + &
(c_mygrid[13][8] - c_b[7][5])^2 &
(c_mygrid[13][4] - C_b[7][1])^2 + &
(c_mygrid[13][5] - C_b[7][2])^2 + &
(c_mygrid[13][6] - C_b[7][3])^2 + &
(c_mygrid[13][7] - C_b[7][4])^2 + &
(c_mygrid[13][8] - C_b[7][5])^2 &
)"
thermo_style custom step v_B5atom v_B5grid v_rmse_global

2
examples/snap/in.snap.compute
View File

@ -70,7 +70,7 @@ compute bsum2 snapgroup2 reduce sum c_b[*]
# fix bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
compute vbsum all reduce sum c_vb[*]
# fix vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
variable db_2_25 equal c_db[2][25]
variable db_2_25 equal C_db[2][25]
# set up compute snap generating global array

2
examples/snap/in.snap.compute.quadratic
View File

@ -70,7 +70,7 @@ compute bsum2 snapgroup2 reduce sum c_b[*]
# fix bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
compute vbsum all reduce sum c_vb[*]
# fix vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
variable db_2_100 equal c_db[2][100]
variable db_2_100 equal C_db[2][100]
# set up compute snap generating global array

8
examples/voronoi/in.voronoi
View File

@ -146,10 +146,10 @@ variable i2 equal 257
compute v1 all voronoi/atom occupation
compute r0 all reduce sum c_v1[1]
compute r1 all reduce sum c_v1[2]
variable d5a equal c_v1[${i1}][1]
variable d5b equal c_v1[${i2}][1]
variable d5c equal c_v1[${i1}][2]
variable d5d equal c_v1[${i2}][2]
variable d5a equal C_v1[${i1}][1]
variable d5b equal C_v1[${i2}][1]
variable d5c equal C_v1[${i1}][2]
variable d5d equal C_v1[${i2}][2]
thermo_style custom c_r0 c_r1 v_d5a v_d5b v_d5c v_d5d
run 0

11
examples/voronoi/in.voronoi.data
View File

@ -63,11 +63,9 @@ undump dlocal
# TEST 2:
#
# This compute voronoi generates
# local and global quantities, but
# not per-atom quantities
# This compute voronoi generates peratom and local and global quantities
compute v2 all voronoi/atom neighbors yes edge_histo 6 peratom no
compute v2 all voronoi/atom neighbors yes edge_histo 6
# write voronoi local quantities to a file
@ -75,7 +73,7 @@ dump d2 all local 1 dump.neighbors2 index c_v2[1] c_v2[2] c_v2[3]
# sum up a voronoi local quantity
compute sumarea all reduce sum c_v2[3]
compute sumarea all reduce sum c_v2[3] inputs local
# output voronoi global quantities
@ -83,6 +81,3 @@ thermo_style custom c_sumarea c_v2[3] c_v2[4] c_v2[5] c_v2[6] c_v2[7]
thermo 1
run 0

1
lib/colvars/colvar.cpp
View File

@ -30,6 +30,7 @@ colvar::colvar()
after_restart = false;
kinetic_energy = 0.0;
potential_energy = 0.0;
period = 0.0;
#ifdef LEPTON
dev_null = 0.0;

10
lib/machdyn/Install.py
View File

@ -31,8 +31,8 @@ checksums = { \
# help message
HELP = """
Syntax from src dir: make lib-smd args="-b"
or: make lib-smd args="-p /usr/include/eigen3"
Syntax from src dir: make lib-machdyn args="-b"
or: make lib-machdyn args="-p /usr/include/eigen3"
Syntax from lib dir: python Install.py -b
or: python Install.py -p /usr/include/eigen3"
@ -40,8 +40,8 @@ Syntax from lib dir: python Install.py -b
Example:
make lib-smd args="-b" # download/build in default lib/smd/eigen-eigen-*
make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
make lib-machdyn args="-b" # download/build in default lib/machdyn/eigen-eigen-*
make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
"""
pgroup = parser.add_mutually_exclusive_group()
@ -105,7 +105,7 @@ if buildflag:
edir = os.path.join(homepath, "eigen-%s" % version)
os.rename(edir, eigenpath)
# create link in lib/smd to Eigen src dir
# create link in lib/machdyn to Eigen src dir
print("Creating link to Eigen include folder")
if os.path.isfile("includelink") or os.path.islink("includelink"):

6
lib/machdyn/README
View File

@ -4,7 +4,7 @@ to use the MACHDYN package in a LAMMPS input script.
The Eigen library is available at http://eigen.tuxfamily.org. It's
a general C++ template library for linear algebra.
You can type "make lib-smd" from the src directory to see help on how
You can type "make lib-machdyn" from the src directory to see help on how
to download build this library via make commands, or you can do the
same thing by typing "python Install.py" from within this directory,
or you can do it manually by following the instructions below.
@ -12,13 +12,13 @@ or you can do it manually by following the instructions below.
Instructions:
1. Download the Eigen tarball at http://eigen.tuxfamily.org and
unpack the tarball either in this /lib/smd directory or somewhere
unpack the tarball either in this lib/machdyn directory or somewhere
else on your system. It should unpack with into a directory with
a name similar to eigen-eigen-bdd17ee3b1b3. You can rename
the directory to just "eigen" if you wish. Note that Eigen is a
template library, so you do not have to build it.
2. Create a soft link in this dir (lib/smd)
2. Create a soft link in this dir (lib/machdyn)
to the eigen directory. E.g if you unpacked Eigen in this dir:
% ln -s eigen-eigen-bdd17ee3b1b3 includelink
If you unpacked Eigen somewhere else and renamed

4
lib/pace/Install.py
View File

@ -18,11 +18,11 @@ from install_helpers import fullpath, geturl, checkmd5sum, getfallback
# settings
thisdir = fullpath('.')
version ='v.2023.01.3.fix'
version ='v.2023.10.04'
# known checksums for different PACE versions. used to validate the download.
checksums = { \
'v.2023.01.3.fix': '4f0b3b5b14456fe9a73b447de3765caa'
'v.2023.10.04': '70ff79f4e59af175e55d24f3243ad1ff'
}
parser = ArgumentParser(prog='Install.py', description="LAMMPS library build wrapper script")

4
src/ADIOS/dump_atom_adios.cpp
View File

@ -281,8 +281,8 @@ void DumpAtomADIOS::init_style()
auto nstreams = std::to_string(num_aggregators);
internal->io.SetParameters({{"substreams", nstreams}});
if (me == 0)
utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n", filename,
nstreams);
utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n",
filename, nstreams);
}
internal->io.DefineVariable<uint64_t>("ntimestep");

6
src/ADIOS/dump_custom_adios.cpp
View File

@ -290,6 +290,7 @@ void DumpCustomADIOS::init_style()
/* Define the group of variables for the atom style here since it's a fixed
* set */
if (!internal->io) {
internal->io = internal->ad->DeclareIO(internal->ioName);
if (!internal->io.InConfigFile()) {
// if not defined by user, we can change the default settings
@ -300,8 +301,8 @@ void DumpCustomADIOS::init_style()
auto nstreams = std::to_string(num_aggregators);
internal->io.SetParameters({{"substreams", nstreams}});
if (me == 0)
utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n", filename,
nstreams);
utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n",
filename, nstreams);
}
internal->io.DefineVariable<uint64_t>("ntimestep");
@ -345,3 +346,4 @@ void DumpCustomADIOS::init_style()
internal->varAtoms = internal->io.DefineVariable<double>(
"atoms", {UnknownSizeYet, nColumns}, {UnknownSizeYet, 0}, {UnknownSizeYet, nColumns});
}
}

9
src/BOCS/fix_bocs.cpp
View File

@ -1024,7 +1024,10 @@ void FixBocs::final_integrate()
if (pstat_flag) {
if (pstyle == ISO) pressure->compute_scalar();
else pressure->compute_vector();
else {
temperature->compute_vector();
pressure->compute_vector();
}
couple();
pressure->addstep(update->ntimestep+1);
}
@ -1961,6 +1964,7 @@ void FixBocs::nhc_press_integrate()
int ich,i,pdof;
double expfac,factor_etap,kecurrent;
double kt = boltz * t_target;
double lkt_press;
// Update masses, to preserve initial freq, if flag set
@ -2006,7 +2010,8 @@ void FixBocs::nhc_press_integrate()
}
}
double lkt_press = pdof * kt;
if (pstyle == ISO) lkt_press = kt;
else lkt_press = pdof * kt;
etap_dotdot[0] = (kecurrent - lkt_press)/etap_mass[0];
double ncfac = 1.0/nc_pchain;

10
src/BODY/fix_wall_body_polyhedron.cpp
View File

@ -17,18 +17,20 @@
------------------------------------------------------------------------- */
#include "fix_wall_body_polyhedron.h"
#include <cmath>
#include <cstring>
#include "atom.h"
#include "atom_vec_body.h"
#include "body_rounded_polyhedron.h"
#include "domain.h"
#include "update.h"
#include "error.h"
#include "force.h"
#include "math_const.h"
#include "math_extra.h"
#include "memory.h"
#include "error.h"
#include "update.h"
#include <cmath>
#include <cstring>
using namespace LAMMPS_NS;
using namespace FixConst;

2
src/Depend.sh
View File

@ -64,6 +64,7 @@ fi
if (test $1 = "COLLOID") then
depend GPU
depend KOKKOS
depend OPENMP
fi
@ -185,6 +186,7 @@ fi
if (test $1 = "ML-SNAP") then
depend ML-IAP
depend KOKKOS
depend INTEL
fi
if (test $1 = "CG-SPICA") then

2
src/ELECTRODE/electrode_matrix.cpp
View File

@ -84,7 +84,7 @@ void ElectrodeMatrix::compute_array(double **array, bool timer_flag)
electrode_kspace->compute_matrix(&mpos[0], array, timer_flag);
MPI_Barrier(world);
if (timer_flag && (comm->me == 0))
utils::logmesg(lmp, fmt::format("KSpace time: {:.4g} s\n", MPI_Wtime() - kspace_time));
utils::logmesg(lmp, "KSpace time: {:.4g} s\n", MPI_Wtime() - kspace_time);
//cout << array[0][0] << ", " << array[0][1] << endl;
pair_contribution(array);
//cout << array[0][0] << ", " << array[0][1] << endl;

8
src/ELECTRODE/electrode_vector.cpp
View File

@ -60,10 +60,10 @@ ElectrodeVector::~ElectrodeVector()
{
if (timer_flag && (comm->me == 0)) {
try {
utils::logmesg(lmp, fmt::format("B time: {:.4g} s\n", b_time_total));
utils::logmesg(lmp, fmt::format("B kspace time: {:.4g} s\n", kspace_time_total));
utils::logmesg(lmp, fmt::format("B pair time: {:.4g} s\n", pair_time_total));
utils::logmesg(lmp, fmt::format("B boundary time: {:.4g} s\n", boundary_time_total));
utils::logmesg(lmp, "B time: {:.4g} s\n", b_time_total);
utils::logmesg(lmp, "B kspace time: {:.4g} s\n", kspace_time_total);
utils::logmesg(lmp, "B pair time: {:.4g} s\n", pair_time_total);
utils::logmesg(lmp, "B boundary time: {:.4g} s\n", boundary_time_total);
} catch (std::exception &) {
}
}

8
src/ELECTRODE/pppm_electrode.cpp
View File

@ -136,7 +136,7 @@ void PPPMElectrode::init()
}
if (order < 2 || order > MAXORDER)
error->all(FLERR, fmt::format("PPPM/electrode order cannot be < 2 or > {}", MAXORDER));
error->all(FLERR, "PPPM/electrode order cannot be < 2 or > {}", MAXORDER);
// compute two charge force
@ -816,7 +816,7 @@ void PPPMElectrode::one_step_multiplication(bigint *imat, double *greens_real, d
memory->destroy(rho1d_j);
MPI_Barrier(world);
if (timer_flag && (comm->me == 0))
utils::logmesg(lmp, fmt::format("Single step time: {:.4g} s\n", MPI_Wtime() - step1_time));
utils::logmesg(lmp, "Single step time: {:.4g} s\n", MPI_Wtime() - step1_time);
}
/* ----------------------------------------------------------------------*/
@ -917,7 +917,7 @@ void PPPMElectrode::two_step_multiplication(bigint *imat, double *greens_real, d
}
MPI_Barrier(world);
if (timer_flag && (comm->me == 0))
utils::logmesg(lmp, fmt::format("step 1 time: {:.4g} s\n", MPI_Wtime() - step1_time));
utils::logmesg(lmp, "step 1 time: {:.4g} s\n", MPI_Wtime() - step1_time);
// nested loop over electrode atoms i and j and stencil of i
// in theory could reuse make_rho1d_j here -- but this step is already
@ -958,7 +958,7 @@ void PPPMElectrode::two_step_multiplication(bigint *imat, double *greens_real, d
MPI_Barrier(world);
memory->destroy(gw);
if (timer_flag && (comm->me == 0))
utils::logmesg(lmp, fmt::format("step 2 time: {:.4g} s\n", MPI_Wtime() - step2_time));
utils::logmesg(lmp, "step 2 time: {:.4g} s\n", MPI_Wtime() - step2_time);
}
/* ----------------------------------------------------------------------

54
src/EXTRA-COMPUTE/compute_ackland_atom.cpp
View File

@ -33,6 +33,7 @@
#include <cmath>
#include <cstring>
#include <utility>
using namespace LAMMPS_NS;
@ -346,35 +347,24 @@ void ComputeAcklandAtom::compute_peratom()
2nd routine sorts auxiliary array at same time
------------------------------------------------------------------------- */
#define SWAP(a,b) tmp = a; (a) = b; (b) = tmp;
#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
void ComputeAcklandAtom::select(int k, int n, double *arr)
{
int i,ir,j,l,mid;
double a,tmp;
double a;
arr--;
l = 1;
ir = n;
while (true) {
if (ir <= l+1) {
if (ir == l+1 && arr[ir] < arr[l]) {
SWAP(arr[l],arr[ir])
}
if (ir == l+1 && arr[ir] < arr[l]) std::swap(arr[l],arr[ir]);
return;
} else {
mid=(l+ir) >> 1;
SWAP(arr[mid],arr[l+1])
if (arr[l] > arr[ir]) {
SWAP(arr[l],arr[ir])
}
if (arr[l+1] > arr[ir]) {
SWAP(arr[l+1],arr[ir])
}
if (arr[l] > arr[l+1]) {
SWAP(arr[l],arr[l+1])
}
std::swap(arr[mid],arr[l+1]);
if (arr[l] > arr[ir]) std::swap(arr[l],arr[ir]);
if (arr[l+1] > arr[ir]) std::swap(arr[l+1],arr[ir]);
if (arr[l] > arr[l+1]) std::swap(arr[l],arr[l+1]);
i = l+1;
j = ir;
a = arr[l+1];
@ -382,7 +372,7 @@ void ComputeAcklandAtom::select(int k, int n, double *arr)
do i++; while (arr[i] < a);
do j--; while (arr[j] > a);
if (j < i) break;
SWAP(arr[i],arr[j])
std::swap(arr[i],arr[j]);
}
arr[l+1] = arr[j];
arr[j] = a;
@ -396,8 +386,8 @@ void ComputeAcklandAtom::select(int k, int n, double *arr)
void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
{
int i,ir,j,l,mid,ia,itmp;
double a,tmp;
int i,ir,j,l,mid,ia;
double a;
arr--;
iarr--;
@ -406,25 +396,25 @@ void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
while (true) {
if (ir <= l+1) {
if (ir == l+1 && arr[ir] < arr[l]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
return;
} else {
mid=(l+ir) >> 1;
SWAP(arr[mid],arr[l+1])
ISWAP(iarr[mid],iarr[l+1])
std::swap(arr[mid],arr[l+1]);
std::swap(iarr[mid],iarr[l+1]);
if (arr[l] > arr[ir]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
if (arr[l+1] > arr[ir]) {
SWAP(arr[l+1],arr[ir])
ISWAP(iarr[l+1],iarr[ir])
std::swap(arr[l+1],arr[ir]);
std::swap(iarr[l+1],iarr[ir]);
}
if (arr[l] > arr[l+1]) {
SWAP(arr[l],arr[l+1])
ISWAP(iarr[l],iarr[l+1])
std::swap(arr[l],arr[l+1]);
std::swap(iarr[l],iarr[l+1]);
}
i = l+1;
j = ir;
@ -434,8 +424,8 @@ void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
do i++; while (arr[i] < a);
do j--; while (arr[j] > a);
if (j < i) break;
SWAP(arr[i],arr[j])
ISWAP(iarr[i],iarr[j])
std::swap(arr[i],arr[j]);
std::swap(iarr[i],iarr[j]);
}
arr[l+1] = arr[j];
arr[j] = a;

54
src/EXTRA-COMPUTE/compute_basal_atom.cpp
View File

@ -31,6 +31,7 @@
#include "update.h"
#include <cmath>
#include <utility>
using namespace LAMMPS_NS;
@ -431,35 +432,24 @@ void ComputeBasalAtom::compute_peratom()
2nd routine sorts auxiliary array at same time
------------------------------------------------------------------------- */
#define SWAP(a,b) tmp = a; (a) = b; (b) = tmp;
#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
void ComputeBasalAtom::select(int k, int n, double *arr)
{
int i,ir,j,l,mid;
double a,tmp;
double a;
arr--;
l = 1;
ir = n;
while (true) {
if (ir <= l+1) {
if (ir == l+1 && arr[ir] < arr[l]) {
SWAP(arr[l],arr[ir])
}
if (ir == l+1 && arr[ir] < arr[l]) std::swap(arr[l],arr[ir]);
return;
} else {
mid=(l+ir) >> 1;
SWAP(arr[mid],arr[l+1])
if (arr[l] > arr[ir]) {
SWAP(arr[l],arr[ir])
}
if (arr[l+1] > arr[ir]) {
SWAP(arr[l+1],arr[ir])
}
if (arr[l] > arr[l+1]) {
SWAP(arr[l],arr[l+1])
}
std::swap(arr[mid],arr[l+1]);
if (arr[l] > arr[ir]) std::swap(arr[l],arr[ir]);
if (arr[l+1] > arr[ir]) std::swap(arr[l+1],arr[ir]);
if (arr[l] > arr[l+1]) std::swap(arr[l],arr[l+1]);
i = l+1;
j = ir;
a = arr[l+1];
@ -467,7 +457,7 @@ void ComputeBasalAtom::select(int k, int n, double *arr)
do i++; while (arr[i] < a);
do j--; while (arr[j] > a);
if (j < i) break;
SWAP(arr[i],arr[j])
std::swap(arr[i],arr[j]);
}
arr[l+1] = arr[j];
arr[j] = a;
@ -481,8 +471,8 @@ void ComputeBasalAtom::select(int k, int n, double *arr)
void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
{
int i,ir,j,l,mid,ia,itmp;
double a,tmp;
int i,ir,j,l,mid,ia;
double a;
arr--;
iarr--;
@ -491,25 +481,25 @@ void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
while (true) {
if (ir <= l+1) {
if (ir == l+1 && arr[ir] < arr[l]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
return;
} else {
mid=(l+ir) >> 1;
SWAP(arr[mid],arr[l+1])
ISWAP(iarr[mid],iarr[l+1])
std::swap(arr[mid],arr[l+1]);
std::swap(iarr[mid],iarr[l+1]);
if (arr[l] > arr[ir]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
if (arr[l+1] > arr[ir]) {
SWAP(arr[l+1],arr[ir])
ISWAP(iarr[l+1],iarr[ir])
std::swap(arr[l+1],arr[ir]);
std::swap(iarr[l+1],iarr[ir]);
}
if (arr[l] > arr[l+1]) {
SWAP(arr[l],arr[l+1])
ISWAP(iarr[l],iarr[l+1])
std::swap(arr[l],arr[l+1]);
std::swap(iarr[l],iarr[l+1]);
}
i = l+1;
j = ir;
@ -519,8 +509,8 @@ void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
do i++; while (arr[i] < a);
do j--; while (arr[j] > a);
if (j < i) break;
SWAP(arr[i],arr[j])
ISWAP(iarr[i],iarr[j])
std::swap(arr[i],arr[j]);
std::swap(iarr[i],iarr[j]);
}
arr[l+1] = arr[j];
arr[j] = a;

32
src/EXTRA-COMPUTE/compute_hexorder_atom.cpp
View File

@ -33,6 +33,7 @@
#include <cmath>
#include <complex>
#include <cstring>
#include <utility>
#ifdef DBL_EPSILON
#define MY_EPSILON (10.0*DBL_EPSILON)
@ -267,15 +268,12 @@ inline void ComputeHexOrderAtom::calc_qn_trig(double delx, double dely, double &
sort auxiliary array at same time
------------------------------------------------------------------------- */
#define SWAP(a,b) tmp = a; (a) = b; (b) = tmp;
#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
/* ---------------------------------------------------------------------- */
void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
{
int i,ir,j,l,mid,ia,itmp;
double a,tmp;
int i,ir,j,l,mid,ia;
double a;
arr--;
iarr--;
@ -284,25 +282,25 @@ void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
while (true) {
if (ir <= l+1) {
if (ir == l+1 && arr[ir] < arr[l]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
return;
} else {
mid=(l+ir) >> 1;
SWAP(arr[mid],arr[l+1])
ISWAP(iarr[mid],iarr[l+1])
std::swap(arr[mid],arr[l+1]);
std::swap(iarr[mid],iarr[l+1]);
if (arr[l] > arr[ir]) {
SWAP(arr[l],arr[ir])
ISWAP(iarr[l],iarr[ir])
std::swap(arr[l],arr[ir]);
std::swap(iarr[l],iarr[ir]);
}
if (arr[l+1] > arr[ir]) {
SWAP(arr[l+1],arr[ir])
ISWAP(iarr[l+1],iarr[ir])
std::swap(arr[l+1],arr[ir]);
std::swap(iarr[l+1],iarr[ir]);
}
if (arr[l] > arr[l+1]) {
SWAP(arr[l],arr[l+1])
ISWAP(iarr[l],iarr[l+1])
std::swap(arr[l],arr[l+1]);
std::swap(iarr[l],iarr[l+1]);
}
i = l+1;
j = ir;
@ -312,8 +310,8 @@ void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
do i++; while (arr[i] < a);
do j--; while (arr[j] > a);
if (j < i) break;
SWAP(arr[i],arr[j])
ISWAP(iarr[i],iarr[j])
std::swap(arr[i],arr[j]);
std::swap(iarr[i],iarr[j]);
}
arr[l+1] = arr[j];
arr[j] = a;

70
src/INTEL/TEST/in.intel.snap Normal file
View File

@ -0,0 +1,70 @@
# Toy demonstration of SNAP "scale" parameter, using fix/adapt and hybrid/overlay
# Mixing linear and quadratic SNAP Ni potentials by Zuo et al. JCPA 2020
variable w index 10 # Warmup Timesteps
variable t index 100 # Main Run Timesteps
variable m index 1 # Main Run Timestep Multiplier
variable n index 0 # Use NUMA Mapping for Multi-Node
variable x index 4
variable y index 2
variable z index 2
variable rr equal floor($t*$m)
variable root getenv LMP_ROOT
if "$n > 0" then "processors * * * grid numa"
# mixing parameter
variable lambda equal 0.2
# Initialize simulation
variable a equal 3.52
units metal
# generate the box and atom positions using a FCC lattice
variable nx equal 20*$x
variable ny equal 20*$y
variable nz equal 20*$z
boundary p p p
lattice fcc $a
region box block 0 ${nx} 0 ${ny} 0 ${nz}
create_box 1 box
create_atoms 1 box
mass 1 34.
# choose bundled SNAP Ni potential from Zuo et al. JCPA 2020
pair_style hybrid/overlay snap snap
pair_coeff * * snap 1 &
${root}/examples/snap/Ni_Zuo_JPCA2020.snapcoeff &
${root}/examples/snap/Ni_Zuo_JPCA2020.snapparam Ni
pair_coeff * * snap 2 &
${root}/examples/snap/Ni_Zuo_JPCA2020.quadratic.snapcoeff &
${root}/examples/snap/Ni_Zuo_JPCA2020.quadratic.snapparam Ni
# scale according to mixing parameter
variable l1 equal ${lambda}
variable l2 equal 1.0-${lambda}
fix scale1 all adapt 1 pair snap:1 scale * * v_l1
fix scale2 all adapt 1 pair snap:2 scale * * v_l2
# Setup output
thermo 1
thermo_modify norm yes
# Set up NVE run
timestep 0.5e-3
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
# Run MD
velocity all create 300.0 4928459 loop geom
fix 1 all nve
if "$w > 0" then "run $w"
run ${rr}

2
src/INTEL/TEST/run_benchmarks.sh
View File

@ -35,7 +35,7 @@ export I_MPI_PIN_DOMAIN=core
# End settings for your system
#########################################################################
export WORKLOADS="lj rhodo lc sw water eam airebo dpd tersoff"
export WORKLOADS="lj rhodo lc sw water eam airebo dpd tersoff snap"
export LMP_ARGS="-pk intel 0 -sf intel -screen none -v d 1"
export RLMP_ARGS="-pk intel 0 lrt yes -sf intel -screen none -v d 1"

2
src/INTEL/angle_charmm_intel.h
View File

@ -59,7 +59,7 @@ class AngleCharmmIntel : public AngleCharmm {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nangletypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nangletypes, Memory *memory);

2
src/INTEL/angle_harmonic_intel.h
View File

@ -60,7 +60,7 @@ class AngleHarmonicIntel : public AngleHarmonic {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nangletypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nangletypes, Memory *memory);

2
src/INTEL/bond_fene_intel.h
View File

@ -59,7 +59,7 @@ class BondFENEIntel : public BondFENE {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nbondtypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nbondtypes, Memory *memory);

2
src/INTEL/bond_harmonic_intel.h
View File

@ -59,7 +59,7 @@ class BondHarmonicIntel : public BondHarmonic {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nbondtypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nbondtypes, Memory *memory);

2
src/INTEL/dihedral_charmm_intel.h
View File

@ -68,7 +68,7 @@ class DihedralCharmmIntel : public DihedralCharmm {
flt_t *weight;
ForceConst() : ljp(nullptr), fc(nullptr), weight(nullptr), _npairtypes(0), _ndihderaltypes(0) {}
~ForceConst() { set_ntypes(0, 0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, 0, nullptr); }
void set_ntypes(const int npairtypes, const int ndihderaltypes, Memory *memory);

2
src/INTEL/dihedral_fourier_intel.h
View File

@ -63,7 +63,7 @@ class DihedralFourierIntel : public DihedralFourier {
fc_packed1 **fc;
ForceConst() : fc(nullptr), _ndihedraltypes(0) {}
~ForceConst() { set_ntypes(0, nullptr, nullptr, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr, nullptr, nullptr); }
void set_ntypes(const int ndihedraltypes, int *setflag, int *nterms, Memory *memory);

2
src/INTEL/dihedral_harmonic_intel.h
View File

@ -63,7 +63,7 @@ class DihedralHarmonicIntel : public DihedralHarmonic {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _ndihderaltypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int ndihderaltypes, Memory *memory);

2
src/INTEL/dihedral_opls_intel.h
View File

@ -62,7 +62,7 @@ class DihedralOPLSIntel : public DihedralOPLS {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _ndihderaltypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int ndihderaltypes, Memory *memory);

2
src/INTEL/fix_intel.cpp
View File

@ -20,6 +20,7 @@
#include "fix_intel.h"
#include "comm.h"
#include "domain.h"
#include "error.h"
#include "force.h"
#include "neighbor.h"
@ -470,6 +471,7 @@ void FixIntel::pair_init_check(const bool cdmessage)
int need_tag = 0;
if (atom->molecular != Atom::ATOMIC || three_body_neighbor()) need_tag = 1;
if (domain->triclinic && force->newton_pair) need_tag = 1;
// Clear buffers used for pair style
char kmode[80];

2
src/INTEL/improper_cvff_intel.h
View File

@ -61,7 +61,7 @@ class ImproperCvffIntel : public ImproperCvff {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nimpropertypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nimpropertypes, Memory *memory);

2
src/INTEL/improper_harmonic_intel.h
View File

@ -60,7 +60,7 @@ class ImproperHarmonicIntel : public ImproperHarmonic {
fc_packed1 *fc;
ForceConst() : fc(nullptr), _nimpropertypes(0) {}
~ForceConst() { set_ntypes(0, nullptr); }
~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
void set_ntypes(const int nimpropertypes, Memory *memory);

161
src/INTEL/intel_simd.h
View File

@ -46,13 +46,38 @@ namespace ip_simd {
typedef __mmask16 SIMD_mask;
inline bool any(const SIMD_mask &m) { return m != 0; }
struct SIMD_int {
__m512i v;
SIMD_int() {}
SIMD_int(const __m512i in) : v(in) {}
inline int & operator[](const int i) { return ((int *)&(v))[i]; }
inline const int & operator[](const int i) const
{ return ((int *)&(v))[i]; }
operator __m512i() const { return v;}
};
struct SIMD256_int {
__m256i v;
SIMD256_int() {}
SIMD256_int(const __m256i in) : v(in) {}
SIMD256_int(const int in) : v(_mm256_set1_epi32(in)) {}
inline int & operator[](const int i) { return ((int *)&(v))[i]; }
inline const int & operator[](const int i) const
{ return ((int *)&(v))[i]; }
#ifdef __INTEL_LLVM_COMPILER
inline SIMD256_int operator&=(const int i)
{ v=_mm256_and_epi32(v, _mm256_set1_epi32(i)); return *this; };
#else
inline SIMD256_int operator&=(const int i)
{ v=_mm256_and_si256(v, _mm256_set1_epi32(i)); return *this; };
#endif
inline SIMD256_int operator+=(const int i)
{ v=_mm256_add_epi32(v, _mm256_set1_epi32(i)); return *this; };
operator __m256i() const { return v;}
};
struct SIMD_float {
__m512 v;
SIMD_float() {}
@ -64,7 +89,24 @@ namespace ip_simd {
__m512d v;
SIMD_double() {}
SIMD_double(const __m512d in) : v(in) {}
SIMD_double(const double in) { v=_mm512_set1_pd(in); }
inline double & operator[](const int i) { return ((double *)&(v))[i]; }
inline const double & operator[](const int i) const
{ return ((double *)&(v))[i]; }
operator __m512d() const { return v;}
SIMD_double & operator=(const double i)
{ _mm512_set1_pd(i); return *this; }
SIMD_double &operator=(const SIMD_double &i)
{ v = i.v; return *this; }
SIMD_double operator-() { return _mm512_xor_pd(v, _mm512_set1_pd(-0.0)); }
SIMD_double & operator+=(const SIMD_double & two)
{ v = _mm512_add_pd(v, two.v); return *this; }
SIMD_double & operator-=(const SIMD_double & two)
{ v = _mm512_sub_pd(v, two.v); return *this; }
SIMD_double & operator*=(const SIMD_double & two)
{ v = _mm512_mul_pd(v, two.v); return *this; }
};
template<class flt_t>
@ -99,6 +141,12 @@ namespace ip_simd {
// ------- Set Operations
inline SIMD256_int SIMD256_set(const int l0, const int l1, const int l2,
const int l3, const int l4, const int l5,
const int l6, const int l7) {
return _mm256_setr_epi32(l0,l1,l2,l3,l4,l5,l6,l7);
}
inline SIMD_int SIMD_set(const int l0, const int l1, const int l2,
const int l3, const int l4, const int l5,
const int l6, const int l7, const int l8,
@ -109,6 +157,10 @@ namespace ip_simd {
l8,l9,l10,l11,l12,l13,l14,l15);
}
inline SIMD256_int SIMD256_set(const int l) {
return _mm256_set1_epi32(l);
}
inline SIMD_int SIMD_set(const int l) {
return _mm512_set1_epi32(l);
}
@ -121,6 +173,10 @@ namespace ip_simd {
return _mm512_set1_pd(l);
}
inline SIMD256_int SIMD256_count() {
return SIMD256_set(0,1,2,3,4,5,6,7);
}
inline SIMD_int SIMD_zero_masked(const SIMD_mask &m, const SIMD_int &one) {
return _mm512_maskz_mov_epi32(m, one);
}
@ -147,6 +203,10 @@ namespace ip_simd {
// -------- Load Operations
inline SIMD256_int SIMD_load(const SIMD256_int *p) {
return _mm256_load_epi32((int *)p);
}
inline SIMD_int SIMD_load(const int *p) {
return _mm512_load_epi32(p);
}
@ -159,6 +219,10 @@ namespace ip_simd {
return _mm512_load_pd(p);
}
inline SIMD_double SIMD_load(const SIMD_double *p) {
return _mm512_load_pd((double *)p);
}
inline SIMD_int SIMD_loadz(const SIMD_mask &m, const int *p) {
return _mm512_maskz_load_epi32(m, p);
}
@ -171,6 +235,10 @@ namespace ip_simd {
return _mm512_maskz_load_pd(m, p);
}
inline SIMD256_int SIMD_gather(const int *p, const SIMD256_int &i) {
return _mm256_i32gather_epi32(p, i, _MM_SCALE_4);
}
inline SIMD_int SIMD_gather(const int *p, const SIMD_int &i) {
return _mm512_i32gather_epi32(i, p, _MM_SCALE_4);
}
@ -179,6 +247,10 @@ namespace ip_simd {
return _mm512_i32gather_ps(i, p, _MM_SCALE_4);
}
inline SIMD_double SIMD_gather(const double *p, const SIMD256_int &i) {
return _mm512_i32gather_pd(i, p, _MM_SCALE_8);
}
inline SIMD_double SIMD_gather(const double *p, const SIMD_int &i) {
return _mm512_i32gather_pd(_mm512_castsi512_si256(i), p, _MM_SCALE_8);
}
@ -201,6 +273,12 @@ namespace ip_simd {
_mm512_castsi512_si256(i), p, _MM_SCALE_8);
}
inline SIMD_double SIMD_gather(const SIMD_mask &m, const double *p,
const SIMD256_int &i) {
return _mm512_mask_i32gather_pd(_mm512_undefined_pd(), m,
i, p, _MM_SCALE_8);
}
template <typename T>
inline SIMD_int SIMD_gatherz_offset(const SIMD_mask &m, const int *p,
const SIMD_int &i) {
@ -252,6 +330,15 @@ namespace ip_simd {
return _mm512_store_pd(p,one);
}
inline void SIMD_store(SIMD_double *p, const SIMD_double &one) {
return _mm512_store_pd((double *)p,one);
}
inline void SIMD_scatter(const SIMD_mask &m, int *p,
const SIMD256_int &i, const SIMD256_int &vec) {
_mm256_mask_i32scatter_epi32(p, m, i, vec, _MM_SCALE_4);
}
inline void SIMD_scatter(const SIMD_mask &m, int *p,
const SIMD_int &i, const SIMD_int &vec) {
_mm512_mask_i32scatter_epi32(p, m, i, vec, _MM_SCALE_4);
@ -268,8 +355,22 @@ namespace ip_simd {
_MM_SCALE_8);
}
inline void SIMD_scatter(const SIMD_mask &m, double *p,
const SIMD256_int &i, const SIMD_double &vec) {
_mm512_mask_i32scatter_pd(p, m, i, vec, _MM_SCALE_8);
}
inline void SIMD_scatter(double *p,
const SIMD256_int &i, const SIMD_double &vec) {
_mm512_i32scatter_pd(p, i, vec, _MM_SCALE_8);
}
// ------- Arithmetic Operations
inline SIMD256_int operator+(const SIMD256_int &one, const SIMD256_int &two) {
return _mm256_add_epi32(one,two);
}
inline SIMD_int operator+(const SIMD_int &one, const SIMD_int &two) {
return _mm512_add_epi32(one,two);
}
@ -286,6 +387,10 @@ namespace ip_simd {
return _mm512_add_epi32(one,SIMD_set(two));
}
inline SIMD256_int operator+(const SIMD256_int &one, const int two) {
return _mm256_add_epi32(one,SIMD256_set(two));
}
inline SIMD_float operator+(const SIMD_float &one, const float two) {
return _mm512_add_ps(one,SIMD_set(two));
}
@ -299,6 +404,11 @@ namespace ip_simd {
return _mm512_mask_add_epi32(one,m,one,SIMD_set(two));
}
inline SIMD256_int SIMD_add(const SIMD_mask &m,
const SIMD256_int &one, const int two) {
return _mm256_mask_add_epi32(one,m,one,SIMD256_set(two));
}
inline SIMD_float SIMD_add(const SIMD_mask &m,
const SIMD_float &one, const float two) {
return _mm512_mask_add_ps(one,m,one,SIMD_set(two));
@ -309,6 +419,11 @@ namespace ip_simd {
return _mm512_mask_add_pd(one,m,one,SIMD_set(two));
}
inline SIMD_double SIMD_add(const SIMD_mask &m,
const SIMD_double &one, const SIMD_double &two) {
return _mm512_mask_add_pd(one,m,one,two);
}
inline SIMD_int SIMD_add(const SIMD_int &s, const SIMD_mask &m,
const SIMD_int &one, const SIMD_int &two) {
return _mm512_mask_add_epi32(s,m,one,two);
@ -387,6 +502,10 @@ namespace ip_simd {
return _mm512_mul_pd(one,two);
}
inline SIMD256_int operator*(const SIMD256_int &one, const int two) {
return _mm256_mullo_epi32(one,SIMD256_set(two));
}
inline SIMD_int operator*(const SIMD_int &one, const int two) {
return _mm512_mullo_epi32(one,SIMD_set(two));
}
@ -417,6 +536,12 @@ namespace ip_simd {
return _mm512_fmadd_pd(one,two,three);
}
inline SIMD_double SIMD_fma(const SIMD_mask m, const SIMD_double &one,
const SIMD_double &two,
const SIMD_double &three) {
return _mm512_mask3_fmadd_pd(one,two,three,m);
}
inline SIMD_float SIMD_fms(const SIMD_float &one, const SIMD_float &two,
const SIMD_float &three) {
return _mm512_fmsub_ps(one,two,three);
@ -493,6 +618,10 @@ namespace ip_simd {
return _mm512_pow_pd(one, two);
}
inline SIMD_double SIMD_pow(const SIMD_double &one, const double two) {
return _mm512_pow_pd(one, SIMD_set(two));
}
inline SIMD_float SIMD_exp(const SIMD_float &one) {
return _mm512_exp_ps(one);
}
@ -501,6 +630,18 @@ namespace ip_simd {
return _mm512_exp_pd(one);
}
inline SIMD_double SIMD_cos(const SIMD_double &one) {
return _mm512_cos_pd(one);
}
inline SIMD_double SIMD_sin(const SIMD_double &one) {
return _mm512_sin_pd(one);
}
inline SIMD_double SIMD_tan(const SIMD_double &one) {
return _mm512_tan_pd(one);
}
// ------- Comparison operations
inline SIMD_mask SIMD_lt(SIMD_mask m, const SIMD_int &one,
@ -533,6 +674,14 @@ namespace ip_simd {
return _mm512_mask_cmplt_pd_mask(m, SIMD_set(one), two);
}
inline SIMD_mask operator<(const SIMD256_int &one, const SIMD256_int &two) {
return _mm256_cmplt_epi32_mask(one,two);
}
inline SIMD_mask operator<(const int one, const SIMD256_int &two) {
return _mm256_cmplt_epi32_mask(SIMD256_set(one),two);
}
inline SIMD_mask operator<(const SIMD_int &one, const SIMD_int &two) {
return _mm512_cmplt_epi32_mask(one,two);
}
@ -577,6 +726,10 @@ namespace ip_simd {
return _mm512_cmple_ps_mask(SIMD_set(one), two);
}
inline SIMD_mask operator<=(const SIMD_double &one, const SIMD_double &two) {
return _mm512_cmple_pd_mask(one, two);
}
inline SIMD_mask operator<=(const double one, const SIMD_double &two) {
return _mm512_cmple_pd_mask(SIMD_set(one), two);
}
@ -593,6 +746,14 @@ namespace ip_simd {
return _mm512_cmplt_pd_mask(two,one);
}
inline SIMD_mask operator>(const SIMD_double &one, const double two) {
return _mm512_cmplt_pd_mask(SIMD_set(two),one);
}
inline SIMD_mask operator==(const SIMD256_int &one, const int two) {
return _mm256_cmpeq_epi32_mask(one,_mm256_set1_epi32(two));
}
inline SIMD_mask operator==(const SIMD_int &one, const SIMD_int &two) {
return _mm512_cmpeq_epi32_mask(one,two);
}

32
src/INTEL/npair_halffull_newton_intel.cpp
View File

@ -20,7 +20,9 @@
#include "atom.h"
#include "comm.h"
#include "domain.h"
#include "error.h"
#include "force.h"
#include "modify.h"
#include "my_page.h"
#include "neigh_list.h"
@ -56,6 +58,9 @@ void NPairHalffullNewtonIntel::build_t(NeighList *list,
const int * _noalias const numneigh_full = list->listfull->numneigh;
const int ** _noalias const firstneigh_full = (const int ** const)list->listfull->firstneigh; // NOLINT
const double delta = 0.01 * force->angstrom;
const int triclinic = domain->triclinic;
#if defined(_OPENMP)
#pragma omp parallel
#endif
@ -82,6 +87,7 @@ void NPairHalffullNewtonIntel::build_t(NeighList *list,
const int * _noalias const jlist = firstneigh_full[i];
const int jnum = numneigh_full[i];
if (!triclinic) {
#if defined(LMP_SIMD_COMPILER)
#pragma vector aligned
#pragma ivdep
@ -102,6 +108,30 @@ void NPairHalffullNewtonIntel::build_t(NeighList *list,
if (addme)
neighptr[n++] = joriginal;
}
} else {
#if defined(LMP_SIMD_COMPILER)
#pragma vector aligned
#pragma ivdep
#endif
for (int jj = 0; jj < jnum; jj++) {
const int joriginal = jlist[jj];
const int j = joriginal & NEIGHMASK;
int addme = 1;
if (j < nlocal) {
if (i > j) addme = 0;
} else {
if (fabs(x[j].z-ztmp) > delta) {
if (x[j].z < ztmp) addme = 0;
} else if (fabs(x[j].y-ytmp) > delta) {
if (x[j].y < ytmp) addme = 0;
} else {
if (x[j].x < xtmp) addme = 0;
}
}
if (addme)
neighptr[n++] = joriginal;
}
}
ilist[ii] = i;
firstneigh[i] = neighptr;
@ -203,7 +233,7 @@ void NPairHalffullNewtonIntel::build_t3(NeighList *list, int *numhalf)
void NPairHalffullNewtonIntel::build(NeighList *list)
{
if (_fix->three_body_neighbor() == 0) {
if (_fix->three_body_neighbor() == 0 || domain->triclinic) {
if (_fix->precision() == FixIntel::PREC_MODE_MIXED)
build_t(list, _fix->get_mixed_buffers());
else if (_fix->precision() == FixIntel::PREC_MODE_DOUBLE)

41
src/INTEL/npair_halffull_newton_trim_intel.cpp
View File

@ -20,7 +20,9 @@
#include "atom.h"
#include "comm.h"
#include "domain.h"
#include "error.h"
#include "force.h"
#include "modify.h"
#include "my_page.h"
#include "neigh_list.h"
@ -57,6 +59,8 @@ void NPairHalffullNewtonTrimIntel::build_t(NeighList *list,
const int ** _noalias const firstneigh_full = (const int ** const)list->listfull->firstneigh; // NOLINT
const flt_t cutsq_custom = cutoff_custom * cutoff_custom;
const double delta = 0.01 * force->angstrom;
const int triclinic = domain->triclinic;
#if defined(_OPENMP)
#pragma omp parallel
@ -84,6 +88,7 @@ void NPairHalffullNewtonTrimIntel::build_t(NeighList *list,
const int * _noalias const jlist = firstneigh_full[i];
const int jnum = numneigh_full[i];
if (!triclinic) {
#if defined(LMP_SIMD_COMPILER)
#pragma vector aligned
#pragma ivdep
@ -114,6 +119,40 @@ void NPairHalffullNewtonTrimIntel::build_t(NeighList *list,
if (addme)
neighptr[n++] = joriginal;
}
} else {
#if defined(LMP_SIMD_COMPILER)
#pragma vector aligned
#pragma ivdep
#endif
for (int jj = 0; jj < jnum; jj++) {
const int joriginal = jlist[jj];
const int j = joriginal & NEIGHMASK;
int addme = 1;
if (j < nlocal) {
if (i > j) addme = 0;
} else {
if (fabs(x[j].z-ztmp) > delta) {
if (x[j].z < ztmp) addme = 0;
} else if (fabs(x[j].y-ytmp) > delta) {
if (x[j].y < ytmp) addme = 0;
} else {
if (x[j].x < xtmp) addme = 0;
}
}
// trim to shorter cutoff
const flt_t delx = xtmp - x[j].x;
const flt_t dely = ytmp - x[j].y;
const flt_t delz = ztmp - x[j].z;
const flt_t rsq = delx * delx + dely * dely + delz * delz;
if (rsq > cutsq_custom) addme = 0;
if (addme)
neighptr[n++] = joriginal;
}
}
ilist[ii] = i;
firstneigh[i] = neighptr;
@ -235,7 +274,7 @@ void NPairHalffullNewtonTrimIntel::build_t3(NeighList *list, int *numhalf,
void NPairHalffullNewtonTrimIntel::build(NeighList *list)
{
if (_fix->three_body_neighbor() == 0) {
if (_fix->three_body_neighbor() == 0 || domain->triclinic) {
if (_fix->precision() == FixIntel::PREC_MODE_MIXED)
build_t(list, _fix->get_mixed_buffers());
else if (_fix->precision() == FixIntel::PREC_MODE_DOUBLE)

28
src/INTEL/npair_intel.cpp
View File

@ -204,6 +204,8 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
}
const int special_bound = sb;
const double delta = 0.01 * force->angstrom;
#ifdef _LMP_INTEL_OFFLOAD
const int * _noalias const binhead = this->binhead;
const int * _noalias const bins = this->bins;
@ -229,7 +231,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
in(ncache_stride,maxnbors,nthreads,maxspecial,nstencil,e_nall,offload) \
in(offload_end,separate_buffers,astart,aend,nlocal,molecular) \
in(ntypes,xperiodic,yperiodic,zperiodic,xprd_half,yprd_half,zprd_half) \
in(pack_width,special_bound) \
in(pack_width,special_bound,delta) \
out(overflow:length(5) alloc_if(0) free_if(0)) \
out(timer_compute:length(1) alloc_if(0) free_if(0)) \
signal(tag)
@ -331,7 +333,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
const flt_t ztmp = x[i].z;
const int itype = x[i].w;
tagint itag;
if (THREE) itag = tag[i];
if (THREE || (TRI && !FULL)) itag = tag[i];
const int ioffset = ntypes * itype;
const int ibin = atombin[i];
@ -365,7 +367,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
ty[u] = x[j].y;
tz[u] = x[j].z;
tjtype[u] = x[j].w;
if (THREE) ttag[u] = tag[j];
if (THREE || (TRI && !FULL)) ttag[u] = tag[j];
}
if (FULL == 0 && TRI != 1) {
@ -486,6 +488,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
// Triclinic
if (TRI) {
if (FULL) {
if (tz[u] < ztmp) addme = 0;
if (tz[u] == ztmp) {
if (ty[u] < ytmp) addme = 0;
@ -494,6 +497,25 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
if (tx[u] == xtmp && j <= i) addme = 0;
}
}
} else {
if (j <= i) addme = 0;
if (j >= nlocal) {
const tagint jtag = ttag[u];
if (itag > jtag) {
if ((itag+jtag) % 2 == 0) addme = 0;
} else if (itag < jtag) {
if ((itag+jtag) % 2 == 1) addme = 0;
} else {
if (fabs(tz[u]-ztmp) > delta) {
if (tz[u] < ztmp) addme = 0;
} else if (fabs(ty[u]-ytmp) > delta) {
if (ty[u] < ytmp) addme = 0;
} else {
if (tx[u] < xtmp) addme = 0;
}
}
}
}
}
// offload ghost check

Some files were not shown because too many files have changed in this diff Show More