NequIP: E(3)-Equivariant Interatomic Potentials in PyTorch

The gap NequIP fills: potentials that respect rotation without augmenting data

Classical force fields are fast and transfer poorly. Plain neural network potentials are more flexible but treat atomic environments as unstructured point sets, so a rotated configuration looks like a different input unless you augment the training set with rotated copies. NequIP's premise, stated in the original Nature Communications paper cited in the README, is that building E(3) equivariance into the network architecture rather than learning it from augmented data gives better accuracy per training sample. The target audience is therefore narrow and specific: researchers who have a few hundred to a few thousand DFT-labelled configurations of a material or molecule and want a potential that generalizes across the configurations they did not label. It is not a tool for someone who wants to run an MD simulation out of the box on a system nobody has parameterized, although the foundation potentials at nequip.net narrow that gap considerably for elements they cover.

What is actually inside the package: a framework, not a single model

The README describes NequIP as a software framework for building E(3)-equivariant interatomic potentials, and the extension-package section makes the architecture explicit: the package provides the training loop, data pipeline, and inference machinery, while specific architectures are shipped as separate packages. The clearest example given is allegro, which implements the strictly local Allegro architecture from a separate Nature Communications paper. That distinction matters when you read benchmark tables. A number reported for Allegro is a number for the allegro extension package, not for the core NequIP model, and the two make different locality assumptions. The core repository also hosts the foundation potential family, which the README says covers most of the periodic table and can be used directly or fine-tuned. The data flow implied by the documentation is conventional for this class of code: configurations are converted into a dataset, a model is trained against energies and forces, and the trained model is then compiled for inference and exported to a calculator or a pair style. The compiled inference step is presented as a first-class part of the workflow rather than an optional optimization, which is a design choice worth noting.

Getting it running: install, train, compile, deploy

The README does not inline installation commands, pointing instead to the Read the Docs site and to a Colab tutorial notebook that the project says runs entirely on Google Colab's cloud VM with nothing installed locally. That notebook is the honest starting point, because it sidesteps the compilation and GPU-kernel setup that the highlighted-features list assumes. The package is distributed on PyPI as nequip, so a pip install is the expected entry point, but the acceleration features named in the README (compiled training, compiled inference, multi-GPU training via DDP, and GPU kernel modifiers through OpenEquivariance and CuEquivariance) each carry their own setup requirements documented in separate guide pages. CuEquivariance is labelled alpha in the README, which is a fair warning that the NVIDIA kernel path is not the stable one. Deployment to simulation engines goes through two documented routes: an ASE calculator integration, and LAMMPS integrations through the pair styles in pair_nequip_allegro or through the LAMMPS ML-IAP integration. Those are different interfaces with different build steps, and the README treats them as separate pages rather than variations of one thing. The one config fact stated plainly in the README is the breaking change: a major backwards-incompatible update to the nequip package landed on 23 April 2025 as v0.7.0, and v0.6.2 remains available in GitHub Releases and on PyPI for existing config files.

The v0.7.0 break is the real adoption cost

Most projects with a config-driven training loop accumulate small deprecations. NequIP's README flags the opposite: a single release that invalidates the previous config format, with an upgrading guide at docs/guide/upgrading.md and the old version kept alive rather than patched forward. For a group with a working v0.6.2 training pipeline, that means a choice between freezing on an unmaintained branch and rewriting configs against a schema that has since moved through v0.18.0 and v0.19.0. The release cadence shown here (v0.18.0 in May 2026, v0.19.0 in July 2026, v0.19.1 in September 2026) suggests the schema is still moving. Anyone planning a multi-year project should assume at least one more migration and budget for it. The other cost is the compiled inference path. Compilation is what makes the potentials fast enough for production MD, but it ties a trained model to a specific hardware and software combination. A model compiled for one GPU generation or one PyTorch build is not automatically portable to another, and the README does not claim otherwise. Treat the compiled artifact as a build product to be regenerated, not as a portable weight file.

Where it is the wrong tool

NequIP trains on energies and forces and produces a potential energy surface. If the quantity you care about is a band gap, a redox potential, an excited-state lifetime, or anything else that is not the ground-state energy as a function of nuclear coordinates, this framework has nothing for you, and no amount of fine-tuning will change that. The second wrong-tool case is small data in the literal sense. Equivariance improves sample efficiency relative to non-equivariant architectures, but it does not eliminate the need for labelled configurations that sample the relevant configurational space. A training set that never visits a distorted geometry will not produce a potential that handles it, equivariant or not. Third, if your workflow is a single-point energy evaluation inside an existing Python script, the compilation and export machinery is overhead you will pay for and not use; the ASE calculator route exists, but the project's own framing puts compiled inference at the center of the workflow. Finally, the documentation is spread across Read the Docs pages, a Colab notebook, a separate foundation-potential site, and extension repositories. There is no single file that tells you the whole story, and the README is a signpost rather than a manual.

Alternatives and the actual difference in approach

The nearest comparison is MACE, another equivariant message-passing potential with its own training code and its own pre-trained model family. Both descend from the same line of work, and the practical difference for an adopter is packaging and ecosystem rather than the underlying equivariance argument. NequIP's distinguishing structural choice is the extension-package model: the core framework is deliberately architecture-agnostic, and Allegro is shipped separately as a strictly local alternative. That means a NequIP user can switch locality assumptions without switching training infrastructure, which is a real advantage if you are comparing architectures on one dataset. The cost is that you now depend on two repositories staying in sync. A second alternative is a descriptor-based approach in the ACE or SOAP family, where a fixed, physically motivated descriptor is combined with a linear or kernel model. Those methods are typically easier to fit and easier to interpret, and they do not require a compilation step, but they generally need more reference data to reach the same accuracy on the same system, which is the tradeoff the equivariant architecture is designed to avoid. Choosing between them is a question about how many DFT calculations you can afford, not about which code is better maintained.

Licence and maintenance expectations

The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is permissive and imposes no copyleft obligation on models you train or on code you write around it. Two caveats are worth stating without drifting into legal advice. First, the README asks that any use of the software acknowledge and link to the repository, and it lists four papers to cite depending on what you use: the framework paper for general use, the foundation potentials paper if you use any pre-trained model from nequip.net or matbench-discovery, the original NequIP paper, and the computational scaling paper for optimized LAMMPS MD. Citation is not a licence condition under MIT, but it is an explicit request and academic users should honour it. Second, the MIT grant covers the nequip package. The extension packages and the GPU kernel libraries the README links to (OpenEquivariance, CuEquivariance) are separate projects with their own licences, and a commercial deployment that pulls in CuEquivariance needs to check that licence independently. On maintenance: the project is not archived, the last push recorded here is 1 September 2026, and releases have been roughly every six to ten weeks through 2026, so the codebase is active. The maintenance cost that lands on you is not abandonment risk, it is migration cost, and the v0.7.0 break is the evidence for that.

Editorial conclusion

Adopt NequIP if you are training or fine-tuning an equivariant potential on your own DFT data and you can commit to the v0.7.0-and-later config format, since anything written against v0.6.2 configs will not load without a rewrite. Do not adopt it if your target property is not a potential energy surface, or if you need a drop-in ASE calculator with no compilation step. Before committing, verify three things against the docs: that the current config schema matches your existing YAML, that a compiled model artifact exists for your hardware and PyTorch build, and that the LAMMPS pair style you intend to use is the one your workflow already links against. The foundation potentials at nequip.net are the fastest way to find out whether the accuracy is adequate before you train anything.

Official sources

1. License: MIT
2. mir-group/nequip on GitHub
3. Project website
4. README
5. Releases