Qutrit (Qudit) simulation using Qibo

[igres26]

As Qibo evolves we should start considering taking its quantum simulations to the next level. And to d-level quantum bits after that.

Qudit manipulation will allow Qibo users to create different kind of algorithms that could then be deployed on quantum hardware as experimental implementations of quantum computers usually allow for control of more than two states. It also has value from a quantum information perspective even before experimental implementation.

I would start with an initial Qutrit implementation and possibly build a generalization from there.

[alecandido]

I would bump this issue, and reconsider our backends in this light.

This is also related to qibo-core, but the support in there will be minimal: we just need to

• support the declaration of the possible number of states for each element, in order to make the backend aware, and propagate the information
• extend the gates' addition, in order to specify not only the elements, but even the states

The rest is truly up to the backends (instantiate a suitable initial_state, execute the gates).

I would not even start from qutrits, since I believe that anything specific to qutrits will have to be undone for the generic qudits.
Instead, I would propose the following interface:

• circuit creation:

  Circuit([2] * 4 + [3] * 2 + [2] * 2)

  a circuit on 8 elements, of which elements 4 and 5 are qutrits, the rest qubits
• gates addition:

  c.add(X, [4], [0, 2])
  c.add(CNOT, [3, 4], [None, [1, 2]])  # None = [0, 1]

  specifying not only the elements, but also the states it should act on

The qubits gates on a restricted number of states should be interpreted as the original matrices on the subspace of states specified, and extended with an identity on the other states (i.e. they isolate the relevant elements from the tensor product basis as for qubits, ignoring the state of all the others, and in the subspace of the relevant elements they act as described above: the known matrix, extended with identity bits as needed).

This should be possible to be efficiently implemented in the backends through careful slicing (or appropriately taking the states into account in the loops, when explicit).

Then, we could explicitly add qutrit gates (acting on the all the three states at the same time in a non-trivial way) and so on, for which the interface would be a simple extension of the former:

c.add(SINGLE_QUTRIT, [3], [0, 2, 3])
c.add(BOTH_QUTRITS, [6, 7], [None, [0, 1, 3]])  # if a qutrit gate, None = [0, 1, 2]

But I'm not sure whether they are needed at all. @igres26?

[igres26]

This proposal looks solid. I had in mind something simpler, having only elements of dimension d, not a mix of those, but that can open new possibilities.

Having qudit gates will then be necessary, as most people using them will most likely be interested in applying qudit gates. However, I like this idea of applying 2-qubit gates on particular pairs of states within the larger qudit. Might also be very useful.

If adding d-level quantum systems does not require a big change in the qibo-core background, we should do it.

[alecandido]

Having qudit gates will then be necessary, as most people using them will most likely be interested in applying qudit gates.

No problem for qudit-specific gates, they will just need their own names, and will be added to the overall enumeration of possible gates.

If adding d-level quantum systems does not require a big change in the qibo-core background, we should do it.

qibo-core is already using the element nomenclature internally, instead of qubit (at the price of being a bit less familiar), in order to avoid specification of any given structure for the local subsystems. In principle, we would not have any problem even with continuous subsystems.

However, this makes even clearer one point: for qibo-core won't be a big-deal, simply because qibo-core will contain no backend at all.
The major complications in simulation will be handled by the individual backends, e.g. the NumpyBackend.

Nevertheless, my guess is that there should be a suitable way to exploit matrix slicing and implement a generic qudit simulator. At least in the case of NumPy-like operations.
Possibly, this will come at the expense of more limited performances compare to the pure-qubits backends, since we'll be able to make fewer assumptions.

I had this in mind while designing qibo-core, even because the Qibocal team is working on the qutrits calibration, and the might be interested in a suitable simulator. @Edoardo-Pedicillo
At the moment, there is no dedicated person power, so I'm just making an effort such that the current projects will facilitate this implementation in the future.
This is also the motivation of the https://github.com/qiboteam/qibo/issues?q=label%3Anice-project, under which I'm trying to collect possible interesting and (more or less) self-contained projects for further contributors.