QCHackers/tqec

Integrate `tqec` with `LaSsynth`

Opened this issue · 3 comments

inmzhang commented

Is your feature request related to a problem? Please describe.

What is LaSsynth?

LaSsynth is a synthesis for lattice surgery subroutines. After specifying the desired inputs/outputs ports and the stabilizer flows, it will use a SAT solver to solve the internal structure of the lattice surgery construction under limited spacetime volume. You can take a look at this demo to learn more about it.

Why is it useful for tqec?

  1. LaSsynth provides a way to automatically construct a valid spacetime model but can not run simulations for it. Then it's natural to take the output of LaSsynth as the input of tqec to run and verify the construction at the circuit level.
  2. LaSsynth provides a text format representation(LaSre) of the spacetime model and it can be taken as a starting point for the design of a portable text format of tqec computation structure.
  3. LaSsynth provides the functionality to convert a LaSre file to a .gltf model and visualized the model as well as the correlation surfaces.
  4. LaSsynth provides the functionality to convert a LaSre file to the corresponding zx diagrams(using stimzx) representation and verify the the stabilizer flows.

How it can be used with tqec?

LaSsynth provides a representation of the Lattice Surgery subroutine in a text format called LaSre.

LaSre of CNOT 图片

It can be seen as a complete description of the structure of a 3D spacetime model or our BlockGraph. To be more specific:

  • n_i/j/ks specify the the spacetime volume
  • n_p/ports/port_cubes specify the number and positions of inputs/outputs of the subroutine. And these ports can corresponds to the virtual cubes in the BlockGraph.
  • n_s/stabs specifies the stabilizer flow generators. The concept of the stabilizer flow translates naturally to the correlation surface in the lattice surgery model. And it relates to the existing correlation subgraphs in BlockGraph.
  • ExistI/J/K specifies the positions of block structures including the cubes and pipes.
  • ColorI/J specifies the type of the block structures.
  • CorrIJ... specifies the explicit correlation surfaces presented in each pipe for each stabilizer flows.
  • NodeY specifies the existence of the Y basis initialization/measurements, which currently is not implemented in tqec but is planned for sure.

As above, the one-to-one translation between LaSre and BlockGraph should be possible.

Limitations

To integrate the two libraries, there are some problems that we need to solve in my mind:

  • Spatial Hadamard in LaSynth is not allowed by default, but can be enabled with some changes to the code.
  • Y cubes need to be implemented in tqec, or turn off the option for now.
  • If we want to use LaSre to represent the BlockGraph, we need to be able to fill the ports with actual cubes, which corresponds to logical initialization/measurements that instantiate a subroutine into a real computation.
nelimee commented

I agree that this would be a very sensible and interesting addition. It might be too soon though. In my opinion, here are the steps we should focus on right now:

  1. Have a fully working logical CNOT computation. This has been our main goal since the beginning, we are very close now, so we should prioritize as much as possible that goal.
  2. Clean up the code, removing/simplifying/refactoring everything to have a clean code base that can still output a fully functional CNOT. This includes (non-exhaustive):
    • Template refactoring,
    • A huge documentation and testing improvement,
    • Removing now useless code,
  3. Implement new features with the stabilized and cleaned-up code base.

I think this feature is 1) not needed for the completion of our first goal and 2) can wait until we finished cleaning up the codebase. An argument for implementing that now (instead of waiting) is that this feature is, at its core, "just" a translator from LaSre to BlockGraph, which only requires the API to create a BlockGraph instance (i.e., a small portion of the API) and so might not be impacted too much by a refactor.
Any opinion?

  • 👍1
inmzhang commented

Yes this should not be a goal for the near term and I should note that in the first place. I had conversation with Austin about LaSsynth some times ago but forgot to write it up as an issue... And I do think it won't take too much work to implement this feature after finalizing and refactoring our library.

  • 👍1
afowler commented