Thanks a lot for the blog post! Really appreciate the side-by-side comparison of SQcircuit and scQubits. I totally agree with "Doing the Thing instead of endlessly preparing yourself to Do the Thing"!
To answer your question whether the tunable coupling vs. coupler flux curve is what I expected: No ;-) I would expect that at zero coupler flux, when the coupler is far removed from the qubits in frequency, so it doesn't participate much and the qubits are almost uncoupled. But at zero coupler flux, the plot shows a gap=2*coupling of 500 MHz which is super large.
After some digging: it looks like when you construct a circuit from YAML with scQubits, it uses a default cutoff of |n| = 5 for the non-periodic variables, which is of course too small to model transmons. If you make the cutoff much larger the calculation takes long, so hierarchical diagonalization is probably the way to go. Code below, this works with scqubits==3.0.2 :-)
The "leading order" intuitive explanation of tunable couplers I'm familiar corresponds to eq (2) in Yan et al, https://arxiv.org/abs/1803.09813. It says that a direct capacitance gives a positive coupling, and an indirect coupling via the coupler transmon gives a negative coupling. So if you get the indirect coupling just right by tuning the coupler frequency, the two coupling channels cancel out. I can't really back that explanation up, so I'm looking forward to your coupler blogpost!
That would suggest that the direct qubit-qubit capacitance is necessary to have an off-point. I.e., the stray qubit-qubit capacitance is a feature not a bug here. That turns out to be the case numerically: Plotting the coupling on a logscale, it never actually reaches zero, but stays above 1MHz or so which would be too large in practice. If you add a small capacitance between nodes 1 and 3, with a charging energy of say 48.4 GHz, there is a good off point. Let me know if you agree!
I agree with you that beyond a flux of 0.4 or so, the coupler goes below the qubits in frequency, so getting the coupling as the difference between the second and first excited energies no longer works.
Also there’s a new tunable coupler paper that just dropped: https://arxiv.org/pdf/2207.06607.pdf
What if you made a coupler out of two transmons instead of one? Might be fun to simulate
Thanks a lot for the blog post! Really appreciate the side-by-side comparison of SQcircuit and scQubits. I totally agree with "Doing the Thing instead of endlessly preparing yourself to Do the Thing"!
To answer your question whether the tunable coupling vs. coupler flux curve is what I expected: No ;-) I would expect that at zero coupler flux, when the coupler is far removed from the qubits in frequency, so it doesn't participate much and the qubits are almost uncoupled. But at zero coupler flux, the plot shows a gap=2*coupling of 500 MHz which is super large.
After some digging: it looks like when you construct a circuit from YAML with scQubits, it uses a default cutoff of |n| = 5 for the non-periodic variables, which is of course too small to model transmons. If you make the cutoff much larger the calculation takes long, so hierarchical diagonalization is probably the way to go. Code below, this works with scqubits==3.0.2 :-)
The "leading order" intuitive explanation of tunable couplers I'm familiar corresponds to eq (2) in Yan et al, https://arxiv.org/abs/1803.09813. It says that a direct capacitance gives a positive coupling, and an indirect coupling via the coupler transmon gives a negative coupling. So if you get the indirect coupling just right by tuning the coupler frequency, the two coupling channels cancel out. I can't really back that explanation up, so I'm looking forward to your coupler blogpost!
That would suggest that the direct qubit-qubit capacitance is necessary to have an off-point. I.e., the stray qubit-qubit capacitance is a feature not a bug here. That turns out to be the case numerically: Plotting the coupling on a logscale, it never actually reaches zero, but stays above 1MHz or so which would be too large in practice. If you add a small capacitance between nodes 1 and 3, with a charging energy of say 48.4 GHz, there is a good off point. Let me know if you agree!
I agree with you that beyond a flux of 0.4 or so, the coupler goes below the qubits in frequency, so getting the coupling as the difference between the second and first excited energies no longer works.
```
import numpy as np
import scqubits as scqub
import matplotlib.pyplot as plt
tcap_coupled_tmon = """# transmon circuit
branches:
- ["JJ", 0, 1, 12,10]
- ["JJ", 1, 0, 12,10]
- ["C", 1, 0, 0.2]
- ["C", 1, 2, 4.84]
- ["JJ", 0, 2, 36,10]
- ["JJ", 2, 0, 36,10]
- ["C", 2, 0, 0.1]
- ["C", 2, 3, 4.84]
- ["JJ", 0, 3, 12,10]
- ["JJ", 3, 0, 12,10]
- ["C", 3, 0, 0.2]
"""
tcap_tmons = scqub.Circuit(tcap_coupled_tmon, from_file=False, ext_basis="discretized")
tcap_tmons.configure(transformation_matrix=np.eye(3), # work in node variables, rather than automatically choosing variables
system_hierarchy=[[1], [2], [3]], # hierarchical diagonalization, treat each node var as a subsystem
subsystem_trunc_dims=[7, 7, 7]) # diagonalize and truncate each subsystem to 7 dimensions before diagonalizing joint system
for i in [1, 2, 3]:
setattr(tcap_tmons, f'Φ{i}', 0.3) # Set both qubits at flux 0.3
setattr(tcap_tmons, f'cutoff_n_{i}', 50) # To diagonalize each subsystem, go up to |n|=50, rather than the default |n|=5
flux_array = np.linspace(0.0, .4, 201)
# flux_array = np.linspace(0.35, .37, 201) # Zoom in on the off point
fig, ax = tcap_tmons.plot_evals_vs_paramvals('Φ2', flux_array, evals_count=7, subtract_ground=True)
ax.set_title('Spectrum vs. coupler flux')
spec = tcap_tmons.get_spectrum_vs_paramvals('Φ2', flux_array, evals_count=3, subtract_ground=True)
gap = spec.energy_table[:, 2] - spec.energy_table[:, 1]
print(f'Minimum coupling [GHz]: {np.min(gap)/2=}')
plt.figure(figsize=(10, 8))
plt.plot(flux_array, gap / 2)
plt.xlabel('$\Phi$2 ($\Phi_0$)', fontsize=24)
plt.ylabel('Coupling (GHz)', fontsize=24)
plt.yscale('log')
plt.tick_params(labelsize=20)
plt.title('Coupling vs. coupler flux')
plt.tight_layout()
plt.show()
```