Pi/2 pulse

[sorewachigauyo]

Currently qibolab generates R(X) pulse of varying angles by changing the amplitude from a pi-pulse. By varying the amplitude/power of the pulse, the magnitude of the stark shift on the qubit frequency changes and it does not guarantee the precision of the rotation (rather, the axis of rotation also changes).

In the context of circuit execution, pi/2 pulses are generally used in place of GPI2 gates. I would suggest having an interface where we can define optimized or preferred pulses pertaining to the common gates. For example, instead of halving the amplitude, I may prefer to halve the duration instead.

[alecandido]

There has been already a related discussion in 28d71db#commitcomment-144903307

At the end of that, I opened #947 and #948 and qiboteam/qibocal#965.

However, the solution here is an alternative, and it takes much less to be implemented, since it does not require the $\pi/2$-pulse to be completely independent of the $\pi$-pulse.

[sorewachigauyo]

The impetus is the following circuit

import qibo
from qibo.gates import RZ, GPI2, M
import numpy as np
import matplotlib.pyplot as plt

circ = qibo.Circuit(5)
circ.add(GPI2(0, 0))
circ.add(GPI2(0, 0))
circ.add(M(0))

swp = np.linspace(0, 2 * np.pi, 50)
results = np.zeros(len(swp))

for idx, k in enumerate(swp):
    circ.set_parameters([0, k])
    results[idx] = circ().probabilities()[0]

plt.plot(swp, results)
plt.ylabel(r"P($|0\rangle$)")
plt.xlabel(r"$\theta$ [rad.]")

With the current code, I get a graph as follows:

By hacking the pi/2 pulses to be duration-based instead of amplitude-based

[alecandido]

Yes, but that's just the minimal example, meaning that everything is affected in general...

At some point, it was even discussed (I don't remember where) to actually calibrate the $\pi/2$-pulse, instead of the $\pi$-pulse, since then we're using GPI2 in compilation. Though this would affect the Rabi output, which we can change, but I'm not sure we want to (or we need to add a toggle for that - at which point it wouldn't be a replacement any longer...)

[Edoardo-Pedicillo]

In Qibocal, we are planning to implement routines for calibrating the pi/2 and to discuss changing Qibolab consistently.

Looking at the snippet, I am uncertain about its meaning. It performs a Ramsey experiment and looking at the two plots, it is clear that their phases are different and the amplitudes are close, so the asymmetry between the two cases is quite small.
From these elements, it seems that the difference is just a shift of the qubit frequency ( I don't have many details to make another hypothesis).
To compare the two approaches and appreciate the differences, I suggest executing the pi/2 pulse and a qubit state tomography and then comparing the two fidelities.

I have tried to execute it on qw11q and I got these results:

• time based
  
• amplitude based
  

Also in my results there is a small phase shift, but even with a high number of shots (5000) I'm not sure it is meaningful,
maybe I should display some error bars.

[sorewachigauyo]

Yes, it is a stark shift of the qubit frequency, caused by a combination of how Qibolab is currently generating the pi/2 pulse, the linewidth of my qubit and the power I am currently using. I think maybe your Rabi frequency is smaller than mine? I was using a pi-pulse of 46ns and drive power of about -71dBm at the qubit (IQM5Q).

For the code snippet, I was mainly debugging why a Hadamard gate decomposition was giving erroneous result and decided to check the virtual Z phase control through this small experiment, which led me to see that the pi/2 pulse was the problem.

[alecandido]

But why should it Stark-shift differently whether it is amplitude or duration based?
I.e. it is anyhow a drive pulse, and the Stark shift is driven by the residual photon population. So, unless you have a relaxation time which is too short (and it gets improved by a longer pi/2 pulse), or you have some kind of coupling between your drive line and the resonator (and it gets improved by using a smaller amplitude), I don't see why you should have a residual photon population at all...

For the code snippet, I was mainly debugging why a Hadamard gate decomposition was giving erroneous result and decided to check the virtual Z phase control through this small experiment, which led me to see that the pi/2 pulse was the problem.

Concerning this, I'm also not sure why @Edoardo-Pedicillo said that it is a Ramsey experiment, since the sweep is done on the angle of the second rotation, not on the intermediate delay (which is absent).

In Qibocal, we are planning to implement routines for calibrating the pi/2 and to discuss changing Qibolab consistently.

All-in-all, I truly wonder whether we should just calibrate the pi/2 (and not the pi, at least until #947). Though, we may have to break or abuse Qibolab...
But we should discuss this in more details.

[sorewachigauyo]

But why should it Stark-shift differently whether it is amplitude or duration based? I.e. it is anyhow a drive pulse, and the Stark shift is driven by the residual photon population. So, unless you have a relaxation time which is too short (and it gets improved by a longer pi/2 pulse), or you have some kind of coupling between your drive line and the resonator (and it gets improved by using a smaller amplitude), I don't see why you should have a residual photon population at all...

I would say it's more of the coupling between the driving field from the microwave and the qubit. From my very basic understanding of the classical AC stark shift, in the duration halved pi/2, we kept the power of the drive the same as the pi-pulse, so the frequency of the pulse was "correctly tuned" to the AC stark shifted frequency. However, when we cut the amplitude by half, the extent of the stark shift decreases and the frequency of the qubit is moving back towards to its actual frequency, so this leads to a larger detuning between the "current qubit frequency" and the drive frequency.

(I think you see some of that in the dispersion that you linked above)

[alecandido]

I see your point, so it was about the amplitude.

What I usually have in mind with the AC Stark shift is the following Hamiltonian

which is causing a qubit frequency shift because of non-trivial expectation value of the operator $a^\dagger a$.

However, you're right in that it seems to be also referred to the shift induced by a detuned pulse

with $\Omega$ the Rabi frequency, and $\Delta$ the detuning (when $\Omega \ll |\Delta|$).

I confused the two, my bad.

[sorewachigauyo]

Ah, right, I forgot that the effect of the photon occupation of the resonator on the qubit is also called the AC Stark shift.

[Edoardo-Pedicillo]

Concerning this, I'm also not sure why @Edoardo-Pedicillo said that it is a Ramsey experiment, since the sweep is done on the angle of the second rotation, not on the intermediate delay (which is absent).

Ramsey-like, because if the qubit and drive frequencies are different, in terms of gates the Ramsey experiment is RX(pi/2)-RZ(theta)-RX(pi/2) that it is exactly the circuit in the script.

All-in-all, I truly wonder whether we should just calibrate the pi/2 (and not the pi, at least until #947). Though, we may have to break or abuse Qibolab...

In this thesis (https://web.physics.ucsb.edu/~martinisgroup/theses/Chen2018.pdf) section 5.9 they calibrate both pi and pi/2 pulse. If we have just the pi/2 pulse, running a pi pulse with two pulses is inefficient.

[alecandido]

Ramsey-like, because if the qubit and drive frequencies are different, in terms of gates the Ramsey experiment is RX(pi/2)-RZ(theta)-RX(pi/2) that it is exactly the circuit in the script.

Yeah, it was not clear to me there was a detuning at all. Though I'm not yet sure is exactly analogous to Ramsey, since a delay has an interplay with coherence times, while a virtual Z rotation would lack that part. I guess this is part of the -like specifier...

In this thesis (web.physics.ucsb.edu/~martinisgroup/theses/Chen2018.pdf) section 5.9 they calibrate both pi and pi/2 pulse. If we have just the pi/2 pulse, running a pi pulse with two pulses is inefficient.

Well, that's even correct, but in general the more native pulses we calibrate, the more efficient it is. Isn't it?
And I guess most of the gates would be compiled to the $\pi/2$-pulse, as in here

qibolab/src/qibolab/compilers/default.py

Lines 52 to 79 in a6049a9

	def u3_rule(gate, platform):
	"""U3 applied as RZ-RX90-RZ-RX90-RZ."""
	qubit = list(platform.qubits)[gate.target_qubits[0]]
	# Transform gate to U3 and add pi/2-pulses
	theta, phi, lam = gate.parameters
	# apply RZ(lam)
	virtual_z_phases = {qubit: lam}
	sequence = PulseSequence()
	# Fetch pi/2 pulse from calibration
	RX90_pulse_1 = platform.create_RX90_pulse(
	qubit, start=0, relative_phase=virtual_z_phases[qubit]
	)
	# apply RX(pi/2)
	sequence.add(RX90_pulse_1)
	# apply RZ(theta)
	virtual_z_phases[qubit] += theta
	# Fetch pi/2 pulse from calibration
	RX90_pulse_2 = platform.create_RX90_pulse(
	qubit,
	start=RX90_pulse_1.finish,
	relative_phase=virtual_z_phases[qubit] - math.pi,
	)
	# apply RX(-pi/2)
	sequence.add(RX90_pulse_2)
	# apply RZ(phi)
	virtual_z_phases[qubit] += phi
	return sequence, virtual_z_phases

(delegated to the transpiler in 0.2).
So, the $\pi$-pulse would be used only to translate exactly the $X$ gate, and nothing else. I'm not sure that is a priority (i.e. more a priority than #947).

P.S.: from section 5.9 of the thesis, it seems to me that they are calibrating the $\pi$-pulse as an intermediate step for $\pi/2$ calibration...

[Edoardo-Pedicillo]

So, the π-pulse would be used only to translate exactly the X gate, and nothing else. I'm not sure that is a priority (i.e. more a priority than #947).
P.S.: from section 5.9 of the thesis, it seems to me that they are calibrating the 𝜋 -pulse as an intermediate step for 𝜋 / 2 calibration...

I agree with the priorities, even though this could affect the RB gate fidelity, so probably Qibocal side it is a priority.

Just a small comment: in the thesis, they use X and Y, as shown in sec. 6.2