Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stream line standard rb #391

Merged
merged 37 commits into from
Jun 13, 2023
Merged

Stream line standard rb #391

merged 37 commits into from
Jun 13, 2023

Conversation

wilkensJ
Copy link
Contributor

@wilkensJ wilkensJ commented Jun 7, 2023

Checklist:

  • Reviewers confirm new code works as expected.
  • Tests are passing.
  • Coverage does not decrease.
  • Documentation is updated.

@codecov
Copy link

codecov bot commented Jun 7, 2023

Codecov Report

Merging #391 (aeda2ff) into main (cae85be) will increase coverage by 0.78%.
The diff coverage is 98.97%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #391      +/-   ##
==========================================
+ Coverage   95.44%   96.23%   +0.78%     
==========================================
  Files          46       43       -3     
  Lines        2942     2866      -76     
==========================================
- Hits         2808     2758      -50     
+ Misses        134      108      -26     
Flag Coverage Δ
unittests 96.23% <98.97%> (+0.78%) ⬆️

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

Impacted Files Coverage Δ
...cterization/randomized_benchmarking/standard_rb.py 99.11% <98.75%> (-0.89%) ⬇️
src/qibocal/auto/operation.py 93.15% <100.00%> (+0.09%) ⬆️
src/qibocal/auto/runcard.py 97.82% <100.00%> (+0.04%) ⬆️
src/qibocal/auto/task.py 97.64% <100.00%> (ø)
...haracterization/randomized_benchmarking/fitting.py 93.54% <100.00%> (ø)
...cterization/randomized_benchmarking/noisemodels.py 100.00% <100.00%> (+22.22%) ⬆️

... and 1 file with indirect coverage changes

Copy link
Contributor

@Jacfomg Jacfomg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, can we add something saying that the layer_gen() allows the generation of proper random circuits to avoid confusion for the next people that will read the routines ? Just because my first thought was why were you not passing random_clifford() directly.

@vodovozovaliza
Copy link
Contributor

Would it be okay to add a runcard test_autocalibration_sim.yml with a numpy backend to test RB routines with noise models? Noise models simulation will not work with qibolab backend.

Copy link
Contributor

@Jacfomg Jacfomg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that for the time being if you try to specify noise_models but you have specified a platform not to have it change to a simulation backend on itself for now but check the platform and raise an error. I will look into that.

@Jacfomg
Copy link
Contributor

Jacfomg commented Jun 8, 2023

Would it be okay to add a runcard test_autocalibration_sim.yml with a numpy backend to test RB routines with noise models? Noise models simulation will not work with qibolab backend.

I would say yes for now, ideally we will want to have them both on the same runcard. I am not sure if how. Maybe runcards with both a global platform and backend and the routine chooses ?

from qibocal.protocols.characterization.randomized_benchmarking.utils import (
extract_from_data,
random_clifford,
)

from .data import RBData
from .params import RBParameters
from .fitting import exp1B_func, fit_exp1B_func

Copy link
Contributor

@Jacfomg Jacfomg Jun 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a little example could be nice or will it be unnecessary @andrea-pasquale. Also specifies in a way what is Simulation or not.

Standard RB: Summary or paper ?

An example action for using this routine is the following:

        qubits: [0, 1, 2]
        actions:

            - id: StdRB
            priority: 00
            operation: standard_rb
            #main: 
            parameters:
                nqubits: 5
                qubits: [0,2]
                depths:
                    start: 5
                    stop: 15
                    step: 3
                niter: 5
                nshots: 1024
                noise_model: [Sim]
                noise_params: [Sim]

"""

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what does [Sim] stand for?:)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simulation. Just thought of something to tell people which parameters they need for hardware and simulation, feel free to change it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean for the documentation? Yes totally! I mean the actions_qq_auto has the part already, but I totally agree, we have to add a documentation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, I am also trying to think if we have new people joining, but maybe it's redundant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm, I would say that the best approach here would be to define a backend argument and to throw an error if the noise model is used with the qibolab backend. I still don't know if this is the best approach.

In #351 I decided to used the following approach to fix tests:

if "noise_model" in action["parameters"]:
yield {
"actions": [action],
"backend": "numpy",
"qubits": list(PLATFORM.qubits),
}
else:
yield {"actions": [action], "qubits": list(PLATFORM.qubits)}

Another idea could be to define a new type for those routine that are executable also in simulation.
I would say that this is out of the scope of this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, the noise model can also be applied through qibolab and is not at all restricted to simulation, or? Technically, it is just a transpiler that is run before passing the circuit to the platform. It is just that the current noise models will often result in circuits (with channels) that qibolab does not know how to compile, e.g. because probabilistic compilation is not implemented. A noise model with only coherent error for example, would already work. The reason we have the noise model parameters in the run card is because it actually also makes sense to allow for 'synthetic' noise when running things on the device. Thus, I think it might actually not be qibocal's job to catch the exception but qibolab's (in the sense it is already doing).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation @ingoroth.
I also agree that this should be addressed in qibolab (and perhaps even in qibo).
Until we solve the issue at least for qibocal we need to always use simulation to run a noise model.
We can merge this PR without this feature for the time being.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrea-pasquale can you show me what should be changed now for this PR? I am a bit lost in what should stay/be changed, sorry of the confusion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding this point you can open an issue if you want.
All the rest looks good to me.

Copy link
Contributor

@andrea-pasquale andrea-pasquale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @wilkensJ @vodovozovaliza @Jacfomg for all the updates.
Generally the code looks good to me. You can find a few suggestions below.

src/qibocal/auto/operation.py Outdated Show resolved Hide resolved
from qibocal.protocols.characterization.randomized_benchmarking.utils import (
extract_from_data,
random_clifford,
)

from .data import RBData
from .params import RBParameters
from .fitting import exp1B_func, fit_exp1B_func

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm, I would say that the best approach here would be to define a backend argument and to throw an error if the noise model is used with the qibolab backend. I still don't know if this is the best approach.

In #351 I decided to used the following approach to fix tests:

if "noise_model" in action["parameters"]:
yield {
"actions": [action],
"backend": "numpy",
"qubits": list(PLATFORM.qubits),
}
else:
yield {"actions": [action], "qubits": list(PLATFORM.qubits)}

Another idea could be to define a new type for those routine that are executable also in simulation.
I would say that this is out of the scope of this PR.

@Jacfomg
Copy link
Contributor

Jacfomg commented Jun 9, 2023

Found an issue when ussing dummy that the probabilities get divided based on how many qubits you put on the parameters for the RB. Dummy seemed working properly, we may want to check what's happening next week with that.

@Jacfomg
Copy link
Contributor

Jacfomg commented Jun 12, 2023

Also, now that we have the platform on the routine we can remove the nqubits as a parameter as @andrea-pasquale suggested

Comment on lines +56 to 57
set_backend(self.backend, self.platform)
return construct_backend(self.backend, self.platform)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stavros11 this is a temporary solution.
I don't know if there is a better way to do it. Currently it was not working since for the RB when executing circuits we don't pass the backend and by doing circuit() we will fall back to the default backend.
Currently I feel like this approach is a bit redundant. Do you have any suggestions?

Copy link
Contributor

@andrea-pasquale andrea-pasquale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @vodovozovaliza @wilkensJ @Jacfomg.
Feel free to merge this PR.

@vodovozovaliza vodovozovaliza added this pull request to the merge queue Jun 13, 2023
Merged via the queue into main with commit 10cbdf0 Jun 13, 2023
@vodovozovaliza vodovozovaliza deleted the standard_rb_streamline branch June 13, 2023 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants