Migrazione da BackendV1 a BackendV2
La classe Qiskit BackendV1 è stata deprecata e verrà rimossa dal servizio. Questa guida alla migrazione descrive i piccoli adattamenti necessari se utilizzi un provider che è passato da BackendV1 a BackendV2.
Se usi esclusivamente qiskit_ibm_runtime e qiskit_aer, non è richiesta alcuna azione. Il pacchetto qiskit_ibm_runtime ha sempre utilizzato BackendV2, e qiskit_aer usa BackendV2 dalla versione 0.13.
Modifiche di alto livello in BackendV2
Il modello Qiskit Backend è stato progettato per fornire all'SDK Qiskit un livello di astrazione
che permettesse di ragionare sui computer quantistici nell'ambito dell'SDK. La prima iterazione del modello è stata introdotta con la
classe BackendV1. Questa classe memorizzava le informazioni del backend in una serie
di contenitori di dati, ovvero le classi BackendConfiguration e
BackendProperties.
La classe BackendV2 ha ridefinito l'accesso utente alla maggior parte delle proprietà del backend per farle funzionare con le strutture dati native di Qiskit e rendere i pattern di
accesso più diretti. Il nucleo del modello BackendV2 è la classe
Target, una rappresentazione del QPU che contiene i vincoli di transpilazione che Qiskit può usare per ottimizzare i circuiti per l'esecuzione.
L'SDK Qiskit è stato aggiornato per lavorare esclusivamente con input BackendV2,
e la maggior parte dei provider è passata da BackendV1 a BackendV2. Ci si aspetta che i provider esistenti deprechino il vecchio accesso dove possibile per offrire una migrazione graduale, ma alla fine gli utenti dovranno adattare il proprio codice.
Il principio alla base di BackendV2 è
che la maggior parte delle informazioni su un backend è contenuta nel suo
oggetto Target, e gli attributi del backend spesso interrogano
il proprio attributo BackendV2.target per restituire informazioni. Tuttavia, in molti casi gli attributi forniscono solo
un sottoinsieme delle informazioni che il target può contenere. Ad esempio, backend.coupling_map
restituisce un oggetto CouplingMap costruito a partire dal
Target accessibile tramite l'attributo BackendV2.target. Tuttavia, il target potrebbe contenere
istruzioni che operano su più di due qubit (che non possono essere rappresentate in una
CouplingMap) oppure potrebbe avere istruzioni che operano solo su un sottoinsieme di qubit (o su due link di qubit, nel caso di un'istruzione a due qubit), che non verranno
dettagliate nella coupling map completa restituita da
BackendV2.coupling_map. Quindi, a seconda del tuo caso d'uso,
potrebbe essere necessario approfondire la ricerca al di là del semplice accesso equivalente con
BackendV2.
Modifiche specifiche in BackendV2
La maggior parte degli attributi ha una sostituzione diretta, il che semplifica il processo di migrazione. L'unico punto di disallineamento tra le interfacce riguarda la CouplingMap.
Di seguito è riportata una tabella con esempi di pattern di accesso in BackendV1 e la nuova forma
con BackendV2.
Scorri verso destra per vedere le note importanti.
BackendV1 | BackendV2 | Note |
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Il valore restituito da BackendV2 è un oggetto CouplingMap. In BackendV1 è una lista di archi. Inoltre, questo è solo una vista delle informazioni contenute in backend.target, che potrebbe essere solo un sottoinsieme delle informazioni contenute nell'oggetto Target. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | L'attributo BackendV2.version rappresenta la versione dell'interfaccia astratta Backend implementata dall'oggetto, mentre BackendV2.backend_version è un metadato relativo alla versione del backend stesso. |
backend.configuration().basis_gates | backend.operation_names | BackendV2 restituisce un elenco di nomi di operazioni contenuti nell'attributo backend.target. Il Target potrebbe contenere più informazioni di quelle esprimibili tramite 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 BackendV2, il tasso di errore per l'operazione Measure su un dato qubit viene usato per modellare l'errore di readout. Tuttavia, un oggetto BackendV2 può implementare più tipi di misurazione ed elencarli separatamente in un Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | In BackendV2, la durata per l'operazione Measure su un dato qubit viene usata per modellare la lunghezza del readout. Tuttavia, un oggetto BackendV2 può implementare più tipi di misurazione ed elencarli separatamente in un Target. |