Handle noise models

[nathanshammah]

I propose to consider introducing a framework to define and handle noise models, which could have the benefit of simplifying 'experiments' run by users with simulators, avoid code duplication within executors, and facilitate conversions beyond the intermediate representation of quantum circuits.

It has emerged progressively, also thanks to discussions about Mitiq with different folks (users, researchers, devs), that the quantum error mitigation tasks are mainly composed of two parts: noise characterization and the proper mitigation. So far, it has been taken for granted that the former is quite a crowded space, with some tools that are device-specific or platform-specific, such as in qiskit.ignis and so on, where it may not make too much sense for Mitiq development to go into.

Thus, also in relation with other libraries' formats, it may be useful to help inform the error mitigation techniques available with Mitiq. Mitiq can be thought of as an army Swiss knife of error mitigation, where multiple techniques are applied to the same system or algorithm and compared, such as zero-noise extrapolation, and different extrapolation techniques therein, probabilistic error cancellation, and other ones.

Some sort of noise module could help set up, possibly with the help of a NoiseModel class and similar features, some properties accompanying a given system, in order to exchange information of a given noise model to be extracted, by the various techniques.

The heterogeneity of noise models (color noise spectra in SchWARMA, superoperator-based, etc.) may require to make such options quite flexible and extensible. While this endeavor may be overarching even mitiq's scope and be quite complex, some basic features could be implemented simply and already avoid some duplication in the code base, for example simply facilitating conversions among frameworks, e.g., T1 noise in cirq and in qiskit's density matrix simulators.

[rmlarose]

Was there a specific use case that brought this up?

We agreed quite early that noise would be handled in a platform-specific manner just as circuits are. It's good and interesting to think outside of this, but I think there needs to be more detail.

• Would we still allow multiple circuit types in your proposal?
• What could the proposed representation handle that a general Kraus operator representation like Cirq could not handle?
  • If it's more general than, e.g., Cirq, how do we convert that and use it in the Cirq framework?

Conversions between (unitary) circuits are already nontrivial, I suspect it would be more difficult for noise.

[rmlarose]

Any new thoughts around this @nathanshammah?

[rmlarose]

Closing because I think this is stale / out of scope. @nathanshammah please reopen if this is not the case.