ase-calculator-kit

A thin, unified ASE calculator factory for machine-learning interatomic potentials and external DFT calculators. Every call returns a standard ase.Calculator, so the rest of your ASE workflow stays unchanged.

Supported MLIP backends:

• SevenNet (installed by default)
• CHGNet
• MatterSim
• NequIP OAM
• UMA / fairchem
• MACE — must be installed in a separate virtual environment, see MACE needs its own environment

Supported DFT backends:

• VASP
• Quantum ESPRESSO (qe, espresso, quantum-espresso)

Install

pip install ase-calculator-kit

The default installation is intentionally lightweight: it pulls in ASE and PyYAML and no NNP backend, so it does not drag in torch. Each backend is an explicit extra — install only what your workflow needs:

# One backend
pip install "ase-calculator-kit[sevennet]"
pip install "ase-calculator-kit[chgnet]"
pip install "ase-calculator-kit[mattersim]"
pip install "ase-calculator-kit[nequip]"
pip install "ase-calculator-kit[uma]"

# Several selected backends
pip install "ase-calculator-kit[chgnet,mattersim]"

# Every co-installable NNP backend and the optional D3 correction
pip install "ase-calculator-kit[all]"

# D3 correction without installing every NNP backend
pip install "ase-calculator-kit[dispersion]"

⚠️ MACE is the one exception: it needs a virtual environment of its own. mace-torch pins e3nn==0.4.4, while sevenn, fairchem-core, mattersim and nequip all require e3nn>=0.5. There is no resolution that satisfies both, so mace is not part of [all], and pip install "ase-calculator-kit[all,mace]" cannot succeed.

python -m venv .venv-mace
.venv-mace/bin/pip install "ase-calculator-kit[mace]"

See MACE needs its own environment.

Missing backend packages are reported only when that calculator is requested, with the matching extra to install.

Python versions

Python 3.12 and newer. The package itself has no upper bound, but one backend currently does:

Since 0.5.4 no backend caps below 3.14. uma (and therefore all) used to be ❌ on 3.14, because fairchem-core declared requires-python = ">=3.11,<3.14" and pinned torch~=2.8.0, which has no cp314 wheels; fairchem-core 2.22.0 — the floor this release requires — lifted the cap and moved to torch~=2.13.0.

A backend that lags a Python release is left to cap itself rather than hidden behind an environment marker: pip then names the backend in the error, while a marker would make the install succeed and silently leave the backend out.

Use this import for new code:

from ase_calculator_kit import get_calculator

Usage

MLIP calculators keep the lightweight keyword API:

from ase.build import bulk
from ase_calculator_kit import get_calculator

atoms = bulk("Cu", "fcc", a=3.6)

atoms.calc = get_calculator("sevennet", model="7net-omni", modal="mpa")
print(atoms.get_potential_energy())

atoms.calc = get_calculator("chgnet", device="mps")
print(atoms.get_potential_energy())

atoms.calc = get_calculator("mattersim", model="5M")
print(atoms.get_potential_energy())

atoms.calc = get_calculator("nequip", model="L")
print(atoms.get_potential_energy())

atoms.calc = get_calculator("uma", model="uma-s-1p2p1", task="omat")
print(atoms.get_potential_energy())

In the separate MACE environment, the same call shape applies:

atoms.calc = get_calculator("mace", model="mh-1", head="omat_pbe")
print(atoms.get_potential_energy())

DFT calculators are config-only:

from ase_calculator_kit import get_calculator

atoms.calc = get_calculator("vasp", config="examples/dft/vasp_pbe_static.yaml")
atoms.calc = get_calculator("qe", config="examples/dft/qe_pbe_static.yaml")

For VASP and QE, arbitrary keyword arguments are intentionally rejected to keep calculation conditions explicit and reproducible:

get_calculator("vasp", encut=520)  # TypeError

For reproducibility, VASP configs must explicitly specify profile.command (QE additionally requires profile.pseudo_dir and pseudopotentials); environment-variable-only execution is intentionally not used by this wrapper.

Use overrides= for small dynamic changes:

atoms.calc = get_calculator(
    "vasp",
    config="examples/dft/vasp_pbe_static.yaml",
    overrides={"directory": "runs/vasp/Cu_001"},
)

Write the final merged config for auditability:

atoms.calc = get_calculator(
    "qe",
    config="examples/dft/qe_pbe_static.yaml",
    overrides={"directory": "runs/qe/Cu_001"},
    write_resolved_config=True,
)

API Reference

Calculator names

get_calculator(name, **kwargs) takes one of these names (case-insensitive); available_calculators() returns the same list at runtime.

An unknown name raises ValueError listing the valid names.

MLIP keyword arguments

All MLIP backends accept device= ("auto" by default; see Apple Silicon (MPS) support), dispersion=False, dispersion_xc=None, dispersion_damping=None, dispersion_cutoff=None, dispersion_cutoff_smoothing=None (see Dispersion), and forward any extra keywords to the underlying calculator.

DFT keyword arguments

DFT backends accept only these three; anything else raises TypeError.

Public helpers

from ase_calculator_kit import (
    attach_calculator,
    available_calculators,
    available_dft_calculators,
    available_mlip_models,
    available_models,
    get_dft_calculator,
    get_mlip_calculator,
    resolve_calculator_config,
)

available_mlip_models()     # ['chgnet', 'fairchem', 'mace', 'mattersim', 'nequip', 'sevennet', 'uma']
available_dft_calculators() # ['espresso', 'qe', 'quantum-espresso', 'vasp']
available_calculators()     # both of the above; available_models() is an alias
attach_calculator(atoms, "uma", task="omat")  # sets atoms.calc, returns atoms

Exceptions

from ase_calculator_kit import CalculatorKitError, DispersionError, MissingDependencyError

Examples

Run a CPU single point with every MLIP model/variant:

python examples/run_all_models.py
python examples/run_all_models.py --device auto
python examples/run_all_models.py --only chgnet sevennet nequip

Create DFT calculator objects from YAML without running VASP/QE:

python examples/dft/create_dft_calculator_from_config.py vasp \
  examples/dft/vasp_pbe_static.yaml

DFT YAML examples live in examples/dft.

Apple Silicon (MPS) support

Every MLIP backend was run on a single point (bulk("Cu")) with device="mps" on an Apple Silicon Mac (arm64, PyTorch 2.8, MPS available). Results:

For the MPS-supported backends, device="auto" resolves to mps on Apple Silicon when no CUDA device is present. NequIP, MACE and UMA accept only "cpu" / "cuda"; passing device="mps" raises a clear ValueError, and device="auto" falls back to cpu.

Choosing an MLIP Variant

SevenNet model

atoms.calc = get_calculator("sevennet", model="7net-omni-i12")  # modal="mpa"
atoms.calc = get_calculator("sevennet", model="7net-omat")      # no modal

The Omni family is one training recipe at three capacities, so the modal table below applies unchanged to all three. Keep the model fixed across a campaign — i8 and i12 are separate models, not refinements of an 7net-omni number, so energies are not comparable between them.

Multi- vs single-fidelity is handled for you. modal defaults to "auto", which sends mpa to a multi-fidelity model and nothing at all to a single-fidelity one, so model="7net-omat" needs no second argument. Passing an explicit modal to a single-fidelity model now raises: sevenn only warns and drops it, and the dropped modal was still being used to pick the D3 functional — model="7net-0", modal="matpes_r2scan" used to apply r2SCAN dispersion parameters to a PBE model.

SevenNet modal

omol25_low and omol25_high split OMol25 by spin state, not by accuracy — pick the one matching your system. SevenNet's own guidance is that mpa stays the recommended default even for molecules, organic crystals, and molecular liquids; choose another task only when you need consistency with a specific functional or benchmark protocol.

Single-fidelity models such as 7net-0 do not take modal; pass modal=None.

NequIP OAM model

NequIP OAM models are loaded through NequIP's nequip.net: loader and cached by NequIP. To avoid a download, pass model_path="path/to/model.nequip.zip".

MatterSim model

1M (default) is for fast screening, 5M is more accurate. Keep the checkpoint fixed across a campaign.

MACE model and head

atoms.calc = get_calculator("mace")                            # mh-1 / omat_pbe
atoms.calc = get_calculator("mace", model="medium-omat-0")     # no head needed

head defaults to "auto": omat_pbe for mh-1, and no head at all for the single-head checkpoints above (they carry one head named Default, and handing them a head name from another model makes MACE quietly compute with the head it does have). The omat-0 and matpes checkpoints are released under the ASL license, not MIT — MACE prints a notice when it downloads one.

MACE-MH-1 is a single checkpoint with six readout heads. The head is the level of theory, not an accuracy setting: the same structure returns PBE, r2SCAN or ωB97M energies depending on which one you pick.

atoms.calc = get_calculator("mace", head="matpes_r2scan")

Two things worth knowing before trusting a number from this model:

• An unknown head does not raise upstream. MACE logs a warning and computes with the last head in the file, so a typo returns a plausible energy from the wrong level of theory. This package rejects unknown heads with a ValueError instead, before the checkpoint is downloaded. The head names above are read back from the shipped mace-mh-1.model; the model card advertises an rgd1_b3lyp head that the published checkpoint does not carry.
• default_dtype defaults to "float64", following the MH-1 model card — the right choice for geometry optimisation and phonons. Pass default_dtype="float32" for faster MD.

UMA task

For the molecular task (omol), set atoms.info["charge"] and atoms.info["spin"] before computing — see Molecular systems for why this matters.

eSEN-30M-OMat is not available through this package

eSEN-30M-OMat is an OMat24-trained fairchem model, so it looks like it should sit next to UMA here. It does not, and the reason is structural rather than an oversight:

• the checkpoint (esen_30m_omat.pt, in the gated repo facebook/OMAT24) is a fairchem-core 1.x artefact, loaded with OCPCalculator(checkpoint_path=…);
• fairchem-core 2.x — what the uma extra installs — ships no eSEN architecture, and pretrained_mlip.available_models lists only UMA plus the OMol25 / OC25 / ODAC eSEN checkpoints, none of them OMat24;
• fairchem-core 1.10 requires torch~=2.4, numpy<2 and Python <3.13, so it cannot share an environment with the 2.x line, with MACE, or with much else.

Supporting it would mean a third isolated environment, as MACE has. If you need it today, install fairchem-core<2 separately and use its own OCPCalculator. For an OMat24-level model inside this package, use get_calculator("mace", model="medium-omat-0") or get_calculator("sevennet", model="7net-omat") — same dataset, same PBE(+U) reference level.

Molecular systems (charge and spin)

Molecular models need two inputs that no bulk model does: the total charge of the system and its spin multiplicity (2S+1). ASE has no standard place for either, so they are passed through atoms.info, and the backends differ in whether they read them at all.

UMA: set both keys explicitly

from ase.build import molecule
from ase_calculator_kit import get_calculator

atoms = molecule("H2O")
atoms.info["charge"] = 0   # total charge
atoms.info["spin"] = 1     # spin multiplicity, 2S+1 (1 = closed shell)
atoms.calc = get_calculator("uma", task="omol")
print(atoms.get_potential_energy())

A hydroxide anion and a neutral radical are the cases that actually bite:

oh_minus = molecule("OH")
oh_minus.info["charge"] = -1   # anion
oh_minus.info["spin"] = 1      # closed shell
oh_minus.calc = get_calculator("uma", task="omol")

oh_radical = molecule("OH")
oh_radical.info["charge"] = 0
oh_radical.info["spin"] = 2    # doublet — one unpaired electron
oh_radical.calc = get_calculator("uma", task="omol")

Do not rely on the defaults. fairchem does not raise when charge or spin is missing. It logs a warning, writes charge=0 / spin=1 into the atoms.info dict you passed in, and returns a neutral closed-shell result. An ion or an open-shell species then comes back silently wrong. Set both keys on every molecular structure, including the ones you think are obvious.

Both keys are integers. charge may range from -100 to 100 and spin from 0 to 100; they are read only by the omol head, and other UMA tasks ignore them.

SevenNet: no charge or spin input

sevenn has no charge or spin argument, so the modal embedding is the only handle on the molecular reference data. Charged species and a chosen open-shell state cannot be expressed — omol25_high selects a model trained on high-spin configurations, but it is not a multiplicity you set per structure. Use get_calculator("uma", task="omol") when the charge and spin of the system matter.

MACE-MH-1: molecular heads, no charge or spin

MACE-MH-1's omol head was fine-tuned on a subsample of OMol25 that is explicitly neutral and closed-shell, and spice_wB97M on SPICE-1, which is likewise neutral. There is no charge or spin input to set, and no head that covers ions or a chosen open-shell state. Use get_calculator("uma", task="omol"), or MACE-Polar below, when the charge and spin of the system matter.

MACE-Polar: charge, spin, and an applied field

polar-1-s / polar-1-m / polar-1-l are MACE's electrostatics foundation models, trained on OMol25 at ωB97M-V. They are the one group of checkpoints loaded through upstream's mace_polar rather than mace_mp — the model name is what switches the loader, so nothing else changes at the call site.

They need one package on top of mace-torch. It is not on PyPI, so no extra of this project can pull it in and you install it yourself, into the MACE environment:

.venv-mace/bin/pip install git+https://github.com/WillBaldwin0/graph_electrostatics.git@v0.4.0

That repository builds a distribution named graph_longrange — the module the checkpoints unpickle. The name mismatch matters at the command line: pip rejects the graph_electrostatics @ git+… spelling as an inconsistent name, so pass the bare URL as above. Ask for a polar checkpoint without it and get_calculator raises MissingDependencyError with this command, rather than letting MACE fail with No module named 'graph_longrange' after the download.

from ase.build import molecule
from ase_calculator_kit import get_calculator

atoms = molecule("H2O")
atoms.info["charge"] = 0
atoms.info["spin"] = 1
atoms.info["external_field"] = [0.0, 0.0, 0.01]   # V/Å, along z
atoms.calc = get_calculator("mace", model="polar-1-m")
print(atoms.get_potential_energy())
print(atoms.calc.results["dipole"])               # non-periodic cells only

Beyond energy, forces and stress, calc.results carries dipole, charges, spins and an electrostatic energy breakdown (electrostatic_energy, electron_energy, interaction_energy). Read them from calc.results directly: MACE leaves them out of implemented_properties, so ASE's own accessors do not see them and atoms.get_dipole_moment() raises PropertyNotImplementedError even though calc.results["dipole"] is there. Partial charges are also not a uniquely defined quantity — read them as a decomposition of the model's electrostatics, not as a measurement.

The same silent-default trap as UMA's omol. MACE substitutes charge=0, spin=1 and a zero field when the keys are absent, without a warning. An ion, a radical, or a field-on calculation then comes back silently neutral, closed-shell and unpolarised. Set the keys you mean.

dispersion=True is refused for all three: OMol25's ωB97M-V reference already carries the nonlocal VV10 term, so a D3 correction would double-count it.

polar-1-m and polar-1-l carry 12 Å and 18 Å receptive fields; polar-1-s is the small model. All three live in the MACE environment like every other MACE checkpoint, and all three are stored in float32 — with this package's default_dtype="float64" default, MACE logs that it is converting them, which is the conversion and not a failure.

Non-periodic cells

ase.build.molecule() returns pbc=False with a zero cell, which UMA accepts. UMA rejects only two ambiguous cases: a fully periodic structure whose cell is all zeros, and a partially periodic one (pbc=[True, True, False]).

Dispersion

Add a Grimme-D3(BJ) correction on top of MLIP models with dispersion=True:

atoms.calc = get_calculator("uma", task="omat", dispersion=True)
atoms.calc = get_calculator("uma", task="oc20", dispersion=True)
atoms.calc = get_calculator("chgnet", dispersion=True)
atoms.calc = get_calculator("sevennet", modal="pet_mad", dispersion=True)
atoms.calc = get_calculator("mace", head="omat_pbe", dispersion=True)

With dispersion=True the returned object is an ASE SumCalculator([backend_calculator, d3_calculator]), not the backend calculator itself — it satisfies the same ase.Calculator interface, but do not rely on backend-specific attributes or isinstance checks against the backend class.

Some models already include dispersion in their training functional, so dispersion=True is refused for them with DispersionError:

get_calculator("uma", task="omol", dispersion=True)      # DispersionError: ωB97M-V includes VV10
get_calculator("sevennet", modal="spice", dispersion=True)  # DispersionError: SPICE is ωB97M-D3(BJ)
get_calculator("mace", head="omol", dispersion=True)     # DispersionError: ωB97M-VV10

Every molecular task falls in this category — molecular reference data is almost always dispersion-corrected, each dataset in its own way (VV10, an explicit D3(BJ) term, or MBD-NL). That verdict cannot be overridden with dispersion_xc=; remove dispersion=True instead. A task this table does not cover yet is refused by default but can be unlocked with an explicit dispersion_xc once you have checked its functional yourself.

Choosing the damping function

dispersion_damping= selects between Becke-Johnson ("bj", the default) and zero damping ("zero"):

atoms.calc = get_calculator(
    "uma", task="oc20", dispersion=True, dispersion_damping="zero"
)

The two are separately fitted parameter sets, not a numerical detail. D3 does not screen a metal's C6 coefficients, so on molecule–metal systems the choice can move the correction by a factor of two — for RPBE, benzene on Pt(111) picks up −4.6 eV of dispersion with BJ damping against −2.4 eV with zero damping.

Match the reference dataset when the model has one. OC20 and OC22 carry no dispersion at all, so either damping is a choice you are making rather than reproducing; OC25, in contrast, is RPBE + D3 with zero damping, which is why task="oc25" refuses an added correction outright.

Note also that RPBE's D3 parameters — both dampings — are absent from Grimme's published fits and carry no citation in the reference parameter tables, unlike PBE's. Treat RPBE-D3 numbers on metals as indicative.

Cutoff and smoothing follow PFP

The D3 term runs at cutoff=14.0 Å with cutoff_smoothing="poly" — PFP v7.0.0+'s settings, not torch-dftd's own defaults of 95 Bohr (50.3 Å) and no smoothing.

This package exists to compare models against each other, and PFP is one of the models being compared. Left at torch-dftd's defaults, the dispersion term added to a SevenNet or MACE energy would be a different quantity from the one inside a PFP energy, on top of the model difference you are trying to measure. Matlantis published the validation for the shorter cutoff: an MAE of 0.0024 eV over the Wellendorff adsorption benchmark — negligible against the 0.01 eV scale those numbers live on — and no change in the 90th percentile of COD unit-cell-volume error, in exchange for roughly three times the reachable system size. "none" smoothing was a PFP bug fixed in v7.0.0; it leaves the force discontinuous at the cutoff radius, which is exactly what a relaxation or MD run walks into.

Both are overridable, so a dataset built on torch-dftd's defaults stays reproducible:

atoms.calc = get_calculator(
    "chgnet", dispersion=True,
    dispersion_cutoff=50.3, dispersion_cutoff_smoothing="none",
)

cnthr, the coordination-number cutoff, is left at torch-dftd's own default; torch-dftd clamps it to cutoff when it is larger, which is the same path PFP goes through.

See docs/models.md for the full per-model table.

MACE needs its own environment

MACE is supported since 0.5.0, but it cannot share an environment with the other MLIP backends, and no amount of pip flags will change that:

An exact pin against four lower bounds has no solution, so mace is deliberately excluded from the all extra. Give it a second virtual environment:

python -m venv .venv-mace
.venv-mace/bin/pip install "ase-calculator-kit[mace]"

# with the D3 correction as well
.venv-mace/bin/pip install "ase-calculator-kit[mace,dispersion]"

Everything else in this package behaves identically there — the factory, the dispersion policy, the DFT backends. Only the other MLIP backends are missing, and asking for one reports the usual MissingDependencyError. Conversely, in your main environment get_calculator("mace") raises a MissingDependencyError that names this constraint rather than suggesting an install that cannot work.

from ase.build import bulk
from ase_calculator_kit import get_calculator

atoms = bulk("Cu", "fcc", a=3.6)
atoms.calc = get_calculator("mace", head="omat_pbe")   # model="mh-1" by default
print(atoms.get_potential_energy())

The MH-1 checkpoint (~57 MB) is downloaded on first use and cached in ~/.cache/mace. Its model card states an ASL license, which is not the MIT license of this package — check the model's own terms before using it in commercial work.

GPU acceleration (accelerator=)

MACE can replace its equivariant tensor products with cuequivariance or openequivariance kernels on CUDA. accelerator= selects that, and defaults to "auto":

.venv-mace/bin/pip install "mace-torch[cueq,cueq-cuda-12]"

atoms.calc = get_calculator("mace")                       # auto
atoms.calc = get_calculator("mace", accelerator="cueq")   # force it
atoms.calc = get_calculator("mace", accelerator="none")   # never

Why "auto" measures instead of asking "is it importable". Both cheaper questions have been observed to give the wrong answer:

• On a Tesla V100 (sm_70), cuequivariance 0.11 imports, the calculator builds, and then the first energy evaluation dies with cudaErrorNoKernelImageForDevice — the shipped kernels do not cover that architecture. An import check would hand back a calculator that explodes later, in the middle of a run.
• ACEsuit/mace#1298 reports cuequivariance returning +5500 eV where the plain model returns −200 eV on a multi-head checkpoint — without raising at all.

So "auto" builds both models, compares them on a two-atom cell, and keeps the accelerated one only if the energies agree. The extra cost is one model build and two tiny single points, paid only when cuequivariance is installed; if it is not, "auto" is free. enable_cueq= / enable_oeq= can still be passed directly, and an explicit flag skips the probe.

Measured on a V100 with cuequivariance 0.11.1 installed: accelerator="auto" warns, falls back, and returns −3.74034995 eV for bulk("Cu") — identical to CPU float64 to 1e-13 eV — while accelerator="cueq" raises.

Development

python -m venv .venv
.venv/bin/pip install -e ".[dev]" -c constraints.txt
.venv/bin/pytest

# MACE has its own environment; the same suite runs there too
python -m venv .venv-mace
.venv-mace/bin/pip install -e ".[mace,dispersion,dev]" -c constraints.txt
.venv-mace/bin/pytest

pyproject.toml declares compatible version ranges so the package installs next to whatever ASE/NNP versions you already have; constraints.txt pins the exact combination that is tested, and CI installs with it.

pytest runs only the fast tests by default. Slow tests (pytest -m slow) run real MLIP CPU single-point calculations and may download model weights; install .[dev,all] -c constraints.txt first so every backend is importable.

Further Reading

• docs/models.md — per-model dispersion policy and training functionals.
• docs/code-guide_ja.md — 実装の化学的な判断と モジュールの責務（日本語）.
• AGENTS.md — repository map, invariants, and conventions for AI coding agents (Claude, GPT, and others).
• CHANGELOG.md — release history.
• docs/releasing.md — how a release reaches PyPI and Zenodo.

Citation

If this package contributed to published work, please cite the archived release. CITATION.cff holds the machine-readable metadata — GitHub renders it under "Cite this repository", and Zenodo reads it when minting the DOI.

@software{ase_calculator_kit,
  title  = {ase-calculator-kit: a unified ASE calculator factory for MLIP and DFT calculators},
  author = {Wakamiya, Taishiro and Ishikawa, Atsushi},
  year   = {2026},
  doi    = {10.5281/zenodo.21807793},
  url    = {https://github.com/ishikawa-group/ase-calculator-kit}
}

10.5281/zenodo.21807793 is the concept DOI: it always resolves to the newest archived version. To cite one specific release instead, use its version DOI from the Zenodo record — 0.3.4 is 10.5281/zenodo.21807794.

License

MIT