Current Ramsey fitting bug

[DavidSarlle]

@andrea-pasquale @DaniloKolesnyk @Edoardo-Pedicillo @aorgazf I have being testing the Ramsey fitting and to me seems that the delta_phys calculated in the fitting should be subtracted in qubit_frequency instead of added.

If you check the reports below, you will see that, after running multiple ramsey, if the delta_phys is subtracted, the delta_phys tends to decrease. If the delta_phys is added, it tends to increase in each iteration.

(+ delta_phys)
multiple ramsey detuned (delta +).pdf

(-delta_phys)
multiple ramsey detuned (delta -).pdf

[igres26]

Did you manually detune your qubit frequency before running these experiments? What was your value for n_osc?

This function clearly captures the correct sign of the detuning as long as the induced change of frequency from the oscillations is larger than the detuning due to miscalibration. This will be the default state of the calibration once we reach Ramsey, unless something has gone terribly wrong, or the frequencies are manually detuned beyond the induced detuning of the routine.

[DavidSarlle]

@igres26 I did not detune the qubit frequency manually. The qubit frequency used was the one obtained from the qubit spec.
The number of oscilations was 10. Do we have to check the number of oscilations introduced by the user in order to be sure that the induced change of frequency from the oscillations is larger than the detuning due to miscalibration?

[igres26]

I see what is wrong now. The delta_phys is computed with the right sign under the conditions I stated. But then the corrected_qubit_frequency should subtract the delta_phys to recover the real frequency.

[DavidSarlle]

I see what is wrong now. The delta_phys is computed with the right sign under the conditions I stated. But then the corrected_qubit_frequency should subtract the delta_phys to recover the real frequency.

That was exactly what I was suggesting, because the reports are quite clear. If we substract the delta_phys to recover the real frequency, the next Ramsey iterations are reducing the physical detunning.
I was not talking about the sign when computing the delta phys, but about the sign when reconstructing the qubit freq.

[igres26]

Yep. You are right. I asked @andrea-pasquale to re-check the tests he did, since they shouldn't have worked in the first place to make sure we are not missing anything. But the found Delta should always be subtracted to recover the real frequency.

[andrea-pasquale]

I've rerun Ramsey on the RFSoC with the two signs by changing the qubit frequncy by +0.5 MHz.
The first ramsey has 5 oscillations while the second one has 3 oscillations.
This is the current version that we have in main

This is the version with the other sign:

For the RFSoC the current sign is correct. I think that this is the case because even if the new frequency is qubit_freq + delta_freq the result is correct because delta_freq < 0.
A possible solution to be consistent could be to fix delta_freq to be positive during the fitting and then we should put a minus sign. I will test with qblox now.

What do you think @igres26 and @DavidSarlle?

EDIT: in the fitting the delta_freq is already taken to be positive, so I don't know exactly where is the issue. For the RFSoC the minus sign comes from the fact that we are subtracting oscillations/t_max.

[igres26]

Double-check things, as 4 oscillations in 2000 ns is a detuning of 2 MHz, which compared with 3 oscillations should be 1.5 MHz, therefore yielding a delta_phys of +0.5 MHz. Which then should be subtracted. Can you check why you get a - sign if the detuning seen is higher than the number of oscillations you put?

[igres26]

@DavidSarlle So after testing the code with different drivers this is the conclusion we arrived to:

the sign of delta_phys depends on if you are positively or negatively detuning the ramsey experiment with the n_osc variable. The code was a bit confusing, as it does make more sense that the frequency is corrected by subtracting delta_phys from the value of the runcard. However, this was done with a change of sign, as the detuning in the ramsey is negative (!) so the signs cancelled out, and the correction was overall okay.

The real issue seems to be that given the same relative_phase, qblox is applying the inverse rotation compared to the rfsoc and zurich drivers (have not tested qm) and therefore reversing the sign of the correction and giving the wrong results.

We have to make sure that the phases are applied in the same way in all drivers if we want the routines to be independent of the platform!

The fit will be changed to be a bit easier to follow, but this will not fix the problem if all drivers do not behave equally.

[DavidSarlle]

@igres26 thanks for testing. I understand. For the moment (while we debug if we can do something with the phase at the level of the driver) we can modify Ramsey routine to return only the delta_phys, and in qibolab, depending on the platform, add or subtract the delta to the current qubit freq during the update method. This modification will not affect any driver... What do you think @andrea-pasquale @igres26 @aorgazf ?

[andrea-pasquale]

I think that this should be ok for now.

[andrea-pasquale]

I believe that with the latest version of qblox also this issue has been fixed.