[Feature Request] Native Cartesian magnetic-force mode for Newtonian spin dynamics in LAMMPS #6077

Summary

Please provide an explicit Cartesian magnetic-force mode for the LAMMPS native-spin interface, initially for dpa4spin/kk, while retaining the existing precession convention by default.

Newtonian variable-magnitude spin integrators need the conservative force F_S = -dE/dS. The model already returns this quantity, but the LAMMPS adapter converts it before storing it in atom->fm. Native support would let a separately maintained LAMMPS integrator consume the raw force without patching or vendoring DeePMD's interface sources.

Current behavior and motivation

Inspected upstream master at 025f4f698d4ff50c0b5538f19dc0b00ad1459ba3:

• pair_dpa4spin_kokkos.cpp scales the model magnetic force by the moment magnitude and 1 / hbar before accumulating it into fm.
• This convention is appropriate for the existing precession-based LAMMPS SPIN integrator. A Cartesian Newtonian integrator instead advances I * d2S/dt2 = F_S and needs the unconverted gradient.
• Recovering the raw force afterward by multiplying by hbar / |S| is not a general solution: at zero moment the original value has already been lost. Post-force thermostats and restraints can also accumulate Cartesian forces into the same array, so the conversion boundary must be explicit.

The downstream LAMMPS fork currently handles this through a small build-directory patch to the Kokkos adapter. The installed DeePMD library and external source checkout remain unchanged. A native mode would remove this source-patch dependency.

Requested behavior

1. Offer an explicit selection between the existing precession convention and the Cartesian -dE/dS convention. Preserve the current default and avoid inferring the choice from whether the model uses native spin.
2. In Cartesian mode, store the model gradient using the appropriate energy-per-model-spin unit conversion, without multiplying by the moment magnitude or dividing by hbar, including for zero moments.
3. Expose the selected convention through a machine-readable interface so a consuming integrator can reject incompatible configurations. For example, a downstream fork uses Pair::extract("fm_cartesian_force", dim) with a scalar integer declaration. The exact upstream API can be chosen independently.
4. Preserve Kokkos device residency and single-/multi-rank magnetic-force accumulation, and make the behavior available in both built-in and plugin builds.

An initial implementation limited to the Kokkos device style and units metal would cover the downstream use case. Supporting this force convention does not require moving the Newtonian integrator into DeePMD-kit.

Suggested validation

• Preserve existing precession-mode behavior.
• Compare Cartesian magnetic forces to energy finite differences for non-collinear, small, and zero moments.
• Check declaration/selection consistency and reject unsupported combinations explicitly.
• Check single-rank versus MPI force accumulation and built-in versus plugin behavior with compatible builds.

This request is based on source inspection and the downstream integration contract; it does not claim a new GPU or MPI validation run. It is separate from #6075 / #6012 (unsuffixed host-style registration) and #5993 (unit handling in the existing precession mode).