Fast single-qubit RB for QM

[stavros11]

Following the discussion in #951 (comment), I am opening a draft PR for this as others may be interested.

As described in that comment, it provides a faster (close to ideal time) implementation of single qubit RB for QM, following the example from https://github.com/qua-platform/qua-libs/blob/main/Quantum-Control-Applications/Superconducting/Single-Fixed-Transmon/16a_randomized_benchmarking.py with the sampling of random sequences happenning on the device. It also provides the possibility to disable the last inverse gate and apply filtered post-processing, or reduce the relaxation time to execute restless.

Example runcard:

platform: qw11q

targets: ["D1"]  # only works for one qubit (no two qubits in parallel)

actions:

  - id: rb_qua
    operation: rb_ondevice
    parameters:
      num_of_sequences: 10000  # Number of random sequences.
      max_circuit_depth: 500  # Maximum circuit depth.
      delta_clifford: 10  # Depth step. Depths applied are [1, delta, 2 * delta, ..., max].
      n_avg: 1  # Number of repetitions of the same circuit (for averaging).
      save_sequences: True  # Download the Clifford gate indices used from the device.
      apply_inverse: True  # Apply inverse gate at the end of every circuit. If `False` it will apply "filtered" post-processing.

Example report: http://login.qrccluster.com:9000/jKoOT3NjREyjnnb1m-R_0A==/. More examples here: qiboteam/qibolab_platforms_qrc#154 (comment).

The are no plans to merge this soon as the code quality is not very good, so I would not spend time on reviews at this stage. Any suggestions for improvements are welcome though, for example for the data saving that is a bit messy.

[alecandido]

@stavros11 @ingoroth in particular I mean here we could iterate with a for_each_ over a list, provided by the user as an input, in place of the max_circuit_depth parameter.

[stavros11]

I think this loop needs to have step 1 in every cases, because a few lines below we are saving sequence_list[depth] to the stream that is then used to return the sequence indices to the user if save_sequences=True. And we need to save the indices at all depths, even when we are not running on every depth (regardless of logarithmic or no). Therefore, for_each_ wouldn't be useful here.

[alecandido]

Couldn't you use another variable to index it?

The equivalent of for i, depth in enumerate(depths) and then save in sequence_list[i].
(of course QUA doesn't have enumerate() on hardware, but you could realize just by initializing a counter to 0 outside, and increment it by 1 at every loop)

[stavros11]

@ingoroth in a74c0ee I added the possibility to increase depths logarithmically. It can be enabled using logarithmic: True and delta_clifford will then act as the exponent, so the depths should be 2, 2^delta_clifford, 2^(2*delta_clifford), ..., up to max_circuit_depth. An example action runcard is:

  - id: RB QUA
    operation: rb_ondevice
    parameters:
      num_of_sequences: 10000  # Number of random sequences.
      max_circuit_depth: 1024 # Maximum circuit depth.
      delta_clifford: 1
      logarithmic: True
      n_avg: 1  # Number of repetitions of the same circuit (for averaging).
      save_sequences: True  # Download the Clifford gate indices used from the device.
      apply_inverse: True  # Apply inverse gate at the end of every circuit. If `False` it will apply "filtered" post-processing.

I did a quick test and it seems to work (and is quite faster) up to depth 1024, but failed for 2048. If that is not sufficient for you application we could try to push it.

[stavros11]

This was not compatible with the OPX1000 due to some bugs related to the latest qm-qua prerelease or its firmware, in particular:

1. Voltage offsets (used for sweetspots) are not set properly from the config, so we need to force the using the set_dc_offset in the QUA program (this is a bug in QOP320 confirmed by QM).
2. Strict timing throws an error which was not happening in the OPX+. I asked QM to check this and temporarily bypassed this using compiler options.

The workarounds for these were done in 7d22c7b and now this should work also for the OPX1000, see for example a report with the qw5q_platinum: http://login.qrccluster.com:9000/KjIpqUWCQw6-ehT9HlgvTw==

@biankawolo @igres26 you may be interested in this. If you attempt to pull, please use git pull --rebase because I also rebased this to the latest main.