Modularize error mitigation techniques

[natestemen]

Idea

Many quantum error mitigation (QEM) techniques take place in two general phases.

1. Create circuits based on some protocol/algorithm (ZNE: noise scaled circuits, PEC: probabilistically sampled circuits, DDD: circuits with idle windows filled in, etc)
2. Take results from the execution of circuits in step 1 and combine them in special ways to obtain the QEM estimator.

Ideally, each technique in Mitiq should have a function available for each of these steps that authors can then use to both better understand what's happening, and hack on these techniques.

Example

Here's what this could look like. Ideally all techniques will have the same interface so it's easy to hot swap techniques. function names subject to change, just brainstorming.

circuits = mitiq.zne.intermediary_circuits(
    circuit_of_interest,
    scale_factors=...,
    scale_method=...,
)

# user can now inspect circuits and understand what they look like, and how many there are.
# run circuits and save them into results
results = ...

mitiq.zne.combine_results(
    results,
    circuits,
) # ordering needs to remain the same results/circuits in order for QEM techniques to work correctly.

[jordandsullivan]

Sharing a few ideas here which I have come across in working on other issues:

• CDR calls a method within zne.scaling called fold_gates_at_random. We could take out zne.scaling and zne.inference as common methods
• There is a class already within Calibration called MitigationTechnique. We could pull this out as a class and put it in mitiq.qem and make it the class which all the other methods instantiate from
• Potentially pulling out non-public helper functions and utils from zne.folding
• Maybe change data structure for e.g. zne.folding._valid_gate_names to an enhanced enum

[nathanshammah]

Thanks for the very nice comments @natestemen @jordandsullivan. We should gauge how to fold this approach in a way that doesn't make categorization in the way of usability. If there was a way to implement this more as "tagging" rather than re-classifying functions, maybe I would like it more. That said, really happy to see this move forward as it's important also for composing techniques, #2288.

[jordandsullivan]

Another example that I think wouldn't risk breaking compatibility would be these serial_executor and batched_executor which live in test_pec, but are used in many tests elsewhere and appear to be useful in calling using PEC and DDD more generally.

These functions could be taken out of tests and put in a utilities module, or added as perhaps even added as class methods onto Executor.

[jordandsullivan]

Possibility of taking extrapolate functions out into their own module.

[cosenal]

Converting this to a discussion. We will create a new issue for a proof of concept of this modularization on one of the techniques (e.g. ZNE) with specific use cases in mind.