Minor changes to the style/contribute modify pages
This commit is contained in:
@ -23,7 +23,6 @@ General howto
|
||||
Howto_library
|
||||
Howto_couple
|
||||
Howto_mdi
|
||||
Howto_bpm
|
||||
Howto_broken_bonds
|
||||
|
||||
Settings howto
|
||||
@ -83,6 +82,7 @@ Packages howto
|
||||
Howto_spherical
|
||||
Howto_granular
|
||||
Howto_body
|
||||
Howto_bpm
|
||||
Howto_polarizable
|
||||
Howto_coreshell
|
||||
Howto_drude
|
||||
|
||||
@ -38,8 +38,8 @@ Packages versus individual files
|
||||
The remainder of this chapter describes how to add new "style" files of
|
||||
various kinds to LAMMPS. Packages are simply collections of one or more
|
||||
such new class files which are invoked as a new style within a LAMMPS
|
||||
input script. In some cases also collections of supporting functions or
|
||||
classes are included as separate files in a package, especially when
|
||||
input script. In some cases collections of supporting functions or
|
||||
classes are also included as separate files in a package, especially when
|
||||
they can be shared between multiple styles. If designed correctly, these
|
||||
additions typically do not require any changes to the core code of
|
||||
LAMMPS; they are simply add-on files that are compiled with the rest of
|
||||
@ -88,8 +88,8 @@ Once you have prepared everything, see the :doc:`LAMMPS GitHub Tutorial
|
||||
new files through a GitHub pull request yourself. If you are unable or
|
||||
unwilling to submit via GitHub yourself, you may also submit patch files
|
||||
or full files to the LAMMPS developers and ask them to submit a pull
|
||||
request on GitHub on your behalf. Then create a gzipped tar file of
|
||||
all changed or added files or a corresponding patch file using
|
||||
request on GitHub on your behalf. If this is the case, create a gzipped
|
||||
tar file of all new or changed files or a corresponding patch file using
|
||||
'diff -u' or 'diff -c' format and compress it with gzip. Please only
|
||||
use gzip compression, as this works well and is available on all platforms.
|
||||
|
||||
|
||||
@ -40,13 +40,14 @@ conditions. This is the GNU public license in version 2 (not 3 or later)
|
||||
for the publicly distributed versions, e.g. on the LAMMPS homepage or on
|
||||
GitHub. On request we also make a version of LAMMPS available under
|
||||
LGPL 2.1 terms; this will usually be the latest available or a previous
|
||||
stable version with a few LGPL 2.1 incompatible files removed.
|
||||
stable version with a few LGPL 2.1 incompatible files removed. More details
|
||||
are found on the :doc:`LAMMPS open-source license page <Intro_opensource>`.
|
||||
|
||||
Your new source files should have the LAMMPS copyright, GPL notice, and
|
||||
your name and email address at the top, like other user-contributed
|
||||
LAMMPS source files.
|
||||
|
||||
Contributions may be under a different license for long as that
|
||||
Contributions may be under a different license as long as that
|
||||
license does not conflict with the aforementioned terms. Contributions
|
||||
that use code with a conflicting license can be split into two parts:
|
||||
|
||||
@ -58,7 +59,7 @@ that use code with a conflicting license can be split into two parts:
|
||||
Please note, that this split licensed mode may complicate including the
|
||||
contribution in binary packages.
|
||||
|
||||
Using Pull Requests on GitHub (preferred)
|
||||
Using pull requests on GitHub (preferred)
|
||||
-----------------------------------------
|
||||
|
||||
All contributions to LAMMPS are processed as pull requests on GitHub
|
||||
@ -71,7 +72,7 @@ depends on the amount of time required to prepare the pull request and
|
||||
free time available by the LAMMPS developer in question to spend on this
|
||||
task.
|
||||
|
||||
Integration Testing (strict)
|
||||
Integration testing (strict)
|
||||
----------------------------
|
||||
|
||||
Contributed code, like all pull requests, must pass the automated
|
||||
@ -159,7 +160,7 @@ decks.
|
||||
similar is acceptable when used to avoid unwanted domain decomposition
|
||||
of empty volumes).
|
||||
|
||||
- outside of the log files no generated output should be included
|
||||
- outside of the log files, no generated output should be included
|
||||
|
||||
- custom thermo_style settings may not include output measuring CPU or other time
|
||||
as that makes comparing the thermo output between different runs more complicated.
|
||||
@ -169,7 +170,7 @@ decks.
|
||||
|
||||
- the total file size of all the inputs and outputs should be small
|
||||
|
||||
- where possible potential files from the "potentials" folder or data
|
||||
- where possible, potential files from the "potentials" folder or data
|
||||
file from other folders should be re-used through symbolic links
|
||||
|
||||
Howto document (optional)
|
||||
@ -187,7 +188,7 @@ your documentation, README files and examples, and the easier you make
|
||||
it for people to get started, the more likely it is that users will try
|
||||
out your new feature.
|
||||
|
||||
Programming Style Requirements (varied)
|
||||
Programming style requirements (varied)
|
||||
---------------------------------------
|
||||
|
||||
The LAMMPS developers aim to employ a consistent programming style and
|
||||
@ -231,7 +232,7 @@ list all non-conforming lines. By adding the `-f` flag to the command
|
||||
line, they will modify the flagged files to try removing the detected
|
||||
issues.
|
||||
|
||||
Indentation and Placement of Braces (strongly preferred)
|
||||
Indentation and placement of braces (strongly preferred)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
LAMMPS uses 2 characters per indentation level and lines should be
|
||||
@ -240,7 +241,7 @@ kept within 100 characters wide.
|
||||
For new files added to the "src" tree, a `clang-format
|
||||
<https://clang.llvm.org/docs/ClangFormat.html>`_ configuration file is
|
||||
provided under the name `.clang-format`. This file is compatible with
|
||||
clang-format version 8 and later. With that file present files can be
|
||||
clang-format version 8 and later. With that file present, files can be
|
||||
reformatted according to the configuration with a command like:
|
||||
`clang-format -i new-file.cpp`. Ideally, this is done while writing the
|
||||
code or before a pull request is submitted. Blocks of code where the
|
||||
@ -302,7 +303,7 @@ The core of LAMMPS is written in C++11 in a style that can be mostly
|
||||
described as "C with classes". Advanced C++ features like operator
|
||||
overloading or excessive use of templates are avoided with the intent to
|
||||
keep the code readable to programmers that have limited C++ programming
|
||||
experience. C++ constructs are acceptable when they help improving the
|
||||
experience. C++ constructs are acceptable when they help improve the
|
||||
readability and reliability of the code, e.g. when using the
|
||||
`std::string` class instead of manipulating pointers and calling the
|
||||
string functions of the C library. In addition a collection of
|
||||
@ -313,7 +314,7 @@ portability are provided.
|
||||
|
||||
Included Fortran code has to be compatible with the Fortran 2003
|
||||
standard. Python code must be compatible with Python 3.5. Large parts
|
||||
or LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
|
||||
of LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
|
||||
compatible with Python 2.7. Compatibility with Python 2.7 is
|
||||
desirable, but compatibility with Python 3.5 is **required**.
|
||||
|
||||
@ -432,7 +433,7 @@ you are uncertain, please ask.
|
||||
- Please use clang-format only to reformat files that you have
|
||||
contributed. For header files containing a ``SomeStyle(keyword,
|
||||
ClassName)`` macros it is required to have this macro embedded with a
|
||||
pair of ``// clang-format off``, ``// clang-format on`` commends and
|
||||
pair of ``// clang-format off``, ``// clang-format on`` comments and
|
||||
the line must be terminated with a semi-colon (;). Example:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
Reference in New Issue
Block a user