[Feature, DA] Compile certain digital rotations directly in the emulated analog interface

[jpmoutinho]

Current emulated analog interface works with specific AnalogBlocks which are converted to HamEvo in the PyQ backend with the background interaction, or respective pulses in the Pulser backend. This can probably be done in a more general way by directly compiling blocks composed of digital rotations like kron(RX(i, angle) for i in range(n_qubits)). The advantages would be:

• No more issues with the global qubit support, which would just be the qubit support of the block.
• Open the way to compiling other single-qubit gates like X and add the background interaction, needed for bDAQC (https://github.com/pasqal-io/qadence/issues/154).

[nmheim]

While I'd like to get rid of the global qubit support as well, my understanding is that with our digital-analog approach we want to combine analog and digital gates, because they represent two fundamentally different modes of operation (essentially interaction on/off), so that a layer of RX rotations is something different than an AnalogRX block with the same qubit support. so we would still need some way of letting the user specify what kind of interaction they want. (Happy to be corrected though!:)

[jpmoutinho]

Thanks @nmheim! Sorry we discussed this a while ago and then I had a follow-up discussion with @madagra and then I never discussed it again with you. Indeed I think you are right about the modes of operation. What we are going for here would be a more general way to do it. Essentially the user would define whether their device operates according to either:

• step-wise DAQC (sDAQC) -- which allows single-qubit rotations without background interaction.
• banged DAQC (bDAQC) -- which compiles single-qubit rotations into an Hamiltonian with a global background interaction. This choice would be made, e.g., in the Device class, and then a parser would transpile the circuit to identify blocks of the type kron(single_qubit_op(i) for i in some range of qubits) and transpile those, compiling the operations into the corresponding drive Hamiltonian, and adding or not the interaction term depending on the mode of operation of the device. Note that the real devices can in theory also do sDAQC (aka "digital") with the Raman channels.

In principle, this change would be able to represent the current Analog blocks, but also extend a bit the capabilities in terms of other usecases:

• Transpiling stuff like kron(RX(i, theta_i), RY(j, theta_j), RZ(z, theta_z)), which represents full local addressibility, which maybe it will be useful to have it there for the future.
• Transpiling other gates like X, needed for certain algorithms.

[nmheim]

Ok, that sounds nice! And like a lot of cool work on transpilation. maybe we can drop python 3.9 support and use https://benhoyt.com/writings/python-pattern-matching/ @madagra ?

nvm, python can't pattern match as nice as I thought.

[Roland-djee]

@jpmoutinho Is this getting picked up ?

[jpmoutinho]

Not immediately, but yes I have this on my radar. I do think it will need to be done, but still unsure how.

[Roland-djee]

Not immediately, but yes I have this on my radar. I do think it will need to be done, but still unsure how.

OK I think we can pick that one up once we get seriously started on the compilation initiative.

[Roland-djee]

@kaosmicadei