Understanding virtual devices in Boulder Opal

The virtual device is the single source of truth for the QPU's calibration state in Boulder Opal. It acts as the digital representation of the physical device, mapping routine and experiment parameter outputs to their physical components. Every parameter output is written back to the virtual device, and every routine uses the virtual device to track progress across steps.

A virtual device is created from a YAML configuration file that describes the QPU topology, controller wiring, and initial parameter estimates. Once created, it stores a SuperconductingProcessor model containing all QPU components (transmons, resonators, couplers, Purcell filters, and feedlines), together with their physical parameters.

The virtual device is persistent and server-side. Multiple team members can access the same device, all routine and experiment results are written back automatically, and you can maintain multiple virtual devices in parallel, for example one per cooldown or one per experimental configuration.

1. Virtual device objects

Two objects can represent different views on a virtual device:

• The DeviceSummary contains metadata: the device ID, name, creation timestamp (created_at), and last-updated timestamp (updated_at). Retrieve summaries of your devices with await client.get_devices().
• The DeviceData contains the technical payload: the QPU model (a SuperconductingProcessor) and the controller configuration. Retrieve it with await client.get_device_data().

The cell below fetches the full DeviceData object for the active device. You can inspect it to retrieve the relevant information.

device_data = await client.get_device_data()

2. Component parameters

The SuperconductingProcessor in DeviceData.qpu stores a set of physical parameters for each QPU component, such as transition frequencies, coherence times, drive amplitudes, and readout thresholds. The exact parameter names available on each component class, and the expected units when reading or writing them, depend on the QPU. See your QPU's reference documentation for the full list.

Retrieve a specific component's parameters with get_component() on the QPU object. The cell below returns the parameter values stored for a single component.

device_data.qpu.get_component(component_id="q0")

3. Component references and connectivity

Each component is identified by a component ID. The naming convention is vendor- and architecture-specific, encoding component type and position in the QPU layout. See your QPU's reference documentation for the patterns used on your device.

Each component connects to the controller through named ports, with each port type carrying a different signal class for a different physical role. The set of port names, the signals they carry, and the components they attach to also depend on the QPU, consult your QPU's reference for the full port map.

Components also carry traits that describe their physical role and connectivity, for example which resonator is coupled to which transmon. Edges and couplers define the two-qubit interaction topology.

Use await client.display_device_data_sheet() to render a summary table of all components and their current parameter values. Pass node_name to filter the display to a single component. The cell below renders the data sheet filtered to a single component.

await client.display_device_data_sheet(node_name="q0")

4. State updates

Updates to the device state can occur in different ways in Boulder Opal Scale Up.

4.1 Manual updates

Modify component parameters directly with update_component() on the QPU object, then submit the changes with await client.update_device(). Use this when a routine has not converged or when injecting an independently measured value. See the How to manually update device parameters user guide for more information.

4.2 Autonomous updates

Experiments run with update="auto" or update="prompt" write their results back to the virtual device automatically on success or when the update is approved. Routines set this attribute on the experiments they orchestrate, creating a closed-loop calibration cycle. See the How to run a custom experiment user guide for more information on running experiments.

Next steps

• Getting started tutorial: install the SDK, connect to your hardware, and run your first calibration.
• The hierarchy of workflows: how experiments, routines, and solutions relate to one another.
• How to manually update device parameters: override component values or gate calibrations directly.