Inizializzazione dei qubit
Versioni dei pacchetti
Il codice in questa pagina è stato sviluppato utilizzando i seguenti requisiti. Si consiglia di usare queste versioni o versioni più recenti.
qiskit-ibm-runtime~=0.46.1
Quando un circuito viene eseguito su un'unità di elaborazione quantistica (QPU) IBM®, all'inizio del circuito viene tipicamente inserito un reset implicito per garantire che i qubit siano inizializzati a zero. Questo è controllato dal flag init_qubits, impostato come opzione di esecuzione primitiva.
Tuttavia, le imperfezioni nel processo di reset possono introdurre errori di preparazione dello stato. Per attenuare l'errore, la QPU inserisce anche un tempo di ritardo di ripetizione (o rep_delay) tra i circuiti. Ogni Backend ha un rep_delay predefinito diverso, ma di solito è impostato per bilanciare la fedeltà del reset rispetto al tempo di esecuzione totale. Esegui backend.default_rep_delay per trovare il rep_delay predefinito per uno specifico QPU.
Poiché tutte le QPU IBM utilizzano l'esecuzione a frequenza di ripetizione dinamica, puoi modificare il rep_delay per ogni job. I circuiti che invii in un job primitivo vengono raggruppati insieme per l'esecuzione sulla QPU. Questi circuiti vengono eseguiti iterando sui circuiti per ogni shot richiesto; l'esecuzione avviene per colonne su una matrice di circuiti e shot, come illustrato nella figura seguente.

Poiché il rep_delay viene inserito tra i circuiti, ogni shot dell'esecuzione incontra questo ritardo. Pertanto, man mano che si riduce il rep_delay, il tempo totale di esecuzione sulla QPU diminuisce, a scapito di un aumento del tasso di errore nella preparazione dello stato, come illustra l'immagine seguente:

Se imposti sia rep_delay=0 che init_qubits=False, i circuiti si "fondono" insieme, poiché i qubit inizieranno nello stato finale dello shot precedente.
Nota che, sebbene i circuiti in un job primitivo vengano raggruppati insieme per l'esecuzione sulla QPU, non vi è alcuna garanzia sull'ordine in cui vengono eseguiti i circuiti provenienti dai PUB. Ad esempio, se invii pubs=[pub1, pub2], i circuiti di pub1 potrebbero non essere eseguiti prima di quelli di pub2. Non vi è nemmeno la garanzia che i circuiti dello stesso job vengano eseguiti come un singolo batch sulla QPU.
Specificare rep_delay per un job primitivo​
Verifica sempre il range supportato di rep_delay per il QPU specifico che stai usando. Questi valori non sono uguali per ogni QPU e possono cambiare nel tempo.
Tieni presente che un aumento del rep_delay avrà un impatto diretto sul tuo tempo di esecuzione e sul consumo di capacità .
# Added by doQumentation — required packages for this notebook
!pip install -q qiskit-ibm-runtime
from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2 as Sampler
service = QiskitRuntimeService()
# Make sure your backend supports it
backend = service.least_busy(
operational=True, min_num_qubits=100, dynamic_reprate_enabled=True
)
# Determine the allowable range
backend.rep_delay_range
sampler = Sampler(mode=backend)
# Specify a value in the supported range
sampler.options.execution.rep_delay = 0.0005
Passi successivi​
- Prova un esempio nel tutorial Quantum approximate optimization algorithm (QAOA).
- Consulta come iniziare con Estimator.
- Consulta come iniziare con Sampler.