Migrar de BackendV1 para BackendV2
A classe Qiskit BackendV1 foi descontinuada e será removida do serviço. Este guia de migração descreve os pequenos ajustes que você precisa fazer se usar um provedor que fez upgrade de BackendV1 para BackendV2.
Se você usar exclusivamente os sites qiskit_ibm_runtime e qiskit_aer, nenhuma ação será necessária. O pacote qiskit_ibm_runtime sempre usou o BackendV2 e o qiskit_aer usa o BackendV2 desde a versão 0.13.
Alterações de alto nível em BackendV2
O modelo Qiskit Backend foi projetado para fornecer ao site Qiskit SDK uma camada de abstração que permitisse o raciocínio sobre computadores quânticos dentro do escopo do SDK. A primeira iteração do modelo foi introduzida com o BackendV1 classe. Essa classe armazenou as informações de backend em uma série de de contêineres de dados, a saber, o BackendConfiguration e BackendProperties classes.
A classe BackendV2 classe redefiniu o o acesso do usuário à maioria das propriedades de back-end para fazê-las funcionar com estruturas de dados nativas do Qiskit e ter padrões de acesso mais simples. O núcleo do modelo BackendV2 modelo é o Target uma representação da QPU que contém as restrições de transpilação que o Qiskit pode usar para otimizar os circuitos para execução.
O site Qiskit SDK foi atualizado para funcionar exclusivamente com BackendV2 entradas, e a maioria dos provedores fez o upgrade de BackendV1 para BackendV2. Espera-se que os provedores existentes preteram o acesso antigo sempre que possível para proporcionar uma migração tranquila, mas, eventualmente, os usuários precisarão ajustar seus códigos.
O princípio por trás do BackendV2 é que a maioria das informações sobre um backend está contida em seu Target objeto, e os atributos do backend geralmente consultam seu atributo BackendV2.target para retornar informações. Entretanto, em muitos casos, os atributos fornecem apenas um subconjunto de informações que o destino pode conter. Por exemplo, backend.coupling_map retorna um CouplingMap construído a partir do Target acessível no atributo BackendV2.target atributo. No entanto, o destino pode conter instruções que operam em mais de dois qubits (que não podem ser representadas em um CouplingMap) ou pode ter instruções que operam somente em um subconjunto de qubits (ou dois links de qubit, para uma instrução de dois qubits), que não serão detalhadas no mapa de acoplamento completo retornado por BackendV2.coupling_map. Portanto, dependendo do seu caso de uso, talvez seja necessário analisar mais profundamente do que apenas o acesso equivalente com BackendV2.
Alterações específicas em BackendV2
A maioria dos atributos tem um substituto direto, simplificando os esforços de migração. O único ponto de incompatibilidade entre as interfaces está no CouplingMap.
A seguir, há uma tabela de exemplos de padrões de acesso em BackendV1 e o novo formulário com BackendV2.
Role para a direita para ver observações importantes.
Notas | ||
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | O retorno de BackendV2 é um objeto CouplingMap objeto. Em BackendV1 é uma lista de bordas. Além disso, essa é apenas uma visão das informações contidas em backend.target , que pode ser apenas um subconjunto das informações contidas no Target objeto. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | O atributo BackendV2.version representa a versão da interface abstrata Backend que o objeto implementa, enquanto BackendV2.backend_version são metadados sobre a versão do próprio backend. |
backend.configuration().basis_gates | backend.operation_names | O BackendV2 retorna uma lista de nomes de operações contidos no atributo backend.target . O Target pode conter mais informações do que as que podem ser expressas por essa lista de nomes. Por exemplo, algumas operações funcionam apenas em um subconjunto de qubits e alguns nomes implementam a mesma porta com parâmetros diferentes. |
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 | Em BackendV2a taxa de erro para a operação Measure operação em um determinado qubit é usada para modelar o erro de leitura. No entanto, um objeto BackendV2 pode implementar vários tipos de medição e listá-los separadamente em um objeto Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | Em BackendV2a duração da operação Measure operação em um determinado qubit é usada para modelar o comprimento da leitura. No entanto, um objeto BackendV2 pode implementar vários tipos de medição e listá-los separadamente em um objeto Target. |