Repository navigation
✨ Simulation of Deterministic State Preparation Circuits using Stim #421
Description
Activity
This might also be interesting for @MaxieHelenBichmann.
But as this would be kind of a useful thing in general (high level language for conditional STIM), one could also think about giving this to a student.
Reacted by Maxie Helen BichmannI was looking into how
simulation_det.pycurrently works and to test the current qsample based simulation of a small circuit using the Steane code followingStatePrep.mdin the documentation, and noticed that the functionqiskit_to_qsample()insimulation_det.pyhad a small bug where in this line of codeelse: qubits = {qiskit_circuit.qubits.index(q) for q in qargs}was causing it to fail as qsample expects a tuple in the set for
CXgates of the structure{(control, target)}, but the above code, for example, passes{3, 5}instead of{(3, 5)}. A simple fix is just to usetuple()which worked perfectly fine for me. Since I saw that you plan to remove qsample as a dependency in the future because it is not well-maintained, I am not sure if this needs a separate bug report issue of its own yet! Meanwhile , I'm currently experimenting with STIM for the conditional simulation purpose as an alternative to qsample.yes, we had multiple issues with qsample, so we turned off the deterministc tests. This is likely the reason why this did not get catched.
It's not super important, but I think it still makes sense to fix this if possible. So feel free to create an issue/PR for that! 👍
Reacted by orisus42Sorry for taking so long on this! I have looked into a stim-based implementation for deterministic verification and correction using QECC's
DeterministicVerificationHelperoutput directly with an example Steane code. In qsample'sdss_logical_error_ratesfor smallpvalues needed 2000 shots (around 2 seconds) to reach a given precision but plain stim Monte Carlo, as expected, required millions of shots more to match the same level of precision, but because stim is so fast it was able to reach it in about 20 seconds, and this was a very naive implementation so I'm sure many more optimizations are possible for it to use lesser shots. For codes withd < 5it isn't prohibitive to use stim but for high precisions it definitely does take more time and large number of shots.Besides Steane code is really simple in its branching structure so I am testing a bit more richer codes like the Shor code, but weirdly the results don't match up very nicely with qsample's so there's probably more to it and the gap increases with how many CNOTs are in the prep circuit. Is there any other direction you would suggest to think about for this?
Hey! Great to hear that you are working on that!
Yes, exactly this was our idea/hope that for the small codes that we consider here, stim has some overhead, but it's manageable. This does not generalize, that's true but we think as long as we can reproduce our results/tests with that instead of qsample, we are happy.
What do you mean with "don't match up very nicely"? Did you try some other codes than Shor or Steane?
What's the problem this feature will solve?
Currently, simulations of deterministic circuits are done using the qsample package. Due to issues with that library, it would be good to have an alternative simulator based on stim, for example.
Describe the solution you'd like
qsample is useful for FTQC protocols with branching paths based on measurement outcomes. This can, in principle, also be achieved using stim circuits. Since stim is based on Monte-Carlo simulation, the number of samples required to achieve the same results as with qsample might be quite large. Since we only deal with$d<5$ codes, this should not be prohibitive, though.
Implementation-wise, the
NoisyDFTStatePrepSimulatorcould have a flag in the__init__method to choose the simulator, or there might be dedicated simulators depending on the simulation backend.