Get rid of "flux" tuples and find good way to deal with flux based hardware constraints

[AdriaanRol]

Flux tuples/edges were introduced in the CCLight config as a target of an operation. We have found that in experiment this is a very inconvenient (bad) way of specifying the target of a flux pulse. Furthermore, this is not a fundamental constraint of the underlying hardware (both CCLight and Transmon device).

There are three main types of flux pulses (sorted by # target qubits)

• Phase pulses/single qubit flux pulses
• Two qubit flux pulses (such as the CZ)
• Three qubit flux pules such as those performing a CZ on two qubits and moving another qubit out of the way.

The first step is to get rid of the current (artificial) constraint, which requires any flux based operation to target an edge (and having two qubits as target). The second step would be to find a proper way of describing the intricacies of these constraints and how to best express this both in the configuration files and when writing a program.

This subject requires a lot of discussion, and as such should be postponed until after #160 .

[wvlothuizen]

The backend for the CC (see PR #202) can now do 1/2/3 qubit flux pulses.

Currently, this backend uses the CC-light resource constraint scheduler (cc_light_schedule_rc()), which is mostly fine because there seems to be little dependency on the CC-light platform.

However, there seems to be no way to properly schedule 1 or 3 qubit flux gates, and e.g. do the flux dance.

Is any work going on on this subject

[jvansomeren]

Hi Wouter,

When discussing 1 and 3 qubit flux gates with Xiang, he told me these are all based on a misunderstanding. It was also after I explained that when there are 3 qubit flux gates, there should also be 4 qubit flux gates. Anyhow, around the same time, the resource constraint manager and scheduler were revised by me to deal with the constraints related to detuning qubits on flux operations, which are now part of the master branch.

So the next thing to do is to have all facts on the table, from the needs that led to the idea to have 1 and 3 qubit gates (and 4 …) and the constraints related to detuning, their description in the json file and their support.

Currently I am working on Resource constrained scheduling misses opportunities for parallel executionhttps://github.com/QE-Lab/OpenQL/issues/179 (issue 179).

Best,

Hans

Op 5 dec. 2018, om 13:55 heeft Wouter Vlothuizen notifications@github.com<mailto:notifications@github.com> het volgende geschreven:

The backend for the CC (see PR #202https://github.com/QE-Lab/OpenQL/pull/202) can now do 1/2/3 qubit flux pulses.

Currently, this backend uses the CC-light resource constraint scheduler (cc_light_schedule_rc()), which is mostly fine because there seems to be little dependency on the CC-light platform.

However, there seems to be no way to properly schedule 1 or 3 qubit flux gates, and e.g. do the flux dance.

Is any work going on on this subject

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/QE-Lab/OpenQL/issues/176#issuecomment-444475439, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQcwto1LQyiWRVWmGKCjo-uT6O4YWs4sks5u18JDgaJpZM4WzsAs.

[wvlothuizen]

Hi Hans,

I think I found a description of the detuned_qubits constraint in #175.

I can see how that can take care of the scheduling (i.e. not perform other operations on the detuned qubits), but cannot see how the actual detuning can be performed without having either a single qubit flux gate for the detuning, or a 3 qubit flux gate that includes the detuning, especially for the CC which needs an explicit gate to perform the detuning (there is no implicit knowledge about the gates).

[jvansomeren]

Hi Wouter,

When you want, Adriaan, you and me could have a meeting to flesh this out.

What I have in mind is that a 2 qubit flux gate gets expanded to those gates (fluxing the individual 5 qubits in a single cycle), somewhere in the chain after scheduling, so either in the compiler back-end generating QISA instructions, or in the assembler, or in a microcode expansion unit during execution time.

This expansion can be done after scheduling without much intelligence because the scheduler is ignorant about the implementation method of 2 qubit flux gates (one of the 3 methods above) but knows which (at most 5) qubits are involved and blocks use of them by another operation. So it has made 'room' for the expansion.

How the expansion is done, can be implemented by look-up tables generated from the topology (nearest neighbors) and the frequency domain (high, middle or low) of the individual qubits: a 2 qubit gate of which one of the qubits is in a high frequency domain will have as other operand a qubit in the middle frequency domain; all the other (at most 3) neighbouring middle frequency domain qubits have to be detuned; a 2 qubit gate of which one of the qubits is in the low frequency domain, only requires lowering the frequency of its other operand qubit.

But again, a meeting may be more efficient than elaborating all this by mail.

Best,

Hans

On 12/07/2018 06:27 PM, Wouter Vlothuizen wrote:

Hi Hans,

I think I found a description of the detuned_qubits constraint in #175 https://github.com/QE-Lab/OpenQL/issues/175.

I can see how that can take care of the scheduling (i.e. not perform other operations on the detuned qubits), but cannot see how the actual detuning can be performed without having either a single qubit flux gate for the detuning, or a 3 qubit flux gate that includes the detuning, especially for the CC which needs an explicit gate to perform the detuning (there is no implicit knowledge about the gates).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/QE-Lab/OpenQL/issues/176#issuecomment-445304914, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcwtjBTrZp-ZElFKywEEmmKGTvdONA5ks5u2qTogaJpZM4WzsAs.

[imranashraf]

addressed in https://github.com/QE-Lab/OpenQL/issues/224. so closing.