Source-linked AI summary
Qiskit Backend Specifications for OpenQASM and OpenPulse Experiments
David C. McKay, Thomas Alexander, Luciano Bello, Michael J. Biercuk, Lev Bishop, Jiayin Chen, Jerry M. Chow, Antonio D. Córcoles, Daniel Egger, Stefan Filipp, Juan Gomez, Michael Hush, Ali Javadi-Abhari, Diego Moreda, Paul Nation, Brent Paulovicks, Erick Winston, Christopher J. Wood, James Wootton, Jay M. Gambetta
arXiv:1809.03452v1quant-phcs.ET
TL;DR
Quantum computing needs standardized interfaces and a language for specifying and recovering experiments’ time dynamics. This paper specifies Qiskit backends and Qobj data structures, and introduces hardware-agnostic OpenPulse for pulse-level control alongside OpenQASM.
Problem
Quantum computing lacks standardized interfaces and a language that captures experiments’ continuous time dynamics across users, devices, and simulators.
Source: §1 · p. 4Method
The paper defines Qiskit backend APIs and Qobj experiment data structures, with OpenQASM for abstract operations and OpenPulse for timedynamics.
Source: §2 · p. 5, §2.1 · p. 7, §3 · p. 19Results
The specification supports communicating experiments across real devices and simulators while providing hardware-agnostic pulse-level control for a broad class of quantum devices.
Source: §1 · p. 4, §5 · p. 29Takeaways & Limitations
Qiskit provides a common reference framework for algorithm designers, circuit designers, and quantum physicists to design and optimize experiments.
Source: §1 · p. 4Fully generic classical processing, closed-loop feedback, and device reconfiguration beyond a single experiment are outside the specification’s scope.
Source: §1.3 · p. 5
Abstract
from arXiv · showhide
As interest in quantum computing grows, there is a pressing need for standardized API's so that algorithm designers, circuit designers, and physicists can be provided a common reference frame for designing, executing, and optimizing experiments. There is also a need for a language specification that goes beyond gates and allows users to specify the time dynamics of a quantum experiment and recover the time dynamics of the output. In this document we provide a specification for a common interface to backends (simulators and experiments) and a standarized data structure (Qobj --- quantum object) for sending experiments to those backends via Qiskit. We also introduce OpenPulse, a language for specifying pulse level control (i.e. control of the continuous time dynamics) of a general quantum device independent of the specific hardware implementation.
1 Introduction
The document defines Qiskit backend, Qobj, OpenQASM, and OpenPulse specifications to support algorithm designers, circuit designers, and quantum physicists using simulators and real quantum devices. It also establishes intended audiences, document organization, scope limits, and JSON-based interface conventions.
1 Introduction
1.1 Intended Audience
- The specification addresses users needing experiment dynamics, Qiskit contributors, and providers offering cloud-access quantum devices or simulators.OpenPulse users seek exact time dynamics and collected measurements, while contributors focus on data structures and API design.Source: §1.1 · p. 4
1.2 Outline of Document
- The document covers the Qiskit API, OpenQASM experiments and examples, OpenPulse specifications, and several OpenPulse experiment examples.These topics are distributed across §§ 2–8.Source: §1.2 · p. 4
1.3 Outside of the Scope
- Fully generic classical processing, closed-loop feedback, and device reconfiguration beyond a single experiment are outside the specification and may require extensions.The examples include changing a magnetic field on timescales longer than one experiment.Source: §1.3 · p. 5
1.4 Interface Language and Schemas
- Backend interfaces use JSON with snake_case naming, schemas define the data structures, and complex numbers use nested real-imaginary pairs.Non-integer values are JSON numbers without abstract-model precision guarantees; hardware may impose device-specific constraints.Source: §1.4 · p. 5
2 Qiskit API … 2.3 Backend
This section specifies interoperable Qiskit interfaces for providers, backends, Qobj experiments, and jobs in quantum experiments. It describes backend capabilities, configuration, properties, defaults, schemas, status information, and job submission and retrieval methods for devices and simulators.
2.1 General Overview of a Qiskit Experiment
- A Qobj batches concurrent experiments, expressed in OpenQASM or OpenPulse, whose measurements use backend memory and fast register storage for readout and conditional operations.OpenQASM represents gates, measurements, and conditionals; OpenPulse specifies continuous-time pulses and can store additional measurement data such as raw demodulated signals or IQ values.Source: §2.1 · p. 7
2.2 Provider
- Providers manage authenticated backend collections, expose available backends, and retrieve a named Backend object.This establishes the provider as the access point for backend discovery and selection.Source: §2.2 · p. 8
2.3 Backend
- Backends provide a common interface for devices and simulators, supporting experiment execution and configuration, while all backends support OpenQASM and some support OpenPulse.The Backend class also exposes required data structures and function calls for backend-specific operation.Source: §2.3 · p. 8
2.3.1 Configuration
- Backend configuration identifies capabilities such as qubit count, basis gates, coupling maps, simulator or local operation, conditional support, configurability, registers, and OpenPulse acceptance.Backends may add optional metadata including online date, display name, sample name, description, URL, and tags.Source: §2.3.1 · pp. 8–9
2.3.2 gate config Data Structure
- Gate configurations describe each OpenQASM gate’s name, parameters, qubit coupling, basis-gate definition, conditional support, latency map, and optional description.Latency maps indicate whether feedback to register slots is fast or slow.Source: §2.3.2 · p. 10
2.3.3 Properties
- Backend properties optionally report calibration and characterization data, including dated qubit, gate, and general parameters represented as name-date-unit-value structures.Examples include qubit T1, T2, readout error, and frequency, plus gate error and gate time.Source: §2.3.3 · pp. 11–12
2.3.4 Defaults / 2.3.5 Schema
- Backend defaults supply typical Qobj job parameters, with particular importance for OpenPulse experiments.The schema call returns backend-specific JSON constraints that supplement the generic Qobj schema and enable user validation.Source: §2.3.4 · p. 13, §2.3.5 · p. 13
2.3.6 Status
- Backend status reports whether the backend is operational, how many jobs are pending, and an accompanying status message.The backend name and version identify the reported backend.Source: §2.3.6 · pp. 13–14
2.3.7 Run
- Backend.run(Qobj) creates and returns a job object for the submitted Qobj.The Qobj data structure is specified in § 2.4.1.Source: §2.3.7 · p. 14
2.3.8 Jobs
- Backend.jobs() may list the user’s previously run jobs, optionally restricting results by time period or filters such as job ID and date.Backends may choose whether to retain or expose only jobs from a specified period, such as the last week.Source: §2.3.8 · p. 14
2.4 Job
The section defines jobs as accepted backend experiments managed through identifiers, status, cancellation, and result retrieval, and specifies Qobj as the structure carrying configurations and experiment sequences. It also describes status values, cancellation behavior, and backend-specific measurement-result retrieval.
2.4 Job
- A job is an accepted backend experiment identified by a provider-unique job id and used for status updates, cancellation, and result retrieval.Jobs may be queued, running, or completed, and are created from a Qobj structure.Source: §2.4 · p. 14
2.4.1 Qobj Data Structure
- Qobj encapsulates backend configuration and experiment sequences, including experiment type, schema version, metadata, per-experiment settings, instructions, and execution controls.Its user configuration includes shots, memory slots, and optional simulator seeds or maximum credits; experiments repeat in listed order until the requested shots are completed.Source: §2.4.1 · pp. 14–16
2.4.2 Job Status
- Job.status() reports the job id, a backend-defined message, and a status such as QUEUED, RUNNING, CANCELLED, or DONE.Additional Job.done(), Job.running(), and Job.cancelled() calls return booleans indicating those conditions.Source: §2.4.2 · p. 16
2.4.3 Job Cancel
- Job.cancel() removes a queued job or stops a running job, and prevents credit deduction on credit-based backends.Source: §2.4.3 · p. 16
2.4.4 Job Result (Measurement Retrieval)
- Job.result() retrieves measurement results with backend-specific behavior, either blocking until all results are available or returning stored data incrementally.The result data structure is defined in § 2.5.Source: §2.4.4 · pp. 16–17
2.5 Result Data Structure
The result structure identifies the backend job and experiment status while organizing experiment outputs, measurement representations, and simulator snapshots. It supports counts, memory, statevector, unitary, and snapshot data forms.
2.5 Result Data Structure
- Job results identify the backend, Qobj and job IDs, execution date, header, completion status, success, and a list of experiment results.The top-level structure records backend_name, backend_version, qobj_id, job_id, date, header, status, success, and results.Source: §2.5 · p. 17
- Each experiment result records shots, status, success, headers, optional seeds and measurement-return mode, plus backend-dependent experiment data.Shots may be a count or a range for asynchronous or sectioned data; meas_return selects averaged or per-shot data.Source: §2.5 · pp. 17–18
2.5.1 Measurement Data
- Measurement data can represent memory-state counts, per-shot classical memory, simulator statevectors, circuit unitaries, or snapshots.Counts use nonzero hexadecimal memory states, memory lists hexadecimal states per shot, and statevector and unitary return final simulator or circuit data.Source: §2.5.1 · p. 18
2.5.2 Snapshots
- Snapshots organize simulator state at designated commands by snapshot type and user-specified label, with schemas defined separately.Each snapshot type contains subkeys named by the snapshot command, and each label stores data captured at that sequence point.Source: §2.5.2 · p. 19
3 OpenQASM Representation as a Quantum Object (Qobj) Data Structure
The section specifies how OpenQASM circuit experiments are parsed into Qobj structures for backend or simulator execution, rather than redefining OpenQASM [7]. This representation consolidates quantum and classical registers and separates classical storage into slow memory and fast register.
3.1 Experiment Sequence Commands
- OpenQASM Qobj experiment sequences require a name and reserve commands including bfunc, copy, reset, barrier, measure, and snapshot.These commands define the supported experiment sequence structure.Source: §3.1 · p. 19
3.1.1 Boolean Function
- A boolean function applies (register AND mask) relation val, stores the result in a register slot, and optionally writes it to memory.The mask selects register bits, while the result can support conditional commands.Source: §3.1.1 · p. 20
3.1.2 Copy Function
- The copy function duplicates one register slot into one or more destination register slots.Its structure specifies the source register_orig and destination register_copy slots.Source: §3.1.2 · pp. 20–21
3.1.3 Gate
- Each OpenQASM gate specifies its name and target qubits, with optional parameters and conditional execution based on a register value.Optional texparams provide LaTeX-formatted parameters, while conditionals enable feedback when supported.Source: §3.1.3 · p. 21
3.1.4 Barrier
- A barrier enforces temporal ordering so later instructions on specified qubits occur after all earlier instructions.The barrier applies to a listed set of qubits.Source: §3.1.4 · p. 21
3.1.5 Reset
- The reset instruction returns listed qubits to the ground state.Its structure identifies the qubits to reset.Source: §3.1.5 · pp. 21–22
3.1.6 Measure
- Measurement projects specified qubits and records results in same-length memory slots, with optional register slots supporting fast feedback.Repeated writes overwrite the same memory slot, and backend register maps may constrain allowable register slots.Source: §3.1.6 · p. 22
3.1.7 Snapshot
- The simulator-only snapshot command records a labeled snapshot of simulator state, with snapshot types and additional configuration defined separately.The state snapshot is identified by its label, while available types depend on a separate simulator specification.Source: §3.1.7 · pp. 22–23
4 OpenQASM Qobj Examples
The section illustrates OpenQASM Qobj and result data objects through Bell-state, teleportation, and three-qubit repetition-code experiments. The examples show circuit instructions, measurement storage, conditional feedback, and representative result counts.
4 OpenQASM Qobj Examples
- The examples encode experiments as QASM Qobjs with schema version 1.0, backend configuration, instruction sequences, memory mappings, and corresponding result objects.The section presents these structures for Bell states, teleportation, and repetition-code experiments, including backend metadata and success status.Source: §4 · p. 23, §4.1 · p. 23, §4.2 · p. 25
4.1 Bell State
- Bell-state Qobjs define two experiments with 1000 shots and 2 memory slots, producing distinct result distributions for |11>+|00> and |01>+|10> states.The first experiment reports counts of 450 for 0x0, 10 for 0x1, 20 for 0x2, and 520 for 0x3; the second reports 5, 510, 480, and 5 respectively.Source: §4.1 · pp. 23–25
4.2 Teleportation
- The circuit teleports Q0’s initial superposition state to Q2 using a Bell state between Q1 and Q2, joint measurement of Q0 and Q1, and conditional operations on Q2.The Qobj configuration specifies 1000 shots and two memory slots.Source: §4.2 · p. 25
4.3 Three-Qubit Repetition Code
- The three-qubit repetition-code Qobj encodes a quantum state in |000⟩ and |111⟩, uses parity measurements on two ancillas to detect bit flips, and conditionally applies a pi-pulse to undo each detected error.Its configuration specifies 1000 shots.Source: §4.3 · p. 27
5 OpenPulse Specification
OpenPulse provides hardware-agnostic pulse-level control of continuous quantum-device dynamics beyond OpenQASM, while supporting calibrated starting points, advanced control experiments, and simple feedback. Its interface defines timed pulse sequences, measurement outputs at multiple levels, and conditional drive operations for qubit experiments.
Specification goals
- OpenPulse enables hardware-agnostic pulse-level control of continuous dynamics across devices including superconducting qubits, solid-state spins, trapped ions, and NV centers.Pulses use complex-valued envelopes relative to user-adjustable global clocks, targeting qubits with single-meter measurements.Source: §5 · p. 29
Experiment capabilities
- OpenPulse extends experiments beyond OpenQASM with decoupling, calibration, pulse-shaping, optimal-control, and advanced readout experiments, while devices can provide calibrated pulses and system parameters.Devices may also map gates to pulse sequences, allowing gate-based circuits and user-defined mappings to run through OpenPulse.Source: §5 · pp. 29–30
Pulse interface
- Experiments are single timed sequences of predefined pulses across channels, with times expressed in device-defined dt units and pulse libraries supplied through the API.Each qubit has drive and measurement-stimulus channels; additional U Channels may be available, while DC control channels are outside the specification.Source: §5 · p. 30
Measurement and feedback
- Measurement outputs support raw Level 0 signals, kernel-processed complex Level 1 values, and discriminator-based Level 2 qubit states stored in memory.Level 2 results can populate registers that conditionally apply drive pulses, enabling simple classical feedback such as active reset.Source: §5 · pp. 30–31, Figure 3 · p. 31
Backend execution
- The backend loads Qobj experiments into a run queue, reports status, may stream measurement memory, and executes multiple experiments concurrently across repeated shots.Real-time measurement streaming is not guaranteed, and no other Qobj Experiment can run during the concurrent execution period.Source: §5 · p. 31
5.1 Additional API Calls
This section specifies the additional backend APIs and Qobj configuration structures that support OpenPulse experiments. It covers hardware and default-device data, pulse-sequence command definitions, measurement processing, and configuration constraints for acquisition, frequency, memory, and repetition parameters.
5.1.1 Backend Configuration
- OpenPulse backend APIs add configuration fields for channels, Hamiltonians, local oscillators, measurement, timing, multiplexing, bandwidth, and conditional-operation latencies.The configuration includes allowable measurement levels, qubit and measurement LO ranges, input and output discretization, repetition times, available kernels and discriminators, and latency information.Source: §5.1 · p. 32, §5.1.1 · pp. 32–33
5.1.2 Backend Defaults
- Backend.defaults() returns estimated qubit and measurement frequencies, pulse buffers, a default pulse library, OpenQASM-to-OpenPulse command definitions, and default measurement processing.The default pulse library may reflect the latest calibration or a default estimate, while the command definitions provide a relatively static OpenQASM conversion layer intended to avoid calibration bottlenecks.Source: §5.1.2 · pp. 33–34
5.1.3 Hamiltonian Specification
- The Hamiltonian structure requires LaTeX and machine-readable term representations, with variables and oscillators supporting device frequencies, coupling maps, control channels, and higher system levels.The required LaTeX string uses Pauli or ladder operators, while additional terms may be symbolic or frequency-valued; ladder operators can represent higher levels such as transmon anharmonicity.Source: §5.1.3 · pp. 34–35
5.1.4 Kernel and Discriminator Specification
- Kernels and discriminators are named structures with default parameters, but their behavior is not formally specified and users may construct discriminators locally from level-1 measurement output.Devices may expose multi-qubit kernels or discriminators, which require acquisition over the corresponding number of qubits.Source: §5.1.4 · p. 35
5.1.5 Pulse Library
- The pulse library identifies pulses by unique names and represents envelopes as complex amplitude samples spaced by the device time unit dt, with amplitudes bounded by absolute value 1.Only point lists are transmitted in the language-agnostic API; user-supplied pulses override same-named entries in the default library.Source: §5.1.5 · p. 36
5.1.6 OpenQASM Command Definition
- Command definitions map each basis-gate or measurement OpenQASM command to a pulse sequence over specified qubits and channels, beginning at t = 0 and ending after the final pulse.Parameterized gate values are represented as PX placeholders, enabling Qiskit to convert OpenQASM circuits into OpenPulse format.Source: §5.1.6 · pp. 36–37
- OpenQASM command definitions represent pulse sequences across channels, including measurement acquisition and two-qubit gates such as cx.The acquire command requires a memory-slot key appended during conversion, and the cx definition can apply pulse sequences to multiple channels.Source: §5.1.6 · p. 39
5.1.7 Additional Configuration Settings in Qobj
- Additional Qobj configuration sets measurement level, pulse library, memory-slot size, and measurement-return mode, with meas_return allowing single-shot or averaged output.At measurement level 2, meas_return is fixed to single; memory-slot size applies when output is Level 0.Source: §5.1.7 · p. 40
- Qobj configuration also specifies qubit and measurement local-oscillator frequencies and an experiment repetition time, all constrained by backend or device-provided ranges and lists.The frequencies are given in GHz, while rep time is the delay between experiments in µs.Source: §5.1.7 · p. 40
5.2 Experiment Sequence Commands
OpenPulse experiment sequences specify timed commands for driving, phase control, persistent values, and measurement acquisition, with conditionals available under defined backend and measurement-level constraints. Simulators may additionally support time-stamped snapshots.
5.2 Experiment Sequence Commands
- Experiment sequences comprise input pulses, frame changes, persistent values, and acquisition commands, with boolean and copy functions permitted when supported by the backend at measurement level 2.These commands define the user/device interface for specifying experimental time sequences.Source: §5.2 · p. 40
5.2.1 Input Drive Pulse
- Input drive pulses identify a library pulse, integer-dt start time, and d, m, or U channel, with optional level-2 conditional feedback based on a register.Pulse names cannot be the reserved names “fc”, “pv”, or “acquire”.Source: §5.2.1 · p. 41
5.2.2 Frame Change
- Frame-change pulses independently advance a channel’s phase for subsequent pulses by e−iφ, specifying an integer-dt application time, channel, and device-specific-precision phase in radians.The conditional option also applies to frame-change pulses.Source: §5.2.2 · pp. 41–42
5.2.3 Persistent Value
- Persistent-value pulses apply a complex value bounded by absolute value 1 and hold it until the next pulse, potentially across experiments, before channels reset to zero after a Qobj.They can be used to create long square pulses, subject to device support for persistence between experiments.Source: §5.2.3 · p. 42
5.2.4 Acquisition Item
- Acquisition commands specify measurement timing, qubits, memory or optional register destinations, and level-dependent kernels and discriminators; listed kernels and discriminators follow qubit order and may operate jointly.Identical-time acquisitions can route one dataset through different processing functions and memory slots, but device support and acquisition limits may constrain this behavior.Source: §5.2.4 · pp. 42–43
5.2.5 Snapshot
- OpenPulse simulators may support snapshots carrying an additional t0 field that records the snapshot time.Snapshot support is specified as an optional simulator capability.Source: §5.2.5 · p. 44
5.3 Time Sequence Specification
OpenPulse represents experiments as time-ordered sequences of action items, supporting pulse-driven measurement and acquisition as well as conditional feedback. Channel outputs are zero between pulses unless a persistent value pulse maintains them.
5.3 Time Sequence Specification
- OpenPulse specifies an experiment as a time-ordered list of action items, such as drive pulses, measurement stimuli, and acquisition.The sequence format orders actions by their time positions.Source: §5.3 · p. 44
- A sequence can include two acquisitions with the second acquisition and subsequent actions conditioned on the first result.The feedback example uses a conditional action and stores the two acquisition results separately.Source: §5.3 · p. 44
- Between pulses on the same channel, output is zero unless a persistent value pulse is specified, which holds its value until another pulse is applied.This defines the channel behavior between explicitly scheduled pulses.Source: §5.3 · p. 44
5.4 Measurement Output
Qiskit defines three measurement-output levels, progressing from raw acquisition pulses to kernel-processed IQ values and discriminated computational states. Level-2 outputs also support register-based pulse masking for measurement feedback.
5.4 Measurement Output
- Measurements are retrieved through Job.result(), with Level 0 returning raw pulses, Level 1 complex IQ values, and Level 2 computational-basis states.Devices need not support all levels; Level 1 uses a user-selected kernel, while Level 2 additionally uses a discriminator.Source: §5.4 · p. 45
5.4.1 Measurement Output Level 0: Raw
- Level 0 returns equal-time-spaced amplitude samples from the mixed-down acquisition stream, but its high bandwidth and memory demands favor sparse use in averaging mode.All measurements must have equal length, so memory slots share the same duration.Source: §5.4.1 · pp. 45–46
5.4.2 Measurement Output Level 1: IQ Values
- Level 1 applies a device-provided or default measurement kernel to Level-0 data and returns one complex IQ value per memory slot.The result structure supports averaged or single-shot IQ data.Source: §5.4.2 · p. 46
5.4.3 Measurement Output Level 2: Qubit State
- Level 2 applies a selected kernel and discriminator, producing computational-basis states as a histogram of counts comparable to OpenQASM experiments.The discriminator thresholds the kernel’s qubit measurements to determine the output state.Source: §5.4.3 · pp. 46–47
5.4.4 Measurement Feedback
- Level-2 measurement output can write to registers and mask subsequent pulses according to register values.This extends discriminated measurement with register-based feedback control.Source: §5.4.4 · p. 47
6 Example Configurations for OpenPulse
This section illustrates OpenPulse backend configurations and defaults across superconducting, ion-trap, and liquid-NMR devices. The examples expose device-specific channels, timing, measurement, frequency, and Hamiltonian information through common backend calls.
6.1 Fixed-Frequency Qubits Coupled via Fixed-Frequency Buses
- Fixed-frequency qubits coupled through a fixed-frequency bus use cross-resonance control, multiplexed measurement, 1GHz drive bandwidth, and boxcar/max_1Q_fidelity readout settings.The configuration reports open_pulse=true, n_uchannels=2, dt=1.333, dtm=10, and meas_map=[[0,1]], while defaults provide estimated qubit and measurement frequencies.Source: §6.1 · pp. 47–48
6.2 Tunable Qubits Coupled via Fixed-Frequency Buses
- Tunable qubits coupled through a fixed-frequency bus use DC-centered flux controls with 200 MHz bandwidth, separate measurements, and additional narrow flux-control channels.The backend configuration lists channel bandwidths [-0.5,0.5] for drives and [-0.1,0.1] for flux controls; existing DC flux biases are set to indicated values.Source: §6.2 · pp. 49–51
6.3 Fixed-Frequency Qubits Coupled via Tunable Buses
- Fixed-frequency qubits coupled through a tunable bus expose two bus flux controls for difference- and sum-frequency driving alongside separate measurements and 1 GHz drive bandwidth.The configuration represents the two flux-control modes through u_channel_lo scales [1,0] and [-1,0] for the qubits.Source: §6.3 · pp. 51–52
6.4 Ion Trap
- The ion-trap example models three Yb ions with addressable Raman beams, fluorescence readout at measurement level 2, default kernels, and timescales 100−1000 times longer than superconducting qubits.Its Hamiltonian describes Raman-beam coupling to motional trap modes “p”, enabling construction of a Molmer-Sorensen gate.Source: §6.4 · pp. 53–55
6.5 NMR
- The liquid-NMR example represents multiple drive and measurement frequencies on single coils, uses receiver-signal filtering, and conveys the large global field outside the specification.It reports three qubits, dt=1000, dtm=100, rep_times=[1000000], and a shared measurement map [[0,1,2]].Source: §6.5 · p. 55
7 Sample Pulse Libraries for OpenPulse
This section presents Q-CTRL Black Opal pulse-library examples in OpenPulse, showing Gaussian-segment controls for robust net-X operations and their noise-suppression filter functions.
7.1 Q-CTRL Black Opal
- Black Opal outputs OpenPulse-compatible JSON pulse-library entries, illustrated through the walsh_gaussian and BB1_gaussian examples.The examples use sampled waveform envelopes, with segment duration set by the device time unit dt.Source: §7.1 · pp. 56–57
- The walsh_gaussian control implements a net X operation robust against dephasing-driven overrotation and phase errors using optimized Gaussian segments.It uses Walsh-function synthesis, and its exclusively x-axis rotations produce real-valued samples.Source: §7.1 · p. 57
- The BB1_gaussian control implements a net X operation robust against driving-strength fluctuations and pulse-timing errors through a Wimperis-derived composite pulse.Its varying rotation axes require complex samples encoding drive amplitudes around the x and y axes.Source: §7.1 · pp. 57–58
- The controls’ low filter-function values indicate noise suppression, with filter functions calculated by Black Opal and shown alongside the pulse formats.The figure uses fixed segment durations and scales the controls to an arbitrarily selected duration of 40 µs for laboratory-frequency units.Source: §7.1 · p. 58, Figure 4 · p. 58
8 Sample Experiments for OpenPulse
This section illustrates OpenPulse Qobj experiments through Rabi oscillation and T1 sequences, covering backend configuration, pulse sequencing, acquisition settings, and measurement-result formats. It also specifies experiment parameters including pulse data, memory, frequencies, repetition timing, and shot count.
8.1 Rabi Oscillation
- The Rabi experiment varies drive amplitude across 0, 0.5, and 1.0, treating amplitude 1.0 as a π-pulse on a one-qubit OpenPulse backend.The backend reports OpenPulse support, measurement levels [0,1,2], dt and dtm of 0.83333, and repetition times [100,250,500,1000].Source: §8.1 · p. 59
8.1.1 Pulse Library and Time Sequence
- The pulse library contains Gaussian pulses with peak amplitudes 1.0 and 0.5, plus a square measurement pulse; sequences select each pulse and acquire at t0 12.Acquisition omits kernel and discriminator settings, so backend defaults are used.Source: §8.1.1 · p. 60
8.1.2 Level 0 Measurement
- The experiment returns averaged measurement output at measurement level 0 for three Qobj experiments labeled amplitudes 0, 0.5, and 1.0.Source: §8.1.2 · pp. 61–62
8.1.3 Level 1 Measurement
- Level 1 returns five single-shot complex measurements per experiment, preserving state-dependent phase information in the raw acquisition data.The examples assume phase 0 for qubit 0 and π/2 for qubit 1.Source: §8.1.3 · pp. 63–64
8.1.4 Level 2 Measurement
- Level 2 converts the three amplitude experiments into classified counts: amplitude 0 yields 0x0 five times, amplitude 0.5 yields 0x0 twice and 0x1 three times, and amplitude 1.0 yields 0x1 five times.Each result contains five shots and corresponding hexadecimal memory values.Source: §8.1.4 · p. 66
8.2 T1
- The T1 example reuses the Rabi pulse library, treats pulse2 as a π pulse, and aligns measurement pulses between experiments, with listed timings at t0 190, 160, and 130.A separate square_pulse entry uses t0 200.Source: §8.2 · pp. 66–67
- The T1 experiment uses default acquisition kernel and discriminator settings and retrieves measurements as level 1 averaged data.The run dictionary leaves the acquisition kernel and discriminator unspecified, while setting the measurement level and averaged return mode.Source: §8.2 · pp. 67–68
- The example Qobj identifies a PULSE experiment with schema version 1.0.0, experiment entries, and a pulse library.The JSON includes qobj_id, schema_version, type, experiments, and pulse_library fields.Source: §8.2 · p. 68
- The run configuration uses one memory slot of size 6, qubit and measurement LO frequencies of 5.0 and 6.5, a 1000 repetition time, and 5 shots.The configuration also sets averaged measurement return through the meas_return field.Source: §8.2 · p. 68