codecov[bot]
commented
5 months ago Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 97.25%. Comparing base (
37d0605) to head (6e28237).
Closed Jacfomg closed 4 months ago
codecov[bot]
commented
5 months ago All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 97.25%. Comparing base (
37d0605) to head (6e28237).
andrea-pasquale
commented
5 months ago Shouldn't the protocol also have an update function where it writes the depletion_time on the platform?
Jacfomg
commented
4 months ago Shouldn't the protocol also have an
updatefunction where it writes thedepletion_timeon the platform?
How would you fit it ?
andrea-pasquale
commented
4 months ago Shouldn't the protocol also have an
updatefunction where it writes thedepletion_timeon the platform?How would you fit it ?
I am not familiar with the experiment. I was just asking if this protocol is supposed to measure the depletion time. If not forget it.
Jacfomg
commented
4 months ago Shouldn't the protocol also have an
updatefunction where it writes thedepletion_timeon the platform?How would you fit it ?
I am not familiar with the experiment. I was just asking if this protocol is supposed to measure the depletion time. If not forget it.
It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.
andrea-pasquale
commented
4 months ago It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.
Then we should implement a protocol that does exactly this, right? (Outside this PR)
Jacfomg
commented
4 months ago It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.
Then we should implement a protocol that does exactly this, right? (Outside this PR)
Either that or we go for the QM way of getting this for the fit.
sorewachigauyo
commented
4 months ago The use of reset schemes should also reduce the delay between shots (relaxation_time runcard parameter), no? It would be good to also have this new time somewhere.
Jacfomg
commented
4 months ago The use of reset schemes should also reduce the delay between shots (
relaxation_timeruncard parameter), no? It would be good to also have this new time somewhere.
Yes, the active reset schemes will lower the relaxation time, but they will be somewhat limited by this resonator depletion time as you could not adress the qubit properly until the photons are depleted (They are also another schemes to active deplete the resonator to make all this faster). For now, I made this to store it in qibolab https://github.com/qiboteam/qibolab/pull/895.
sorewachigauyo
commented
4 months ago I see. I thought this was a reset scheme, my bad.
@alecandido Should probably take note of this when conditional logic is implemented in Qibolab pulse sequencing, which is probably a necessary feature to add eventually, since QM and Zurich already supports this (and probably can have an initial implementation with fast_reset in ExecutionParameters).
@Jacfomg Have you tested the depletion time with the active reset, if it improves the fidelity?
alecandido
commented
4 months ago @sorewachigauyo Yes, conditioning pulses on measurement outcomes is currently unsupported.
Interface-wise, it shouldn't be a too complex addition. Though it is not well-fitting the idea of a pulse sequence, and it would make it closer to a program. So, it is simple only as a patch. I have the feeling that going towards full-fledged support for flow control, it would make us rebuilding QUA (or anything like the other DSLs), since that will resemble more a program with a processor/interpreter (i.e. the sequencer), rather than a pre-compiled sequence.
Jacfomg
commented
4 months ago @alecandido Should probably take note of this when conditional logic is implemented in Qibolab pulse sequencing, which is probably a necessary feature to add eventually, since QM and Zurich already supports this (and probably can have an initial implementation with
fast_resetinExecutionParameters).@Jacfomg Have you tested the depletion time with the active reset, if it improves the fidelity?
Let's just say that for now it is not supported anymore for the Zurich driver (I made a crappy implementation to try to overcome qibolab limitations a while ago, that we removed now). I tested active reset with Zurich before being aware of this so results were bad, I expect better performance after waiting the resonator relaxation time. Still, we would need to understand first how to optimize the QND of the readout as right now 1/10 states 1 measurered, when I tested this with QM, were then measured again and were 0s, so they didn't keep the state after measurement for a effective active reset scheme.
(Sorry I edited your comment instead of replying, I edited it back)
Jacfomg
commented
4 months ago @sorewachigauyo Yes, conditioning pulses on measurement outcomes is currently unsupported.
Interface-wise, it shouldn't be a too complex addition. Though it is not well-fitting the idea of a pulse sequence, and it would make it closer to a program. So, it is simple only as a patch. I have the feeling that going towards full-fledged support for flow control, it would make us rebuilding QUA (or anything like the other DSLs), since that will resemble more a program with a processor/interpreter (i.e. the sequencer), rather than a pre-compiled sequence.
At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now. That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.
alecandido
commented
4 months ago At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now.
Yes, and that's why I said we could implement it as a patch. We could just label a pulse with the id of another measurement, and resolve the translation in the drivers.
That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.
Point is that, for sequences, we need to label all the pulses. Feasible, but hits the boundary. If you wanted to nest two different ifs, then we'd stop there, or we should start implementing boolean operations in the labeling ids, and that would be a mess...
At that point, much better to give up on the idea of the sequence, and switch paradigm for a program.
Jacfomg
commented
4 months ago At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now.
Yes, and that's why I said we could implement it as a patch. We could just label a pulse with the id of another measurement, and resolve the translation in the drivers.
That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.
Point is that, for sequences, we need to label all the pulses. Feasible, but hits the boundary. If you wanted to nest two different
ifs, then we'd stop there, or we should start implementing boolean operations in the labeling ids, and that would be a mess... At that point, much better to give up on the idea of the sequence, and switch paradigm for a program.
Ah yes, but with the patch we could play with some simple active reset schemes that may cut down the relaxation time a lot or just some checks, even if it is just a conditional if you measure a 0 skip the relaxation time and just do resonator deplation and if you measure 1 wait the relaxation time. Just so maybe you could consider this for the qibolab 0.2. Also, the several mesurements seems a bit for more advanced active reset schemes or error correction.
alecandido
commented
4 months ago Yes, definitely, I would do that (you could even add an issue in Qibolab, if not yet there, and add the milestone 0.2).
I hope the patch will be backward compatible, I have to think about that (I'm mainly worried about deserialization, since it will be an additional argument). If it is, we don't even need to do necessarily in 0.2.0 or postpone it forever, to avoid breaking, but rather release 0.2.0 asap, and then implement it in 0.2.1.
(The program approach is for sure breaking, and it would be 0.3 or further, no way it could land in current 0.2)
Jacfomg
commented
4 months ago Yes, definitely, I would do that (you could even add an issue in Qibolab, if not yet there, and add the milestone 0.2).
I hope the patch will be backward compatible, I have to think about that (I'm mainly worried about deserialization, since it will be an additional argument). If it is, we don't even need to do necessarily in 0.2.0 or postpone it forever, to avoid breaking, but rather release 0.2.0 asap, and then implement it in 0.2.1.
(The program approach is for sure breaking, and it would be 0.3 or further, no way it could land in current 0.2)
You have this already https://github.com/qiboteam/qibolab/issues/592 , so I won't create another active reset issue if this is okay for you
Following https://arxiv.org/abs/1604.00916. Just to measure the resonator depletion time. Another route would be a simpler Ramsey with a pre-measurament pulse as QM does https://github.com/qua-platform/qua-libs/blob/main/Quantum-Control-Applications/Superconducting/Single-Flux-Tunable-Transmon/09b_resonator_depletion_time.py#L124
For fitting reason I have the impression QM way would be easier to fit but the AllXY gives more information and possible ways of calibrating a depletion pulse I think.
Checklist:
mastermainmain