Von BackendV1 zu migrieren BackendV2
Die Qiskit BackendV1 klasse ist veraltet und wird aus dem Dienst genommen. In diesem Migrationsleitfaden werden die kleinen Anpassungen beschrieben, die Sie vornehmen müssen, wenn Sie einen Anbieter nutzen, der ein Upgrade von BackendV1 auf BackendV2.
Wenn Sie ausschließlich qiskit_ibm_runtime und qiskit_aer verwenden, besteht kein Handlungsbedarf. Das Paket qiskit_ibm_runtime hat immer BackendV2 verwendet, und qiskit_aer verwendet seit der Version 0.13 BackendV2 .
Hochrangige Änderungen in BackendV2
Das Qiskit Backend modell wurde entwickelt, um Qiskit SDK mit einer Abstraktionsebene auszustatten abstraktionsschicht zu bieten, die es ermöglicht, im Rahmen des SDK über Quantencomputer nachzudenken. Die erste Iteration des Modells wurde mit dem BackendV1 klasse. Diese Klasse speicherte die Backend-Informationen in einer Reihe von von Datencontainern, nämlich den BackendConfiguration und BackendProperties klassen.
Die BackendV2 klasse definiert neu benutzerzugriff für die meisten Backend-Eigenschaften neu definiert, damit sie mit nativen Qiskit-Datenstrukturen arbeiten und flachere zugriffsmuster haben. Der Kern des BackendV2 modells ist die Target klasse, eine Darstellung der QPU, die die Transpilationsbeschränkungen enthält, die Qiskit zur Optimierung von Schaltungen für die Ausführung verwenden kann.
Die Website Qiskit SDK wurde aktualisiert und arbeitet nun ausschließlich mit BackendV2 eingaben, und die meisten Anbieter haben ein Upgrade von BackendV1 auf BackendV2. Es wird erwartet, dass die bestehenden Anbieter den alten Zugang nach Möglichkeit abschaffen, um eine reibungslose Migration zu ermöglichen, aber letztendlich werden die Nutzer ihren Code anpassen müssen.
Das Prinzip hinter BackendV2 ist dass die meisten Informationen über ein Backend in dessen Target objekt enthalten sind, und die Attribute des Backends fragen oft sein BackendV2.target -Attribut ab, um Informationen zurückzugeben. In vielen Fällen liefern die Attribute jedoch nur eine Teilmenge der Informationen, die das Ziel enthalten kann. Zum Beispiel, backend.coupling_map gibt eine CouplingMap zurück, das aus der Target zugänglich im BackendV2.target attribut. Das Ziel kann jedoch Folgendes enthalten anweisungen enthalten, die mit mehr als zwei Qubits arbeiten (die nicht in einem Standardformat dargestellt werden können) CouplingMap) oder es könnte Anweisungen enthalten, die nur auf einer Teilmenge von Qubits (oder zwei Qubit-Verbindungen für eine Anweisung mit zwei Qubits), die nicht nicht detailliert in der vollständigen Kopplungskarte, die von BackendV2.coupling_map. Abhängig von Ihrem Anwendungsfall, könnte es notwendig sein, tiefer zu schauen als nur den gleichwertigen Zugriff mit BackendV2.
Spezifische Änderungen in BackendV2
Für die meisten Attribute gibt es einen direkten Ersatz, was den Migrationsaufwand vereinfacht. Der einzige Punkt, an dem die Schnittstellen nicht übereinstimmen, ist in der CouplingMap.
Es folgt eine Tabelle mit Beispielen von Zugriffsmustern in BackendV1 und dem neuen Formular mit BackendV2.
Scrollen Sie nach rechts, um wichtige Hinweise zu sehen.
Hinweise | ||
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Die Rückgabe von BackendV2 ist ein CouplingMap objekt. In BackendV1 handelt es sich um eine Kantenliste. Außerdem ist dies nur eine Ansicht der in backend.target enthaltenen Informationen, die möglicherweise nur eine Teilmenge der in dem Target objekts. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | Das Attribut BackendV2.version steht für die Version der abstrakten Backend schnittstelle, die das Objekt implementiert, während BackendV2.backend_version Metadaten über die Version des Backends selbst sind. |
backend.configuration().basis_gates | backend.operation_names | Die Funktion BackendV2 gibt eine Liste der im Attribut backend.target enthaltenen Vorgangsnamen zurück. Die Target kann mehr Informationen enthalten, als durch diese Liste von Namen ausgedrückt werden kann. Beispielsweise funktionieren einige Operationen nur auf einer Teilmenge von Qubits, und einige Namen implementieren das gleiche Gatter mit unterschiedlichen Parametern. |
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 | Unter BackendV2wird die Fehlerrate für die Measure operation an einem bestimmten Qubit verwendet, um den Auslesefehler zu modellieren. Allerdings kann ein BackendV2 objekt kann jedoch mehrere Messtypen implementieren und diese separat in einer Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | Unter BackendV2wird die Dauer für die Measure operation an einem bestimmten Qubit verwendet, um die Ausleselänge zu modellieren. Allerdings kann ein BackendV2 objekt kann jedoch mehrere Messtypen implementieren und diese separat in einer Target. |