[LKFEIYI]

Reminder

• I have read AGENTS.md and docs/developers_guide/agent_governance.md.
• I have linked an issue or explained why this PR does not need one.
• I have added adequate unit tests and/or case tests, or explained why not.
• I have listed the exact verification commands run and their results.
• I have described user-visible behavior changes, including INPUT parameter changes.
• I have explained core-module impact for ESolver, HSolver, ElecState, Hamilt, Operator, Psi, or other source/ changes.
• I have requested any needed governance exception below.

Linked Issue

Third part of #8052. It follows #8075 (PCC) and #8162 (SCCS Step 1: periodic SCCS).

Remaining follow-up PRs, each stacked on the previous one: lowpass and full cavity → SCF integration → solvent-aware cavity.

What's changed?

imp_sol 2 can now be combined with assume_isolated pcc_0d and pcc_2d (O. Andreussi and N. Marzari, Phys. Rev. B 90, 245101 (2014)). This removes the cell-size dependence of charged solvated systems: molecules (pcc_0d) and slabs (pcc_2d, open along pcc_2d_axis). Neutral periodic SCCS from Step 1 is unchanged.

Deliberate difference from Environ (inherited from #8075): for a charged slab, pcc_2d uses the monopole constant −πQL/(3A), whereas Environ uses −πQ/(3L).

• Cavity derivatives: two paths. sccs_cav_deriv builds grad s and lapl s for the dielectric coefficient.

  • Periodic cells keep Step 1's chain derivatives, as Environ deriv_method chain: grad s = s′ grad n and lapl s = s′ lapl n + s″ |grad n|², from FFT derivatives of the density n.
  • With PCC the switching function s itself is differentiated on the FFT grid, as Environ deriv_method fft, because the chain coefficient is not converged at the cavity edge.

  The PCC cases are therefore compared with QE in fft mode below. Periodic results are unchanged from Step 1. CavityPoint gains d2solute_drho2 for the chain path, which is checked against finite differences.

Validation against QE 7.6 + Environ 3.1.1

Case	ΔG ABACUS (eV)	ΔG QE (eV)	ΔΔG (meV)
H2O, PCC2D	−0.29933	−0.29932	−0.00
H3O⁺, PCC0D	−4.67264	−4.67271	+0.07
H3O⁺, PCC2D, 20 × 20 × 20 bohr (A = L²)	−2.07807	−2.07821	+0.14
H3O⁺, PCC2D, 12 × 20 × 12 bohr	−0.37602	−1.62666	+1250.6 (monopole constant, see above)

• Cavity surface and volume agree to 0.01–0.02 bohr² and bohr³.
• The electrostatic term E_sol_el + E_pcc agrees with QE's "electrostatic embedding" to ≤ 1.2 meV.
• Solvation forces (solvent − vacuum) agree to 1.1e-4 eV/Å for neutral H2O with PCC2D. For H3O⁺ with PCC they differ by 3–5e-2 eV/Å; there QE's own analytic forces miss its finite differences by 4–6e-2 eV/Å. The lowpass filter in the next PR addresses force accuracy with PCC.

How the comparison was run. (reply to ABACUS-PR-BOT)

• Each case directory has an ABACUS INPUT/STRU/KPT and a QE pw.in + environ.in.

• One script runs them with OMP_NUM_THREADS=1:

  • ABACUS: mpirun -np 8 abacus_std_para > run.log
  • QE: mpirun -np 8 pw.x -environ -in pw.in > run.log

• analyze.py takes ΔG from !FINAL_ETOT_IS (ABACUS) and ! total energy (QE). It reads the surface and volume from the SCCS_CAVITY line and from environ.debug, and the forces from TOTAL-FORCE and "Forces acting on atoms".

• Executables:

  • ABACUS: the stacked SCCS branch (v3.11.0-beta10), GCC 11, OpenMPI 5.0.10, FFTW 3.3.11, OpenBLAS 0.3.33, ELPA, LibXC 7.1.2.
  • QE 7.6 + Environ 3.1.1.

  The ABACUS energies were reproduced bit-for-bit. Since then the code has only been renamed and switched to the ModuleBase SI constants, which moves the solvation energies by about 2×10⁻⁸ eV.
  Deferred checks: there are no charged integration cases (CI time; charged energies are validated in the table above). Force accuracy with PCC is addressed by the lowpass filter in the next PR.

[ABACUS-PR-BOT]

Static review of 0c2c11d. No builds or ABACUS runtime tests were run; CI diagnostics were unavailable.

Non-blocking: Please add the exact build/test/comparison commands, executable identity/configuration, MPI ranks and observed outcomes behind the validation table, noting which force/convergence checks remain deferred. Also state the generated INPUT-documentation workflow and whether documentation-generation/CLI checks were run.

[mohanchen]

@LKFEIYI LGTM, but some conflicts need to be resolved

[mohanchen]

@ABACUS-PR-BOT do you have further comments?

[ABACUS-PR-BOT]

I found no new implementation issue in the merge/conflict resolution at 3270172, following up on your question. The SCCS+PCC force-accuracy qualification in INPUT help remains open; the unused include is fixed.

The remaining validation provenance is non-blocking and can be supplied in a follow-up: identify the exact comparison revision and record focused build/test/INPUT-documentation/CLI checks run or skipped. The comparison commands, ranks and environment are already supplied.

This was a static review; no product runs were performed, and CI diagnostics were unavailable.