-
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
Ramsey unrolling #666
Ramsey unrolling #666
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #666 +/- ##
==========================================
- Coverage 97.32% 97.29% -0.03%
==========================================
Files 106 106
Lines 7057 7108 +51
==========================================
+ Hits 6868 6916 +48
- Misses 189 192 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@@ -161,31 +166,67 @@ def _acquisition( | |||
errors=errors, | |||
), | |||
) | |||
else: | |||
if params.n_osc != 0: |
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.
There is a lot of repeated code under the cases n_osc == 0
and n_osc != 0
. I would like to suggest unifying them, or moving the repeated functionality into a function. It would be even nicer if the ramsey_signal
also benefits from such unification. Unfortunately I am not able to understand what is the meaning of n_osc
from its documentation, so cannot suggest a more concrete refactoring. Let's discuss.
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 @hay-k. We should definitely find a way to improve it. Just for reference n_osc
stands for number of oscillations
. In the ramsey protocol by putting a non zero integer value we include a detuning through the relative phase that will generate n_osc
number of oscillations in the plot.
qibocal/src/qibocal/protocols/characterization/ramsey.py
Lines 190 to 195 in 528c3b9
RX90_pulses2[qubit].relative_phase = ( | |
RX90_pulses2[qubit].start | |
* (-2 * np.pi) | |
* (params.n_osc) | |
/ params.delay_between_pulses_end | |
) |
Having said this, I believe that in
ramsey
we differentiate between the n_osc==0
and the n_osc!=0
case because in the first case the protocol can be implemented through a simple sweeper on the start of the second RX90 pulse while in the second case, if I remember correctly, there are some limitations in our drivers that prevents us from sweeping start and relative phase at the same time. @stavros11 feel free to correct me if I said something wrong.
Of course the best solution for qibocal should be to keep the code as clean as possible and let the drivers handle these specific cases.
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 see, thanks for the explanation! I think, in general, the drivers (and their developers, of course) will benefit a lot from a more unified and consistent implementation. Anyways, that's a story for another day. I believe we should still simplify the code in this particular instance, even without improving anything else anywhere else. That should be doable, and I am here to assist. @Jacfomg probably best if we discuss AFK.
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.
Sure, it's sounds like a good plan.
I don't see any unit tests. (in #665 also) |
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 have not tested the code yet.
It seems ok. @Jacfomg you removed the ramsey_sequences
because we are assuming that all the drivers will be compatible either with sweepers or with sequence unrolling, correct?
tests/runcards/protocols.yml
Outdated
- id: ramsey_signal_detuned | ||
priority: 0 | ||
operation: ramsey_sequences | ||
operation: ramsey_signal | ||
parameters: | ||
unrolling: True |
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.
@hay-k this is the uni test. In this yaml
we put all the protocols that are later tested in tests/test_protocols.
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.
hmm, let's discuss this, because if I understand those tests correctly, they are more like integration or end-to-end tests, rather than unit tests. But in any way this seems like a discussion that should be kept away from this PR, not to hinder its progress.
@@ -161,31 +166,67 @@ def _acquisition( | |||
errors=errors, | |||
), | |||
) | |||
else: | |||
if params.n_osc != 0: |
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 @hay-k. We should definitely find a way to improve it. Just for reference n_osc
stands for number of oscillations
. In the ramsey protocol by putting a non zero integer value we include a detuning through the relative phase that will generate n_osc
number of oscillations in the plot.
qibocal/src/qibocal/protocols/characterization/ramsey.py
Lines 190 to 195 in 528c3b9
RX90_pulses2[qubit].relative_phase = ( | |
RX90_pulses2[qubit].start | |
* (-2 * np.pi) | |
* (params.n_osc) | |
/ params.delay_between_pulses_end | |
) |
Having said this, I believe that in
ramsey
we differentiate between the n_osc==0
and the n_osc!=0
case because in the first case the protocol can be implemented through a simple sweeper on the start of the second RX90 pulse while in the second case, if I remember correctly, there are some limitations in our drivers that prevents us from sweeping start and relative phase at the same time. @stavros11 feel free to correct me if I said something wrong.
Of course the best solution for qibocal should be to keep the code as clean as possible and let the drivers handle these specific cases.
Yeah, I would say it is a fair assumption. It has been there for far too long and I'm not aware of it being used. |
tests/runcards/protocols.yml
Outdated
priority: 0 | ||
operation: ramsey_sequences | ||
operation: ramsey_seqeunces |
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.
operation: ramsey_seqeunces | |
operation: ramsey_sequences |
It adds unrolling to the detuned ramsey
Checklist:
master
main
main