-
Notifications
You must be signed in to change notification settings - Fork 7
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
Conversation
Codecov Report
Additional details and impacted files@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this 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.
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
Would it be okay to add a runcard |
…/standard_rb.py Co-authored-by: Juan Cereijo <[email protected]>
There was a problem hiding this 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.
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
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 | ||
|
There was a problem hiding this comment.
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]
"""
There was a problem hiding this comment.
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?:)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
qibocal/tests/test_protocols.py
Lines 21 to 28 in 8e404f8
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…/standard_rb.py Co-authored-by: Juan Cereijo <[email protected]>
for more information, see https://pre-commit.ci
…/standard_rb.py Co-authored-by: Juan Cereijo <[email protected]>
…/standard_rb.py Co-authored-by: Juan Cereijo <[email protected]>
for more information, see https://pre-commit.ci
…qibocal into standard_rb_streamline
…into standard_rb_streamline
…qibocal into standard_rb_streamline
…into standard_rb_streamline
There was a problem hiding this 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.
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 | ||
|
There was a problem hiding this comment.
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:
qibocal/tests/test_protocols.py
Lines 21 to 28 in 8e404f8
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.
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
src/qibocal/protocols/characterization/randomized_benchmarking/standard_rb.py
Outdated
Show resolved
Hide resolved
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. |
Also, now that we have the platform on the routine we can remove the nqubits as a parameter as @andrea-pasquale suggested |
set_backend(self.backend, self.platform) | ||
return construct_backend(self.backend, self.platform) |
There was a problem hiding this comment.
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?
There was a problem hiding this 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.
Checklist: