Migrare da BackendV1 a BackendV2
La classe Qiskit BackendV1 è stata deprecata e sarà rimossa dal servizio. Questa guida alla migrazione descrive le piccole modifiche da apportare se si utilizza un provider che ha effettuato l'aggiornamento da BackendV1 a BackendV2.
Se si utilizzano esclusivamente qiskit_ibm_runtime e qiskit_aer, non è necessario intervenire. Il pacchetto qiskit_ibm_runtime ha sempre utilizzato BackendV2, mentre qiskit_aer ha utilizzato BackendV2 dalla versione 0.13.
Cambiamenti di alto livello in BackendV2
Il modello Qiskit Backend è stato progettato per fornire all'indirizzo Qiskit SDK un livello di astrazione che che permettesse di ragionare sui computer quantistici nell'ambito dell'SDK. La prima iterazione del modello è stata introdotta con la BackendV1 classe. Questa classe memorizzava le informazioni del backend in una serie di di contenitori di dati, ovvero i contenitori BackendConfiguration e BackendProperties e le classi.
La BackendV2 ha ridefinito l'accesso l'accesso dell'utente alla maggior parte delle proprietà del backend, per farle funzionare con le strutture dati native di Qiskit e avere schemi di accesso più semplici modelli di accesso più semplici. Il cuore del BackendV2 modello è il Target una rappresentazione della QPU che contiene i vincoli di transpilazione che Qiskit può utilizzare per ottimizzare i circuiti per l'esecuzione.
Il sito Qiskit SDK è stato aggiornato in modo da funzionare esclusivamente con gli BackendV2 ingressi, e la maggior parte dei fornitori è passata da BackendV1 a BackendV2. Si prevede che i provider esistenti deprecheranno il vecchio accesso, ove possibile, per garantire una migrazione graduale, ma alla fine gli utenti dovranno adattare il loro codice.
Il principio alla base BackendV2 è che la maggior parte delle informazioni su un backend è contenuta nel suo Target oggetto e gli attributi del backend spesso interrogano l'attributo BackendV2.target per restituire informazioni. Tuttavia, in molti casi gli attributi forniscono solo un un sottoinsieme di informazioni che il target può contenere. Ad esempio, backend.coupling_map restituisce un oggetto CouplingMap costruito a partire dall'elemento Target accessibile nell'attributo BackendV2.target dell'attributo. Tuttavia, la destinazione potrebbe contenere istruzioni che operano su più di due qubit (che non possono essere rappresentate in un file CouplingMap) o potrebbe contenere istruzioni che operano solo su un sottoinsieme di qubit (o due collegamenti di qubit, per un'istruzione a due qubit), che non saranno dettagliati nella mappa di accoppiamento completa restituita da BackendV2.coupling_map. Quindi, a seconda del caso d'uso, potrebbe essere necessario guardare più in profondità rispetto all'accesso equivalente con BackendV2.
Modifiche specifiche in BackendV2
La maggior parte degli attributi ha una sostituzione diretta, che semplifica gli sforzi di migrazione. L'unico punto di discrepanza tra le interfacce si trova nell'elemento CouplingMap.
Segue una tabella di esempi di modelli di accesso in BackendV1 e il nuovo modulo con BackendV2.
Scorrere a destra per vedere le note importanti.
Note | ||
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Il ritorno da BackendV2 è un oggetto CouplingMap oggetto. In BackendV1 è un elenco di bordi. Inoltre, questa è solo una visione delle informazioni contenute in backend.target , che possono essere solo un sottoinsieme delle informazioni contenute nell'oggetto Target oggetto. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | L'attributo BackendV2.version rappresenta la versione dell'interfaccia astratta che l'oggetto Backend che l'oggetto implementa, mentre BackendV2.backend_version è un metadato sulla versione del backend stesso. |
backend.configuration().basis_gates | backend.operation_names | L'attributo BackendV2 restituisce un elenco di nomi di operazioni contenuti nell'attributo backend.target . Il Target potrebbe contenere più informazioni di quelle che possono essere espresse da questo elenco di nomi. Ad esempio, alcune operazioni funzionano solo su un sottoinsieme di qubit e alcuni nomi implementano lo stesso gate con parametri diversi. |
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 BackendV2il tasso di errore per l'operazione Measure operazione su un dato qubit viene utilizzato per modellare l'errore di lettura. Tuttavia, un BackendV2 può implementare più tipi di misura ed elencarli separatamente in un file Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | In BackendV2la durata dell'operazione su un Measure operazione su un dato qubit viene utilizzata per modellare la lunghezza di lettura. Tuttavia, un BackendV2 può implementare più tipi di misura ed elencarli separatamente in un file Target. |