search

QCHackers / tqec

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

Finalize TQEC REST API #38

Open nelimee opened 6 months ago

nelimee commented 6 months ago

Currently, both the frontend (javascript UI / code) and the backend (Python code) are separate pieces of code that do not interact with each other.

The currently envisioned process to create a QEC experiment is the following:

  1. The user starts the frontend.
  2. The user builds the experiment he/she wants to perform, still 100% in the frontend.
  3. Once the experiment is fully caracterised in the frontend, the user asks for the Stim file generation (or multiple Stim files).
  4. [internally] the frontend represents the QEC experiment in a JSON format.
  5. [internally] the frontend sends the generated JSON to the backend (Python code).
  6. [internally] the backend generates a Stim file from the input JSON.
  7. [internally] the backend sends back the generated Stim file to the frontend.
  8. The frontend provides a way to download / export the generated Stim file.

The above process is still in discussion. It has shortcomings, but also has the good property of being really simple to implement on both sides (frontend and backend).

The current communication scheme using JSON, both the frontend and backend need to agree on the JSON format. A tentative format can be found in the specification/schemas folder. We would like to improve this format and actually implement the serialisation / deserialisation procedures in both the frontend and the backend.

afowler commented 5 months ago

Another aspect that should be discussed, in my opinion, is exactly where the simulations generating graphs of logical error rate versus physical error rate will be run. On the user's machine? In some cloud service? As our examples get bigger, a scalable cloud service would definitely be desirable, but on this point I'm not sure what options are available, in particular for free, and just how much compute power is available.

On Wed, Jan 10, 2024 at 2:36 AM Adrien Suau @.***> wrote:

Currently, both the frontend (javascript UI / code) and the backend (Python code) are separate pieces of code that do not interact with each other.

The currently envisioned process to create a QEC experiment is the following:

  1. The user starts the frontend.
  2. The user builds the experiment he/she wants to perform, still 100% in the frontend.
  3. Once the experiment is fully caracterised in the frontend, the user asks for the Stim file generation (or multiple Stim files).
  4. [internally] the frontend represents the QEC experiment in a JSON format.
  5. [internally] the frontend sends the generated JSON to the backend (Python code).
  6. [internally] the backend generates a Stim file from the input JSON.
  7. [internally] the backend sends back the generated Stim file to the frontend.
  8. The frontend provides a way to download / export the generated Stim file.

The above process is still in discussion. It has shortcomings, but also has the good property of being really simple to implement on both sides (frontend and backend).

The current communication scheme using JSON, both the frontend and backend need to agree on the JSON format. A tentative format can be found in the specification/schemas https://github.com/QCHackers/tqec/tree/main/specification/schemas folder. We would like to improve this format and actually implement the serialisation / deserialisation procedures in both the frontend and the backend.

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

vtomole commented 5 months ago

@afowler The package can be installed and run anywhere. The user can decide if they want to run the simulations on their machine or a cloud service. We can put the Python code on a Flask server and have the UI communicate with the server over the wire.

a scalable cloud service would definitely be desirable, but on this point I'm not sure what options are available, in particular for free

This package should work on any cloud service as long as the user can get their hands on some free cloud credits or fork some cash.

vtomole commented 5 months ago

Few options when it comes to credits:

https://cloud.google.com/free https://aws.amazon.com/free/offers/ https://azure.microsoft.com/en-us/free

rryoung98 commented 5 months ago

I'd also like to pitch that qBraid may be interested in being more involved in hosting this as well. We have most of the necessary infrastructure and deploying such applications is part of my technical capabilities.

vtomole commented 5 months ago

+1 for @rryoung98's suggestion :fireworks:

rryoung98 commented 5 months ago

As this matures, I will make sure that qbraid will be a nice home (if we settle on that). In the mean time, the frontend and backend connection, assuming we're okay with the JSON, will need to be REST API requests to and from the python tqec api and the frontend. This is a method of communication that is very common and shouldn't be hard to implement.

Out of the JSONs @nelimee I think QASM could be a good way of moving between the frontend and backend.

  1. It works well with json/application and sending to the python api.
  2. It is a very common way to get circuit information to and from a frontend and server for most major hardware providers.
  3. Compatible with your cirq implementation.

QIR, could also be an optional as well but im not sure if we need all the auxiliary overhead that comes with the LLVM architecture... thoughts?

6,7,8 are trivial. We can just make a folder that's called stims or something and drop the files there as well as the JSON information associated and created from the frontend then use standard methods of accessing filesystems from the frontend.

  1. [internally] the backend generates a Stim file from the input JSON.
  2. [internally] the backend sends back the generated Stim file to the frontend.
  3. The frontend provides a way to download / export the generated Stim file.

These are just ideas suggestions are very welcome.

rryoung98 commented 5 months ago
  1. [internally] the frontend represents the QEC experiment in a JSON format.
  2. [internally] the frontend sends the generated JSON to the backend (Python code).

How far are the above 4 and 5 right now? @nelimee I couldn't find any references in the current code. From our end 3. is unimplemented, but we should be able to work in parallel with UI functionality improvements if we want to push ourselves to get this done end of Jan (haha).

  1. Once the experiment is fully caracterised in the frontend, the user asks for the Stim file generation (or multiple Stim files).
nelimee commented 5 months ago

@afowler about the server, I was thinking about a fully local implementation at the beginning. In later stages, having the possibility to install the backend (or run the generated stim files) on a different server might be a necessity, but I think this is something that should be primarily the user responsibility (as seems to say @vtomole). Basically, if you (as a user) want to run large circuits, you have to provide your own compute power.

@rryoung98 OpenQASM (2.0 I guess?) is fine on my side. I have no strong feeling about that part, anything that fits the needs (easy to generate on the frontend, easy to parse on the backend and able to represent everything that we need) is fine for me. My thoughts about QIR is that this is way too much overkill for our needs, both in terms of representation capabilities, abstraction implemented and tooling required.

@rryoung98 4 is on the frontend side, but 5 is not implemented at all. Basically, I wanted to be sure about the JSON format and what we needed in it before implementing anything. The backend is quite flexible, and I can adapt myself or afford to perform some reasonable computations if the JSON input does not match exactly with what the backend needs. If you are not really limited on your side either, I can finish the description in terms of JSON schema I started in the repository, wait for your validation, and implement that in the backend. Implementing this step should be relatively easy, so I am not too worried about that part.

smburdick commented 5 months ago

Self-assigning based on discussion in the Google Group.

smburdick commented 5 months ago

Merged #40 to establish communication and live servers/endpoints

We still need to implement templates for the frontend; right now, only qubits and plaquettes are represented.

smburdick commented 5 months ago

I think this should be spun off into more specific issues on the frontend/backend sides, as well as defining the serialization templates

nelimee commented 5 months ago

Do you know how to split that issue? In my opinion, we can keep that one open as a placeholder until we start implementing the communication part and actual issues arise.

smburdick commented 5 months ago

Do you know how to split that issue? In my opinion, we can keep that one open as a placeholder until we start implementing the communication part and actual issues arise.

@nelimee I haven't given it a ton of thought lately. The frontend/backend developments have diverged somewhat over the past couple weeks, and I think once we can support building quantum circuits on the frontend (eg, #46), we can finalize this issue, since we'll actually have circuit data to send to the backend.

smburdick commented 3 months ago

Marking this as task 7.5 in the task flow, and adding to the next milestone