Usage with qiskit runtime

[chin-jey]

What should we add?

Since you're deprecating the runtime package, could you show how to use qiskit_ibm_runtime instead, e.g. adapting the tutorial already available in v0.4.0 doc ?

[adekusar-drl]

Thanks for raising this issue. In general, once the QML algorithms are migrated to the primitives, they can make use of sessions introduced in qiskit-ibm-runtime. Thus, when a session is instantiated and primitive instances are created on top of it, you should get a similar to runtime program behaviour. Take a look at the example here: https://github.com/Qiskit/qiskit-ibm-runtime. I agree this example may be not enough to understand the mechanics behind the hood, but should give a first impression.

[chin-jey]

Thanks for the answer. Nevertheless, I don't get how to use this new runtime considering that, from the backend side, the algorithms only require a QuantumInstance while hiding all the computation, which is good (it's what I expect from a library algorithm) but the runtime seems to be working at circuit level

[adekusar-drl]

All algorithms are being migrated to primitives. There'a a new quantum kernel implementation already, see https://github.com/Qiskit/qiskit-machine-learning/blob/main/qiskit_machine_learning/kernels/fidelity_quantum_kernel.py. Neural networks will be updated soon as well, see #436 and #470. None of the new algorithms require QuantumInstance, but rather a primitive.

So, the code may look like (if I did not miss anything):

from qiskit.algorithms.state_fidelities import ComputeUncompute
from qiskit_ibm_runtime import QiskitRuntimeService, Session, Options, Sampler
from qiskit_machine_learning.algorithms import QSVC
from qiskit_machine_learning.kernels import FidelityQuantumKernel

service = QiskitRuntimeService()
options = Options(optimization_level=1)
options.execution.shots = 1024

with Session(service=service, backend="ibmq_qasm_simulator") as session:
    sampler = Sampler(session=session, options=options)
    fidelity = ComputeUncompute(sampler)
    kernel = FidelityQuantumKernel(fidelity=fidelity)
    qsvc = QSVC(quantum_kernel=kernel)
    ...

Hope it helps.

[chin-jey]

I believe it's not clear to me the difference between terra primitives and qiskit runtime primitives. ComputeUncompute seems to be requiring a terra primitive, how can you pass a qiskit runtime one ?

[adekusar-drl]

ComputeUncompute requires an instance of BaseSampler and both implementations, Sampler from Terra and Sampler from the runtime service, extend this base interface.

[adekusar-drl]

@t-imamichi just for information, see above. We need an extended documentation on the primitives :)

[chin-jey]

@adekusar-drl Why do you have two BaseSampler classes ` (and so for the other primitives) though ? For instance, terra and qiskit runtime

[adekusar-drl]

I do believe those base classes from Runtime are just copies from Terra and should go away. I don't recall why initially they were copied, but there's an issue to remove them: Qiskit/qiskit-ibm-runtime#253

Actual implementations, the classes that extends the base ones, are different as the Runtime primitives makes use of cloud stuff.

[chin-jey]

thanks. Can you also clarify what is the rationale behind the primitives ? previously all the algorithms and the neural networks had a QuantumInstance , now I'm puzzled by the fact that we have either a Sampler or an Estimator. What is the difference and how to choose ? I read the documentation, but still I didn't find a good reason for this new "dualism".

[adekusar-drl]

First of all, I suggest to take a look at the documentation of the primitives again: https://qiskit.org/documentation/apidoc/primitives.html. There are two original QNNs: CircuitQNN and OpflowQNN. The former works with bit strings as an output of a circuit, the latter deals with circuits and observables and the output is expectation value that can be interpreted at the post-processing step. Now, there are direct replacements of these QNNs: SamplerQNN and EstimatorQNN. So, nothing new in general at the QNN level.

Then, we may consider that both Sampler and Estimator is indirect replacement of QuantumInstance. Now, where a quantum instance is required you may pass either a sampler or an estimator, depending on the algorithm. They are a higher level abstraction and don't require users to execute circuits manually. So, some circuit execution logic may be moved to a lower level, closer to hardware.

They also replace qiskit runtimes. Thus, you should queue less for quantum resources on cloud if they are instantiated from a runtime session.

Hope this clarifies a bit.

[chin-jey]

@adekusar-drl thanks. In my case I have some code that directly uses a QuantumInstance without qiskit neural networks. Based on your explanation I guess the primitive that fits more the previous work done by a Quantum instance is the Estimator. I find overall this change very confusing and much less straightforward than the QuantumInstance.

[adekusar-drl]

You can use QuantumInstance and both neural networks CircuitANN and OpflowQNN, they are not yet deprecated. Do you have other questions or I can close the issue?

[adekusar-drl]

I'm closing the issue, feel free to re-open or submit a new one.