diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 60fe82d86c..62e7186360 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -108,7 +108,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers. Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub. -Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assesment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). +Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes. The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer. If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork. diff --git a/doc/github-development-workflow.md b/doc/github-development-workflow.md index a7d41dd32a..c34a67dfcf 100644 --- a/doc/github-development-workflow.md +++ b/doc/github-development-workflow.md @@ -95,7 +95,7 @@ on the pull request discussion page on GitHub, so that other developers can later review the entire discussion after the fact and understand the rationale behind choices made. Exceptions to this policy are technical discussions, that are centered on tools or policies themselves -(git, github, c++) rather than on the content of the pull request. +(git, GitHub, c++) rather than on the content of the pull request. ### Checklist for Pull Requests diff --git a/doc/src/Errors_warnings.rst b/doc/src/Errors_warnings.rst index 306c9b7b31..4f29fad9dd 100644 --- a/doc/src/Errors_warnings.rst +++ b/doc/src/Errors_warnings.rst @@ -119,7 +119,6 @@ Doc page with :doc:`ERROR messages ` :doc:`pair style zero ` with a suitable cutoff or use :doc:`comm_modify cutoff `. *Communication cutoff is shorter than a bond length based estimate. This may lead to errors.* - Since LAMMPS stores topology data with individual atoms, all atoms comprising a bond, angle, dihedral or improper must be present on any sub-domain that "owns" the atom with the information, either as a diff --git a/doc/src/Howto_github.rst b/doc/src/Howto_github.rst index 63cb8945e8..311d716f18 100644 --- a/doc/src/Howto_github.rst +++ b/doc/src/Howto_github.rst @@ -72,7 +72,7 @@ explained in more detail here: `feature branch workflow ` -command. At some point we plan to allow regoin surfaces to be used as +command. At some point we plan to allow region surfaces to be used as frictional walls, as well as triangulated surfaces. diff --git a/doc/src/atc_output.rst b/doc/src/atc_output.rst index 3fb1491be1..5003817daa 100644 --- a/doc/src/atc_output.rst +++ b/doc/src/atc_output.rst @@ -14,7 +14,7 @@ Syntax * AtC fixID = ID of :doc:`fix atc ` instance * *output* or *output index* = name of the AtC sub-command * filename_prefix = prefix for data files (for *output*) -* frequency = frequency of output in time-steps (for *output*) +* frequency = frequency of output in timesteps (for *output*) * optional keywords for *output*: - text = creates text output of index, step and nodal variable values for unique nodes diff --git a/doc/src/fix_filter_corotate.rst b/doc/src/fix_filter_corotate.rst index ee608e5361..e33fc0ac4a 100644 --- a/doc/src/fix_filter_corotate.rst +++ b/doc/src/fix_filter_corotate.rst @@ -56,7 +56,7 @@ is slightly modified only for the computation of long-range forces. A good cluster decomposition constitutes in building clusters which contain the fastest covalent bonds inside clusters. -If the clusters are chosen suitably, the :doc:`run_style respa ` is stable for outer time-steps of at least 8fs. +If the clusters are chosen suitably, the :doc:`run_style respa ` is stable for outer timesteps of at least 8fs. ---------- diff --git a/doc/src/fix_rx.rst b/doc/src/fix_rx.rst index c1a1d0950c..9eab06ffad 100644 --- a/doc/src/fix_rx.rst +++ b/doc/src/fix_rx.rst @@ -90,10 +90,10 @@ accepted, *h* is increased by a proportional amount, and the next ODE step is be Otherwise, *h* is shrunk and the ODE step is repeated. Run-time diagnostics are available for the rkf45 ODE solver. The frequency -(in time-steps) that diagnostics are reported is controlled by the last (optional) +(in timesteps) that diagnostics are reported is controlled by the last (optional) 12th argument. A negative frequency means that diagnostics are reported once at the end of each run. A positive value N means that the diagnostics are reported once -per N time-steps. +per N timesteps. The diagnostics report the average # of integrator steps and RHS function evaluations and run-time per ODE as well as the average/RMS/min/max per process. If the diff --git a/doc/utils/sphinx-config/false_positives.txt b/doc/utils/sphinx-config/false_positives.txt index 3ef0b904eb..6843118686 100644 --- a/doc/utils/sphinx-config/false_positives.txt +++ b/doc/utils/sphinx-config/false_positives.txt @@ -2614,7 +2614,6 @@ Ree refactored refactoring reflectionstyle -regoin Reinders reinit relaxbox diff --git a/lib/kokkos/README.md b/lib/kokkos/README.md index a08d238e5d..f820b7be10 100644 --- a/lib/kokkos/README.md +++ b/lib/kokkos/README.md @@ -18,7 +18,7 @@ profiling and debugging tools (https://github.com/kokkos/kokkos-tools). A programming guide can be found on the Wiki, the API reference is under development. -For questions find us on Slack: https://kokkosteam.slack.com or open a github issue. +For questions find us on Slack: https://kokkosteam.slack.com or open a GitHub issue. For non-public questions send an email to crtrott(at)sandia.gov @@ -44,7 +44,7 @@ To learn more about Kokkos consider watching one of our presentations: We are open and try to encourage contributions from external developers. To do so please first open an issue describing the contribution and then issue a pull request against the develop branch. For larger features it may be good -to get guidance from the core development team first through the github issue. +to get guidance from the core development team first through the GitHub issue. Note that Kokkos Core is licensed under standard 3-clause BSD terms of use. Which means contributing to Kokkos allows anyone else to use your contributions diff --git a/lib/quip/README b/lib/quip/README index e6cc3903bd..5e737db11d 100644 --- a/lib/quip/README +++ b/lib/quip/README @@ -17,7 +17,7 @@ Building LAMMPS with QUIP support: 1) Building QUIP 1.1) Obtaining QUIP -The most current release of QUIP can be obtained from github: +The most current release of QUIP can be obtained from GitHub: $ git clone https://github.com/libAtoms/QUIP.git QUIP diff --git a/lib/scafacos/README b/lib/scafacos/README index 86335d9f98..c8181ac7ae 100644 --- a/lib/scafacos/README +++ b/lib/scafacos/README @@ -3,7 +3,7 @@ is required to use the KSPACE scafacos and its kspace_style scafacos command in a LAMMPS input script. The ScaFaCoS library is available at http://scafacos.de or -on github at https://github.com/scafacos, the library was +on GitHub at https://github.com/scafacos, the library was developed by a consortium of different universities in Germany (Bonn, Chemnitz, Stuttgart, Wuppertal) and the Research Centre Juelich (Juelich Supercomputing Centre). diff --git a/src/USER-PLUMED/README b/src/USER-PLUMED/README index f46b2cd9bd..31910bc951 100644 --- a/src/USER-PLUMED/README +++ b/src/USER-PLUMED/README @@ -30,7 +30,7 @@ even if PLUMED is not in the path if as long as the input does not contain a fix plumed command. If you wish to statically link PLUMED you must download PLUMED to the /lib/plumed directory before compiling LAMMPS. You can -download a tar ball into that directory or you can clone the plumed2 repository from github there. Once you have created a +download a tar ball into that directory or you can clone the plumed2 repository from GitHub there. Once you have created a directory containing a distribution of PLUMED within /lib/plumed you then must build PLUMED within that directory by issuing the usual commands. It is worth noting that we have provided a script that will download and build PLUMED for you with a minimal set of options. To run this script you need to issue the following command: