Migrar do BackendV1 para o 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 usa um provedor que atualizou de BackendV1 para BackendV2.
Se você usa exclusivamente qiskit_ibm_runtime e qiskit_aer, nenhuma ação é necessária. O pacote qiskit_ibm_runtime sempre usou BackendV2, e o qiskit_aer usa BackendV2 desde a versão 0.13.
Mudanças de alto nível no BackendV2
O modelo Qiskit Backend foi projetado para fornecer ao Qiskit SDK uma camada de abstração
que permitia raciocinar sobre computadores quânticos dentro do escopo do SDK. A primeira iteração do modelo foi introduzida com a classe
BackendV1. Essa classe armazenava as informações do Backend em uma série
de contêineres de dados, nomeadamente as classes BackendConfiguration e
BackendProperties.
A classe BackendV2 redefiniu
o acesso do usuário para a maioria das propriedades do Backend para que funcionem com estruturas de dados nativas do Qiskit e tenham padrões
de acesso mais planos. O núcleo do modelo BackendV2 é a classe
Target, uma representação do QPU que contém as restrições de transpilação que o Qiskit pode usar para otimizar Circuit para execução.
O Qiskit SDK foi atualizado para trabalhar exclusivamente com entradas BackendV2,
e a maioria dos provedores atualizou de BackendV1 para BackendV2. Espera-se que os provedores existentes descontinuem o acesso antigo onde possível para fornecer uma migração suave, mas eventualmente os usuários precisarão ajustar seu código.
O princípio por trás do BackendV2 é que
a maior parte da informação sobre um Backend está contida em seu objeto
Target, e os atributos do Backend frequentemente consultam
o atributo BackendV2.target para retornar informações. No entanto, em muitos casos os atributos fornecem apenas
um subconjunto de informações que o Target pode conter. Por exemplo, backend.coupling_map
retorna um CouplingMap construído a partir do
Target acessível no atributo
BackendV2.target. No entanto, o Target pode conter
instruções que operam em mais de dois Qubit (que não podem ser representadas em um
CouplingMap) ou pode ter instruções que operam apenas em
um subconjunto de Qubit (ou links de dois Qubit, para uma instrução de dois Qubit), que não serão
detalhados no mapa de acoplamento completo retornado por
BackendV2.coupling_map. Então, dependendo do seu caso de uso,
pode ser necessário olhar mais fundo do que apenas o acesso equivalente com
BackendV2.
Mudanças específicas no BackendV2
A maioria dos atributos tem uma substituição direta, simplificando os esforços de migração. O único ponto de incompatibilidade entre as interfaces está no CouplingMap.
A seguir está uma tabela de exemplos de padrões de acesso no BackendV1 e a nova forma
com BackendV2.
Role para a direita para ver notas importantes.
BackendV1 | BackendV2 | Notas |
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | O retorno do BackendV2 é um objeto CouplingMap. No BackendV1 é uma lista de arestas. Além disso, isso é apenas uma visualização da informação contida em backend.target, que pode ser apenas um subconjunto da informação contida no objeto Target. |
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 pode ser expresso por essa lista de nomes. Por exemplo, algumas operações funcionam apenas em um subconjunto de Qubit, e alguns nomes implementam o mesmo Gate 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 | No BackendV2, a taxa de erro para a operação Measure em um determinado Qubit é usada para modelar o erro de leitura. No entanto, um objeto BackendV2 pode implementar múltiplos tipos de medição e listá-los separadamente em um Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | No BackendV2, a duração da operação Measure em um determinado Qubit é usada para modelar o comprimento de leitura. No entanto, um objeto BackendV2 pode implementar múltiplos tipos de medição e listá-los separadamente em um Target. |