Von BackendV1 zu BackendV2 migrieren
Die Qiskit-Klasse BackendV1 wurde als veraltet markiert und wird aus dem Dienst entfernt. Dieser Migrationsleitfaden beschreibt die kleinen Anpassungen, die du vornehmen musst, wenn du einen Anbieter verwendest, der von BackendV1 auf BackendV2 umgestellt hat.
Wenn du ausschließlich qiskit_ibm_runtime und qiskit_aer verwendest, ist keine Aktion erforderlich. Das Paket qiskit_ibm_runtime verwendet stets BackendV2, und qiskit_aer nutzt BackendV2 seit Version 0.13.
Übergeordnete Änderungen in BackendV2
Das Qiskit-Backend-Modell wurde entwickelt, um dem Qiskit SDK eine
Abstraktionsschicht bereitzustellen, die das Arbeiten mit Quantencomputern im Rahmen des SDK ermöglicht. Die erste Iteration des Modells wurde mit der
Klasse BackendV1 eingeführt. Diese Klasse speicherte die Backend-Informationen in einer Reihe
von Datencontainern, nämlich den Klassen BackendConfiguration und
BackendProperties.
Die Klasse BackendV2 hat den
Benutzerzugriff auf die meisten Backend-Eigenschaften neu definiert, damit sie mit nativen Qiskit-Datenstrukturen funktionieren und flachere
Zugriffsmuster aufweisen. Der Kern des BackendV2-Modells ist die
Klasse Target, eine Darstellung des QPU, die die Transpilationsbeschränkungen enthält, die Qiskit zur Optimierung von Schaltkreisen für die Ausführung verwenden kann.
Das Qiskit SDK wurde aktualisiert, um ausschließlich mit BackendV2-Eingaben zu arbeiten,
und die meisten Anbieter haben von BackendV1 auf BackendV2 umgestellt. Es wird erwartet, dass bestehende Anbieter den alten Zugriff, wo möglich, als veraltet markieren, um eine schrittweise Migration zu ermöglichen, aber letztendlich müssen Nutzer ihren Code anpassen.
Das Prinzip hinter BackendV2 ist,
dass die meisten Informationen über ein Backend in seinem
Target-Objekt enthalten sind und die Attribute des Backends häufig das
Attribut BackendV2.target abfragen, um Informationen zurückzugeben. In vielen Fällen liefern die Attribute jedoch nur
eine Teilmenge der Informationen, die das Target enthalten kann. Beispielsweise gibt backend.coupling_map
eine CouplingMap zurück, die aus dem
Target konstruiert wurde, der über das Attribut
BackendV2.target zugänglich ist. Das Target kann jedoch
Anweisungen enthalten, die auf mehr als zwei Qubits wirken (was in einer
CouplingMap nicht dargestellt werden kann), oder Anweisungen, die nur auf
einer Teilmenge von Qubits (oder Zwei-Qubit-Verbindungen, bei einer Zwei-Qubit-Anweisung) wirken, die
in der vollständigen Coupling-Map, die von
BackendV2.coupling_map zurückgegeben wird, nicht im Detail aufgeführt sind. Je nach Anwendungsfall
kann es daher notwendig sein, tiefer zu schauen als nur der äquivalente Zugriff mit
BackendV2.
Spezifische Änderungen in BackendV2
Die meisten Attribute haben einen direkten Ersatz, was die Migrationsarbeit vereinfacht. Der einzige Unterschied zwischen den Schnittstellen liegt in der CouplingMap.
Im Folgenden findest du eine Tabelle mit Beispiel-Zugriffsmustern in BackendV1 und der neuen Form
mit BackendV2.
Scrolle nach rechts, um wichtige Hinweise zu sehen.
BackendV1 | BackendV2 | 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. Dies ist außerdem nur eine Ansicht der in backend.target enthaltenen Informationen, die möglicherweise nur eine Teilmenge der im Target-Objekt enthaltenen Informationen darstellt. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | Das Attribut BackendV2.version repräsentiert die Version der abstrakten Backend-Schnittstelle, die das Objekt implementiert, während BackendV2.backend_version Metadaten über die Version des Backends selbst enthält. |
backend.configuration().basis_gates | backend.operation_names | BackendV2 gibt eine Liste der im Attribut backend.target enthaltenen Operationsnamen zurück. Das Target kann mehr Informationen enthalten, als durch diese Namensliste ausgedrückt werden kann. Zum Beispiel funktionieren manche Operationen nur auf einer Teilmenge von Qubits, und manche Namen implementieren dasselbe Gate 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 | In BackendV2 wird die Fehlerrate der Measure-Operation auf einem bestimmten Qubit verwendet, um den Auslesefehler zu modellieren. Ein BackendV2-Objekt kann jedoch mehrere Messtypen implementieren und diese separat in einem Target aufführen. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | In BackendV2 wird die Dauer der Measure-Operation auf einem bestimmten Qubit verwendet, um die Ausleselänge zu modellieren. Ein BackendV2-Objekt kann jedoch mehrere Messtypen implementieren und diese separat in einem Target aufführen. |