[Bug Report] Unexpected offset charge in split junction transmon?

QuantumWitness commented 2 years ago

Describe the Bug

I was messing around with SQcircuit and scqubits when I noticed that the energy spectra for a split junction transmon as a function of flux bias $\Phi$ at ng=0 did not agree between the two packages.

Specifically the issue is that, in SQcircuit, the spectrum returns degenerate $|0\rangle \mathrm{and} |1\rangle$ states at half a flux quantum in loop1. This is only expected to happen when the offset charge, which I call ng, is set to 0.5. However, as far as I know, when I initialized the circuit elements and the circuit itself, I did not specify an offset charge and assumed it would start as ng=0.

Further, when I set the offset charge with the command set_charge_offset(1,0), the spectrum I get back is what I would have expected for ng=0.5.

Here is the spectrum around $\Phi_{loop1} = \frac{\Phi_0}{2}$ with ng=0:

Here's the spectrum around the same flux points, but with set_charge_offset(1,0.5) such that ng=0.5:

The minimum of $E_{01}$ is now 798 MHz, which is 4Ec, exactly what you'd expect at ng=0, rather than ng=0.5.

Expected Behavior

I expected the spectra above to be switched with respect to the offset charge.

To Reproduce

Here's the code I used to make the transmon and plot the spectrum.

import SQcircuit as sqcirc
import matplotlib.pyplot as plt

init_flux=0
C = 97 #fF
Ej = 24 #GHz
ng = 0.5
ncut = 30

sqcirc.set_unit_cap('fF')
sqcirc.set_unit_JJ('GHz')

loop1 = sqcirc.Loop(value=init_flux)
C1 = sqcirc.Capacitor(value=C)
JJ1 = sqcirc.Junction(value=Ej/2, loops=[loop1])
JJ2 = sqcirc.Junction(value=Ej/2, loops=[loop1])

elements = {(0,1): [C1,JJ1,JJ2]}

tmon = sqcirc.Circuit(elements)
tmon.set_trunc_nums([ncut])
tmon.set_charge_offset(1,ng)
# get the first two eigenfrequencies and eigenvectors
n_eig=5
efreqs, evecs = tmon.diag(n_eig=n_eig)

# print the qubit frequency
print("qubit frequencies:", efreqs-efreqs[0])

flux_array = np.linspace(-0.48,-.52,101)

eigval_array = np.zeros((n_eig,len(flux_array)))
for index, f in enumerate(flux_array):
    loop1.set_flux(f)
    efreqs, _ = tmon.diag(n_eig=n_eig)
    eigval_array[:,index]=efreqs-efreqs[0]

plt.figure(figsize=(6,4))
for i in range(n_eig):
    plt.plot(flux_array, eigval_array[i,:], label=f'|{i}$\\rangle$')

plt.xlabel('Loop Flux ($\Phi_0$)')
plt.ylabel('Energies (GHz)')
plt.title(fr'Tmon Spectrum, $n_g$ = {ng}')
# plt.legend()
plt.tight_layout()
plt.show()

OS and Version

OS: MacOS 12.1 SQCircuits Version: 0.0.1 Python Version: 3.8

Other Comments

The main question in my mind is: is this a bug, or is there a design decision here that sets some implicit charge offset on the transmon? Or did I do something wrong when creating the circuit?

taha1373 commented 2 years ago

Hi @QuantumWitness,

Thanks for using SQcircuit and sharing your issue with us.

Basically, there is no Bug neither in SQcirucit nor in your code. It all comes to how we construct the basis for the charge modes. ng can be altered through the canonical transformations that we use to build the circuit. Therefore, dealing with circuit prone to charge mode and charge noise, you should also scan your spectrum in ng.

However, I will make sure that in the next patch 0.0.13, we have the same standard with what you described to avoid the confusion.

QuantumWitness commented 2 years ago

Thanks for the clarification!

It turns out I have an additional question about this transform (probably answered in the paper, but I'll ask here first). It's odd to me that a transformation can alter something that seems like it should be invariant, specifically the amount of charge (modulo 2e) at a certain node. What you're saying sounds like the value of ng=0 is kind of arbitrary, like the zero of gravitational potential in a kinematics problem. Is that right?

taha1373 commented 2 years ago

No worries! In building Hilbert space, I was not cautious to make sure that charge offsets on charge island are zero, and they may not stay invariant through the transformations, which I can fix it. What causes confusion is that I meant ng to be shift in charge offset rather than charge on charge islands. I should have used Δng instead of ng, since Δng is what user specifies in SQcircuit.

QuantumWitness commented 2 years ago

Ah, I understand!

Unrelated, but since we're talking here-

Would you prefer people post feature requests as issues in the GitHub? If I (or someone else) is having issues getting a circuit to function correctly, should we post an issue? If no, is there a Discord, Slack, some other way to get assistance with unexpected circuit behavior?

taha1373 commented 2 years ago

No problem @QuantumWitness

First, version 0.0.13 is released and the issue of unknown charge offset should be solved.
Second, you made a vary good point. Let's keep all problem, issues, and frustrations in github, since other people may encounter the same issue and they can solve it by searching online.
Third, for feature request and more detail discussion, it's a good idea to have a channel that people can discuss the ideas. I personally prefer Discord to Slack from all perspectives, but people in Academia mainly use Slack. So I probably make a Slack channel. Also if you want any function or properties to be added to SQcircuit you can write down the code based on PEP8 style and send us pull request. (you can also email me if you have any specific suggestion or idea)

QuantumWitness commented 2 years ago

Thanks for the info. Downloaded v0.0.13 and it looks like things are working as expected.

stanfordLINQS / SQcircuit