Calculator Reference

This page identifies the calculator values accepted by the current Tako release. For interface operation, see Choose a Calculator. For physical approximations and applicability, see Choosing a Method. Script construction and validation are defined in Calculator Construction and Validation.

Registered levels

Asset sizes come from the current manifest and can change when a model is replaced. Record the asset filename or immutable hash in addition to the level string when strict reproduction is required.

tako.calculator.mlip() defaults to nequip-s when no level is supplied. The calculation setup dialog defaults to g-xTB, which needs no model download. Reusable scripts should always state levelOfTheory explicitly.

g-xTB’s parametrization is molecular, and the theory itself is unreliable under periodic boundary conditions. Periodic g-xTB runs proceed (the setup dialog shows a warning when the structure carries a cell), but prefer GFN2-xTB, an MLIP, or periodic DFT for crystals.

Dispersion selection

Dispersion is separate from the level of theory. Tako stores the requested policy and the effective correction independently of levelOfTheory.

DFT-revD4 is g-xTB’s native self-consistent dispersion model and is therefore its default. No g-xTB-specific D3 parameter fit is published. The explicit DFT-D3 alternative uses the published ωB97M D3(BJ) parameters because g-xTB was parameterized against ωB97M-V; results record dispersion_parameter_method: "wb97m" rather than presenting it as a g-xTB fit.

The skala-1.0 string is the published D3 parameter-record key. It is paired with the SKALA 1.1 electronic model and does not change it. D3(BJ) works for molecular calculations and for supported periodic calculations, including forces and stress where the selected calculator exposes them. The three-body ATM term remains disabled.

Generic DFT-D4 is not exposed for PBE, r2SCAN, or SKALA in the browser. The current pure-Rust standalone D4 path does not yet provide the complete charge-response derivative and periodic virial chain required to keep optimization, MD, phonon, vibration, and cell calculations consistent with its energy. Tako does not offer an energy-only approximation as if it were a force-capable correction.

Checkpoint provenance

Two checkpoints built with the same architecture can have different training data, reference energies, cutoffs, and force heads. For a reproducible report, record the levelOfTheory, the model name written to result.json, and the weight SHA-256 below.

The hash prefixes above identify Tako’s actual bytes, not an upstream “latest” alias. When a future release changes a weight, the hash must change even if the menu label remains the same. OMat24 documentation also warns that its DFT/DFT+U labels are not directly interchangeable with Materials Project energies without reference-energy and mixing corrections; therefore never combine absolute energies from these checkpoints with energies from another method or database.

Model weights ship from atomicarchitects/nequix, mir-group/nequip, and mirror-physics/equiformer_v3, all MIT-licensed; see Tako → License Info in the app.

Shared calculator capabilities

Capability metadata and returned result fields are distinct. In particular, the GFN2 profile contains a dipole capability for spectroscopy paths, but tako.singlePoint does not return a dipole field. Always consult the operation result schema rather than inferring a result key from the calculator profile.

DFT geometry boundary

The UI defaults new DFT selections to a functional plus def2-SVP; semantic script levels still resolve bare pbe/r2scan by geometry. Before a selection can run, TakoScript resolves the basis and compares the structure’s elements against a maintained coverage set. Unsupported choices are disabled before a module or checkpoint is loaded.

PBC GTH / MOLOPT coverage (qc.rs / CP2K data)

Bundled def2 families cover H–La and Hf–Rn (omit Ce–Lu). All GTH rows pair with gth-pbe. Lanthanides remain out of the broad MOLOPT tables above; molecular def2 still covers La.

Operation boundary

The lower-level capability arrays also contain scan. It is capability vocabulary rather than a public top-level Script operation in the current API.

Operation validation reports API-level compatibility. It now rejects GFN2 electronic post-processing outside singlePoint; for example, optimization cannot request a charge result merely because the GFN calculator has charge capability. Validation does not establish training-domain accuracy, electronic-state correctness, numerical convergence, or experimental agreement.

The request-time property values are energy, forces, stress, dos, pdos, charges, electronDensity, chargeDensity, nci, wfn, orbitals, spinDensity, esp, densityDerivatives, fukui, and elf. GFN2 accepts all of them where the operation implements the corresponding stage; MLIP calculators accept only energy, forces, and stress and reject or omit electronic-analysis requests. Energy is always retained during normalization. Forces remain a default for force-capable levels, but an explicit energy-only DFT request stays energy-only. The Single Point dialog does not expose a visible Electron density switch even though electronDensity is accepted by the Script and runtime layers.

g-xTB state record

GFN2 state record

Charge, unpaired-electron count, and spin polarization describe the modeled state, not convergence settings.

MLIP state record

Runtime and model must be compatible. Nequix weights use the nequix runtime, NequIP weights use nequip, and Equiformer weights use equiformer. Normalization follows the model family when it is unambiguous; a conflicting explicit request is rejected at model loading rather than silently interpreted as a different file format.

MLIP calculators have no charge, spin, solvent, orbital, or population-analysis state. The shared interface may continue to display charge/unpaired fields, but these values are not MLIP input channels.

Asset inventory

Model Manager reports Bundled, Not downloaded, partial/resumable, or cached state for each row. The selected calculator can require both a module and a weight. Cache presence indicates the asset is downloaded and available to run.

Validation and readiness return values

calculator.validate(operation, { properties }) returns:

calculator.readiness(manifest, records) returns { ready, summary } for the manifest and asset records supplied by the caller. With no live records supplied, it describes requirements against an empty cache; it is not a query of the browser’s current Model Manager state. A typical summary line reads Module mlip: 2.57 MiB required, 0 B stored. For an “is it already here?” question, prefer the Model Manager (see Choose a Calculator) or the agent’s list_models tool over calling readiness against an empty cache.

Provenance record

For every reported numerical result, retain:

• calculator family and exact levelOfTheory;
• runtime and model identifier for MLIP;
• model/asset filename or immutable hash when available;
• application and calculation-backend version;
• GFN2 dispersion, charge, unpaired-electron, and spin-polarization state;
• SCF and solvation overrides;
• requested properties and operation settings;
• input geometry, periodic cell, constraints, and composition/reference convention;
• convergence and failure/cancellation state.

The statements “available,” “capability-valid,” “numerically converged,” and “validated for this chemistry” are distinct and require different evidence.