Implement the following TQEC:

Needs at least #45 fixed.

Idea provided by Austin.

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

We should agree to a template as a group.

• Detailed description of the issue
• What priority the issue takes, if relevant
• What solution(s) submitter has already been considered or tested

Every non-recoverable errors due to wrong inputs in the tqec Python package are asserted using assert. Even though the assertion message is better than nothing, it would be clearer to raise errors with descriptive names and descriptions, that can potentially be catched by a power-user expecting such an error and knowing how to recover from it.

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.

Running npm start on main gives

@rryoung98 Since I am merging #41 with the latest changes this week, I will add this to my work, but feel free to jump in if desired.

The creating a plaquette functionality at the moment involves dragging the closest plaquette up down left and right.

However, this functionality creates a buggy experience where plaquettes will pop up when the (deltaX-initialposition) is large enough and the mouse was recently clicked but not pressed down.

We want to remove to improve this by perhaps using arrow keys or another method that is more definite.

In the initalizeClearButton() this.destroy() is called which is dangerous.

If the subchild plaquette does not have graphic associated with itself, there is a possibility that the clearing functionality will crash the app.

TypeError: this._geometry is null

The last step before the full "corner" is to be able to perform the following steps:

1. Initialize a logical qubit in the $\vert 0_L\rangle$ state.
2. Perform a few rounds of memory.
3. Move the logical qubit in the $Z$ direction (exactly #50).
4. Perform a few rounds of memory on the newly placed logical qubit.
5. Move the logical qubit in the $X$ direction (exactly #51).
6. Perform a few rounds of memory on the newly placed logical qubit.
7. Measure the observable.

Basically, a corner without the complexity of changing plaquette orientation midway and changing the orientation of the observables.

Idea provided by Austin.

When I rotate this plaquette, should it snap into place with the nearest 3 available qubits? Or do they remain part of the plaquette?

The tqec Python library is missing tests.

Currently, the only tests are functional ones, implemented in notebooks/ and only run locally.

This is the first issue about adding tests to the tqec Python package. The question that I want to discuss here is:

What package/framework should we use to test the tqec library?

Here is a list of features that I would like to have:

• easy to run in CI,
• well recognised in the Python ecosystem and well maintained,
• ability to filter out some tests (for example with a tagging system).

The last point would be nice to include for tests that need a lot of computing time / computing power to run. These could be filtered out in the CI but still included in the tests when run locally.

I am in favour of pytest, but I am also really open to any other suggestion that makes sense.

As discussed in #70, there can be some improvement ideas on the tqec.display.display_templates_svg function, which includes the following or more:

1. Display the relationships between templates (corner pinning).
2. Find a way to display the "scalable" property of the outer outer edges. For example, outer edges that will scale when scale_to is called are depicted as double-ended arrows whereas those that does not scale are depicted with inward-arrows.

This may also relate to issue #67.

The frontend should begin with building templates which are filled with plaquettes. The feature needs to determine an area where plaquettes will be made by the user as well as determine the top left most qubit as the 0 index for relative positioning.

From a code comment.

When I copy a plaquette by dragging, sometimes an extra plaquette appears, usually next to the new one, but sometimes on a different part of the tileset. Example video

Mentioned in #12.

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

• Specify user experiences
• Specify tabs/windows from the hand drawings of the UI
• Consider UI/UX builder libraries and tools

In the main branch, when I run npm start DISABLE_ESLINT_PLUGIN=true, and open the frontend in the browser, I cannot click on grid intersections to spawn new qubits as I did before.

@rryoung98 Since I'm continuing my work on the frontend, I will investigate.

@smburdick commented:

I would suggest writing a separate function for Moments

Originally posted by @smburdick in #55 (comment)

Ah, this is a recursive function! I still think separating them out makes this a little more comprehensible.

Originally posted by @smburdick in #55 (comment)

To make this a little more explicit, you could create a FlattenedCircuitOperation class that is the desired input type.

Originally posted by @smburdick in #55 (comment)

Again, I think using different functions instead of isinstance makes it less brittle and more comprehensible, but that may not be possible in this case if the function is already being invoked this way.

Originally posted by @smburdick in #55 (comment)

This issue tracks the different places that should eventually be refactored in the tqec library.

The tqec Python package currently works under the assumption that all the Plaquette instances provided when calling the generate_circuit function are of the same shape.

The shape of a Plaquette instance is currently defined as the coordinates of the lower-right-most qubit, each increased by one, which assumes that qubits are the closest possible to the origin (0, 0). This definition (and how we compute the shape, if we still need to compute it) have to change.

Lifting this assumption will likely require non-trivial changes, I am open to any suggestion.

After restarting the JupyterLab, this error can occur:

$ python -m jupyter lab
Traceback (most recent call last):
  File "/home/codespace/.local/bin/jupyter-lab", line 5, in <module>
    from jupyterlab.labapp import main
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyterlab/__init__.py", line 8, in <module>
    from .handlers.announcements import (
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyterlab/handlers/announcements.py", line 14, in <module>
    from jupyter_server.base.handlers import APIHandler
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyter_server/base/handlers.py", line 23, in <module>
    from jupyter_events import EventLogger
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyter_events/__init__.py", line 3, in <module>
    from .logger import EVENTS_METADATA_VERSION, EventLogger
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyter_events/logger.py", line 19, in <module>
    from .schema import SchemaType
  File "/home/codespace/.local/lib/python3.10/site-packages/jupyter_events/schema.py", line 9, in <module>
    from referencing import Registry
  File "/home/codespace/.local/lib/python3.10/site-packages/referencing/__init__.py", line 4, in <module>
    from referencing._core import Anchor, Registry, Resource, Specification
  File "/home/codespace/.local/lib/python3.10/site-packages/referencing/_core.py", line 89, in <module>
    class Specification(Generic[D]):
  File "/home/codespace/.local/lib/python3.10/site-packages/referencing/_core.py", line 115, in Specification
    ] = field(alias="anchors_in")
TypeError: field() got an unexpected keyword argument 'alias'

I am in the process of moving the python_prototype/tqec package into the main tqec folder, and so I also moved the dependencies to the requirements.txt and dev-requirements.txt files.

The issue is that installing the tqec package takes more than 5 minutes (I cancelled the installation after that) because pip is trying to find the correct versions for all the dependencies.
Removing useless dependencies seems to be the right way to go, so are these dependencies actually needed, or can I remove them?

• notebook in requirements.txt (in my opinion, this should at least move in dev-requirements.txt).
• general-superstaq[dev]~=0.3.23 in dev-requirements.txt.

The Python package installation only works in editable mode (python -m pip -e).

Installing from scratch the tqec package with:

# In an active and freshly created virtual environment.
cd tqec
python -m pip install .
python -m pip install jupyterlab sinter pymatching

and trying to run any of the notebooks by running

python -m jupyter lab

will output a module not found error at the first tqec import:

ModuleNotFoundError                       Traceback (most recent call last)
Cell In[1], line 7
      4 import stim
      5 from stimcirq import cirq_circuit_to_stim_circuit
----> 7 from tqec.constructions.qubit import ScalableQubitSquare
      8 from tqec.detectors.gate import ShiftCoordsGate
      9 from tqec.detectors.transformer import fill_in_global_record_indices

ModuleNotFoundError: No module named 'tqec.constructions'

When running the example in doubling_distance.ipynb, the template's scaling will not work correctly after scaled with k=2.

The result can be reproduced with the following code:

>>> display_template(doubling_template.scale_to(6))
 .  .  1  .  1  .  1  .  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  1  .  1  .  1  .  .
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
.  1  .  1  .  1  .  1  .  1  .  1  .  1  .  .
>>> doubling_template.scale_to(2)
>>> display_template(doubling_template.scale_to(6))
.  .  1  .  1  .  1  .  .  .  .  .  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .
1  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  .  .  .  .  .  .  .  .  .  .  .  .  .
.  1  1  1  1  1  1  1  .  .  .  .  .  1  .  1  .  1  .  .
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  .  .  .  .  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  .  .  .  .  1  1  1  1  1  1  .
.  1  1  1  1  1  1  .  .  .  .  .  .  1  1  1  1  1  1  .
.  1  1  1  1  1  1  .  .  .  .  .  .  1  1  1  1  1  1  .
.  1  1  1  1  1  1  .  .  .  .  .  .  1  1  1  1  1  1  .
.  1  1  1  1  1  1  .  .  .  .  .  .  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  .
.  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
.  1  .  1  .  1  .  1  .  .  .  .  .  1  .  1  .  1  .  .

The problem is with the scaling implementation of ScalableRectangle. When the width == height, both of the width and height will be scaled. However, in the case of "doubling distance"(or most of other cases), there should be some rectangles that only need to scale a single dimension.

To solve the problem, my idea is to only allow ScalableRectangle to change one of the dimension. I will submit a PR once #62 is merged.

I can clone plaquettes in any other direction -- is this intentional?

• For example -- p1, p2, ... where a lower number is higher priority
• Assign tags to active and backlogged tasks

Implement the exact same experiment as #50 but:

• physical qubits are initialised in the $\vert + \rangle$ state,
• the logical qubit is extended vertically, meaning that the $X$ observable is extended and the $Z$ observable is moved 2 plaquettes up.

Idea provided by Austin.

We could use https://quantumjavascript.app/Q-Circuit.html

Some ideas on the simulation part to gain more confidence on the correctness of implementation:

• We can simulate for both of the X/Z logical basis to verify that the extended logical basis outperforms the regular one.
• We can simulate a equal-distance square logical qubit memory experiment for comparison. If the implementation is correct, the extended logical basis should outperform that in the square case. And the regular logical basis should perform worse than that in the square case(there are more error paths for it to fail).

Originally posted by @inmzhang in #44 (comment)

The commit 6824a55 removed the output of some notebooks, which is not desirable (see below) and would like to revert these changes. Moreover, it changed the README.md, leading to two ways of installing the package without any explanations on which to pick.

Also note: the section

nbstripout is a great option for clearing the output of the jupyter notebooks. It can be installed using pip install nbstripout. For more info see below in before you commit section.

should be removed in my opinion. The notebooks in the notebooks/ directory are here to demonstrate the code, document it for a novice user by providing a working example with its outputs and to functionally test the overall code.
These 3 purposes benefit from the inclusion of the notebooks output to the repository.

We can discuss on whether or not the notebook outputs should be included in the repository, I know the standard way of doing is to strip, so if the 3 justifications above do not satisfy you please tell me.

Implement the experiments described in #50 and #51, rotating everything by 90°.

In particular this means that:

• $X$ and $Z$ plaquettes will be placed differently,
• $X$ and $Z$ observables will change their position and orientation (horizontal $\leftrightarrow$ vertical).

Idea provided by Austin.

Measurements need to be translated to record offsets in order to be readable and usable by Stim. This is currently handled by CircuitMeasurementMap that takes a cirq.Circuit instance as input and provides a way to compute the record offset for any measurement in this cirq.Circuit instance.

The current implementation of CircuitMeasurementMap is not adapted to the movement of a logical qubit due to one "limitation" (that was originally a feature): it counts measurements in a repeated cirq.CircuitOperation only once.

This means that if we perform the following QEC experiment:

1. Initialize a logical qubit,
2. Extend the logical qubit horozontally (let's say to the right),
3. Wait a few (let's say $n_1$) QEC cycles,
4. Measure out the data qubits on the left, where the logical qubit originally was,
5. Wait a few (let's say $n_2$) QEC cycles,
6. Measure the final observable,

the CircuitMeasurementMap would not be able to accurately compute the measurement records of the measurements included in the final observable, because it would count each measurement in the $n_2$ QEC cycles only once (instead of $n_2$ times).

A quick fix would be to change the behaviour of CircuitMeasurementMap on cirq.CircuitOperation instances when they are repeated.

Since tqec (Python backend) and tqec-js (React frontend) are becoming large projects in their own right, it'd make sense to separate them into their own repositories, and combine them back into this repository as submodules.

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.

          @smburdick Thanks. Let's move the discussion renaming of `tqecjs` elsewhere.

Originally posted by @vtomole in #41 (comment)

Per #17 discussion.

Running npm start in main causes these errors

Failed to compile.

[eslint]
src/App.jsx
  Line 7:1:   Expected indentation of 1 tab but found 2 spaces   indent
  Line 7:28:  Unexpected trailing comma                          comma-dangle
  Line 11:1:  Expected indentation of 1 tab but found 2 spaces   indent
  Line 12:1:  Expected indentation of 2 tabs but found 4 spaces  indent
  Line 13:1:  Expected indentation of 3 tabs but found 6 spaces  indent
  Line 14:1:  Expected indentation of 4 tabs but found 8 spaces  indent
  Line 15:1:  Expected indentation of 3 tabs but found 6 spaces  indent
  Line 16:1:  Expected indentation of 3 tabs but found 6 spaces  indent
  Line 17:1:  Expected indentation of 4 tabs but found 8 spaces  indent
  Line 18:1:  Expected indentation of 4 tabs but found 8 spaces  indent
  Line 19:1:  Expected indentation of 4 tabs but found 8 spaces  indent
  Line 20:1:  Expected indentation of 3 tabs but found 6 spaces  indent
[...]

I don't think we should allow tabs and spaces simultaneously, and should not allow tab characters at all.

It is generally preferred to insert space characters, since they are more consistent across editors than tab characters, among other reasons. I personally have VSCode set to insert spaces to indent with the tab key.

The check folder seems completely unused for the moment. Can we remove it from the repository?

From #12 description

Template and TemplateOrchestrator instances are currently scaled to a given dimension (or scale, or k, all these symbols refer to same quantity for the moment) with the scale_to method.

This k is defined as the number of plaquettes in one of the scalable dimensions or the Template.
With an example, for the ScalableQubitSquare, k is defined as the number of plaquettes in the x dimension of the inner ScalableAlternatingSquare (or equivalently the y dimension, both are always equal). For k == 4, the following template is constructed:

.  .  1  .  1  .
2  3  4  3  4  .
.  4  3  4  3  5
2  3  4  3  4  .
.  4  3  4  3  5
.  6  .  6  .  .

The current definition of k is not standard and might be an API issue for future users that might have hard times understanding the rationale behind this decision (there is none except that it was fixed like that at the very early stage of code development).

It would be nice to change, at least in user-facing parts of the library, the meaning of this parameter to something that is more understandable. Options are the following:

1. The equivalent of k // 2 as was initially proposed in the course slides. This would force the user to generate "valid" codes. As noted by Austin, the current ScalableCorner construction is generating an invalid code for odd k (drawn below is k == 3):

   .  .  1  .  .  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   .  4  3  4  5  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   .  4  3  4  6  .  7  .  7  .
   2  3  4  8  9  8  9  8  9 10
   .  4  8  9  8  9  8  9  8  .
   2 11  9  8  9  8  9  8  9 10
   .  . 12  .  . 12  . 12  .  .
   

2. Change k by code_distance. This option may be the easiest one to understand for people with a background in QEC. In fact this is what is done in the Normalise the API between stim and tqec section of the logical_qubit_memory_experiment.ipynb notebook.

In am open to more ideas for options, and would love to have feedback on the different options provided here.

The backend (i.e., the Python library tqec) and the frontend (i.e., the Javascript library tqecjs) need to interact in some way. The current scheme, retained for its simplicity, is that the tqec backend should be able to answer as a REST server to some queries and the tqecjs frontend will perform these queries on behalf of the user using the frontend.

The unique query, for the moment, that is needed is the one that will send from the frontend to the backend all the information needed to describe the QEC setting wanted by the user, to which the server should answer with the generated Stim file(s).

#43 is discussing the JSON format that both the backend and the frontend need to agree on in order to allow a good communication between the two. Note that this is still a work in progress and the specification discussed in #43 can still change.

On the backend side, we need to be able to create all the necessary Python structures from the JSON sent from the frontend.

This issue can be solved by:

• implementing a from_json method for each class that might be communicated and a generic from_json function that will handle the instantiation of the correct class.
• using the pydantic library to handle all the serialisation-related work.

The solutions above are up to discussion with anyone wanting to help on that.

As noted in f6f2932, the tqec package is currently able to correctly generate a memory experiment on a logical qubit.

This experiment is a first demonstration that the code is generating valid Stim files that can be used to simulate QEC experiments, but only replicates a result that has been known, generated and simulated plenty of times.

I think the tqec package should now evolves in two complementary ways.

First, the code base need to be cleaned up, some assumptions (#34 for example) should be lifted, some quality of life (see #36) features should be implemented, and some parts of the code should be made more robust (#33 and #35).

Alongside the clean-up, and as part of the process of making the library more robust, we should try to push the tqec library to its limits, and push back these limits to a level where we can generate QEC experiments that were never generated or simulated before.

The goal of this issue is to discuss the follow-up experiment(s) that will be implemented to test the robustness of the code already written, fix the bugs that will likely inevitably show up in the process, and end-up with a scientific result novel and interesting enough to be worth envisioning a publication.

I know we have webpack automatically setup for the frontend, but I'm also thinking about the backend as well as the endpoints we have for both of them. We should create some actions to deploy the code to these endpoints whenever a change has occured. We should also run some tests automatically when a PR is opened (just like cirq).

Following the install instructions:
> npm install
generate a few warnings that aren't stoppers (I think due to conflicting dependencies).

Then I launch the development mode:
> npm start
and gets:

NOTE: I am running on a remote Linux server using VSCode from a Windows laptop.

We can plan issues we want to tackle in the frontend here, which can be spun off into separate issues and PRs as time goes on, and following #69 and #41 being merged. Many of these issues are already present. If they can be handled individually just fine, we can close this issue

• Add circuit editor -- #22 , #46
• Finalize plaquette copying method and bug fixing -- #30
• Compartmentalize server API calls -- #38

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

The current UI only allows 2 unit vertically/horizontally separated qubits, which is conducive for Google architecture superconducting quantum computers, but not, for example, IBM's.

We need to support manual tiling, instead of enforcing a single tiling, as specified in the updated task flow.

• When the app is opened, there is only a grid with no qubits.
• Prompt the user to specify a constellation of qubits
• Create a rectangular (minimal) bounding box around the qubits
• Allow the user to resize the parallelogram by dragging individual vertices to other grid points, allowing them to select a new grid point if the updated parallelogram still contains the entire constellation
• Once those prompts are completed, the grid tessellates, filling the entire grid with qubits per the tiling.

- [ ] [Optional] Offer additional "shape modes", such as (general) quadrilateral, triangle, and hexagon

Alternatively, we could prompt the user to specify two non-parallel vectors to create the parallelogram, but this approach is less intuitive, and mathematically equivalent to the above procedure.