Is your feature request related to a problem? Please describe.
QDK/Chemistry's qubit mapping engine requires dense N^4 two-body integral tensors regardless of the underlying HamiltonianContainer type. QdkQubitMapper._run_impl() calls hamiltonian.get_two_body_integrals(), which forces full dense materialization even for containers designed to avoid it:
CholeskyHamiltonianContainer builds and caches a dense four-center tensor from its Cholesky vectors.SparseHamiltonianContainer materializes a dense N^4 vector from its sparse storage.
The mapper therefore cannot exploit integral sparsity or low Cholesky rank, either in memory (O(N^4) materialization) or in compute (iterating over zeros).
Describe the solution you'd like
QubitMapper (via the "qdk" implementation) should consume two-body integrals from CholeskyHamiltonianContainer and SparseHamiltonianContainer without ever materializing a dense N^4 tensor, while continuing to produce aQubitHamiltonian that is numerically equivalent to the dense path for the same input.
The behaviour exposed by run() and the shape of the returned QubitHamiltonian must not change for any existing caller; only memory and runtime should improve.
Acceptance criteria
- Equivalence with the dense path is the primary correctness bar. Loading the same system into a
CholeskyHamiltonianContainer (or, for sparse-friendly systems, a SparseHamiltonianContainer) and runningQubitMapper(implementation="qdk").run(hamiltonian, mapping) must produce a QubitHamiltonian that matches the dense-path result term-by-term: identical Pauli strings and coefficients matching to within 1e-12 absolute error after canonical sorting.
- The equivalence holds for the Jordan-Wigner, Bravyi-Kitaev, and parity
MajoranaMapping encodings, and for both restricted (RHF) and unrestricted (UHF) input Hamiltonians.
- Cholesky path is exercised in a parametrized pytest sweep over at least three molecular systems of differing size and symmetry (e.g. H2/STO-3G, H2O/STO-3G, N2/6-31G), cross-validated against the dense container for every supported encoding above.
- Sparse path is exercised in a parametrized pytest sweep over at least three lattice/model Hamiltonians constructed via the existing model-Hamiltonian builders (e.g.
create_hubbard_hamiltonian on a 2x2 and a 1x4 lattice, and a Pariser-Parr-Pople instance), cross-validated against the dense container for every supported encoding above.
- A new pytest module under
python/tests/ covers the above; the full existing test suite continues to pass.
- The fast paths are mentioned in
docs/source/user/comprehensive/algorithms/qubit_mapper.rst under the "qdk" implementation section, noting which HamiltonianContainer types benefit.
Is your feature request related to a problem? Please describe.
QDK/Chemistry's qubit mapping engine requires dense N^4 two-body integral tensors regardless of the underlying
HamiltonianContainertype.QdkQubitMapper._run_impl()callshamiltonian.get_two_body_integrals(), which forces full dense materialization even for containers designed to avoid it:CholeskyHamiltonianContainerbuilds and caches a dense four-center tensor from its Cholesky vectors.SparseHamiltonianContainermaterializes a dense N^4 vector from its sparse storage.The mapper therefore cannot exploit integral sparsity or low Cholesky rank, either in memory (O(N^4) materialization) or in compute (iterating over zeros).
Describe the solution you'd like
QubitMapper(via the"qdk"implementation) should consume two-body integrals fromCholeskyHamiltonianContainerandSparseHamiltonianContainerwithout ever materializing a dense N^4 tensor, while continuing to produce aQubitHamiltonianthat is numerically equivalent to the dense path for the same input.The behaviour exposed by
run()and the shape of the returnedQubitHamiltonianmust not change for any existing caller; only memory and runtime should improve.Acceptance criteria
CholeskyHamiltonianContainer(or, for sparse-friendly systems, aSparseHamiltonianContainer) and runningQubitMapper(implementation="qdk").run(hamiltonian, mapping)must produce aQubitHamiltonianthat matches the dense-path result term-by-term: identical Pauli strings and coefficients matching to within 1e-12 absolute error after canonical sorting.MajoranaMappingencodings, and for both restricted (RHF) and unrestricted (UHF) input Hamiltonians.create_hubbard_hamiltonianon a 2x2 and a 1x4 lattice, and a Pariser-Parr-Pople instance), cross-validated against the dense container for every supported encoding above.python/tests/covers the above; the full existing test suite continues to pass.docs/source/user/comprehensive/algorithms/qubit_mapper.rstunder the"qdk"implementation section, noting whichHamiltonianContainertypes benefit.