Migrer de BackendV1 vers BackendV2
La classe Qiskit BackendV1 est dépréciée et sera supprimée du service. Ce guide de migration décrit les petits ajustements à effectuer si tu utilises un
fournisseur qui est passé de BackendV1 à BackendV2.
Si tu utilises exclusivement qiskit_ibm_runtime et qiskit_aer, aucune action n'est nécessaire. Le paquet qiskit_ibm_runtime a toujours utilisé
BackendV2, et qiskit_aer utilise BackendV2 depuis la version 0.13.
Changements de haut niveau dans BackendV2
Le modèle Qiskit Backend a été conçu pour fournir au SDK Qiskit une couche d'abstraction
permettant de raisonner sur les ordinateurs quantiques dans le périmètre du SDK. La première itération du modèle a été introduite avec la classe
BackendV1. Cette classe stockait les informations du backend dans une série de conteneurs
de données, à savoir les classes BackendConfiguration et
BackendProperties.
La classe BackendV2 a redéfini l'accès utilisateur à la plupart des propriétés du backend afin
de les faire fonctionner avec les structures de données natives de Qiskit et de proposer des schémas d'accès plus plats. Le cœur du modèle
BackendV2 est la classe Target, une représentation du QPU qui contient les contraintes de
transpilation que Qiskit peut utiliser pour optimiser les circuits en vue de leur exécution.
Le SDK Qiskit a été mis à jour pour fonctionner exclusivement avec des entrées BackendV2,
et la plupart des fournisseurs sont passés de BackendV1 à BackendV2. Il est
attendu que les fournisseurs existants déprecient l'ancien accès dans la mesure du possible afin de proposer une migration progressive, mais les
utilisateurs devront à terme adapter leur code.
Le principe derrière BackendV2 est que la plupart des informations sur un backend sont contenues
dans son objet Target, et que les attributs du backend interrogent souvent son attribut BackendV2.target pour
retourner des informations. Cependant, dans de nombreux cas, les attributs ne fournissent qu'un sous-ensemble des informations que le target peut contenir.
Par exemple, backend.coupling_map retourne un objet CouplingMap construit à partir du
Target accessible via l'attribut BackendV2.target. Cependant, le target peut contenir des instructions
opérant sur plus de deux qubits (qui ne peuvent pas être représentées dans un CouplingMap) ou il peut
avoir des instructions qui n'opèrent que sur un sous-ensemble de qubits, ce qui ne sera pas détaillé dans la coupling map complète retournée par
BackendV2.coupling_map. Selon ton cas d'usage, il peut donc être nécessaire d'aller plus loin que le simple accès équivalent avec
BackendV2.
Changements spécifiques dans BackendV2
La plupart des attributs ont un remplacement direct, ce qui simplifie les efforts de migration. Le seul point de divergence entre les interfaces concerne le CouplingMap.
Voici un tableau des exemples de schémas d'accès dans BackendV1 et leur nouvelle forme
avec BackendV2.
Fais défiler vers la droite pour voir les notes importantes.
BackendV1 | BackendV2 | Notes |
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | La valeur retournée par BackendV2 est un objet CouplingMap. Dans BackendV1, il s'agit d'une liste d'arêtes. De plus, il s'agit simplement d'une vue des informations contenues dans backend.target, qui peut ne représenter qu'un sous-ensemble des informations contenues dans l'objet Target. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | L'attribut BackendV2.version représente la version de l'interface abstraite Backend qu'implémente l'objet, tandis que BackendV2.backend_version est une métadonnée sur la version du backend lui-même. |
backend.configuration().basis_gates | backend.operation_names | BackendV2 retourne une liste de noms d'opérations contenus dans l'attribut backend.target. Le Target peut contenir plus d'informations que ce qui peut être exprimé par cette liste de noms. Par exemple, certaines opérations ne fonctionnent que sur un sous-ensemble de qubits, et certains noms implémentent la même porte avec des paramètres différents. |
backend.configuration().dt | backend.dt | |
backend.configuration().dtm | backend.dtm | |
backend.configuration().max_experiments | backend.max_circuits | |
backend.configuration().online_date | backend.online_date | |
InstructionDurations.from_backend(backend) | backend.instruction_durations | |
backend.defaults().instruction_schedule_map | backend.instruction_schedule_map | |
backend.properties().t1(0) | backend.qubit_properties(0).t1 | |
backend.properties().t2(0) | backend.qubit_properties(0).t2 | |
backend.properties().frequency(0) | backend.qubit_properties(0).frequency | |
backend.properties().readout_error(0) | backend.target["measure"][(0,)].error | Dans BackendV2, le taux d'erreur de l'opération Measure sur un qubit donné est utilisé pour modéliser l'erreur de lecture. Cependant, un objet BackendV2 peut implémenter plusieurs types de mesure et les lister séparément dans un Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | Dans BackendV2, la durée de l'opération Measure sur un qubit donné est utilisée pour modéliser la longueur de lecture. Cependant, un objet BackendV2 peut implémenter plusieurs types de mesure et les lister séparément dans un Target. |