circuit builder mvp

[rryoung98]

To add the quantum circuits associated with the plaquettes, a circuit visualizer is necessary.

The circuit visualizer should show up after the user clicks on the create plaquette button. Once the user clicks on the create plaquette button the MVP will include a drag or upload QASM file functionality.

Eventually a user should be able to drag and include various gates similar to Quirk. As a suggestion the beta could include Pauli, CNOT, H so that a user can make stabilizer codes efficiently.

[nelimee]

A quick note about that: if the user is allowed to drag & drop any OpenQASM file, it should be trivially "schedulable". By that I mean that it should be clear for all gates (quantum gate + reset + measurement) at which schedule they should be assigned to. We can, by convention, use a left-align, but this will be wrong for most of the interesting stuffs and leave a lot of flexibility. I would, for the moment, require the user to explicitly schedule the gates in the circuit by following the convention below:

1. the quantum circuit can optionally start by a barrier instruction,
2. each new barrier instruction (i.e., each one except the optional very first one) defines a new "Moment" (in the cirq sense),
3. all the gates between 2 barriers should be executable in parallel,
4. two consecutive barrier instructions simply means that there is an empty schedule (or "Moment").

What do you think about that?

[afowler]

+1 for explicit scheduling.

On Wed, Jan 17, 2024, 12:19 AM Adrien Suau @.***> wrote:

A quick note about that: if the user is allowed to drag & drop any OpenQASM file, it should be trivially "schedulable". By that I mean that it should be clear for all gates (quantum gate + reset + measurement) at which schedule they should be assigned to. We can, by convention, use a left-align, but this will be wrong for most of the interesting stuffs and leave a lot of flexibility. I would, for the moment, require the user to explicitly schedule the gates in the circuit by following the convention below:

1. the quantum circuit can optionally start by a barrier instruction,
2. each new barrier instruction (i.e., each one except the optional very first one) defines a new "Moment" (in the cirq sense),
3. all the gates between 2 barriers should be executable in parallel,
4. two consecutive barrier instructions simply means that there is an empty schedule (or "Moment").

What do you think about that?

— Reply to this email directly, view it on GitHub https://github.com/QCHackers/tqec/issues/46#issuecomment-1895306749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKAXTEKSA3YLSDZQX5VDYDYO6CPPAVCNFSM6AAAAABB6CQZTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGMYDMNZUHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Gistbatch]

I was interested in doing #22 but I'm unsure how to start this. Use some existing framework? I built a "prototype" back in December with pixie which already had some of the functionality we would need.

[smburdick]

Those of us in the email thread I started around #119 saw Gian's initial implementation of this (if I'm not mistaken)

[giangiac]

I will create a PR with the relevant code.

The plaquette defined via the current frontend lacks some info present in the step-by-step frontend. Specifically, the selected qubits are not marked as data (either X or Z) or ancilla qubits. I will add that part too.

[rryoung98]

Please add me as a reviewer! Thanks @giangiac 😄

[giangiac]

Please add me as a reviewer! Thanks @giangiac 😄

Actually I was too optimistic :-( There is a level of complexity in this frontend that does not allow me to simply port my approach. Specifically, in the step-by-step frontend I just add "on click" action to the qubit so that by clicking them their "role" changes (none, x, z, a). Then to find the selected qubits I just loop through all the qubits in the workplace and check their role.

Here it is used the Qubit.checkHitAreat and Qubit.deselect both in the definition of the template and of the plaquette. Not sure how to adapt my approach to this design.

[smburdick]

Actually I was too optimistic :-( There is a level of complexity in this frontend that does not allow me to simply port my approach.

One of the key goals in #132 is to simplify the core structure of the frontend that will make it easier for us to add and modify UI components. I will work on adding the Redux store, and we can discuss it in the group meeting as well.

Here it is used the Qubit.checkHitAreat and Qubit.deselect both in the definition of the template and of the plaquette. Not sure how to adapt my approach to this design.

Those definitions (alongside many others) can be defined by a workflow in the Redux store

[smburdick]

I think this can be merged alongside #74 once Gian's work on this is merged

[nelimee]

This issue is not relevant anymore. Closing it. See #323 for more details.