Extending Blocks to include timing information of a quantum gate

[Yusheng Zhao]

Enhancement Idea

In #426, enhancement of Block on the account of revealing circuit depth is requested. On a related topic, it might be rewarding to also add the information of gate time into Block as well.

Motivation

On real machines, XGate and CXGate will have drastically different duration. Block representation ignores such difference. With Block representation, an XGate applied on qubit 1 and CXGate applied on qubit 2,3 will make it look like all three qubits experienced some sort of control for the same amount of time. But in fact, qubit 1 will remain idle for a long time.

Error mitigation techniques like Dynamical Decoupling requires inserting random gates on idle qubits. Blocks with timing information could help

1. Give better visualization which qubits are idle.
2. Make it easier to pack Blocks in a Tetris style. Then, insertion location of random gates could perhaps be found more easily.

In #253 there seems to be the inclination towards giving the user real quantum machine usage. Might as well make things more native towards hardware.

Concerns

Might be too much of a complication on the simple and elegant Block implementation. Not many folks would really need this feature for now. This is more like the pulse-level quantum circuit in Qiskit.

If you think this is a good enhancement, I would be glad to help with the implementation or the related issue #426.

[Xiu-zhe (Roger) Luo]

Hi thanks for the proposal, I like this idea actually, this is definitely a good enhancement!

I think it doesn't need to add this info globally tho, though a Timed block should suffice. The reasons are:

1. the duration information is not necessary for all users
2. the duration information is different for different hardware
3. and it highly depends on how pulse sequences are compiled (e.g when you find a good pulse, it will be shorter)

thus basically need something like the following

struct TimedBlock <: TagBlock
    content
    duration::Float64
end

this gonna require users to manually set a duration (which I think is good if you work on different hardware, and we can always provide some alias). Ideally, this information should be inferred from a lower-level IR (intermediate representation) but this is something we may address in the future with a better compiler pipeline.

It'd be nice if you could join our community call, and we can discuss it this Thursday, please email [e-mail] then I'll send you the calendar invite (since I'm not allowed to share the zoom link publicly)

---

In #253 there seems to be the inclination towards giving the user real quantum machine usage. Might as well make things more native towards hardware.

Might be too much of a complication on the simple and elegant Block implementation. Not many folks would really need this feature for now. This is more like the pulse-level quantum circuit in Qiskit.

There is real hardware support usable actually, and for simple cases (e.g via the IBMQClient package), it actually works pretty well, this is mainly because, at this stage, most of the quantum hardware is provided through cloud service via a REST API, and thus the way to operate the machine to generate a JSON schema and send it to the REST API. So on the client side, the compilation doesn't need to be too complicated at this level.

But considering the progress of hardware and compilation techniques, this is probably not true anymore, many machines can do lots of fast control flows, and more control on native pulses, and the requirement of compilation pipelines like error mitigation, and postprocessing is getting more complicated.

What is actually missing here, is general compilation support, and that was why I haven't been spending much time on integrating the current implementation with the machine, but instead thinking about how to refactor the pipeline. Tho we do support naive circuit transform based on Julia's multiple dispatch since the early days, an elegant and powerful solution is still not there yet.

But I think while we are still working on a new pipeline, it would be nice to have these new use cases included in YaoBlocks before that happens so we can learn more about different use cases.

[Jinguo Liu]

FYI, the next Yao community call is Thursday 12AM (today, midnight). It happens monthly.

[Yusheng Zhao]

@Roger-luo My apologies! I was not able to join the community call due to traveling and relocating. Thank you for the comprehensive response regarding my proposal! I also talked to @GiggleLiu about this issue after the community call happened. Seems like my concern was true. My proposal conflicts with the philosophy of Yao. So the next move should be done with more care. I think I will close this issue for now. Should time permit, I think more conversation on the compilation pipeline etc should be done before I do / propose anything.