Forging is not yet compatible with Qiskit Nature 0.7 and higher

[garrison]

I haven't figured out exactly why yet, but the merging of https://github.com/qiskit-community/qiskit-nature/pull/1248 broke our "development version tests."

=================================== FAILURES ===================================
_ TestEntanglementForgingGroundStateSolver.test_entanglement_forging_vqe_hydrogen _

self = <test.forging.test_entanglement_forging_ground_state_solver.TestEntanglementForgingGroundStateSolver testMethod=test_entanglement_forging_vqe_hydrogen>

    @unittest.skipIf(not pyscf_available, "pyscf is not installed")
    def test_entanglement_forging_vqe_hydrogen(self):
        """Test of applying Entanglement Forged Solver to compute the energy of a H2 molecule."""
        # Set up the ElectronicStructureProblem
        driver = PySCFDriver(
            atom="H .0 .0 .0; H .0 .0 0.735",
            unit=DistanceUnit.ANGSTROM,
            charge=0,
            spin=0,
            basis="sto3g",
        )
        driver.run()
        problem = driver.to_problem(basis=ElectronicBasis.AO)
        qcschema = driver.to_qcschema()
        mo_coeff = get_ao_to_mo_from_qcschema(qcschema).coefficients.alpha["+-"]

        # Specify the ansatz and bitstrings
        ansatz = EntanglementForgingAnsatz(
            circuit_u=TwoLocal(2, [], "cry", [[0, 1], [1, 0]], reps=1),
            bitstrings_u=[(1, 0), (0, 1)],
        )

        # Set up the entanglement forging vqe object
        solver = EntanglementForgingGroundStateSolver(
            ansatz=ansatz,
            optimizer=SPSA(maxiter=0),
            initial_point=[0.0, np.pi / 2],
            mo_coeff=mo_coeff,
        )

        # Solve for the ground state energy
>       results = solver.solve(problem)

test/forging/test_entanglement_forging_ground_state_solver.py:125: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
circuit_knitting/forging/entanglement_forging_ground_state_solver.py:299: in solve
    hamiltonian_terms = self.get_qubit_operators(problem)
circuit_knitting/forging/entanglement_forging_ground_state_solver.py:399: in get_qubit_operators
    hamiltonian_ops, self._energy_shift = cholesky_decomposition(
circuit_knitting/forging/cholesky_decomposition.py:110: in cholesky_decomposition
    h_1_op, h_chol_ops, freeze_shift, _, _ = _get_fermionic_ops_with_cholesky(
circuit_knitting/forging/cholesky_decomposition.py:266: in _get_fermionic_ops_with_cholesky
    coeff_mo = copy.copy(mo_coeff)
../../miniconda3/lib/python3.9/copy.py:102: in copy
    return _reconstruct(x, None, *rv)
../../miniconda3/lib/python3.9/copy.py:271: in _reconstruct
    if hasattr(y, '__setstate__'):
.tox/py/lib/python3.9/site-packages/qiskit_nature/second_q/operators/tensor.py:194: in __getattr__
    array = self.__array__()
.tox/py/lib/python3.9/site-packages/qiskit_nature/second_q/operators/tensor.py:145: in __array__
    return self._array
.tox/py/lib/python3.9/site-packages/qiskit_nature/second_q/operators/tensor.py:194: in __getattr__
    array = self.__array__()
.tox/py/lib/python3.9/site-packages/qiskit_nature/second_q/operators/tensor.py:145: in __array__
    return self._array
E   RecursionError: maximum recursion depth exceeded
!!! Recursion detected (same locals & position)

[garrison]

Specifically, the changed behavior relates to the following line:

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/8c23c30e0ee4c2bb81e3766ade07ea1dc0ebb98c/test/forging/test_entanglement_forging_ground_state_solver.py#L108

Before https://github.com/qiskit-community/qiskit-nature/pull/1248 landed, this line resulted in mo_coeff being an ndarray. But now, with the most recent Qiskit Nature main, it is instead a qiskit_nature.second_q.operators.tensor.Tensor.

[garrison]

We should also revert #407 as part of the fix to this, when that day comes.

[garrison]

I've added the "urgent" label, because now that https://github.com/Qiskit/qiskit/pull/11086 (removal of qiskit.algorithms) has been merged to Qiskit, CKT no longer works with Qiskit main, which is expected to become Qiskit 1.0. The problem is that we are now pinned to qiskit-nature>=0.6.0, < 0.7, but the latest Qiskit Nature consistent with that constraint still imports -- in various places -- from qiskit.algorithms and nowhere from qiskit_algorithms.

One thing we could ask for is a qiskit-nature 0.6.3 release that depends on and imports from qiskit_algorithms instead of qiskit.algorithms, so that code relying on Qiskit Nature 0.6.X can continue to work. Another option is to make our code compatible with Qiskit Nature 0.7 (this issue). And, of course, another option is to continue working toward removing the Qiskit Nature dependency altogether (#275). No matter what we choose, it looks like Jan 31 is our deadline if we want to continue being compatible with the latest Qiskit release (and we have much less time if we want to be compatible with Qiskit 1.0.0pre1).