HHL.solve() doesn't use specified quantum_instance.

[ahehn-nv]

Environment

• Qiskit Terra version: 0.21.2
• Python version: all
• Operating system: Linux

What is happening?

HHL.solve() in qiskit/algorithms/linear_solvers/hhl.py constructs a quantum circuit qc, stores it in solution.state and calls HHL._calculate_norm(self, qc). This function performs an evaluation of the quantum circuit "qc" using qiskit's built-in StateVector simulator and does not use the quantum_instance provided to the constructor of hhl: https://github.com/Qiskit/qiskit-terra/blob/070b9e214718b413f3d2f1142ffdc07d1d750c91/qiskit/algorithms/linear_solvers/hhl.py#L238 Is this intentional?

The tutorial https://qiskit.org/textbook/ch-applications/hhl_tutorial.html shows the following example at the end of section 4A

    from qiskit import Aer

    backend = Aer.get_backend('aer_simulator')
    hhl = HHL(1e-3, quantum_instance=backend)

    accurate_solution = hhl.solve(matrix, vector)
    classical_solution = NumPyLinearSolver().solve(matrix, vector / np.linalg.norm(vector))

    print(accurate_solution.euclidean_norm)
    print(classical_solution.euclidean_norm)

suggesting that quantum_instance allows the use of qiskit-aer in HHL.solve().

Additional information: hhl._calculate_norm(self, qc) boils down to an evaluation via https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/opflow/state_fns/circuit_state_fn.py#L258 in CircuitStateFn.to_matrix():

[3]   /usr/local/lib/python3.8/dist-packages/qiskit/algorithms/linear_solvers/hhl.py(525)solve()
-> solution.euclidean_norm = self._calculate_norm(solution.state)
[4]   /usr/local/lib/python3.8/dist-packages/qiskit/algorithms/linear_solvers/hhl.py(220)_calculate_norm()
-> norm_2 = (~StateFn(observable) @ StateFn(qc)).eval()
[5]   /usr/local/lib/python3.8/dist-packages/qiskit/opflow/list_ops/composed_op.py(141)eval()
-> return reduce(tree_recursive_eval, reversed(eval_list))
[6]   /usr/local/lib/python3.8/dist-packages/qiskit/opflow/list_ops/composed_op.py(131)tree_recursive_eval()
-> return l_arg.eval(r)
[7]   /usr/local/lib/python3.8/dist-packages/qiskit/opflow/state_fns/operator_state_fn.py(249)eval()
-> front = front.eval()
[8]   /usr/local/lib/python3.8/dist-packages/qiskit/opflow/state_fns/circuit_state_fn.py(308)eval()
-> vector_state_fn = self.to_matrix_op().eval()
[9]   /usr/local/lib/python3.8/dist-packages/qiskit/opflow/state_fns/state_fn.py(429)to_matrix_op()
-> return VectorStateFn(self.to_matrix(massive=massive), is_measurement=self.is_measurement)
[10] > /usr/local/lib/python3.8/dist-packages/qiskit/opflow/state_fns/circuit_state_fn.py(251)to_matrix()
-> def to_matrix(self, massive: bool = False) -> np.ndarray:

How can we reproduce the issue?

Script based on the tutorial https://qiskit.org/textbook/ch-applications/hhl_tutorial.html :

import numpy as np
from qiskit.algorithms.linear_solvers.hhl import HHL
from qiskit.providers.aer.backends import AerSimulator
from qiskit.algorithms.linear_solvers.matrices.tridiagonal_toeplitz import TridiagonalToeplitz

matrix = np.array([[1, -1/3], [-1/3, 1]])
vector = np.array([1, 0])

backend = AerSimulator()
hhl = HHL(1e-3, quantum_instance=backend)

accurate_solution = hhl.solve(matrix, vector)
print(accurate_solution.euclidean_norm)

What should happen?

HHL should use the backend (e.g., qiskit-aer simulator) passed to the HHL constructor for the circuit evaluation when HHL.solve() is called.

Any suggestions?

No response

[woodsp-ibm]

@anedumla Any comment on this one.

@ahehn-nv I will note that as from the upcoming release of Terra, in early October, HHL will be deprecated and later removed from Terra https://github.com/Qiskit/qiskit-terra/blob/bcec9a314c68d9412a89904701d45491a68a12c0/qiskit/algorithms/linear_solvers/hhl.py#L112-L114 The tutorial will have to be amended accordingly too.

[anedumla]

@woodsp-ibm it must be a leftover from an older version of HHL and the part with the quantum instance was not updated - my bad.

I think one of the reasons I did not notice is that we are not really using it on real hardware, which is the reason it is being deprecated. At the moment I am working on moving it to the research repo - is there something else that needs to be amended in the tutorial other than changing the imports from qiskit-terra to qisit-research?

[woodsp-ibm]

I did not know that the algorithm would be moved over - as you see from the deprecation notice we are referring to the textbook. But that uses this algo as part of it so maybe that will be updated to use what you are putting on qiskit-research and the deprecation message can stay referring to the textbook via which people will see it on qiskit-research?

Are you also updating the HHL to use primitives when you relocate it? QuantumInstance is planned for deprecation/removal - the other algorithms remaining here are all being refactored over to use primitives for this upcoming release (0.22). The original algorithm using QuantumInstance are planned to be deprecated in 0.23 (at present they are marked pending deprecation and will work alongside the primitive based ones for one release before being deprecated)

[anedumla]

Actually turns out that there is some pendant discussion as to which repo it should be moved, so will have to wait for that decision before updating the textbook.

Regarding the primitives - I was not aware QuantumInstace was going to be deprecated too, thanks for the notice. Will update that too once we decide where to put it.

[woodsp-ibm]

@anedumla As HHL is deprecated here and you have the code in another repository linked from the textbook what to do with the issues here. I don't think there is any intent of altering the code here to potentially address any of these since its now deprecated. Do you want to take note of these and maybe create issues in the other repository. At some point these will be closed as not planned. So with this issue in the list too (first one), the ones relevant to HHL I can find are

#8735 #8332 #8102 #8069 #7926