Commit a1188c03 authored by Sievers's avatar Sievers
Browse files

Merge branch 'master' of https://github.com/charlessievers/lammps into...

Merge branch 'master' of https://github.com/charlessievers/lammps into fix_numerical_differentiation
parents 7dafec17 b9ff623c
Loading
Loading
Loading
Loading
+1 −1
Original line number Diff line number Diff line
@@ -73,7 +73,7 @@ Here is a checklist of steps you need to follow to submit a single file or user
* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). As appropriate, the text files can include mathematical expressions in MathJAX markup or links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file.  For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). The text files can include mathematical expressions and symbol in ".. math::" sections or ":math:" expressions or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html`, `make pdf` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file.  For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/USER for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the *.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.

+12 −5
Original line number Diff line number Diff line
@@ -52,7 +52,13 @@ include(CheckCCompilerFlag)
include(CheckIncludeFileCXX)

if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
  set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict -std=c++11")
  set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
endif()

if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
  if(NOT ("${CMAKE_BUILD_TYPE}" STREQUAL "Debug"))
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ffast-math -ftree-vectorize -fexpensive-optimizations")
  endif()
endif()

# we require C++11
@@ -125,12 +131,12 @@ set(LAMMPS_API_DEFINES)
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE
  GRANULAR KSPACE LATTE MANYBODY MC MESSAGE MISC MOLECULE PERI POEMS QEQ
  REPLICA RIGID SHOCK SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI
  USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS
  USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESODPD USER-CGSDK USER-COLVARS
  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD USER-LB
  USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
  USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REAXC
  USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF
  USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-ADIOS)
  USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REACTION
  USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
  USER-UEF USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-ADIOS)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES})
  option(PKG_${PKG} "Build ${PKG} Package" OFF)
@@ -175,6 +181,7 @@ option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
if(BUILD_MPI)
  find_package(MPI REQUIRED)
  include_directories(${MPI_CXX_INCLUDE_PATH})
  add_definitions(-DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1)
  list(APPEND LAMMPS_LINK_LIBS ${MPI_CXX_LIBRARIES})
  option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
  if(LAMMPS_LONGLONG_TO_LONG)
+4 −4
Original line number Diff line number Diff line
@@ -95,7 +95,7 @@ OPT.
   * :doc:`eam/fs (gikot) <pair_eam>`
   * :doc:`edip (o) <pair_edip>`
   * :doc:`edip/multi <pair_edip>`
   * :doc:`edpd <pair_meso>`
   * :doc:`edpd <pair_mesodpd>`
   * :doc:`eff/cut <pair_eff>`
   * :doc:`eim (o) <pair_eim>`
   * :doc:`exp6/rx (k) <pair_exp6_rx>`
@@ -171,8 +171,8 @@ OPT.
   * :doc:`lubricate/poly (o) <pair_lubricate>`
   * :doc:`lubricateU <pair_lubricateU>`
   * :doc:`lubricateU/poly <pair_lubricateU>`
   * :doc:`mdpd <pair_meso>`
   * :doc:`mdpd/rhosum <pair_meso>`
   * :doc:`mdpd <pair_mesodpd>`
   * :doc:`mdpd/rhosum <pair_mesodpd>`
   * :doc:`meam/c <pair_meamc>`
   * :doc:`meam/spline (o) <pair_meam_spline>`
   * :doc:`meam/sw/spline <pair_meam_sw_spline>`
@@ -242,7 +242,7 @@ OPT.
   * :doc:`sw (giko) <pair_sw>`
   * :doc:`table (gko) <pair_table>`
   * :doc:`table/rx (k) <pair_table_rx>`
   * :doc:`tdpd <pair_meso>`
   * :doc:`tdpd <pair_mesodpd>`
   * :doc:`tersoff (giko) <pair_tersoff>`
   * :doc:`tersoff/mod (gko) <pair_tersoff_mod>`
   * :doc:`tersoff/mod/c (o) <pair_tersoff_mod>`
+2 −2
Original line number Diff line number Diff line
@@ -509,14 +509,14 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`

*Bond/react: Atom affected by reaction too close to template edge*
   This means an atom which changes type or connectivity during the
   reaction is too close to an 'edge' atom defined in the superimpose
   reaction is too close to an 'edge' atom defined in the map
   file. This could cause incorrect assignment of bonds, angle, etc.
   Generally, this means you must include more atoms in your templates,
   such that there are at least two atoms between each atom involved in
   the reaction and an edge atom.

*Bond/react: Fix bond/react needs ghost atoms from farther away*
   This is because a processor needs to superimpose the entire unreacted
   This is because a processor needs to map the entire unreacted
   molecule template onto simulation atoms it knows about. The
   comm\_modify cutoff command can be used to extend the communication
   range.
+11 −5
Original line number Diff line number Diff line
Building the LAMMPS manual
**************************

Depending on how you obtained LAMMPS, the doc directory has 2 or 3
sub-directories and optionally 2 PDF files and 2 e-book format files:
Depending on how you obtained LAMMPS, the doc directory has up
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
plus 2 e-book format files:


.. parsed-literal::

   src             # content files for LAMMPS documentation
   html            # HTML version of the LAMMPS manual (see html/Manual.html)
   tools           # tools and settings for building the documentation
   utils           # tools and settings for building the documentation
   docenv          # virtualenv for processing the manual sources
   doctrees        # temporary data from processing the manual
   mathjax         # code and fonts for rendering math in html
   Manual.pdf      # large PDF version of entire manual
   Developer.pdf   # small PDF with info about how LAMMPS is structured
   LAMMPS.epub     # Manual in ePUB e-book format
   LAMMPS.mobi     # Manual in MOBI e-book format
   lammps.1        # man page for the lammps command
   msi2lmp.1       # man page for the msi2lmp command

If you downloaded LAMMPS as a tarball from the web site, all these
directories and files should be included.
If you downloaded LAMMPS as a tarball from the web site, the html folder
and the PDF files should be included.

If you downloaded LAMMPS from the public git repository, then the HTML
and PDF files are not included.  Instead you need to create them, in one
Loading