Migrar de BackendV1 a BackendV2
La clase Qiskit BackendV1 ha quedado obsoleta y será retirada del servicio. Esta guía de migración describe los pequeños ajustes que debe realizar si utiliza un proveedor que actualizó de BackendV1 a BackendV2.
Si utiliza exclusivamente qiskit_ibm_runtime y qiskit_aer, no es necesario tomar ninguna medida. El paquete qiskit_ibm_runtime siempre ha utilizado BackendV2, y qiskit_aer utiliza BackendV2 desde la versión 0.13.
Cambios de alto nivel en BackendV2
El modelo Qiskit Backend se diseñó para proporcionar a Qiskit SDK una capa de abstracción que permitiera razonar sobre los ordenadores cuánticos dentro del ámbito del SDK. La primera iteración del modelo se introdujo con el BackendV1 clase. Esta clase almacenaba la información del backend en una serie de contenedores de datos, a saber BackendConfiguration y BackendProperties .
La clase BackendV2 clase redefinió acceso de usuario para la mayoría de las propiedades de backend para que funcionen con estructuras de datos nativas de Qiskit y tengan patrones de acceso más planos más planos. El núcleo del BackendV2 modelo es el Target una representación del QPU que contiene las restricciones de transpilación que Qiskit puede utilizar para optimizar los circuitos para su ejecución.
El sitio Qiskit SDK se ha actualizado para trabajar exclusivamente con BackendV2 entradas, y la mayoría de los proveedores han actualizado de BackendV1 a BackendV2. Se espera que los proveedores existentes dejen obsoleto el acceso antiguo en la medida de lo posible para facilitar una migración gradual, pero en última instancia los usuarios tendrán que ajustar su código.
El principio BackendV2 es que la mayor parte de la información sobre un backend está contenida en su Target objeto, y los atributos del backend a menudo consultan su atributo BackendV2.target para obtener información. Sin embargo, en muchos casos los atributos sólo proporcionan un subconjunto de la información que puede contener el objetivo. Por ejemplo backend.coupling_map devuelve un CouplingMap construido a partir del Target accesible en el atributo BackendV2.target atributo. Sin embargo, el objetivo puede contener instrucciones que operan sobre más de dos qubits (que no pueden representarse en un CouplingMap) o puede tener instrucciones que sólo operen sobre un subconjunto de qubits (o dos enlaces de qubits, para una instrucción de dos qubits), que no estarán detallado en el mapa de acoplamiento completo devuelto por BackendV2.coupling_map. Así que dependiendo de su caso de uso podría ser necesario buscar más allá del acceso equivalente con BackendV2.
Cambios específicos en BackendV2
La mayoría de los atributos tienen un sustituto directo, lo que simplifica los esfuerzos de migración. El único punto de discordancia entre las interfaces se encuentra en la interfaz CouplingMap.
A continuación se muestra una tabla con ejemplos de patrones de acceso en BackendV1 y el nuevo formulario con BackendV2.
Desplácese a la derecha para ver las notas importantes.
Notas | ||
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | El retorno de BackendV2 es un objeto CouplingMap objeto. En BackendV1 es una lista de aristas. Además, esto es sólo una vista de la información contenida en backend.target que puede ser sólo un subconjunto de la información contenida en el Target objeto. |
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 son metadatos sobre la versión del propio backend. |
backend.configuration().basis_gates | backend.operation_names | La función BackendV2 devuelve una lista de nombres de operaciones contenidos en el atributo backend.target . El sitio Target puede contener más información de la que se puede expresar con esta lista de nombres. Por ejemplo, algunas operaciones sólo funcionan en un subconjunto de qubits, y algunos nombres implementan la misma puerta con diferentes 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 BackendV2la tasa de error de la operación Measure operación en un qubit dado se utiliza para modelar el error de lectura. Sin embargo, un BackendV2 puede implementar varios tipos de medición y enumerarlos por separado en un objeto Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | En BackendV2la duración de la Measure operación en un qubit dado se utiliza para modelar la longitud de lectura. Sin embargo, un BackendV2 puede implementar varios tipos de medición y enumerarlos por separado en un objeto Target. |