Project 3 - Update external source code and optionally convert to plugins
Overview and Motivation
External vs. internal source code
The LAMMPS package is designed to be easily extended and modified. This allows LAMMPS users to develop custom features that can be easily added to the LAMMPS code base. In many cases these features are contributed to the LAMMPS distribution, so they can be used by other LAMMPS users. These may be individual styles with just a single pair of sources or entire USER packages. The developers of such features or packages may choose to not include those but rather maintain them on their own. Yet sometimes they do not have sufficient time to follow the LAMMPS development or change the direction of their research or their position (or both) and then “abandon” their work.
At the same time, the LAMMPS source code is actively developed and thus continuously changing. Most of these changes are done in a fashion that preserve backward compatibility in both, syntax and semantics, but this is not always possible. With the decision to require C++11 as the minimum supported C++ standard also a decision was made to somewhat move away from the original “C with classes” code design premise and instead modernize some of the internal code constructs and make use of more C++ features which often leads to simpler, more readable code, and more code reuse.
Updating sources
Most importantly two namespaces platform and utils were added
containing platform neutral variants of functionality that may require
different implementations on different platforms and containing utility
functions with frequently used functionality and variants that have
better checking for valid arguments than their corresponding
counterparts from the C library. Some of these functions existed before
but were implemented as members of some classes.
As a consequence of these changes, externally developed and maintained source code for LAMMPS may produce compilation errors when added to a current version of LAMMPS, it may behave differently, cause segmentation faults, or invalid numbers. Currently known differences requiring changes are listed on this page in the LAMMPS manual. Additional useful information is here.
When updating source code for LAMMPS it is also beneficial to update it according to the LAMMPS programming style guide. This would make it easier to maintain and to keep up-to-date. It would be required when submitting for inclusion into the distribution.
Plugins
As an increasing number of LAMMPS users takes advantage of pre-build and
pre-packaged LAMMMPS
executables, either as part of
their operating systems or through one of a number of packaging systems,
they are cut off from using features that are provided through packages
with pre-compiled LAMMPS binaries. Through the plugin
command, however, LAMMPS user can
load additional functionality at run time provided it has been compiled
as a plugin. This usually requires writing a plugin
loader that is compiled
against the LAMMPS headers and with the external sources. It is also
possible to load plugins plugins automatically when LAMMPS is started,
if they are found in a folder pointed to by the LAMMPS_PLUGIN_PATH
environment variable.
The LAMMPS developers have started a git repository on GitHub collecting the sources for building such plugins for external LAMMPS packages at: https://github.com/lammps/lammps-plugins
Tasks
-
Identify individual external LAMMPS styles (e.g. pair styles, fix styles, etc.) or externally maintained and distributed LAMMPS packages (aka USER packages) that need to be ported to become compatible with the latest LAMMPS version
-
For each style/package identify which LAMMPS version they are compatible with and create a reference binary and some relevant example inputs that allow to use the features and document the results.
-
Start or clone a repository with the sources/package or add them to https://github.com/lammps/lammps-plugins
-
Forward port the code based on the information provided in the manual and validate it against the previous reference output.
-
If desired, write a suitable plugin loader based on the information provided in the manual
-
Apply additional modernization changes, if desired.
-
Document any additional changes required for porting in the manual.
Examples
Please see the examples provided in the manual