# Is the honeycomb code a subsystem code?

The paper https://arxiv.org/abs/2110.09545.pdf claims that the honeycomb code falls outside the definition of a subsystem code.

But here: https://errorcorrectionzoo.org/list/subsystem, here: https://quantum-journal.org/papers/q-2022-09-21-813/pdf/, here: https://arxiv.org/pdf/2110.05348.pdf, and here: https://arxiv.org/abs/2210.02468, it sounds that the honeycomb is a kind of a subsystem code.

Can any explain the contradiction, or in which sense this is not a subsystem code?

• where do those refs say it’s a subsystem code? Jun 20, 2023 at 15:20
• In the first link, the Flouqet honeycomb code appears in a list of subsystem codes. In the second, it is written: " The logical qubits of the honeycomb code are defined by pairs of anti-commuting logical observables that change over time. This sidesteps a well-known issue with building a subsystem code out of Kitaev’s honeycomb model, namely that it encodes no static logical qubits". It is written more explicitly in this paper: arxiv.org/pdf/2110.05348.pdf Jun 20, 2023 at 17:30

Subsystem codes have observables that commute with all measured operators. The honeycomb code as normally described has measured operators that anticommute with any possible choice of observable. It bypasses this problem by using dynamical observables. They always anticommute with some of the measured operators, but never the ones you just measured or the ones you're about to measure next. So the honeycomb code is not a subsystem code.

However.

Here's what you get if you take make a detector slice diagram of the honeycomb code circuit, as it executes. I made this diagram by downloading the circuits.zip file from https://zenodo.org/record/7072889 and running

stim diagram \
--type detslice-svg \
--tick 0:46 \
--remove_noise \
--out tmp.svg \
--filter_coords "L0:*" \
--in "model=SIEM3000,r=10,w=6,h=9,p=0.0001,obs=V,sheared=False.stim"

open tmp.svg


Each of the squares is the checked stabilizers at some time (the stabilizers that will be measured in order to produce detection events). I've picked a size that makes them repeat in line with the grid. Focusing on just one of those columns we see this repeating thing:

It's hard to tell, because some of these things are overlapping, but the bright red rectangles are each a checked XXXXXX stabilizers, the bright blue rectangles are each a checked ZZZZZZ stabilizers, and the muddy red operators are each a pair of overlapping checked XXXXXX and ZZZZZZ stabilizers. The small blue circles are showing the vertical observable; each blue circle is one of its Z components.

Now forget about the honeycomb code and just look at this picture. This is a picture of a stabilizer code. It has a set of stabilizers to measure, and an observable to protect. It has a code distance. It's actually sort of similar to a color code, but with 1/3 of the stabilizers missing.

The circuit that I loaded to make this picture can be thought of as measuring these stabilizers, while protecting this observable. Sure, there's some shenanigans that occur where there's feedback into the observable from the measurements, but that kind of intermediate complication always happens when you turn codes into circuits. If it wasn't measurement feedback it would be perturbations from CNOTs.

So the honeycomb code is not a stabilizer code, or a subsystem code. But when you compile it into a circuit all that context is forgotten. And if you took the stabilizer code I drew above, and compiled it into a circuit, you could legitimately get the same exact circuit that the honeycomb code uses. It might not be the first circuit that would occur to you, but it's a valid one. So, ultimately, the question is kind of meaningless, because once these things are translated into circuits it all kinda mushes together.

• So the honeycomb code is "circuit equivalent" to a stabilizer code. What are the parameters ($[[n,k,d]]$) of this stabilizer code? Also it seems there are many ways to pick the size and boundaries of a honeycomb code...how does that change things Jun 21, 2023 at 17:07
• @unknown It's a [[n, 1, O(sqrt(n))]] code, same as the honeycomb code (and the surface code and the color code and every planar topological code actually). The boundaries are finicky details that don't change the underlying point being made. The same circuit-equivalence-to-stabilizer-code would hold in the toric case. Jun 21, 2023 at 18:23
• I'm trying to decide if there's something deep behind this "circuit equivalence". Has this been formalized somewhere? (as in some theoretical framework that describes it) Jun 21, 2023 at 18:39
• @unknown I don't think it's been formalized. The deep thing here is that simplified interfaces, like "stabilizer code" and "floquet code", can appear different despite ultimately producing the same output. Looking at a circuit and saying "that's a surface code" is an interpretation of the circuit, highlighting some of its features and ignoring others. Jun 21, 2023 at 18:51
• There should be value in formalizing this. If I give you two circuits, how would you decide if they "produce the same output". What would be the inputs and initial states? Also are there restrictions on what operations are allowed in the circuit? Jun 21, 2023 at 19:32

The honeycomb 'code' is not even really a code - you can't write down a gauge group that defines a (subsystem of a) subspace that defines it. It's really more a fault-tolerant circuit (which steps through surface codes as it executes). It might be called subsystem-y since it involves measuring anti-commuting operators during its execution (as in a subsystem code), but I wouldn't even really call it a 'code' at all.

Re the ECZoo classification, I think it's just hard to classify things. I would say both that the honeycomb code isn't really a code, but is also basically the surface code (in the same way that a 3D cluster state is basically the surface code). In fact, I think this paper shows that floquet codes can be thought of as traveling diagonally through a 3D cluster state.