[Code scan] Symmetrize ASE calculator stress after reshaping virial

[njzjz]

This issue comes from a Codex global scan of deepmodeling/deepmd-kit at commit 73de44b1f94471b2e3bdb6b11f57b34d7bc791bb.

Problem

The ASE calculator stores the model virial as a 3x3 matrix:

deepmd-kit/deepmd/calculator.py

Lines 151 to 155 in 73de44b

	self.results["energy"] = e[0][0]
	# see https://gitlab.com/ase/ase/-/merge_requests/2485
	self.results["free_energy"] = e[0][0]
	self.results["forces"] = f[0]
	self.results["virial"] = v[0].reshape(3, 3)

but when converting virial to stress it operates on the original flat 9-vector v[0]:

deepmd-kit/deepmd/calculator.py

Lines 157 to 163 in 73de44b

	# convert virial into stress for lattice relaxation
	if cell is not None:
	# the usual convention (tensile stress is positive)
	# stress = -virial / volume
	stress = -0.5 * (v[0].copy() + v[0].copy().T) / atoms.get_volume()
	# Voigt notation
	self.results["stress"] = stress.flat[[0, 4, 8, 5, 2, 1]]

For a one-dimensional NumPy array, .T is a no-op. Therefore 0.5 * (v[0] + v[0].T) does not symmetrize the virial tensor; it just returns the flat virial vector. The subsequent Voigt indexing then uses unsymmetrized off-diagonal entries.

Impact

ASE stress returned by the DeePMD calculator can be wrong for models/inputs whose virial tensor is not exactly symmetric. This affects workflows that consume ASE stress, including cell/lattice relaxation.

Suggested fix

Reshape before symmetrizing:

virial = v[0].reshape(3, 3)
stress = -0.5 * (virial + virial.T) / atoms.get_volume()
self.results["stress"] = stress.flat[[0, 4, 8, 5, 2, 1]]

Alternatively, reuse self.results["virial"] after assigning it.

[wanghan-iapcm]

The observation is correct that 0.5 * (v[0] + v[0].T) does not symmetrize, because .T on the flat 9-vector is a no-op. However, this has no effect on the produced stress in practice, so I'm deferring a fix.

The calculator uses the total (system) virial: DP.calculate calls self.dp.eval(...) with the default atomic=False and takes [:3] = (energy, force, virial), where virial is documented as "the virial of the system, in shape (nframes, 9)". The total virial is symmetric by construction (a sum of r_ij ⊗ f_ij over pairs), so self.results["virial"] = v[0].reshape(3, 3) is already symmetric and 0.5 * (V + V.T) == V up to floating-point noise. The Voigt off-diagonals picked by .flat[[0, 4, 8, 5, 2, 1]] therefore match what a correct symmetrization would give.

In other words, the code is misleading (the .T no-op looks like an intended-but-broken symmetrization), but it does not produce an incorrect stress for the symmetric total virial that DP emits. A reshape-then-symmetrize change would be a zero-effect readability/intent cleanup rather than a bug fix.

If there is a concrete model or code path that returns an asymmetric total virial to this calculator, that would change the assessment — please point to it and I'll add the reshape plus a regression test. Otherwise this can likely be closed as a no-op, or kept as a low-priority cleanup.

[njzjz-bot]

Thanks, this assessment makes sense for the normal DP total-virial path.

One nuance I would add is that the reshape-then-symmetrize version should be understood as an ASE/Cauchy-stress convention and a readability cleanup, not as a way to make an arbitrary asymmetric virial physically correct.

For an energy-conserving, rotation-invariant DP model, the total virial should already be symmetric up to numerical noise: the antisymmetric part corresponds to a net torque / response to rigid rotation, which should vanish for a scalar potential with rotational invariance. In that case

virial = v[0].reshape(3, 3)
stress = -0.5 * (virial + virial.T) / atoms.get_volume()

is effectively just projecting numerical noise onto the conventional symmetric stress tensor expected by ASE.

But if a code path produces a genuinely asymmetric total virial, blindly averaging it would hide the underlying issue rather than fix it. That could point to a non-conservative force model, external torque/field contribution, an atomic/local virial gauge issue, or a backend/implementation bug. In such a case I think we should first identify where the antisymmetric component comes from, rather than treating symmetrization as sufficient.

So I agree this is probably not a user-facing bug for the standard total virial returned by DP, but the reshape-before-symmetrize change would still be a reasonable low-priority intent/readability cleanup.

— OpenClaw 2026.6.8 (model: custom-chat-jinzhezeng-group/gpt-5.5)