search

QCHackers / tqec

Design automation software tools for Topological Quantum Error Correction
https://tqec.app
Apache License 2.0
59 stars 17 forks source link

Multi-tab frontend and plaquette library #168

Open giangiac opened 6 months ago

giangiac commented 6 months ago

Design a solution to add "tabs" to the frontend app.

The idea is that different tabs can be specialized to perform the TQEC tasks (see resources on Google's team) sequentially. In case of the frontend this could be:

This feature concerns ONLY the reorganization of the HTML / JS code to allow for multiple tabs. The content of each tab will be developed separately.

smburdick commented 6 months ago

@giangiac Just saw the discussion recording from yesterday. If you need any help merging the circuit editor/tutorial into the codebase, I'm happy to help.

giangiac commented 6 months ago

@smburdick Your help would be great! I tried to add "listeners" so that when the "tab1" and "tab2" buttons are clicked the corresponding content appears/disappears... but I was not able to make it work :-(

smburdick commented 6 months ago

TAB2: access the plaquette library and allow "drag and drop" of the plaquette on a large qubit array

I personally think the plaquette library should be a drop-down on a single workspace, not a separate tab.

possibility of representing the plaquette via a geometric form (square, triangle, semicircle, ...) or simply as an integer (its index from the library)

This can be specified on the plaquette menu.

giangiac commented 6 months ago

I believe there are two separate functionalities that we should implement the solutions "independently".

The first one is the definition of a plaquette in terms of the physical qubits involved and the physical operations on them. This is what the current frontend is doing: creating a library of such plaquettes.

The second one is stitching the plaquettes together, taking them from the library. The same type of plaquette can be used multiple times and the tools need to understand that the same physical qubits might be shared among plaquettes.

afowler commented 6 months ago

Also, when plaquettes are stitched together, there may be identical gates in neighboring plaquettes on identical qubits that should be interpreted as only occurring once.

On Fri, Mar 15, 2024, 8:17 AM giangiac @.***> wrote:

I believe there are two separate functionalities that we should implement the solutions "independently".

The first one is the definition of a plaquette in terms of the physical qubits involved and the physical operations on them. This is what the current frontend is doing: creating a library of such plaquettes.

The second one is stitching the plaquettes together, taking them from the library. The same type of plaquette can be used multiple times and the tools need to understand that the same physical qubits might be shared among plaquettes.

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

smburdick commented 6 months ago

I believe there are two separate functionalities that we should implement the solutions "independently".

The first one is the definition of a plaquette in terms of the physical qubits involved and the physical operations on them. This is what the current frontend is doing: creating a library of such plaquettes.

The frontend doesn't provide the ability to save plaquette/circuit designs to a library. It only allows creating them in the workspace and cloning them. The work for this is laid out in #189, and is part of the next milestone (the current one is being wrapped out rn)

The second one is stitching the plaquettes together, taking them from the library. The same type of plaquette can be used multiple times and the tools need to understand that the same physical qubits might be shared among plaquettes.

Also, when plaquettes are stitched together, there may be identical gates in neighboring plaquettes on identical qubits that should be interpreted as only occurring once.

Are we limited to stitching together plaquettes in the fashion of a standard surface code?

image

Either way, it would be nice for beginners to also provide the option to create a plain d=3,5 surface code, like you can in Crumble.

afowler commented 6 months ago

The initial goal is to have plaquette footprints that are rectangular, with the expectation that some of the qubits on the edges of that rectangle will be shared with neighboring plaquettes. This means we are not strictly limited to just the standard surface code.

On Fri, Mar 15, 2024 at 9:39 AM Sam Burdick @.***> wrote:

I believe there are two separate functionalities that we should implement the solutions "independently".

The first one is the definition of a plaquette in terms of the physical qubits involved and the physical operations on them. This is what the current frontend is doing: creating a library of such plaquettes.

The frontend doesn't provide the ability to save plaquette/circuit designs to a library. It only allows creating them in the workspace and cloning them. The work for this is laid out in #189 https://github.com/QCHackers/tqec/issues/189, and is part of the next milestone (the current one is being wrapped out rn)

The second one is stitching the plaquettes together, taking them from the library. The same type of plaquette can be used multiple times and the tools need to understand that the same physical qubits might be shared among plaquettes.

Also, when plaquettes are stitched together, there may be identical gates in neighboring plaquettes on identical qubits that should be interpreted as only occurring once.

Are we limited to stitching together plaquettes in the fashion of a standard surface code?

image.png (view on web) https://github.com/QCHackers/tqec/assets/16883876/0979dd75-8c7c-4022-bb06-ced4b008a00c

Either way, it would be nice for beginners to also provide the option to create a plain d=3,5 surface code, like you can in Crumble.

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

smburdick commented 6 months ago

From an implementation standpoint, we should keep the Plaquette class open to extension, by saving a qubit lattice as a planar graph with outgoing edges, which can serve as the "stitches" to other plaquetes.