Fix: Intel classic (icpc) build error — ambiguous Conv_Coulomb_Pot_K::cal_orbs_ccp overloads

[Flying-dragon-boxing]

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

Fix #7928

Unit Tests and/or Case Tests for my changes

• Commands run:
  • Intel classic icpc 2021.6/2022.1 build of the previously failing call sites (exx_lri.hpp:77, ewald_vq.hpp:59, instantiated from module_rdmft/rdmft.cpp) — verified by the patch author; see commit message.
  • g++ -std=gnu++14 -fsyntax-only source/source_lcao/module_ri/conv_coulomb_pot_k.cpp with the standard ABACUS define set (__EXX, __LCAO, __MPI, ...), GCC 11.4.0.
  • g++ -std=gnu++14 -fsyntax-only source/source_lcao/module_rdmft/rdmft.cpp (same flags) — the translation unit icpc failed on; passes, confirming no regression for GCC.
  • Repo-wide grep for is_std_vector: no name collisions.
• Result summary: all pass.
• Checks not run, with reason: no new unit test — compile-compatibility fix with zero runtime behavior change; no Intel classic CI exists, and the affected TUs are covered by GCC/icpx CI.

What's changed?

• source_lcao/module_ri/conv_coulomb_pot_k.h: the scalar overloads of Conv_Coulomb_Pot_K::cal_orbs_ccp / cal_orbs_ccp_spencer are now constrained with std::enable_if<!is_std_vector<T>::value>, so for std::vector arguments only the recursive vector overload participates in overload resolution. icpc's EDG frontend cannot order the two function templates by partial ordering and reported "more than one instance of overloaded function matches the argument list"; with the scalar candidate SFINAE'd out there is exactly one viable overload. GCC/icpx behavior is unchanged (they already picked the vector overload via partial ordering).

Note: get_rmesh_proportion in the same header keeps the old primary-template + .cpp-only explicit specialization pattern, but it has no call sites and is never instantiated, so it does not trigger the issue; it can be cleaned up in a follow-up if desired.

Governance Notes

• INPUT/docs changes: none; no user-visible behavior change.
• Core module impact: module_ri only (Coulomb-potential convolution helpers used by EXX/RDMFT); no runtime behavior change.
• Exceptions requested: none.

[Copilot]

🟢 Approval recommended

The change is narrowly scoped to template overload participation and aligns with the reported icpc ambiguity without introducing behavioral changes.

Pull request overview

This PR resolves an Intel Classic (icpc/EDG) compilation failure caused by ambiguous overload resolution between the scalar and recursive std::vector template overloads of Conv_Coulomb_Pot_K::cal_orbs_ccp (and the Spencer variant) in the RI Coulomb-convolution helpers.

Changes:

• Constrain the scalar cal_orbs_ccp / cal_orbs_ccp_spencer templates via SFINAE so they do not participate in overload resolution when T is a std::vector, ensuring icpc selects the intended recursive vector overload.

File summaries

File	Description
source/source_lcao/module_ri/conv_coulomb_pot_k.h	Adds a std::vector type trait and SFINAE constraints to prevent icpc overload ambiguity for nested-vector call sites.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.