[Dependency] module_gint includes source_lcao for the dH sparse output; two headers include more than they use #8232

Describe the Code Quality Issue

Under the module layering, source_hamilt (Hamiltonian operators) sits below the method modules source_pw and source_lcao, and source_pw sits below source_lcao. A few headers break this order, or include a much broader header than they need.

1. module_gint depends on LCAO output code

source_hamilt/module_gint/gint_dvlocal.h includes:

• source_lcao/lcao_hs_arrays.h (line 7)
• source_lcao/module_ri/abfs_vector3_order.h (line 8)

Gint_dvlocal mixes two jobs:

• cal_dvlocal() integrates ⟨φ|V|∇φ⟩ on the real-space grid into three HContainers. This is grid integration and belongs in module_gint.
• cal_dvlocal_R_sparse() and distribute_pvdpR_sparse() convert that result into the LCAO_HS_Arrays sparse format written by out_mat_dh. This is LCAO output code. It is the only reason for the two includes above. Its only caller is sparse_format::cal_dH in source_lcao/spar_dh.cpp, reached through the wrapper ModuleGint::cal_dvlocal_R_sparse in gint_interface.h.

A forward declaration does not help, because gint_dvlocal.cpp uses the members of both types.

2. source_pw includes an LCAO RI header for one enum

source_pw/module_pwdft/op_pw_exx.h:11 includes source_lcao/module_ri/conv_coulomb_pot_k.h, but only uses Conv_Coulomb_Pot_K::Coulomb_Type. That enum is defined in source_hamilt/module_xc/coulomb_config.h.

3. Two headers include more than they use

These are not layering violations, but they widen what every includer depends on:

• source_hamilt/module_xc/kernels/xc_functional_op.h includes source_psi/psi.h. It only needs GetTypeReal, which it already gets from source_base/macros.h, and the base_device tags from source_base/module_device/types.h.
• source_hamilt/module_vdw/vdwd2_parameters.h includes source_io/module_parameter/parameter.h, which brings in the global PARAM object. It only names Input_para, from input_parameter.h, and none of its includers use PARAM.

Suggested fix

1. Move the sparse conversion out of Gint_dvlocal into source_lcao, next to its only caller. It can read the grid result through the existing get_pvdpRx/y/z() getters. Keep cal_dvlocal() in module_gint.
2. In the three headers of items 2 and 3, include the narrower header that declares what they use.

No behavior or output change should result.

Acceptance

• source_hamilt/module_gint no longer includes source_lcao.
• op_pw_exx.h no longer includes source_lcao.
• The full-feature build and the build without LCAO compile, and the unit and integration tests pass.

Additional Context

• Part of [Dependency] Operator layer source_hamilt depending back on electronic state/methods #7599 and [Dependency] Method-layer lateral coupling pw ↔ lcao #7604.
• Two related upward includes in source_hamilt are better handled separately, because open PRs touch the same files:
  • module_xc/exx_info_ri.h:4 → conv_coulomb_pot_k.h: same fix as item 2. Overlaps feat(librpa): strict 2D/3D Coulomb kernels and 2D reader-v1 producer outputs #8176.
  • module_surchem/cal_pseudo.cpp:3 → source_pw/module_pwdft/stru_fac.h: belongs with moving Structure_Factor out of source_pw. Overlaps Feature: periodic self-consistent continuum solvation (SCCS) Step4: delayed start, relax, diagnostics and out_sol #8222.
• Testing note: the conversion in item 1 only runs with out_mat_dh 1, nspin 2 and gamma_only 0. No current integration case reaches that path. tests/integrate/validation_tools/props_mat.sh also compares only the spin-1 dH files.

Task list for Issue attackers (only for developers)

• Identify the specific code file or section with the code quality issue.
• Investigate the issue and determine the root cause.
• Research best practices and potential solutions for the identified issue.
• Refactor the code to improve code quality, following the suggested solution.
• Ensure the refactored code adheres to the project's coding standards.
• Test the refactored code to ensure it functions as expected.
• Update any relevant documentation, if necessary.
• Submit a pull request with the refactored code and a description of the changes made.