LAMMPS: a classical molecular dynamics engine you build yourself

What LAMMPS solves, and who ends up using it

LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel Simulator. The README describes it as a classical molecular dynamics simulation code designed to run efficiently on parallel computers, developed at Sandia National Laboratories with DOE funding. That sentence is the whole positioning: it is a simulation engine, not a modelling application. You describe a system in a script, hand it to the binary, and get trajectories and thermodynamic output back.

The audience follows from that. Someone studying atomic or molecular motion at a scale where a single core is not enough, who is comfortable writing input decks and building software from source. The repository layout reflects this: src/ holds the C++ sources, potentials/ holds interatomic potential files, examples/ holds input decks organised by physics domain, and tools/ holds pre- and post-processing utilities. There is no GUI directory and no installer directory.

The mechanism: packages, potentials and a scripted input deck

LAMMPS is not one monolithic binary. The top-level layout separates a small core from optional functionality: src/ contains the source files, lib/ holds additional provided or external libraries, third_party/ carries copies of third-party software bundled with LAMMPS, and cmake/ holds the build files. Functionality that is not always needed lives behind packages you enable at build time. This is the central design decision, and it has consequences: a build is a configuration choice, and two LAMMPS binaries built from the same commit can differ in what they can simulate.

A run is driven by an input script naming commands. The README links a table of available commands and a set of short tutorials and HowTo discussions, which is where the actual command vocabulary lives. Potentials are data files rather than compiled-in constants, which is why potentials/ sits at the repository root as a first-class directory. The examples/ tree is organised by domain (ASPHERE, ELASTIC, KAPPA, QUANTUM, SPIN, VISCOSITY and many more), so a new user can start from an input deck that already runs rather than from a blank file.

Installing LAMMPS and running a first input deck

The README does not give a one-line install command. It points to https://docs.lammps.org/Build.html as the page explaining how to build LAMMPS, and the repository ships cmake/ build files for that purpose. Because the build is package-driven, the practical first step is deciding which packages your simulation needs before you configure anything.

The README does not spell out a configure invocation, so the exact CMake flags are not something this article can quote from the repository. What the repository does tell you is where the build files live (cmake/) and where the instructions are (the Build page of the manual). Follow that page rather than a flag list copied from somewhere else, because the packages you enable are the part that has to match your simulation.

Once the binary exists, a run is an input script passed on the command line. The README points to https://docs.lammps.org/Run_head.html for how to run LAMMPS, and the examples/ directory supplies ready-made decks by domain. Those decks are the concrete starting point: pick the domain closest to your problem and read the input file before writing your own.

The process reads the script, sets up the system, and writes output to the log file and any dump files the script requests. If it exits with an error, the README points at https://docs.lammps.org/Errors.html for interpreting and debugging errors, which is the page to keep open.

The documentation can also be generated locally rather than read on the web. The README gives these two commands, run from the doc/ directory:

cd doc
make html

That creates HTML pages in doc/html. The README also documents make pdf, which produces Manual.pdf.

Where LAMMPS is the wrong tool

The build model is the first limitation. Because optional functionality sits behind packages enabled at configure time, a binary built without the package you need will not simply warn you; it will not have the feature. If your workflow depends on a specific potential or a specific accelerated path, that has to be settled before the build, not after.

Second, LAMMPS is classical molecular dynamics. The README describes it as a classical MD code, and the examples/QUANTUM directory exists because quantum treatments are a separate, coupled concern rather than the default mode. If your problem is inherently electronic-structure-first, the engine is the wrong layer.

Third, the interface is a script and a command line. There is no GUI in the repository layout, and the README's getting-started path runs through documentation pages rather than a wizard. Anyone expecting to load a structure, drag atoms and press run will be working against the tool rather than with it. The python/ directory provides a Python module and fortran/ provides a Fortran 2003 module, so embedding LAMMPS in a larger workflow is supported, but that is a programming route, not a graphical one.

Finally, the repository ships source. The README's list of top-level entries contains no installers or platform binaries, so a Windows user following the repository alone is looking at building from source.

How LAMMPS differs from GROMACS and OpenMM

The honest comparison is about scope, not speed. GROMACS and OpenMM are also classical MD engines, and both target biomolecular simulation with a comparatively fixed set of force fields and a strong emphasis on making a standard workflow easy to start. LAMMPS takes the opposite bet: a smaller core with packages you switch on, and potentials supplied as files under potentials/ rather than baked into the program.

That difference shows up in the first hour of use. With a fixed-scope engine you typically pick a force field and go. With LAMMPS you first decide which packages to compile in, then which potential file to point at, then write or adapt an input deck. The examples/ tree softens this considerably, since decks are grouped by physics domain, but the configuration step remains yours.

The payoff is breadth. The examples directory alone spans granular media, elasticity, thermal conductivity, quantum coupling, spin dynamics, viscosity and more, which is a wider remit than a biomolecular-first engine normally carries. If your work sits inside standard biomolecular force fields, the fixed-scope tools will get you running sooner. If it sits outside them, the package model is the reason LAMMPS can cover it at all.

Maintenance, releases and what the GPL-2.0 licence means in practice

The repository is not archived, and the last push was on 2026-09-23. Releases follow two tracks visible in the release list: stable releases with numbered updates, such as stable_22Jul2025_update6, and candidate patches such as patch_2Sep2026, described as a stable release candidate. That pattern tells you how to plan upgrades. If you need a fixed target, pin to a stable release and take its updates; if you want upcoming changes early, the candidate track is where they appear first.

Upgrade cost is dominated by the build, not the download. Because packages are enabled at configure time, a new release can change what a package requires or how it is named, and your configure line is the thing that breaks. Keeping the configure invocation in version control, rather than in a shell history, is the difference between a five-minute rebuild and an afternoon of guessing.

LAMMPS is distributed under the GNU General Public License version 2, and the README states the copyright is held by Sandia Corporation under a DOE contract. GPL-2.0 is a copyleft licence, so if you plan to redistribute a modified binary, the licence terms apply to what you distribute. This is not legal advice; if your project ships LAMMPS inside a product, read LICENSE and take your own advice on the obligations.

Citation is a separate obligation from licensing, and the repository makes it easy to satisfy: CITATION.cff sits at the top level with citation information in CFF format.

Editorial conclusion

Adopt LAMMPS if you need scripted, parallel classical molecular dynamics and you are willing to compile it yourself: the CMake build in cmake/ with the packages you need is the normal path, and the doc/ directory lets you generate the manual locally. Do not adopt it if you want a point-and-click modelling environment or a Windows binary you can double-click; the README points at docs.lammps.org for building and running, and the repository ships source, not an installer. Before committing, verify that the interatomic potential you need exists under potentials/ or in the package you enable, and check whether the GPU path you intend to use is present in the build you configure.

Frequently asked questions

Official sources

1. lammps/lammps on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases