[BUG] dpa4spin accepts non-metal units but uses metal-unit hbar

[njzjz-bot]

Summary

The dpa4spin and dpa4spin/kk pair styles accept non-metal physical unit styles, but their magnetic-force conversion always divides by a hard-coded reduced Planck constant in metal units (eV·ps). Magnetic dynamics are therefore unit-incorrect for accepted styles such as real and si.

This is present on origin/master at 8cfd46e37448.

Evidence

The constructor rejects only units lj and explicitly tells users that real is acceptable:

if (strcmp(update->unit_style, "lj") == 0) {
  // ... use a physical unit style such as metal or real.
}

Both implementations then use:

constexpr double kHBar = 6.5821191e-04;  // eV.ps

and scale the magnetic force with force_unit_cvt_factor / kHBar:

• source/lmp/pair_dpa4spin.cpp:113,543-544
• source/lmp/pair_dpa4spin_kokkos.cpp:24,336

For example, LAMMPS real units use force->hplanck = 95.306976368 in kcal/mol·fs, so the numerator is converted while the denominator remains in eV·ps. The result is not the metal-unit result expressed in real units.

The repository's spin test helpers already state that only metal is valid, and LAMMPS's PairSpin::settings() rejects every non-metal unit style.

Expected behavior

The safest fix is to reject strcmp(update->unit_style, "metal") != 0 in dpa4spin, which also covers dpa4spin/kk through its base constructor. Alternatively, all magnetic-force dimensions would need a complete active-unit conversion based on force->hplanck / (2*pi) and the appropriate energy conversion.

A regression test should verify that units real fails at pair-style initialization with a clear error.

---

Coding agent: Codex
Codex version: codex-cli 0.149.0
Model: gpt-5.6-sol
Reasoning effort: xhigh