Output Net Force Vector and Total Drift Magnitude for Calculation Quality Control

[Phorbol]

Background

Motivation and Problem Statement
In large-scale Density Functional Theory (DFT) calculations, particularly those for generating training data for Machine Learning Interatomic Potentials (MLIPs), ensuring the numerical quality and convergence of forces is paramount.

Recent studies, such as the one accompanying the Open Catalyst 2025 (OC25) dataset (arXiv:2509.17862) and a separate analysis on DFT force accuracy (arXiv:2510.19774v1) , have highlighted that a nonzero net force (also referred to as "force drift") is a clear and simple symptom of numerical errors in the DFT calculation.

These numerical errors can stem from various sources, including insufficiently tight electronic convergence thresholds (e.g., EDIFF in VASP) , or other numerical approximations.

The OC25 project, for instance, explicitly calculated the magnitude of this net force vector (which they call "total drift") and used it as a critical quality-control filter to remove unreliable calculations from their final training dataset. This demonstrates a best-practice approach for robust dataset generation.

Currently, ABACUS users do not have a straightforward way to monitor this metric from the standard output. Manually post-processing and summing forces from output files is cumbersome and inefficient for high-throughput workflows.

Describe the solution you'd like

Proposed Solution
I request the implementation of a feature where ABACUS automatically calculates and reports the system's net force after the electronic (SCF) calculation is complete.

Specifically, at the end of each SCF cycle (or at minimum, at the end of the final, converged SCF step for a given ionic position), ABACUS should:

Calculate the Net Force Vector:
This is the (1, 3) vector obtained by summing the force vectors of all N atoms in the system ($\vec{F}{net} = \sum{i=1}^{N} \vec{F}_i$).↳

Calculate the Total Drift Magnitude:
This is the scalar L2-norm (magnitude) of the Net Force Vector ($||\vec{F}_{net}||$).

Above can be written in python like:

import numpy as np

# Sample force data (replace with atoms.get_forces() if using ASE)
forces = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]])

# Calculate the net force vector (sum of all forces)
net_force_vector = np.sum(forces, axis=0)

# Calculate the total drift (magnitude of the net force vector)
total_drift = np.linalg.norm(net_force_vector)

print("Net Force Vector:", net_force_vector)
print("Total Drift Magnitude:", total_drift)

These two values should be printed clearly in the main output log file (e.g., OUT.log or equivalent).
Example Output (at the end of an SCF calculation):

...
SCF calculation converged.
Net Force Vector [eV/A]:   [ -5.5795e-02  -9.6007e-02   6.5738e-02 ]
Total Drift Magnitude [eV/A]:  1.2615e-01
...

Printing this information at the end of every SCF step would be even more beneficial, as it would allow users to monitor the convergence of the net force itself. However, reporting the final values after the last SCF step is the most critical implementation.

Some Reference:

1. https://arxiv.org/pdf/2510.19774
2. https://arxiv.org/pdf/2509.17862

Task list only for developers

• Notice possible changes of behavior
• Explain the changes of codes in core modules of ESolver, HSolver, ElecState, Hamilt, Operator or Psi

Notice Possible Changes of Behavior (Reminder only for developers)

No response

Notice any changes of core modules (Reminder only for developers)

No response

Notice Possible Changes of Core Modules (Reminder only for developers)

No response

Additional Context

No response

Task list for Issue attackers (only for developers)

• Review and understand the proposed feature and its importance.
• Research on the existing solutions and relevant research articles/resources.
• Discuss with the team to evaluate the feasibility of implementing the feature.
• Create a design document outlining the proposed solution and implementation details.
• Get feedback from the team on the design document.
• Develop the feature following the agreed design.
• Write unit tests and integration tests for the feature.
• Update the documentation to include the new feature.
• Perform code review and address any issues.
• Merge the feature into the main branch.
• Monitor for any issues or bugs reported by users after the feature is released.
• Address any issues or bugs reported by users and continuously improve the feature.

[mohanchen]

Thank you for your thoughtful suggestions, it is indeed very helpful, we will consider how to provide the information.