Mitiq <> UCC integration

[natestemen]

Context

Mitiq

Mitiq is an open source toolkit for QEM protocols.

Applying QEM

A typical workflow for executing a quantum circuit with error mitigation follows these steps:

1. Given a circuit of interest $C$, users first optimize it for their desired backend: $C_\text{opt}$.
2. QEM settings are chosen (i.e. the technique, and associated parameters), whereupon mitiq generates a collection of circuits $\{C_1, C_1, \ldots, C_n\}$.
3. These circuits are run on hardware, and the results are processed to extract a mitigated estimate.

Important

One key detail is that circuit optimizations should not be applied without caution to the generated QEM circuits $C_i$​, as some error mitigation techniques rely on transformations that may be mistakenly optimized away. For example, in ZNE, one circuit might be $C_{\text{opt}}C_{\text{opt}}^\dagger C_{\text{opt}}$​, which nominally compiles to the identity but is necessary for ZNE.

A tutorial demonstrating mitiq's "integration" with BQSKit (a quantum compiler) follows this approach: compile first, then apply QEM.

Motivation

Error mitigation and compilation are a venn-diagram with overlap goal being "reduce the effect of errors on a computation". A well-optimized circuit can reduce the circuit depth, thereby reducing the potential for errors to accrue.

Ideas

Integrate UCC into mitiq

This is a natural extension because mitiq is designed around executing quantum circuits, and compilation is often a necessary preprocessing step. The composition of tools aligns well:

• UCC: QPROGRAM -> QPROGRAM (optimization/routing)
• Mitiq: QPROGRAM -> list[QPROGRAM] (QEM)

Thus, the natural approach is compile first, then apply QEM.

1. Add a compile flag to mitiq techniques

   import mitiq
   
   mitiq.xyz.execute_with_xyz(circuit, execute, compile=True)

   This would automatically compile the circuit before applying QEM.

Integrate mitiq into UCC

Instead of having Mitiq control compilation, we could make UCC aware of QEM and/or orchestrate the QEM protocol. A key component of many of these suggestions is that UCC would have to be able to output multiple circuits from a single one.

2. Accept QEM config into ucc.compile

   import ucc
   import mitiq
   
   qem_settings = {
       "technique": "zne",
       "scale factors": [1, 3, 5],
       "extrapolation method": mitiq.zne.inference.LinearFactory,
       "scaling method": mitiq.zne.scaling.fold_all,
   }
   qem_circuits = ucc.compile(circuit, qem_config=qem_settings)
   
   circuit_results = ... # user would run qem_circuits and store results
   
   mitiq.combine_results(qem_settings, circuit_results) # new mitiq function

3. Build the Executor interface into UCC

   import ucc
   
   ucc.compile_and_execute(circuit, executor)

   Personally, I am not a fan of this, but it may make usability easier.
4. Add mitiq as a compilation pass

   import ucc
   
   compiler = ucc.UCCDefault1()
   compiler.pass_manager.append(ucc.passes.ZNEPass(scale_factors=..., ...)

   @jordandsullivan, is this something that is easily supported in the qiskit framework?

No "integration"

Instead of tightly integrating mitiq and UCC, we could keep them separate but compatible.

5. QEM-aware compilation

   import mitiq
   import ucc
   
   qem_circuits = mitiq.xyz.intermediary_circuits(circuit, ...)
   qem_circuits_compiled = ucc.compile(qem_circuits, qem_aware=True)

   The idea here being that maybe there are some optimizations that can be made while respecting the mitigated-circuit structure. This would likely mean different optimizations for different QEM techniques which is a potentially large investment.

These are just preliminary ideas. Looking forward to further discussion coming from this. @bachase @jordandsullivan @Misty-W for comments

[bachase]

Asking to understand

1. Is there a good example to use to make these alternative options more concrete? Is ZNE representative enough of other mitigation techniques?
2. Do we already have a view on the goals of integration? Is it about having a single interface that does both, but also supports a variety of front-ends and back-ends? Or is it more about your point 5, where by putting them in the same "space" may enable some ZNE-aware optimizations in the compiler?
4. I think your points about each tool doing what they do well and then making them composable makes the most sense, but I'm not sure if that compromises on any goals or users experiences we want to solve for.

[natestemen]

1

It is representative in the sense of structure. I.e. one circuit to multiple circuits. I need to think more about this, but there maybe some techniques (PEC) where compilation of the intermediary circuits $C_i$ make sense. But for ZNE, DDD, and LRE you need to retain certain structure.

2

That's a good question that we should define more explicitly to help focus this work. IMO the first goal should be to demonstrate that more accurate estimates can be obtained when using compilation and error mitigation together. The second goal should be to make using these techniques together as easy as possible. It's nice to imagine a future where an application scientist doesn't have to worry about what compilation passes, or error mitigation technique to use, and instead can focus on the science they want to get done. We are likely quite far from that reality, but maybe something good to have in the back of our mind.

3

:P

4

Currently, I think you're right on the first goal of performance, but this is maybe a slight sacrifice on the usability goal. That said, last year when I interviewed people across the quantum computing ecosystem, nearly all of them told me they want as much control over the workflow as possible in order to squeeze out every drop of performance they can. This points towards embracing composability (unix philosophy).

[bachase]

Lol, that formatting went south on me. Thanks for working with it!

[nathanshammah]

Many thanks @natestemen for starting this discussion and the nice outline. At first impact, point 4. looks like the most interesting to me, although in practice it seems to require a bit of design decisions.

ZNE is definitely a generic and compelling example to start from, although a simpler pass to consider first could be dynamical decoupling (Digital DD in Mitiq).

@bachase with regards to the motivation and goal: We want to build into ucc also the capabilities of noise aware compilation.

[natestemen]

point 4. looks like the most interesting

Flushing out point 4 so we can see what it looks like more.

import ucc
import mitiq

compiler = ucc.UCCDefault1()
compiler.pass_manager.append(
    ucc.passes.ZNEPass(
        scale_factors=[1, 5, 7],
        scale_noise=mitiq.zne.scaling.fold_global,
    )
)

circuits = compiler.compile(circuit)

expval_results = [execute(c) for c in circuits]

zne_value = mitiq.zne.combine_results(expval_results)

I'm a little mixed on if this is the correct approach, because under the hood it is equivalent to the following code.

import ucc
import mitiq

compiled = ucc.compile(circuit)

circuits = mitiq.zne.scaled_circuits(
    circuit,
    scale_factors=[1, 5, 7],
    scale_method=mitiq.zne.scaling.fold_global,
)
expval_results = [execute(c) for c in circuits]

zne_value = mitiq.zne.combine_results(expval_results)

I find this second method conceptually much simpler, keeping the responsibilities of each tool more tightly scoped. I understand the vision of having these two tools more tightly coupled, or even one orchestrating the other, but I'm not yet seeing the value gain over what currently exists.

It's possible there is value in pushing QEM into a qiskit transpiler pass for the practice of moving noise-awareness into the compiler, but this assumption/guess needs to be further flushed out, and inspected.