Single-point energy & forces
Computes the total energy and the per-atom forces at the current geometry, with no optimization or dynamics. This is the fastest calculation type and the natural first step for any new structure — use it to sanity-check a structure before committing to a longer optimization or MD run.
Geometry optimization
Relaxes atomic positions to a nearby local minimum by iteratively moving atoms in the direction of the forces until the maximum force component drops below a threshold, fmax.
| Parameter | Default | Notes |
|---|---|---|
| Optimizer | BFGS | Switch to FIRE if BFGS struggles to converge. |
fmax (eV/Å) | 0.05 | 0.01 for production results; 0.005 before running a vibrational/frequency analysis. |
maxOptSteps | 500 | Always set a limit to prevent an infinite loop; increase for large or difficult-to-converge systems. |
Only atomic positions are optimized — cell optimization is not yet supported. Watch the RMS force during optimization: it should decrease monotonically as the structure approaches a minimum.
Molecular dynamics
Propagates a trajectory over time under one of three ensembles. Initial velocities are always drawn from a Maxwell–Boltzmann distribution at the target temperature.
| Ensemble | Thermostat / barostat | Requires |
|---|---|---|
| NVE | None (microcanonical) | Any system. Total energy should stay conserved. |
| NVT | Langevin thermostat (friction parameter) | Target temperature (K). Energy fluctuates around the target temperature rather than staying fixed. |
| NPT | Barostat | Temperature (K), pressure (GPa), and a periodic system with a defined cell. |
- Timestep: typically 0.5–2.0 fs; use a smaller timestep for systems containing light elements such as hydrogen.
- Steps: total number of MD steps to run.
- Temperature (K): the target for the initial Maxwell–Boltzmann velocity distribution and for the NVT/NPT thermostat.
- Langevin friction: controls how strongly the NVT thermostat couples the system to the target temperature.
- Pressure (GPa): the NPT target pressure, entered in GPa and converted internally — see Units & conventions.
Phonon spectrum — planned
Phonon spectrum calculation is on the roadmap but not yet supported in SimpleAtom. For now, vibrational analysis must be performed on a fully converged geometry using an external workflow.D3 dispersion correction
Adds Grimme’s semi-empirical DFT-D3 van der Waals correction on top of MACE-MP-0 predictions. It matters for layered materials, molecular adsorption, and molecular crystals where dispersion forces are significant.
D3 is MACE-MP-0 only
D3 dispersion is only meaningful for MACE-MP-0. MACE-OFF is trained on ωB97M-D3BJ reference data, which already includes dispersion — enabling D3 on top of it double-counts the correction. SimpleAtom disables the D3 toggle automatically when MACE-OFF is selected.Precision
Two floating-point precisions are available:
- float32 — the default. Fast, and sufficient for energies, forces, and standard optimization or MD.
- float64 — required for Hessian and vibrational frequency calculations, and recommended when preparing a structure for such an analysis (converge to
fmax< 0.005 eV/Å first).
Device
Calculations run on cpu by default. If a CUDA GPU is available it can significantly speed up larger systems or longer MD trajectories; SimpleAtom falls back to CPU automatically if CUDA is unavailable or runs out of memory.
Web UI → MACE parameter mapping
Under the hood, SimpleAtom drives the same MACECalculator and mace_mp() / mace_off() factory functions you would use from a Python script. The web parameters map directly onto that API:
| Web UI parameter | Maps to | Notes |
|---|---|---|
| Model Type | mace_mp() / mace_off() / custom upload | Selects the foundation model or a user checkpoint. |
| Model Size | model argument | "small", "medium", "large". |
| Precision | default_dtype | "float32" or "float64". |
| Device | device | "cpu" or "cuda". |
| D3 Dispersion | dispersion | On/off toggle; MACE-MP-0 only. |
| Custom Model Upload | model_paths | User-supplied .model checkpoint file. |
Lower-level parameters — compile_mode, enable_cueq, charges_key, info_keys, and the unit-conversion factors — are handled automatically by the backend and are not exposed in the UI, since they require no configuration for standard workflows.