2
$\begingroup$

I am looking for clarification on two arguments for the detector error models used in Stim, appproximate_disjoint_errors and decompose_errors (i.e. calling circuit.detector_error_model(decompose_errors=True,approximate_disjoint_errors=True)).

I am having a hard time understanding them from documentation alone.

At a high level, is the simulation more accurate when either of these parameters are set to True? What would be the driving motivation to set these arguments to True?

At a lower level, will an exception thrown as a result of crossing either parameter's threshold cause the simulation to halt? Or will the simulation continue to run with 0 or nans being returned as the logical error rates when using sinter?

Finally, when running a circuit, does Stim or Sinter ever set these parameters to True outside of what has been passed to them by the user?

I would appreciate any insight. Thank you for your for your time!

$\endgroup$

1 Answer 1

0
$\begingroup$

is the simulation more accurate when either of these parameters are set to True

Neither of these options will affect the accuracy of simulations driven by the circuit (circuit.compile_sampler() / circuit.compile_detector_sampler()). They could only affect simulations driven from the detector error model itself (circuit.detector_error_model().compile_sampler()).

The decompose_errors=True cannot affect accuracy, because it doesn't throw anything away. When I decompose error(0.01) D1 D2 D3 into error(0.01) D1 D2 ^ D3, you can still tell what the full reror is.

The appproximate_disjoint_errors=True option can affect accuracy. Probably the most blatant example of this is heralded erasures gaining a small probability of not being heralded. For example:

import stim

c = stim.Circuit("""
    HERALDED_ERASE(0.1) 0 1
    MZZ 0 1
    DETECTOR rec[-1]  # MZZ
    DETECTOR rec[-2]  # Heralod 0
    DETECTOR rec[-3]  # Heralod 1
""")

print(c.detector_error_model(approximate_disjoint_errors=True))
# error(0.05) D0 D1
# error(0.05) D0 D2
# error(0.05) D1
# error(0.05) D2

The four error mechanisms in the DEM are independent. So the D0 D1 error can occur at the same time as the D1 error, producing the symptom D0. But that corresponds to the MZZ failing without any heralding, which should be impossible because there are no unheralded errors in the circuit. Ignoring the disjointness has a created a 0.0025 probability of a missing herald.

will an exception thrown as a result of crossing either parameter's threshold cause the simulation to halt

The simulation will not throw an exceptions. But I guess if you have a program analyzing the samples you took from a dem, instead of the circuit, the analysis may throw an exception when it sees impossible things like unheralded errors in a circuit that was supposed to have only heralded errors.

when running a circuit, does Stim or Sinter ever set these parameters to True outside of what has been passed to them by the user?

Stim will never turn these options on without being explicitly told to do so by the user. In general, Stim forces the user to opt into anything that could reduce accuracy or that might not work on all circuits.

Sinter does use approximate_disjoint_errors=True when it infers a dem for a circuit. You can override this by specifying the detector error model in the sinter.Task instances you give to sinter.collect, instead of having sinter infer them from the circuit.

$\endgroup$
2
  • $\begingroup$ Hi Craig, thanks for the response. If I simulate a distance 3 rotated surface code experiment (generated by Stim), and group by parameters passed, I see a difference of half an order of magnitude for smaller numbers with respect to the decompose_errors parameter (x-axis is uniform error rate for the whole surface code). This leads me to believe that decompose_errors does have an effect on accuracy for smaller numbers. Would you know why that is? $\endgroup$ Mar 9 at 23:52
  • $\begingroup$ @MaxwellPoster you're plotting logical error rate, which is distinct from simulation accuracy. In particular, logical error rate is heavily dependent on your decoder. For example, your decoder may simply ignore any unexploded ungraphlike error mechanism, in which case turning off decomposition amounts to configuring your decoder differently. $\endgroup$ Mar 10 at 5:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.