test: compare H(R)/S(R) CSR outputs by matrix values

[GenZeal-Lin]

Summary

This PR makes the integration-test comparison of ASCII H(R)/S(R) CSR outputs aware of sparse-matrix semantics.

CPU and GPU calculations can produce different CSR sparsity patterns for numerically near-zero matrix elements. The previous generic file comparison rejects such outputs when the NNZ / CSR layout differs, even when the actual matrix-value difference is well below the configured test tolerance.

This PR:

• adds a CSR-aware comparator for H(R)/S(R) text outputs;
• treats missing sparse entries as numerical zero;
• compares matrix values using the existing tolerance;
• switches the H(R)/S(R) integration checks to the new comparator;
• enables scf_out_hsr_spin4 and nscf_out_hsr_tr_rr in CUDA CI.

Addresses #7860.

Problem

For nscf_out_hsr_tr_rr, the same CUDA-enabled ABACUS binary produces:

• CPU: 22 entries for R = (0, 0, 0)
• GPU: 24 entries for R = (0, 0, 0)

The two GPU-only entries are approximately 4.83e-10.

The integration test uses an accuracy of 8 (1e-8), so these entries are numerically within the existing tolerance.

However, CompareFile.py compares the serialized CSR representation and fails immediately on the NNZ difference:

hrs1_nao.csr.ref:           22
OUT.autotest/hrs1_nao.csr: 24

Therefore, numerically equivalent sparse matrices can fail the test only because their storage layouts differ.

Changes

A new compare_hsr_csr.py comparator:

1. parses the existing H(R)/S(R) CSR text format;
2. supports both real and complex matrices;
3. validates CSR row pointers, column indices, and duplicate entries;
4. converts each R block to matrix entries keyed by (row, column);
5. treats entries missing from either CSR representation as zero;
6. compares matrix values using the requested absolute tolerance;
7. rejects non-finite values.

catch_properties.sh now uses this comparator for ASCII H(R)/S(R) outputs instead of the generic token-by-token file comparator.

The existing numerical tolerance is unchanged.

Validation

On an NVIDIA GeForce RTX 4090:

• CPU R=(0,0,0) NNZ: 22
• GPU R=(0,0,0) NNZ: 24
• maximum GPU-only residual: approximately 4.83e-10

Comparison results:

• existing generic comparator at 1e-8: FAIL on NNZ mismatch
• new CSR comparator at 1e-8: PASS
• new CSR comparator at 1e-10: FAIL
• injected real-valued 1e-5 error: FAIL
• injected complex-valued 1e-5 error: FAIL
• injected NaN: FAIL
• existing eligible H(R)/S(R) references: 12/12 PASS

The two CUDA cases previously excluded because of this issue are enabled again:

• scf_out_hsr_spin4
• nscf_out_hsr_tr_rr

Scope

This PR does not modify the GPU Gint implementation, production H(R)/S(R) output, or the production sparse threshold.

It only changes the integration-test comparison semantics so that the existing numerical tolerance is applied to matrix values rather than to the serialized CSR layout.

[mohanchen]

I want to comment on the PR you submitted. This is actually a very interesting issue — the GPU produces a few extra terms. Your current approach makes the tests pass, but a more thorough solution would be to investigate where exactly those extra 8/2 terms on the GPU come from, and why the CPU doesn't have them. A difference on the order of 10⁻¹⁰ isn't purely numerical error; it could be a subtle bug.