Cleaning up the repository

[nelimee]

As started in #323, I think we reached the perfect moment to clean up the repository.

Clean up on GitHub

Issues

As discussed in #323 I think we can close most of the front-end related issues. If the work on front-end is resumed at one point, we have an exhaustive list of issues in #323 to help us re-open the correct issues.

PRs

I think the following PRs can be closed without merging:

• #238
• #240
• #297
• #298

Source code

I think we should remove from the main branch most of the front-end v1. In my opinion, the best way of doing that non destructively is to

1. create a branch from the current state of the main branch (i.e., with all the front-end code),
2. remove everything we want to remove from the main branch,
3. keep the branch created in 1. in case we want to get back some of the code.

I will do a PR for this (PS: #326)

[inmzhang]

I think we can also move Gian's frontend code to another branch to avoid distraction. But that will be subject to @giangiac's opinion.

[Gistbatch]

I'm closing my open PRs #238, #297, #298. For the frontend I'm in favor of completely moving it to a separate repository. Gian has most of the frontend development in his fork anyway, so we could move this to QCHackers/tqec-frontend for now. I wouldn't maintain stale branches instead we can tag the last commit with frontend changes and do a version bump after removing it.

[Gistbatch]

I'm closing my open PRs #238, #297, #298. For the frontend I'm in favor of completely moving it to a separate repository. Gian has most of the frontend development in his fork anyway, so we could move this to QCHackers/tqec-frontend for now. I wouldn't maintain stale branches instead we can tag the last commit with frontend changes and do a version bump after removing it.

[Gistbatch]

@nelimee how up-to-date is the status board? I'm not sure which tasks should be prioritized. In my mind, we have four main issues:

• Improve docs, although they are in a decent state
• Improve coverage
• Clean up code as much as possible
• Improve code quality, e.g. refactoring, logging... I could help with any of those but I would also try to scope them as tightly as possible

[nelimee]

Right now, for this particular issue, I think the only question left is what we should do with @giangiac front-end. I like the idea of outsourcing it to another repository, but that is ultimately up to Gian.

About the current refactoring period, I agree with all your points. I would add the following information:

• in-code documentation is in a decent state, but it would be nice to have specific documentation in qchackers.github.io/tqec/ to guide a potential user/developer through the different concepts used in tqec. Just like https://qchackers.github.io/tqec/detectors.html but for templates, plaquettes, scheduled circuits, ZX graphs, block graphs, cubes, pipes, ... Basically a nice glossary and visual / mathematical / code explanations of the concepts we are using in the code.
• coverage is a nice proxy, but not an end goal. In particular, nearly all the tests should at least be checked.
• code cleanup is the largest portion in my opinion.

I will open a specific issue regarding the 4 points you made (EDIT: #335).

[giangiac]

@nelimee @Gistbatch Sorry for the unresponsiveness. I appreciate your patience.

I merged the main branch into the ggg-frontend one and things are working fine in my local machine. However I now get some CI errors and am looking into fixing it. Also, I cannot merge the PR (no write access). --> I will ping you once the CI succeeds.

I see that the "old" frontend has been removed. I will first merge the PR and only then rename the folder ggg_frontend to avoid confusion.

Concerning moving the frontend to a separate repo, I think that's possible since the codebases are largely independent. I would just like to discuss what workflow would take advantage of both tools (frontend and backend): For example one could use the former to create the library used by the latter, but I am not up to date with the I/O of the backend.

[nelimee]

As a note for later (when your PR will be merged and your questions answered), this tool https://github.com/newren/git-filter-repo might be useful to extract the front-end folder into a new repository.

[afowler]

I think it is fair to say that the tool has moved away from using a front end to specify plaquettes and load them into templates visually. I think it is fair to say that this choice of direction was due to recognizing that as a community we really don't have the right mix of skills to make a front end of the complexity and stability required, it simply more realistic to focus on coding plaquettes and templates.

It would definitely be desirable to be able to visualize slices of circuits. This might be a more realistic goal than programming slices of circuits visually.

On Tue, Oct 8, 2024 at 9:45 AM giangiac @.***> wrote:

@nelimee https://github.com/nelimee @Gistbatch https://github.com/Gistbatch Sorry for the unresponsiveness. I appreciate your patience.

I merged the main branch into the ggg-frontend one and things are working fine in my local machine. However I now get some CI errors and am looking into fixing it. Also, I cannot merge the PR (no write access). --> I will ping you once the CI succeeds.

I see that the "old" frontend has been removed. I will first merge the PR and only then rename the folder ggg_frontend to avoid confusion.

Concerning moving the frontend to a separate repo, I think that's possible since the codebases are largely independent. I would just like to discuss what workflow would take advantage of both tools (frontend and backend): For example one could use the former to create the library used by the latter, but I am not up to date with the I/O of the backend.

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

[KabirDubey]

As discussed in https://github.com/QCHackers/tqec/discussions/323 I think we can close most of the front-end related issues. If the work on front-end is resumed at one point, we have an exhaustive list of issues in https://github.com/QCHackers/tqec/discussions/323 to help us re-open the correct issues.

There are some outstanding issues that weren't labeled as frontend but are still confusing to consider with recent updates to the codebase.

My thoughts:

• #61 should be closed because both PR #43 and #240 referenced in it have been closed.
• #246 should be updated to reflect that we can implement a logical CNOT. Do we still need all the plaquette types from the revised task flow slides? It would be nice to have an issue or discussion post that lists our template and plaquette limitations.
• #229 could specify which files in the new repo we need unit tests for. Alternatively, we can close it and link the closed issue to point 2 in #335 until we see active development on test improvements.
• #71; I have not made substantial progress on this since the Template module was refactored. I say that we close this and make new issue describing a feature to visualize slices of circuits. I don't have a strong intuition for how we would go about implementing this, but if it involves porting Templates, I can work on that aspect.

Let me know what you more experienced devs think. If you approve, happy to make these edits myself!

[nelimee]

* [Implement `from_json` in backend #61](https://github.com/QCHackers/tqec/issues/61) should be closed because both PR [Update JSON specification #43](https://github.com/QCHackers/tqec/pull/43) and [Add a REST server with FastAPI #240](https://github.com/QCHackers/tqec/pull/240) referenced in it have been closed.

I agree.

* [Implement more plaquettes in the plaquette library #246](https://github.com/QCHackers/tqec/issues/246) should be updated to reflect that we can implement a logical CNOT. Do we still need all the plaquette types from the revised task flow slides? It would be nice to have an issue or discussion post that lists our template and plaquette limitations.

Can probably be closed too. According to what I just realized in #345 we will have to implement more plaquettes, but new issues will likely have to be opened to accurately describe the context.

* [Implement more unit-tests for the backend #229](https://github.com/QCHackers/tqec/issues/229) could specify which files in the new repo we need unit tests for. Alternatively, we can close it and link the closed issue to point 2 in [Improving the code base #335](https://github.com/QCHackers/tqec/issues/335) until we see active development on test improvements.

I agree. Also, tests will be added alongside the current refactors, so we can probably close this issue for the moment and reopen it (or open a new one) if there is still holes in the tests at the end of the refactors.

* [Improve the function to display `TemplateOrchestrator` as svg #71](https://github.com/QCHackers/tqec/issues/71); I have not made substantial progress on this since the `Template` module was refactored. I say that we close this and make new issue describing a feature to visualize slices of circuits. I don't have a strong intuition for how we would go about implementing this, but if it involves porting Templates, I can work on that aspect.

What would be nice is to be able to superimpose the "image" of a (grid of) logical qubit on the output of stim.Circuit.diagram to help understanding locating the qubits on the stim diagram and understanding their status. We can close this issue too and open a new one with a more detailed description of what would be interesting to have. I think that, on this particular issue, it would be nice to have feedback from everyone to know what would be the best visualisation for everyone.

[afowler]

"What would be nice is to be able to superimpose the "image" of a (grid of) logical qubit on the output of stim.Circuit.diagram to help understanding locating the qubits on the stim diagram and understanding their status."

+1 to this. Being able to step forward and backwards through the ticks of the circuit would be great. An alternative view where you just see the plaquettes and a number in each corner giving the time of interaction would also be very useful. A useful way to focus on just hook errors without numbers is to put a line inside the plaquette connecting the last 2 corners touched.

On Wed, Oct 9, 2024 at 3:14 PM Adrien Suau @.***> wrote:

• Implement from_json in backend #61 should be closed because both PR Update JSON specification #43 and Add a REST server with FastAPI #240 referenced in it have been closed.

I agree.

• Implement more plaquettes in the plaquette library #246 should be updated to reflect that we can implement a logical CNOT. Do we still need all the plaquette types from the revised task flow slides? It would be nice to have an issue or discussion post that lists our template and plaquette limitations.

Can probably be closed too. According to what I just realized in #345 https://github.com/QCHackers/tqec/pull/345 we will have to implement more plaquettes, but new issues will likely have to be opened to accurately describe the context.

• Implement more unit-tests for the backend #229 could specify which files in the new repo we need unit tests for. Alternatively, we can close it and link the closed issue to point 2 in Improving the code base #335 until we see active development on test improvements.

I agree. Also, tests will be added alongside the current refactors, so we can probably close this issue for the moment and reopen it (or open a new one) if there is still holes in the tests at the end of the refactors.

• Improve the function to display TemplateOrchestrator as svg #71; I have not made substantial progress on this since the Template module was refactored. I say that we close this and make new issue describing a feature to visualize slices of circuits. I don't have a strong intuition for how we would go about implementing this, but if it involves porting Templates, I can work on that aspect.

What would be nice is to be able to superimpose the "image" of a (grid of) logical qubit on the output of stim.Circuit.diagram to help understanding locating the qubits on the stim diagram and understanding their status. We can close this issue too and open a new one with a more detailed description of what would be interesting to have. I think that, on this particular issue, it would be nice to have feedback from everyone to know what would be the best visualisation for everyone.

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

[nelimee]

Closing in favour of #335 as the improvements discussed here have all been done.