Migrar de BackendV1 a BackendV2
La clase BackendV1 de Qiskit ha sido marcada como obsoleta y será eliminada del servicio. Esta guía de migración describe los pequeños ajustes que necesitas hacer si usas un
proveedor que actualizó de BackendV1 a BackendV2.
Si usas exclusivamente qiskit_ibm_runtime y qiskit_aer, no necesitas hacer nada. El paquete qiskit_ibm_runtime siempre ha usado BackendV2,
y qiskit_aer lo usa desde la versión 0.13.
Cambios generales en BackendV2
El modelo Backend de Qiskit fue diseñado para proporcionar al SDK de Qiskit una capa de abstracción
que permitiera razonar sobre computadoras cuánticas dentro del alcance del SDK. La primera iteración del modelo se introdujo con la clase
BackendV1. Esta clase almacenaba la información del backend en una serie de contenedores de datos, concretamente las clases
BackendConfiguration y
BackendProperties.
La clase BackendV2 redefinió el acceso del usuario a la mayoría de las propiedades del backend para
que funcionen con las estructuras de datos nativas de Qiskit y tengan patrones de acceso más simples. El núcleo del modelo
BackendV2 es la clase Target, una representación de la QPU que contiene las restricciones
de transpilación que Qiskit puede usar para optimizar los circuitos antes de su ejecución.
El SDK de Qiskit se ha actualizado para trabajar exclusivamente con entradas BackendV2, y la mayoría
de los proveedores han migrado de BackendV1 a BackendV2. Se espera que los
proveedores existentes marquen como obsoleto el acceso antiguo cuando sea posible para facilitar una migración gradual, pero en última instancia
los usuarios necesitarán ajustar su código.
El principio detrás de BackendV2 es que la mayor parte de la información sobre un backend está
contenida en su objeto Target, y los atributos del backend con frecuencia consultan su atributo BackendV2.target
para devolver información. Sin embargo, en muchos casos los atributos solo proporcionan un subconjunto de la información que el target puede
contener. Por ejemplo, backend.coupling_map devuelve un objeto CouplingMap construido a partir del
Target accesible en el atributo BackendV2.target. Sin embargo, el target podría contener instrucciones que operen
sobre más de dos qubits (lo que no se puede representar en un CouplingMap) o podría tener instrucciones que
solo operen sobre un subconjunto de qubits, lo cual no quedará detallado en el mapa de acoplamiento completo que devuelve BackendV2.coupling_map.
Por eso, dependiendo de tu caso de uso, puede ser necesario profundizar más allá del acceso equivalente con
BackendV2.
Cambios específicos en BackendV2
La mayoría de los atributos tienen un reemplazo directo, lo que simplifica el proceso de migración. El único punto de discrepancia entre las interfaces está en el CouplingMap.
A continuación se muestra una tabla con ejemplos de patrones de acceso en BackendV1 y la nueva forma con
BackendV2.
Desplázate hacia la derecha para ver las notas importantes.
BackendV1 | BackendV2 | Notas |
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Lo que devuelve BackendV2 es un objeto CouplingMap. En BackendV1 es una lista de aristas. Además, esto es solo una vista de la información contenida en backend.target, que puede ser únicamente un subconjunto de la información contenida en el objeto Target. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | El atributo BackendV2.version representa la versión de la interfaz abstracta Backend que implementa el objeto, mientras que BackendV2.backend_version es metadato sobre la versión del backend en sí. |
backend.configuration().basis_gates | backend.operation_names | BackendV2 devuelve una lista de nombres de operaciones contenidas en el atributo backend.target. El Target puede contener más información de la que puede expresarse con esta lista de nombres. Por ejemplo, algunas operaciones solo funcionan en un subconjunto de qubits, y algunos nombres implementan la misma puerta con distintos parámetros. |
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 BackendV2, la tasa de error de la operación Measure en un qubit determinado se usa para modelar el error de lectura. Sin embargo, un objeto BackendV2 puede implementar múltiples tipos de medición y listarlos por separado en un Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | En BackendV2, la duración de la operación Measure en un qubit determinado se usa para modelar la longitud de lectura. Sin embargo, un objeto BackendV2 puede implementar múltiples tipos de medición y listarlos por separado en un Target. |