Coherence Flux

[Jacfomg]

Using #949 as it is does not allow me to create several path during the for loop for the bias an have all the report separate. They will be overwritten as far as I understand. Can you take a look @alecandido or @andrea-pasquale

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

[codecov]

Codecov Report

Attention: Patch coverage is 45.45455% with 6 lines in your changes missing coverage. Please review.

Project coverage is 97.46%. Comparing base (9828b46) to head (142255d).
Report is 200 commits behind head on main.

Files with missing lines	Patch %	Lines
src/qibocal/auto/execute.py	45.45%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #954      +/-   ##
==========================================
- Coverage   97.55%   97.46%   -0.10%     
==========================================
  Files         118      118              
  Lines        9056     9067      +11     
==========================================
+ Hits         8835     8837       +2     
- Misses        221      230       +9     

Flag	Coverage Δ
unittests	97.46% <45.45%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/qibocal/auto/execute.py	93.49% <45.45%> (-4.72%)	⬇️

... and 1 file with indirect coverage changes

[andrea-pasquale]

Thanks @Jacfomg for sharing this!
You can find a few suggestions down below.

[andrea-pasquale]

I would just define a dictionary instead of defining a dataclass.

[Jacfomg]

I agree it would do the job but I like keeping similarities between protocols and sacripts it makes things simpler IMO

[alecandido]

My vote goes for skipping the 1-parameter class (there is not even any method associated, so it is truly a wrapper, not even used for the type...)

[andrea-pasquale]

True, but at the same time what we usually have in the runcard is the maximum frequency, right?

[Jacfomg]

What we usually have in the runcard is something wrong then 🤷‍♂️

[andrea-pasquale]

Using #949 as it is does not allow me to create several path during the for loop for the bias an have all the report separate.

I think that the correct of way of using it would be for you to define an executor for each flux point.
Something like:

for bias in biases:
    with Executor.open(
    "myexec",
    path="test_rx_calibration",
    platform="dummy",
    targets=[target],
    update=True,
    force=True,
) as e:
    ....

Would this work for you?

[Jacfomg]

Using #949 as it is does not allow me to create several path during the for loop for the bias an have all the report separate.

I think that the correct of way of using it would be for you to define an executor for each flux point. Something like:

for bias in biases:
    with Executor.open(
    "myexec",
    path="test_rx_calibration",
    platform="dummy",
    targets=[target],
    update=True,
    force=True,
) as e:
    ....

Would this work for you?

That would save the protocol outputs but then I would like to save the data used on the final plotting on another folder

[andrea-pasquale]

Using #949 as it is does not allow me to create several path during the for loop for the bias an have all the report separate.

I think that the correct of way of using it would be for you to define an executor for each flux point. Something like:

for bias in biases:
    with Executor.open(
    "myexec",
    path="test_rx_calibration",
    platform="dummy",
    targets=[target],
    update=True,
    force=True,
) as e:
    ....

Would this work for you?

That would save the protocol outputs but then I would like to save the data used on the final plotting on another folder

Ok then you could pass through CLI the folder for the final plot (for example).
Or if for the bias point you do something like "folder_{bias}" you could just have "folder" for the final plot.

[alecandido]

Or if for the bias point you do something like "folder_{bias}" you could just have "folder" for the final plot.

Indeed:

• each Executor has one folder, where all its output is stored, for all the protocols executed
• the report function just takes a path to an Executor folder, and generates a report with all the protocols in there

So, you have two options:

1. use many executors (or update many times its path attribute) and generate many output folders, out of which generating many reports (with one call to the report() function for each of them)
2. use a single executor, but change id to the various protocols, to save all of them in separate subfolders of the same root one, and then generate a single report (with one report() invocation) containing all the protocols

Intermediate options are available as well, since you can batch them the way you prefer.

Which one is the most convenient depends on the use case. For a limited range of values, which will be used altogether (e.g. comparing them), I'd go for option 2.. If instead you have many values, I'd organize them according to some hierarchy (which in principle could be done even with 2., but you should filter them manually during reports' generation, which is not available in a user-friendly way).

[Jacfomg]

Or if for the bias point you do something like "folder_{bias}" you could just have "folder" for the final plot.

Indeed:

• each Executor has one folder, where all its output is stored, for all the protocols executed
• the report function just takes a path to an Executor folder, and generates a report with all the protocols in there

So, you have two options:

1. use many executors (or update many times its path attribute) and generate many output folders, out of which generating many reports (with one call to the report() function for each of them)
2. use a single executor, but change id to the various protocols, to save all of them in separate subfolders of the same root one, and then generate a single report (with one report() invocation) containing all the protocols

Intermediate options are available as well, since you can batch them the way you prefer.

Which one is the most convenient depends on the use case. For a limited range of values, which will be used altogether (e.g. comparing them), I'd go for option 2.. If instead you have many values, I'd organize them according to some hierarchy (which in principle could be done even with 2., but you should filter them manually during reports' generation, which is not available in a user-friendly way).

I will go with the 1st with the small fix of defining a first unused executed to get some qubit parameters from the platform instead of defining them at every executor

[alecandido]

I will go with the 1st with the small fix of defining a first unused executed to get some qubit parameters from the platform instead of defining them at every executor

You can also instantiate the platform without an executor :)

[alecandido]

You can also instantiate the platform without an executor :)

And, in that case, you will receive a platform with all targets, so you can just query those you want, without instantiating over and over for each target (btw, this is also true for the executor: it executes the routines for a specific target, but its platform always contains all possible targets).

[alecandido]

Quick look at the first script

[alecandido]

My vote goes for skipping the 1-parameter class (there is not even any method associated, so it is truly a wrapper, not even used for the type...)

[Jacfomg]

Quick look at the first script

Regarding the CoherenceFluxSignalData I'm using it since I felt using the data.register_qubit is convenient

[Jacfomg]

because of #981 I can close it.