Migrer de BackendV1 vers BackendV2
La classe Qiskit BackendV1 est devenue obsolète et sera retirée du service. Ce guide de migration décrit les petits ajustements que vous devez effectuer si vous utilisez un fournisseur qui est passé de BackendV1 vers BackendV2.
Si vous utilisez 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 à l'adresse Qiskit SDK une couche d'abstraction d'abstraction permettant de raisonner sur les ordinateurs quantiques dans le cadre du SDK. La première itération du modèle a été introduite avec la BackendV1 classe. Cette classe stocke les informations du backend dans une série de conteneurs de données de conteneurs de données, à savoir les conteneurs BackendConfiguration et BackendProperties .
La BackendV2 a redéfini l'accès utilisateur pour la plupart des propriétés du backend afin de les faire fonctionner avec les structures de données natives de Qiskit et d'avoir des schémas d'accès plus plats d'accès plus plats. Le cœur du modèle BackendV2 est le modèle Target une représentation de la QPU qui contient les contraintes de transpilation que Qiskit peut utiliser pour optimiser les circuits pour l'exécution.
Le site Qiskit SDK a été mis à jour pour fonctionner exclusivement avec des BackendV2 entrées, et la plupart des fournisseurs sont passés de BackendV1 à BackendV2. Il est prévu que les fournisseurs existants suppriment l'ancien accès dans la mesure du possible afin d'assurer une migration gracieuse, mais les utilisateurs devront éventuellement adapter leur code.
Le principe qui sous-tend BackendV2 est le suivant que la plupart des informations concernant un backend sont contenues dans son Target et les attributs du backend interrogent souvent son attribut son attribut BackendV2.target pour obtenir des informations. Cependant, dans de nombreux cas, les attributs ne fournissent qu'un sous-ensemble d'informations que la cible peut contenir qu'un sous-ensemble d'informations que la cible peut contenir. Par exemple, backend.coupling_map renvoie un CouplingMap construit à partir de l'élément Target accessible dans l'attribut BackendV2.target attribut. Cependant, la cible peut contenir des instructions qui opèrent sur plus de deux qubits (qui ne peuvent pas être représentées dans une CouplingMap) ou elle peut contenir des instructions qui n'opèrent que sur un sous-ensemble de qubits (ou deux liens de qubits, pour une instruction à deux qubits), qui ne seront pas détaillés dans la carte de couplage complète renvoyée par la carte de couplage détaillée dans la carte de couplage complète renvoyée par BackendV2.coupling_map. Ainsi, en fonction de votre cas d'utilisation, il peut être nécessaire d'aller plus loin que l'accès équivalent avec BackendV2.
Changements spécifiques dans BackendV2
La plupart des attributs sont directement remplacés, ce qui simplifie les efforts de migration. Le seul point de divergence entre les interfaces se situe au niveau de l'interface CouplingMap.
Voici un tableau d'exemples de schémas d'accès en BackendV1 et le nouveau formulaire avec BackendV2.
Faites défiler l'écran vers la droite pour voir les notes importantes.
Remarques | ||
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Le retour de BackendV2 est un objet CouplingMap objet. En BackendV1 il s'agit d'une liste de bords. En outre, il ne s'agit que d'une vue des informations contenues dans backend.target , qui peuvent n'être qu'un sous-ensemble des informations contenues dans l'objet Target objet. |
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 que l'objet met en œuvre Backend que l'objet implémente, 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 | L'option BackendV2 renvoie une liste de noms d'opérations contenus dans l'attribut backend.target . Les Target peut contenir plus d'informations que ne le permet cette liste de noms. Par exemple, certaines opérations ne fonctionnent que sur un sous-ensemble de qubits, et certains noms mettent en œuvre 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 | En BackendV2le taux d'erreur pour l'opération Measure sur un qubit donné est utilisé pour modéliser l'erreur de lecture. Toutefois, un objet BackendV2 peut mettre en œuvre plusieurs types de mesures et les répertorier séparément dans un fichier Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | En BackendV2la durée de l'opération Measure sur un qubit donné est utilisée pour modéliser la longueur de lecture. Toutefois, un objet BackendV2 peut mettre en œuvre plusieurs types de mesures et les répertorier séparément dans un fichier Target. |