Support fluxonium in emulator

[Wangwei-Lan]

Hi, to whom it may be concerned, I am actually very interested in the qibo library developed by your team. However, I don't have any access to a real QPU platform, nor did I found a virtual QPU that is supported by qibo. So I was wondering are the platforms here available to general public? Thanks very much.

Yours sincerely Wangwei

[alecandido]

Hi @Wangwei-Lan, thanks for your interest.

Actually, the platforms are open only in the sense that the software involved is fully available. But the corresponding hardware is just the one used in the lab in the repo name (as in the case of https://github.com/qiboteam/qibolab_platforms_nqch/).

We used to have a virtual QPU (an emulator), but we recently had a major version upgrade of Qibolab, and we temporarily dropped compatibility with some of the platforms supported.

Right now, there is an ongoing effort for a new virtual QPU driver, which right now is only supporting a single transmon (possibly, with multiple levels) coupled to a drive line. You can find a couple of example platforms in https://github.com/qiboteam/qibocal/tree/main/platforms

As soon as we will roll out further support for the emulator, we will try to provide public platforms for using it.

[Wangwei-Lan]

@alecandido Thanks for your detailed reply. Great to hear that there is a virtual QPU option. So since it is an open source package, it is possible to write my own virtual QPU to be compatible with qibo, right? Since I am most working on fluxonium, a single transmon is definitely not enough for me. Do you have any hint on how to write my own QPU on top of qibo? Thanks in advance.

[alecandido]

Hi @Wangwei-Lan, thanks for getting back!

Yes, Qibo is definitely open-source, and contributions are more than welcome. For the time being, we do not have yet a completely flexible and pluggable structure specific to the virtual QPU itself, but I can illustrate you a bit which the overall landscape.

• Qibo (the qibo package) mainly covers the main language at a circuit level, defining the gates, main algorithms, and the execution backend structure (which itself is pluggable, and we already have backends of different kinds spread over multiple packages)
• Qibolab (the qibolab package) handles the hardware backends (exposing a Qibo-compatible QibolabBackend), and it defines the language at pulse level (mainly superconducting oriented), which serve as the interface between the instrument drivers (handling the actual execution) and Qibocal (the qibocal package) defining the calibration and characterization experiments
• the virtual QPU (called emulator within Qibolab) is one of the possible drivers to execute circuits - for the time being, that's built-in in Qibolab

The virtual QPU itself is mainly composed by two parts:

• the Hamiltonian definition, which is at a very basic level https://github.com/qiboteam/qibolab/blob/main/src/qibolab/_core/instruments/emulator/hamiltonians.py
• the execution, which takes pulse sequences (and possibly sweepers) and couples them to the system through the Hamiltonian-defined coupling (in the former module), using the resulting time-dependent Hamiltonian to run a QuTiP-powered evolution, and post-processing the results to adapt them to the general Qibolab layout https://github.com/qiboteam/qibolab/blob/main/src/qibolab/_core/instruments/emulator/emulator.py

Right now, there is no easy way to switch Hamiltonian, other than jumping in the qibolab source, and adapting to your model. In any case, even the current Hamiltonian can be configured (e.g. to implement transmon qudits) through the general Qibolab platform's configuration, as it is done in the platforms pointed above.

So, what we would need to expose a fluxonium virtual QPU would be:

1. some more code to provide the fluxonium building blocks (Hamiltonians for free evolution, and lines' couplings)
2. a mechanism to expose them through configurations, and switch between transmon and fluxonium (or other types of qubits)

Concerning point 1., the scqubit could also be helpful, since it may provide them out of the box (but we may need to adapt them to the Qibolab structure). Instead, point 2. is just a refinement for stabilization: if you'd like to try to contribute (or even write for yourself in the first place), you may just try to replace the existing transmon Hamiltonians terms with the fluxonium ones. Then, you may get back when you're more or less satisfied of the result, and we may lay out together the suitable integration of the two platforms.

I wished Qibolab were already more modular and easier to integrate, but we're trying to handle many things at the same time (in Qibolab, but also in the broader Qibo as well), so we're constantly evolving. Any help is warmly welcomed :)

[alecandido]

@Wangwei-Lan, given the present scope of the issue, I moved it to the Qibolab repo (where any development would be expected to happen), and adjusted its title.

Let me know if you disagree with any of the changes.

[Wangwei-Lan]

@alecandido Thanks again for your very detailed instructions and that's very helpful. Please feel free to make any modifications of the original post to be in line with your development better.