The quantum lab puzzle that took me five years to solve
Back in my PhD, my team and I ran one of the first ion trap chips with integrated photonics. But the chip had a problem, and I thought I had a clever solution… that for some stubborn reason refused to work. It only took me five years to understand what I did wrong. Let’s see if you can spot it!
The backstory
Here is the setting. In my cryostat, I have an ion trap chip with some 40Ca+ ions. The qubit is encoded in the 2S1/2 ↔ 2D5/2 transition, driven by light at 729 nm. Lasers at 397, 854 and 866 nm are used for state preparation, cooling, measurement and reset.
While most laser beams are applied in free space, the light at 729 nm is delivered through chip-integrated photonics, as shown below.
To perform a quantum gate, I apply 729 nm light from an off-chip laser through an on-chip waveguide onto the ion. The pulse duration determines the gate area. For example, the plot below from my thesis gives a full population transfer (a π pulse, or X gate) in about 3.1 µs. This corresponds to a Rabi frequency of $\Omega/(2\pi) = 1/(2t_\pi) \approx 163\,\mathrm{kHz}$.
This worked beautifully for single-qubit gates, but there was a problem with two-qubit gates: the laser pulses shifted the ion’s position. Due to a combination of chip heating and chip charging (think photoelectric effect), the more power I applied in the pulse, the further away the ion moved. The movement was tiny, on the nanometer scale over tens of seconds, but it was enough to mess up entangling interactions due to its impact on the ions’ motional frequency, which needs to be well stabilised during two-qubit gates.
The (attempted) solution
So what do we do about this charging? Based on some other observations, I established that if I left the light on for long enough, the effect saturated. In other words: once the chip had settled, the ion stopped moving. The problem seemed to be with pulsing the power on and off.
That gave me an idea. Instead of turning the beam off between gates, why not detune it very, very far from the qubit transition? I could shift its frequency with an electro-optic modulator, then bring it back onto resonance whenever I wanted to perform a gate. The power on the chip would stay constant, while the detuned light would, I thought, do essentially nothing to the ion.
As soon as I tried it out, the problem of my ion moving went away. It seemed like detuning the beam, rather than turning it off, really was the magic solution to all my worries. The light-induced qubit frequency shifts, and the resulting decoherence, also seemed reasonable. The only thing left was to choose a detuning large enough to avoid unwanted population transfer.
So how far would I have to detune to keep the D-state excitation probability low enough? We can work this out from the state-transfer probability for a detuned Rabi oscillation. Starting in S1/2, the probability of reaching D5/2 in the ideal two-level model is
\[P_{S\to D}(t) = \frac{\Omega^2}{\Omega^2+\Delta^2}\, \sin^2\!\left(\frac{t}{2}\sqrt{\Omega^2+\Delta^2}\right),\]where $\Omega$ is the resonant Rabi frequency and $\Delta$ is the laser detuning, both in radians per second. The sine squared can never exceed one, so the oscillation contrast, or maximum transfer probability, is
\[P_{\max}(\Delta) = \frac{\Omega^2}{\Omega^2+\Delta^2}.\]For example, requiring this maximum to be less than $\epsilon=10^{-5}$, and using the fitted Rabi frequency above, gives
\[\frac{\lvert\Delta\rvert}{2\pi} > \frac{\Omega}{2\pi}\sqrt{\frac{1}{\epsilon}-1} \approx 51.5\,\mathrm{MHz}.\]So the answer appeared to be: with a detuning of 51.5 MHz or more, I was never going to see a D-state excitation probability above $10^{-5}$, no matter how long I left the light on. That seemed like a safe operating regime!
The puzzle
However, the attempt didn’t go as planned. In experiment after experiment, I saw unwanted population transfer between the qubit states, much larger than I expected from the formula above. Something else was moving the population around, and I couldn’t figure out what (it wasn’t the finite laser linewidth; I checked). Thus, I reluctantly abandoned the scheme in favor of more conventional duty cycle management.
Can you figure out what went wrong? If you can, post your answer in the comments. Otherwise, stay tuned for the next post, where I’ll reveal the answer.