Describe the Code Quality Issue
In namespace hamilt, the kinetic-energy operator exists as two unrelated primary class templates whose names differ only by the case of one letter:
hamilt::EKinetic — LCAO version, source/source_lcao/module_operator_lcao/ekinetic.h, partial specialization EKinetic<OperatorLCAO<TK, TR>>.hamilt::Ekinetic — PW version, source/source_pw/module_pwdft/op_pw_ekin.h, partial specialization Ekinetic<OperatorPW<T, Device>>.
This is the only operator pair with such a split. All sibling operator pairs (Veff, Meta, Nonlocal) follow a single-name convention: one primary template name shared between the PW and LCAO headers (with the primary body guarded by a shared __VEFFTEMPLATE-style inner macro), each side contributing its own partial specialization. Under that convention, Veff is one template with two specializations — greppable and unambiguous. The kinetic pair deviates: two templates, two names, one letter apart.
This naming already caused real harm, not just confusion:
Suggested fix
Either direction resolves the ambiguity:
- Unify with the sibling convention — one primary template name (e.g.
Kinetic or EKinetic) with OperatorPW- and OperatorLCAO-based partial specializations. Prefer declaring the primary template once in a shared location instead of relying on the fragile shared __XXXTEMPLATE guard macros (which also use reserved double-underscore identifiers).
- Rename the PW class to a clearly distinct name, e.g.
EkineticPW (precedent: OperatorEXXPW exists alongside OperatorEXX).
Direction 2 is the smaller change; direction 1 is more consistent with Veff/Meta/Nonlocal.
Additional Context
Surfaced while investigating #7927 (Intel classic build failure); the immediate guard-macro hazard for this pair was cleaned up in #7929, but the case-only naming itself remains.
Task list for Issue attackers (only for developers)
Describe the Code Quality Issue
In namespace
hamilt, the kinetic-energy operator exists as two unrelated primary class templates whose names differ only by the case of one letter:hamilt::EKinetic— LCAO version,source/source_lcao/module_operator_lcao/ekinetic.h, partial specializationEKinetic<OperatorLCAO<TK, TR>>.hamilt::Ekinetic— PW version,source/source_pw/module_pwdft/op_pw_ekin.h, partial specializationEkinetic<OperatorPW<T, Device>>.This is the only operator pair with such a split. All sibling operator pairs (
Veff,Meta,Nonlocal) follow a single-name convention: one primary template name shared between the PW and LCAO headers (with the primary body guarded by a shared__VEFFTEMPLATE-style inner macro), each side contributing its own partial specialization. Under that convention,Veffis one template with two specializations — greppable and unambiguous. The kinetic pair deviates: two templates, two names, one letter apart.This naming already caused real harm, not just confusion:
__EKINETICTEMPLATEfrom the sibling pattern even though the class names no longer match. Co-including both headers in one TU then silently skipped the second primary template, producing the misleading errorEKinetic is not a template(on any compiler, include-order dependent). This obscured the diagnosis of the Intel classic build failure in Intel classic (icpc) build fails: "EKinetic is not a template" — out-of-line destructor of a partial specialization named with a template argument list #7927.EkineticfromEKineticwithout careful reading; the icpc failure report was initially misattributed partly for this reason.Suggested fix
Either direction resolves the ambiguity:
KineticorEKinetic) withOperatorPW- andOperatorLCAO-based partial specializations. Prefer declaring the primary template once in a shared location instead of relying on the fragile shared__XXXTEMPLATEguard macros (which also use reserved double-underscore identifiers).EkineticPW(precedent:OperatorEXXPWexists alongsideOperatorEXX).Direction 2 is the smaller change; direction 1 is more consistent with
Veff/Meta/Nonlocal.Additional Context
Surfaced while investigating #7927 (Intel classic build failure); the immediate guard-macro hazard for this pair was cleaned up in #7929, but the case-only naming itself remains.
Task list for Issue attackers (only for developers)