Implementing Clifford data regression within Mitiq

[L-P-B]

Pre-Request Checklist I am running the latest version of mitiq I checked to make sure that this feature has not already been requested

Issue Description Clifford data regression (CDR) and variable noise Clifford data regression (vnCDR) have recently been shown to outperform zero-noise extrapolation in mitigating noise for observables of interest. I propose that these methods be implemented within the mitiq package.

Both CDR and vnCDR are both learning based mitigation methods, where circuits composed of predominantly Clifford gates (which are therefore possible to evaluate efficiently) are used to construct a training set consisting of noisy and exact data, from the quantum device and classical evaluation respectively. This set of data can then be use to train and ansatz mapping results from noisy-> exact data. The trained ansatz can then be applied on some circuit of interest which is not possible to evaluate classically.

See - (CDR): https://arxiv.org/abs/2005.10189 and (vnCDR): https://arxiv.org/abs/2011.01157

Proposed Solution In order to implement these methods some new features need to be included within Mitiq, the first things that come to mind are:

• A function/class that constructs the training set of mainly Clifford circuits given some circuit of interest (can be constructed in many different ways).
• Some near Clifford simulator that can be used to evaluate these training circuits efficiently.
• A regression function to train an ansatz on the training data to then be applied to the circuit of interest.

The current unitary folding techniques can be used to increase noise in the vnCDR method.

At a high level, all of these features can be combined into 1 (or 2) new functions: 'execute_with_vnCDR' ('execute_with_CDR'), [note: CDR can be contained within the vnCDR function as one execute CDR using the same data obtained by vnCDR.]

[andreamari]

As we discussed, we can give low priority to implementation of the near Clifford simulator. This for two main reasons:

1. It can be replaced by a brute-force (non-near-Clifford) simulator for testing the technique on small circuits.
2. The user could define a near_clifford_executor function in same way they already do for the hardware executor function. So, I am actually not sure if it is a good idea to have a simulator at all inside Mitiq.

[rmlarose]

I agree its lower priority but disagree on (2). If there is a feature I want to use but it requires me to hand code a near-Clifford simulator, I'm simply not going to use that feature. (Not saying we should necessarily write our own near-Clifford simulator, but we certainly should provide a tool to do this and not make it a requirement. )

[L-P-B]

Are there weekly meetings that I should join?

Best,

Max

On Thu, 17 Dec 2020 at 18:40, Ryan LaRose notifications@github.com wrote:

I agree its lower priority but disagree on (2). If there is a feature I want to use but it requires me to hand code a near-Clifford simulator, I'm simply not going to use that feature. (Not saying we should necessarily write our own near-Clifford simulator, but we certainly should provide a tool to do this and not make it a requirement. )

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/unitaryfund/mitiq/issues/477#issuecomment-747623612, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHWV7KHV2PM52YC2L5KBSYTSVJGAXANCNFSM4UU7HRBQ .

[andreamari]

Hi @L-P-B, we usually have public meetings on Discord every Friday (#community-call voice channel usually at 9am PST). However, because of Holidays, the next one is probably on January 8, 2021. Anyway feel free to ask questions on the Discord chat or here.

[rmlarose]

Closing as this is partially done and we have more specific issues for what remains, namely #710, #711, and #712.