discriminate frames with virials labels in Multisystem class

[PKUfjh]

Sometimes we came across with multisystem (such as quip/gap/xyz format files) which has both frames with virials labels and frames without virials labels. The current implementation of the Multisystems class will lead to error message:

RuntimeError: system has virial, but this does not

But this kind of Multisystems are in fact trainable, so I identify frames with virials in Multisystems, such that Systems will have names as:

C60  C60_virials

The former represents systems with 60 carbon atoms without virials labels, the latter represents systems with 60 carbon atoms with virials labels.

[codecov-commenter]

Codecov Report

Merging #294 (31438f0) into devel (c0bb798) will decrease coverage by 0.03%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##            devel     #294      +/-   ##
==========================================
- Coverage   81.57%   81.53%   -0.04%     
==========================================
  Files          62       62              
  Lines        5244     5249       +5     
==========================================
+ Hits         4278     4280       +2     
- Misses        966      969       +3     

Impacted Files	Coverage Δ
dpdata/plugins/ase.py	64.51% <0.00%> (-3.29%)	⬇️
dpdata/system.py	85.28% <100.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c0bb798...31438f0. Read the comment docs.

[wanghan-iapcm]

This is a breaking change to the code that has potential influence on other codes using dpdata.MultiSystems with explicit formula.

I do not support the merging of this PR.

[PKUfjh]

This is a breaking change to the code that has potential influence on other codes using dpdata.MultiSystems with explicit formula.

I do not support the merging of this PR.

Actually this change just modifies the system names in the MultiSystems frames (add "_virials" to the system names), I do not see what negative influence this change will have on other codes.

[njzjz-bot]

Requesting changes because the proposed virial suffix is not stable under MultiSystems atom-name normalization and is also a breaking change to public formula keys. The inline reproduction shows that the original mixed-label failure returns after appending a new element. This needs a stable label-schema grouping design that preserves the formula API, not a temporary key suffix.

Process note: the Codex usage allowance is about to reset, so I am spending the remaining token budget now on this review.

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

[njzjz-bot]

[P1] Do not encode label schema in a temporary formula key

check_atom_names can rebuild the systems dictionary from each System.formula whenever a new element is introduced, so this suffix is lost. I reproduced keys changing from H2_virials to H2O0 after appending an O system; appending an unlabeled H2 then collides again and raises the original virial mismatch. The suffix also changes every public key and output directory for virial-bearing systems. Group by a stable field signature while preserving chemical formula keys instead.