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

Save tile set as Stim file #18

Open smburdick opened 8 months ago

smburdick commented 8 months ago

https://github.com/quantumlib/Stim/blob/main/doc/file_format_stim_circuit.md

nelimee commented 8 months ago

Note that this format is what is generated by the Python code. Why would you need that in the UI?

smburdick commented 8 months ago

Do we want to be able to save the circuit that the user created on the frontend to a file? If so, we can add a button on the frontend, which could invoke a function on the backend (passing the current circuit as a parameter), and return a stim file to the browser.

nelimee commented 8 months ago

Yes I agree, but this scheme does not require the UI part to know about the structure of a Stim file, only to know that it is a textual file. Am I missing something?

smburdick commented 8 months ago

Right, the UI can be totally agnostic of the file structure, it would just have to invoke the Python backend to get the file back

smburdick commented 8 months ago

I'm pretty sure this is Task 11.

nelimee commented 8 months ago

I am still having hard times understanding what this issue is about. The title is about "tile set", but it seems to me that you are rather referring to the final Stim files.

Also, having a Stim file does not equate task 11. For task 11, we still have to simulate the different Stim files and perform the graph. This is made easy by the sinter package, but it is more than simply "getting the Stim files".

smburdick commented 8 months ago

My terminology may be off here. By "tile set", I mean the set of plaquettes the user has made in the frontend. My impression is that these plaquettes and qubits (as well as templates, which we don't have in the UI yet) will need to be communicated to the backend, which will perform some work on the input to generate a circuit or other object that is meaningful to the user, and return that to them.

My most recent pull requests #40 and #41 establish this communication in an early stage -- crucially, the real processing on the backend is missing, (the input is returned as the output by the backend, as a placeholder) as we appear to need templates as well to construct a circuit.

nelimee commented 8 months ago

As a note, I tried to provide a first version of what the backend would need as input to do its job. This can be found here (and I will modify it in the next few days).

smburdick commented 8 months ago

@nelimee Awesome! Thank you for making those specifications. Once #43 is finalized, I will update the serialization in #41

smburdick commented 8 months ago

Updated #41 to incorporate the current specs

smburdick commented 6 months ago

This is being addressed in #192