search

QCHackers / tqec

Design automation software tools for Topological Quantum Error Correction
https://qchackers.github.io/tqec/
Apache License 2.0
74 stars 19 forks source link

Improve measurement handling #302

Closed nelimee closed 1 month ago

nelimee commented 2 months ago

Is your feature request related to a problem? Please describe. Ultimately, we need to use stim's way of specifying measurements: using a (negative) offset relative to the measurement already performed at the point this offset is used.

But this representation is lacking a few features that we might require. Here is a non-exhaustive list of potential issues I found with this representation:

The required global knowledge about space is quite a bummer for detectors as we would like to only have to look locally for flows, without the need to have a global view (yet). Also, the current tqec.circuit.operations.measurement_map.CircuitMeasurementMap implementation is not fit for extra-large circuits as it requires to flatten the whole circuit to index measurements.

Finally, we would like an easy way to list measurements, in particular to list measurements that are not (yet) involved in a detector, which is an indication that we might have missed detectors.

Describe the solution you'd like All the issues described above calls for a better internal way of handling measurements that will then be used across the code base. Ideally, we would like a new way that:

I have something like 

@dataclass(frozen=True)
class Measurement:
    qubit: tuple[int, ...]
    offset: int

where we store the spatial information in the qubit attribute (that might as well be a tuple[int, int] or a cirq.GridQubit) and the temporal information is given by an offset that can be:

(this representation is very close to the already existing tqec.circuit.operations.operationl.RelativeMeasurementData)

Translating from such a representation to stim's one still require global knowledge (at least spatially), but this is a requirement of stim's representation so there is no way around it.

Once we settle on a representation, we will be able to use it to (in no particular order):

Any opinion on that?

afowler commented 2 months ago

+1 to having such an internal representation.

On Tue, Aug 27, 2024 at 12:48 AM Adrien Suau @.***> wrote:

Is your feature request related to a problem? Please describe. Ultimately, we need to use stim's way of specifying measurements: using a (negative) offset relative to the measurement already performed at the point this offset is used.

But this representation is lacking a few features that we might require. Here is a non-exhaustive list of potential issues I found with this representation:

  • a given offset is basically only valid at a particular point in a quantum circuit and becomes invalid as soon as a new measurement is performed.
  • even though the offset is only locally valid, it often requires global information on measurements in space (X/Y plane, not the time dimension) because it needs knowledge about all the measurements that happened between the place we are using the offset and the measurement represented, which often requires to know about all the measurements that happened in space in the current and previous QEC round.

The required global knowledge about space is quite a bummer for detectors as we would like to only have to look locally for flows, without the need to have a global view (yet). Also, the current tqec.circuit.operations.measurement_map.CircuitMeasurementMap implementation is not fit for extra-large circuits as it requires to flatten the whole circuit to index measurements.

Finally, we would like an easy way to list measurements, in particular to list measurements that are not (yet) involved in a detector, which is an indication that we might have missed detectors.

Describe the solution you'd like All the issues described above calls for a better internal way of handling measurements that will then be used across the code base. Ideally, we would like a new way that:

  • can be used locally in space and time,
  • can uniquely identify a measurement in any circuit,
  • if possible, is hashable,
  • can be easily translated to stim's way of specifying measurements.

I have something like

@dataclass(frozen=True)class Measurement: qubit: tuple[int, ...] offset: int

where we store the spatial information in the qubit attribute (that might as well be a tuple[int, int] or a cirq.GridQubit) and the temporal information is given by an offset that can be:

  • a positive integer, in which case this is a global offset from the start of the circuit (read "the offset-th measurement on qubit qubit)
  • a negative integer, in which case this is a local offset from the end of a given sub-circuit.

Translating from such a representation to stim's one still require global knowledge (at least spatially), but this is a requirement of stim's representation so there is no way around it.

Once we settle on a representation, we will be able to use it to (in no particular order):

  • discover detectors locally,
  • encode observables,
  • list measurements that are not (yet) involved in a detector / observable,
  • ...

Any opinion on that?

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

inmzhang commented 2 months ago

Quick thought about this:

As we need both easy access to local/global and spatial/temporal information about measurements, it appears to me that maintaining a global data structure like MeasurementTracker and use it along with circuit construction might be easier. It can maintain both position and timestamp for each measurements, and the reverse indices can be calculated from the records.

nelimee commented 2 months ago

Quick thought about this:

As we need both easy access to local/global and spatial/temporal information about measurements, it appears to me that maintaining a global data structure like MeasurementTracker and use it along with circuit construction might be easier. It can maintain both position and timestamp for each measurements, and the reverse indices can be calculated from the records.

It is approximately what CircuitMeasurementMap is doing but:

I kind of agree that a CircuitMeasurementMap (or MeasurementTracker) structure might be better constructed live along with the circuit, but building from the full circuit potentially gives more freedom (?).