Initialisation des qubits

Versions des packages

Le code de cette page a été développé avec les versions suivantes. Nous recommandons d'utiliser ces versions ou des versions plus récentes.

qiskit-ibm-runtime~=0.46.1

Lorsqu'un circuit est exécuté sur une unité de traitement quantique (QPU) IBM®, une réinitialisation implicite est généralement insérée au début du circuit pour s'assurer que les qubits sont initialisés à zéro. Cela est contrôlé par le drapeau init_qubits, défini comme une option d'exécution de primitive.

Cependant, les imperfections du processus de réinitialisation peuvent introduire des erreurs de préparation d'état. Pour atténuer l'erreur, la QPU insère également un délai de répétition (ou rep_delay) entre les circuits. Chaque backend a un rep_delay par défaut différent, mais il est généralement réglé pour équilibrer la fidélité de réinitialisation et le temps total d'exécution. Exécute backend.default_rep_delay pour trouver le rep_delay par défaut pour une QPU spécifique.

Comme toutes les QPU IBM utilisent l'exécution à taux de répétition dynamique, tu peux modifier le rep_delay pour chaque job. Les circuits que tu soumets dans un job primitif sont regroupés pour être exécutés sur la QPU. Ces circuits sont exécutés en itérant sur les circuits pour chaque shot demandé ; l'exécution se fait colonne par colonne sur une matrice de circuits et de shots, comme illustré dans la figure suivante.

Étant donné que rep_delay est inséré entre les circuits, chaque shot de l'exécution rencontre ce délai. Par conséquent, en réduisant le rep_delay, le temps total d'exécution sur la QPU diminue, au prix d'une augmentation du taux d'erreur de préparation d'état, comme l'illustre l'image suivante :

Si tu définis à la fois rep_delay=0 et init_qubits=False, les circuits « fusionnent », car les qubits commenceront dans l'état final du shot précédent.

Note que si les circuits d'un job primitif sont regroupés pour l'exécution sur la QPU, l'ordre d'exécution des circuits des PUBs n'est pas garanti. Par exemple, si tu soumets pubs=[pub1, pub2], les circuits de pub1 pourraient ne pas s'exécuter avant ceux de pub2. Il n'y a pas non plus de garantie que les circuits du même job s'exécuteront en un seul batch sur la QPU.

Spécifier rep_delay pour un job primitif

Vérifier la valeur rep_delay pour une QPU

Vérifie toujours la plage de rep_delay supportée pour la QPU spécifique que tu utilises. Ces valeurs ne sont pas les mêmes pour chaque QPU et peuvent également changer au fil du temps.

Note qu'une augmentation du rep_delay aura un impact direct sur ton temps d'exécution et ta consommation de 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

Étapes suivantes

Recommandations

• Essaie un exemple dans le tutoriel Algorithme d'optimisation approximative quantique (QAOA).
• Consulte comment démarrer avec l'Estimator.
• Consulte comment démarrer avec le Sampler.