Improved generation of detectors for logical gates

[MarcSerraPeralta]

Improve how the detectors are constructed in stim, specially if we want to be able to simulate logical gates with this software.

Some considerations:

• Model and Setup should not be modified, they have a very well defined functionality (this includes that Model is the one that knows when qubits are measured, thus the Model.meas_target functionality should be kept in Model)
• The "code" division is already done at the level of different scripts inside experiments and circuit_blocks
• The new functionality should be able to handle meas_reset=False. This can be done by knowing that an ancilla outcome ("A1", -1) = stab generator outcome measured in "A1" XOR ("A1", -2) where ("A1", -2) implements the reset in software, i.e. M-R can be seen as M followed by a conditional X and then this X can be propagated to the next measurement and be integrated in the measurement, thus the second measurement outcome is m2 XOR m1 because of the feed-forward/conditional X gate that flips the second measurement. The X propagation is very simple because it gets converted into Z by the Hadamard, then it does not do anything for the C-PauliStab, and finally back to X with the other Hadamard.

Proposed implementation

Create a Detectors class that will be initialized differently for each of the codes by a specific function in each circuit_blocks code. It will be passed to any logical operator, so that the stabilizer generators are updated and it will be also passed to the QEC cycle to generate the detectors. The initialization of the Detectors requires which detector frame to use and if we are using measurement+resets. In every QEC cycle, the previous and current stabilizer generators must be updated. The Detectors class should have the following methods:

• __init__: initializes the class from an initial set of stabilizer generators. (In reality, the stabilizer generators are not needed, only the name of the ancilla qubits because we can use the basis of the initial stabilizer generators to express all the other stabilizer generators, thus the initial ones can be represented as an identity matrix)
• update: updates the current stabilizer generators given a unitary (invertible) matrix (bool mod 2). The matrix is generated in each logical operation block.
• build: return the stim circuit implementing the current set of detectors. This function should be called at the end of every QEC cycle. This method requires an input which is a function that translates ("A1", -3) to a target rec integer, e.g. we can use the Model.meas_target.

TODO

• [x] Improve the documentation to include also the Detector class and add some schematic of how the classes are related to each other
• [x] Implement the Detectors class and the corresponding tests
• [x] Think how to generate the unitary matrices for each logical gate (this should assume an arbitrary layout). Should the layout contain specific information about it?

[MarcSerraPeralta]

Regarding how to generate the unitary matrices, I have decided that this information will be stored in the layout file because (for transveral gates) some extra connections are required between qubits. Therefore, thus connections should be specified in the layout. The current idea is to have an extra field for each qubit, log_gates, which will correspond to a dictionary containing all the possible logical gates implemented and the required information to run them. For the case of ancilla qubits, they will store a list of the new_stab_gens, and for the case of data qubits, they will store information of the gates to perform to them (e.g. cz between which qubits, ...)

[MarcSerraPeralta]

This issue can get very big and I believe it would be best to split it into smaller ones and merge small PR. The problem is with the Layout class, because I need to include the log_gates information and generate layouts that have this information.