Support for V2 primitives

[edoaltamura]

Introduction

This PR introduces support for V2 Primitives within the EstimatorQNN and SamplerQNN high-level classes, resolving compatibility issues for users running experiments on Qiskit IBM Runtime real backends. The addition enables transitioning between local simulations with V1 primitives and hardware executions with V2 primitives, meeting the new requirements for Qiskit Runtime ISA circuits.

Problem description

EstimatorQNN and SamplerQNN default to Estimator and Sampler from qiskit.primitives, which only supports V1 primitives. However, Qiskit IBM Runtime requires V2 primitives (introduced in Qiskit Machine Learning 0.8.0) to run jobs on real quantum backends. Using the V1 primitives results in runtime errors because they are incompatible with Qiskit Runtime’s requirements for structured Primitive Unified Blocks (PUBs) and ISA circuit format.

Changes in This PR

• Conditional support for V2 Primitives. Added a check in EstimatorQNN and SamplerQNN to detect if a V2 primitive (EstimatorV2 or SamplerV2) from qiskit_ibm_runtime is provided. If a V2 primitive is detected, the class will handle it automatically, allowing direct submission of circuits to hardware backends. The output of the jobs (both simulated and hardware) remains the same as before. For instance, where the output used to be quasi-probabilities, now the same quasi-probabilities are computed from the raw counts.

• Backward compatibility with V1 Primitives: Users can continue to use V1 primitives (e.g., SamplerV1 and EstimatorV1) for local simulations with Qiskit Aer. This ensures that existing workflows are unaffected and that users can seamlessly transition to real backends by updating the backend and primitive definitions.

Warning

The V1 Primitives are deprecated as of Qiskit Machine Learning v.0.8.0 and will no longer be officially supported. V2 Primitives will continue to be supported. V1 Primitives will be removed in Qiskit Machine Learning v.0.9.

• Support for ISA Circuits: These updates ensure that circuits and observables are compatible with Qiskit Runtime’s ISA requirements. Added logic to handle circuit transpilation for ISA compatibility when using V2 primitives, with proper mapping of input and weight parameters, especially for composed feature maps and ansatz circuits.

Note

This update is expected to allow running Qiskit Machine Learning workloads on IBM quantum hardware using Qiskit IBM Runtime (a version of it that includes V2 Primitives).

Future considerations

• Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.

• ISA circuit optimization: Further work may be needed to refine circuit transpilation and measurement processes for specific hardware constraints and optimize performance across different backends.

Details and comments

Fixes #742
Fixes #786
Fixes #810
Fixes #839
Fixes #840

Auxiliary issues closed:
Fixes OkuyanBoga#35

Related issues Algorithms:
qiskit-community/qiskit-algorithms#165
qiskit-community/qiskit-algorithms#194
qiskit-community/qiskit-algorithms#164
qiskit-community/qiskit-algorithms#136
qiskit-community/qiskit-algorithms#137

Related issues - others:
qiskit-community/qiskit-finance#338

[woodsp-ibm]

From above:

Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.

V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.

[woodsp-ibm]

With V1 primitives usage being deprecated are you going to swap the notebooks/tutorials over to using V2 which ideally a user should be using now - I did not see any updated by this PR hence this comment

[OkuyanBoga]

With V1 primitives usage being deprecated are you going to swap the notebooks/tutorials over to using V2 which ideally a user should be using now - I did not see any updated by this PR hence this comment

Hi Steve, we are planning to swap the notebooks/tutorials after deprecating V1.

V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.

We thought about this but there are already enough deprecation warnings from Qiskit/Aer/Runtime.

[woodsp-ibm]

I am not sure I understand exactly

we are planning to swap the notebooks/tutorials after deprecating V1.

V1 primitives are already deprecated - with the V2 being supported now ideally those notebooks should be using V2. Even if you issue no deprecation messages from ML logically the support for V1 is being deprecated now with 0.8 with the intent to remove it completely in 0.9, Hence the notebooks being changed now for 0.8 to me logically is still after the V1 support is deprecated. Even if its not part of this PR I would think it would be done for 0.8, no?

[OkuyanBoga]

I am not sure I understand exactly

we are planning to swap the notebooks/tutorials after deprecating V1.

V1 primitives are already deprecated - with the V2 being supported now ideally those notebooks should be using V2. Even if you issue no deprecation messages from ML logically the support for V1 is being deprecated now with 0.8 with the intent to remove it completely in 0.9, Hence the notebooks being changed now for 0.8 to me logically is still after the V1 support is deprecated. Even if its not part of this PR I would think it would be done for 0.8, no?

Due to time constraints, what about doing it in minor updates through 0,8?

[woodsp-ibm]

We thought about this but there are already enough deprecation warnings from Qiskit/Aer/Runtime.

v1 has long gone from Runtime. It could always be arranged, with some global flag that was set once a deprecation was issued, to make the message conditional on this flag not being set such that at least one message gets emitted by ML such people are aware of this. They would have been seeing deprecation messages for some time from Qiskit and Aer and may just kinda ignore them by now such that unless they read the release notes for 0.8 they will have no idea. If it were me I would have the messages in their unconditionally such that if they find it noisy it encourages a switch to V2 which they should be using now right!

[woodsp-ibm]

Due to time constraints, what about doing it in minor updates through 0,8?

Notebooks are part of docs and docs can be republished at any time independent of a release. Hopefully they work right still with the V2 changes - in my mind having them updated would have ensured this. They would get updated and backported and the docs republished - simple as that, no version change needed as such since no new package would get released as they are are not part of what gets published to pypi - just part of the docs.

[edoaltamura]

From above:

Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.

V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.

I just added the deprecation warnings in the top-level classes.

[coveralls]

Pull Request Test Coverage Report for Build 11747274008

Details

• 173 of 218 (79.36%) changed or added relevant lines in 9 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.5%) to 91.214%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit_machine_learning/gradients/param_shift/param_shift_estimator_gradient.py	32	33	96.97%
qiskit_machine_learning/state_fidelities/compute_uncompute.py	36	39	92.31%
qiskit_machine_learning/neural_networks/estimator_qnn.py	27	31	87.1%
qiskit_machine_learning/neural_networks/sampler_qnn.py	26	30	86.67%
qiskit_machine_learning/algorithms/inference/qbayesian.py	20	28	71.43%
qiskit_machine_learning/utils/deprecation.py	7	15	46.67%
qiskit_machine_learning/gradients/param_shift/param_shift_sampler_gradient.py	10	27	37.04%

Files with Coverage Reduction	New Missed Lines	%
qiskit_machine_learning/neural_networks/sampler_qnn.py	1	92.68%

Totals
Change from base Build 11647663594:	-0.5%
Covered Lines:	4765
Relevant Lines:	5224

---

💛 - Coveralls