-
Notifications
You must be signed in to change notification settings - Fork 88
Description
TEP - Stabilizer simulator
Author
@refraction-ray
Status
Draft
Created
2023-07-07
Abstract
Motivation and Scope
Ultimately, it is good to have a clifford simulator in tc, but there are more to consider since the scope and nature of a stabilizer simulator are very different from a general simulator.
The features we require include (from high to low):
- We implicitly assume the features like gate application, extract the stabilizer state representation and sampling (but making a circuit with named gates and sample from it is far from enough (actually of very little use...))
- entanglement entropy calculation
- multiple-qubit random Clifford gate support
- direct manipulation on stabilizers, clifford maps, etc.
- trace to subsystem on a stabilizer state to get a sub stabilizer
- mix state stabilizer simulation
- entanglement negativity calculation
- canonical method for stabilizers
- necessary F2 linalg methods
- decompose gate based on clifford map
- enumerate random gate explicitly
- extended stabilizer simulator (few T) (very low priority feature though)
In the meanwhile, we hope the simulator is as fast as possible.
Usage and Impact
The use cases include: measurement induced phase transition and random circuit research (high priority), quantum error correction (low priority), hybrid ansatz with Clifford and general part (medium priority), simulator backend for CDR method (medium priority), large scale simulation and benchmark on quantum algorithms and mitigation schemes (medium priority).
The general interface is of course tc.StabilizerCircuit(n)
with gates application (the subtle part is about random Clifford gate: how to represent and implement them).
Backward compatibility
Try inherit from AbstractCircuit
, but even this approach has some challenges as in stabilizer case, many gates are easy to direct represented by the Clifford map instead of the specific gate decomposition as native gate set, which is conflict with the minimal IR we have now in AbstractCircuit
Related Work
QuantumClifford.jl is an ideal package with basically all features that we need, but it is written in Julia, leaving the integration with TC a pain.
In Python world, Stim is said to be fast but the doc are spare and the feature we required are basically all missing, the package is more suitable for qec and not random circuit investigation unless a lots of work to build relevant feature in tc. (Even EE on stabilizer state is a pain: https://quantumcomputing.stackexchange.com/questions/16718/measuring-entanglement-entropy-using-a-stabilizer-circuit-simulator)
PyClifford has some of the required features and can serve as one option for the integration, but the efficiency is not benchmarked.
Implementation
Ideally, we would like to incorporate another package for Clifford simulation as the backend instead of reinventing all wheels again. But as we mentioned before, there are many challenges to fuse the stabilizer backend into our general framework since quantum circuit is not as simple as only one measurement shots interface (this is barely what qiskit does) when it comes to the numerical investigation. The good news is that, due to the discrete nature of stabilizer circuit, we will lose AD/JIT/VMAP anyway, so we feel ok to directly reuse other package to simulate.
A quick fix on random gate issue could be a specific API on StabilizerCircuit class with no IR involved, i.e. c.random_gate(0, 1, 2)
, but _qir
not record it. c.stabilizer_state()
will get the stabilizer to manipulate in the original backend package. The measurement API require some thought, afterall, we now have measure
, sample
, post_select
, cond_measure
for a general circuit, how and which to migrate require some efforts