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: https://github.com/Qiskit/qiskit-ibm-runtime/issues/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.

[chin-jey]

Hi @adekusar-drl , no reason to re-open it. I don't find your answer really helpful though: QuantumInstance seems to be soon to be deprecated, then keep using it ain't a solution. I miss the intuition behind these primitives. What do they add new and why the old good Quantuminstance was not good enough ? Let me say again that I'm not using qiskit machine learning neural networks so assuming I had some quantum algorithms, now I'm forced to switch to either an Estimator or a Sampler. These new API seems not really needed to me, but I must be missing something important. What is the advantage, practically and what made you decide to switch to them deprecating QuantumInstance ?

[adekusar-drl]

Sorry, I missed the reply. The intuition is to bring as much circuit processing logic closer to hardware as possible. Ultimately, primitives should provide the same level of high level functionality as QuantumInstance does. This includes parameter management, transpilation, caching, error mitigation and so on. If you don't use machine learning that's fine. Current primitives provide basic computational blocks and many things can be built on top of them. If you use QuantumInstance then you, perhaps, execute plain circuit. Curious what exactly you can't do with primitives?