Example scripts

[Jacfomg]

I agree this should not be like that, but I feel simpler just to reuse the protocols plotting, dataclasses and results objects. Just for now to get some results for the qibocal paper. After we just need to copy paste the acquisition part and that would be the script.

Checklist:

• Reviewers confirm new code works as expected.
• Tests are passing.
• Coverage does not decrease.
• Documentation is updated.
• Compatibility with Qibo modules (Please edit this section if the current pull request is not compatible with the following branches).
  • Qibo: master
  • Qibolab: main
  • Qibolab_platforms_qrc: main

[alecandido]

Thanks for experimenting with the scripts.
It seems clear that import will only be a device to simplify disposable scripts, but more structured application we should advise the usage of the context manager (cf. #949) and access the routines from the executor.
E.g.:

with Executor.open(...) as e:
    e.flipping(...)

Keep this PR draft for a moment. We will work on the context manager, to add plots on the fly, and to put together some (proto-)official recommendations about how to use the scripts API. Then we will come back and simplify this code :)

[Jacfomg]

Thanks for experimenting with the scripts. It seems clear that import will only be a device to simplify disposable scripts, but more structured application we should advise the usage of the context manager (cf. #949) and access the routines from the executor. E.g.:

with Executor.open(...) as e:
    e.flipping(...)

Keep this PR draft for a moment. We will work on the context manager, to add plots on the fly, and to put together some (proto-)official recommendations about how to use the scripts API. Then we will come back and simplify this code :)

Great, once #949 is finished I could take a look to update this.

[Jacfomg]

Also @stavros11 @andrea-pasquale @alecandido I found that for an RB experiment they want for the qibocal paper could we write the RB part with QUA and the rest of the protocols with a qibocal script? If not each RB scans takes half an hour and they would like to do 10 at least in the whole experiment

[andrea-pasquale]

Also @stavros11 @andrea-pasquale @alecandido I found that for an RB experiment they want for the qibocal paper could we write the RB part with QUA and the rest of the protocols with a qibocal script? If not each RB scans takes half an hour and they would like to do 10 at least in the whole experiment

Yes, we could. I believe @stavros11 has a protocol working for the RB protocol. It should be relatively easy to do it.
Regarding that, I'm almost done with an example script. I will push it soon.

[alecandido]

@stavros11 will confirm, but I understood the QUA RB is a Qibocal protocol. So, it could be included in a Qibocal script as the ordinary RB, together with everything else (and even in the unlikely case in which it isn't, and @stavros11 manually generated his report, we could make it a protocol)

Scripts are alternative to runcards, not to protocols.

[stavros11]

@stavros11 will confirm, but I understood the QUA RB is a Qibocal protocol.

Yes, the RB protocol in QUA is now a Qibocal protocol defined in a branch called qua (particularly here https://github.com/qiboteam/qibocal/tree/qua/src/qibocal/protocols/qua).

Here is an example runcard for running this:

platform: qw11q

targets: ["D1"]

actions:

  - id: rb_qua
    operation: rb_ondevice
    parameters:
      num_of_sequences: 10000
      max_circuit_depth: 500
      delta_clifford: 10
      n_avg: 1
      save_sequences: True
      apply_inverse: True  # if `False` it will apply "filtered" post-processing
      state_discrimination: True

and here some example reports: qiboteam/qibolab_platforms_qrc#154. Note that this is different than our existing RB protocol because the sequences are generated in the device and are correlated.

I was not planning to open a PR for this for the following reasons:

1. It is not instrument agnostic, which is against the whole qibolab/qibocal philosophy.
2. Currently it is not even platform agnostic, as some part of configuration.py (device connections) is hard-coded for the qw11q platform. It will not work for any other QM platform, however I am planning to fix this.
3. The code quality is not the best. It is also mostly copied from the qua-libs example (https://github.com/qua-platform/qua-libs/blob/main/Quantum-Control-Applications/Superconducting/Single-Fixed-Transmon/16a_randomized_benchmarking.py) and I am doing as little modifications as possible to avoid breaking it. That's why even the plot is using the matplotlib code from the example and not plotly. The idea is to have a template to quickly port other routines from qua-libs that could be useful and give a speed-up that we cannot easily get from the current qibolab driver.

This routine also has a small enhancement over the original qua example as it allows to download the sequences from the device, since these are needed for the filtered and restless post-processing.

[andrea-pasquale]

@stavros11 will confirm, but I understood the QUA RB is a Qibocal protocol.

Yes, the RB protocol in QUA is now a Qibocal protocol defined in a branch called qua (particularly here https://github.com/qiboteam/qibocal/tree/qua/src/qibocal/protocols/qua).

Here is an example runcard for running this:

platform: qw11q

targets: ["D1"]

actions:

  - id: rb_qua
    operation: rb_ondevice
    parameters:
      num_of_sequences: 10000
      max_circuit_depth: 500
      delta_clifford: 10
      n_avg: 1
      save_sequences: True
      apply_inverse: True  # if `False` it will apply "filtered" post-processing
      state_discrimination: True

and here some example reports: qiboteam/qibolab_platforms_qrc#154. Note that this is different than our existing RB protocol because the sequences are generated in the device and are correlated.

I was not planning to open a PR for this for the following reasons:

1. It is not instrument agnostic, which is against the whole qibolab/qibocal philosophy.

2. Currently it is not even platform agnostic, as some part of `configuration.py` (device connections) is hard-coded for the qw11q platform. It will not work for any other QM platform, however I am planning to fix this.

3. The code quality is not the best. It is also mostly copied from the qua-libs example (https://github.com/qua-platform/qua-libs/blob/main/Quantum-Control-Applications/Superconducting/Single-Fixed-Transmon/16a_randomized_benchmarking.py) and I am doing as little modifications as possible to avoid breaking it. That's why even the plot is using the matplotlib code from the example and not plotly. The idea is to have a template to quickly port other routines from qua-libs that could be useful and give a speed-up that we cannot easily get from the current qibolab driver.

This routine also has a small enhancement over the original qua example as it allows to download the sequences from the device, since these are needed for the filtered and restless post-processing.

Thanks @stavros11, although it is true that your qua protocol goes against qibolab-qibocal philosophy, I was thinking that we could try to sell this an additional feature in order to somewhat detach qibocal from qibolab. It is not necessarily a bad idea to have some protocols which are instrument-specific as long they are very few I would say :)

[stavros11]

2. Currently it is not even platform agnostic, as some part of configuration.py (device connections) is hard-coded for the qw11q platform. It will not work for any other QM platform, however I am planning to fix this.

Regarding this point, I just noticed that even the sweetspots are hard-coded to the previous values, instead of loaded from the runcard, and therefore don't work anymore, other than qubit D4 for which the sweetspot did not change much. I will try to fix this so that it loads the configuration from the qibolab platform.

[alecandido]

Thanks @stavros11, although it is true that your qua protocol goes against qibolab-qibocal philosophy, I was thinking that we could try to sell this an additional feature in order to somewhat detach qibocal from qibolab. It is not necessarily a bad idea to have some protocols which are instrument-specific as long they are very few I would say :)

Well, what means "very few" is rather arbitrary, and that's the dangerous part.

However, I'm also aware that something like this has to be taken into account, but in general, I would follow a different strategy that does not affect the Qibolab-Qibocal split.

In particular, the long-term strategy has been outlined in qiboteam/qibolab#854 and qiboteam/qibolab#917, and it will be at the heart of Qibolab 0.3 (in case you didn't know, I'm already getting ready for the next breaking changes :P).
It won't be simple, and it's far from precise. But we could start taking its philosophy (if you agree with that) as a guiding principle, even for short term developments.

The general idea is to expose more features through Qibolab. Even features that are not available for all drivers.
In this case, getting all the building blocks to implement the RB in Qibocal in a QUA-efficient way would require the full qiboteam/qibolab#917, which is out of reach in the short term.
Instead, what we could do is to implement the full RB in the QM driver, and establish a special instruction for "perform an RB". Since, before actual Qibolab programs, the programs are just sequences, this means that there will an RB pulse.

I know the proposal looks pretty weird at first glance, but I invite you to go through the rationale, and only consider the practical step as the consequence.
Moreover, this will have the benefit of keeping Qibocal complexity low, and all protocols still device-agnostic: there will be a standard_rb_sequence, and a standard_rb as for routines with sweepers (or you could choose other names, but the baseline is that one will be portable to all drivers, and the other one hardware optimized for all drivers supporting it).

[Jacfomg]

I will just push draft stuff here also from the qua protocol before getting proper scripts like the ones in #954

[alecandido]

It definitely sounds bad...

[Jacfomg]

I think both of these changes come from @stavros11 pr

[andrea-pasquale]

I'm closing this since all scripts for the qibocal paper have been moved to https://github.com/qiboteam/qibocal-paper-data