Skip to content

Structure of the Results

Here, we give details on the structure of the Results object, returned by Session.run() and the run_experiment task.

The Results object provides two interfaces for accessing experiment results:

  • a simpler "classic" interface, and
  • a richer "workflow" interface.

Each interface provides access to the full measurement results and will be described in their respective sections below. Both are available regardless of whether workflows were used to run the experiment.

Classic interface

The classic interface provides three attributes:

  • acquired_results
  • neartime_callback_results
  • execution_errors

The measurement results are accessed via .acquired_results:

acquired_results = my_results.acquired_results

This is a dictionary of AcquiredResult objects indexed by the acquire handles. See the next page for more detail on the structure of the data and how to process it further.

When user-defined callback functions executed at near-time were part of the experiment, their return values can be accessed through the dictionary returned by

neartime_callback_results = my_results.neartime_callback_results

where the dictionary keys are the names under which the near-time callback functions have been registered in the session.

If any execution errors occurred, they can be accessed using .execution_errors:

execution_errors = my_results.execution_errors

The errors are a list of tuples containing:

  • the indices of the loops where the error occurred
  • experiment section uid
  • the error message

Workflow interface

The workflow interface provides three attributes:

  • .data
  • .neartime_callbacks
  • .errors

and, in addition:

  • a folder-like interface for exploring the data acquired by larger experiments.

Imagine that we have an experiment on two qubits that, in addition to the measurements of the experiment itself, also performs measurements of calibration traces. The handles associated with all of these measurements are:

  • q0/results
  • q0/calibration/results
  • q1/results
  • q1/calibration/results

The folder-like interface allows you to explore the results as though each / in the handle name represented a folder:

q0_results = my_results["q0"]["results"]
q0_calibration_results = my_results["q0"]["calibration"]["results"]

In the above, both q0_results and q0_calibration_results are AcquiredResult objects -- the same as those returned by looking up the handle in .acquired_results. See the next page for how to work with these.

The folder-like interface may also be explored using attribute access directly on the results:

q0_results = my_results.q0.results
q0_calibration_results = my_results.q0.calibration.results

These return the same AcquiredResult values as the item lookup above.

Lastly, the folder-like interface is also available via the .data attribute:

q0_results = my_results.data["q0"]["results"]
q0_calibration_results = my_results.data.q0.calibration.results

The advantage to going via .data is that the object returned by it contains only the acquired results, while the Result object also has other attributes that might in rare cases clash with the names of measurement handles.

In the workflow interface, the near-time callback results are accessed via .neartime_callbacks:

neartime_results = my_results.neartime_callbacks

The .neartime_callbacks attribute provides an interface very similar to that of .data. For example, if one has a near-time callback function named set_dc_bias that returns the value set to an external DC voltage source, then one could access the returned values with either:

my_results.neartime_callbacks.set_dc_bias
# or
my_results.neartime_callbacks["set_dc_bias"]

The execution errors are accessed via .errors which returns the same list as .execution_errors.

Metadata

Optionally, the Results may store the experiment and device setup used under the attributes:

  • .device_setup and
  • .experiment

Currently, these are populated by default when calling Session.run but after June 19th, 2025 they will not be populated unless requested by passing include_results_metadata=True to either Session (when creating it) or Session.run (when running an experiment).

The deprecated .compiled_experiment attribute will be entirely removed in the release after June 19th, 2025. The CompiledExperiment is not intended to be backwards compatible with older versions of LabOne Q, so its presence prevents being able to guarantee deserializing old results objects, which is desirable.

When using the run_experiment task, you can pass the include_results_metadata flag via the options class RunExperimentOptions of the task. To learn more about using Task and Workflow options, check out this page.

Pipeline job timestamps

When experiment chunking is used, the timestamps related to the execution of all chunk jobs are available as:

  • .pipeline_jobs_timestamps

The returned dictionary is organized by signal, and then job id.