Add twirling to PEC

[purva-thakre]

Has there been a discussion about how to introduce twirling to PEC ?

I see this task was added as optional. If added, I believe there needs to be a twirling set based on the type of twirling specified. eg. Pauli Twirling etc.

[andreamari]

Thanks @purva-thakre, this is a very good point and I almost forgot that twirling was in the PEC project that you linked!
It was added as an "optional" enhancement of PEC but actually it could be nice self-contained module of Mitiq.

Twirling is a non-trivial topic and before jumping into a code implementation I think we need a bit of planning. For example, I think we should:

1. Determine 1 or 2 papers to use as a reference. There are many twirling methods and we need to understand what are the most appropriate for Mitiq. Among different options, I would prefer simple twirling methods and solutions which are easy to implement/maintain in a multi-platform scenario.

2. Understand if twirling can be really considered as an independent pre-processing step which can be independently applied before any error mitigation method (e.g., ZNE, PEC). If this is the case (I hope so!) it would be great since the integration with the rest of Mitiq would be much easier. E.g. one could imagine a simple workflow like this:

twirled_executor = mitiq.twirling.twirl_executor(executor, twirling_group="pauli")
mitigated_executor_one = mitiq.zne.mitigate_executor(twirled_executor)

[purva-thakre]

@andreamari Deleted my previous comment because I misinterpreted some results from the linked papers. Here's a link that gives a rough outline of what could be done.

[andreamari]

Hi @purva-thakre, thanks for the shared document!

I think I need more time to read and understand the papers that you mention but this is my first impression. Using the reduced set looks promising for increasing the efficiency but it seems to require some non-trivial analysis of the noise channel(s) and processing of this information (you sketched many required functions and tools). I wonder if it is not better to start with the easier twirling over the full set of Paulis (i.e. what you mention at the bottom of the document) and, maybe, as a second future step we could focus on improving the efficiency.

[purva-thakre]

From Mitiq meeting : Both full and reduced twirling are constrained by the fact that the error representation should be known. The error basis is converted to Pauli basis before either type of twirling. What error types could be assumed when error operators are unknown ?

[nathanshammah]

Since Milestone 11 is dedicated to reviewing code contributions from the community in general, I'll add this issue to the Milestone. Probably finding some time in our calendars to speak could help too?

[nathanshammah]

As discussed in Friday 12th Mitiq development meeting, this issue is big enough to require potentially a separate milestone and code design document (e.g., MEP).

[nathanshammah]

@purva-thakre are you going to add back the MEP on twirling?

[purva-thakre]

@nathanshammah Yes, right after I figure out a way to undo the changes that do not belong to this PR.

[nathanshammah]

Since the PR is contained in just one file (the .md MEP one), maybe the easiest thing is to do a git rebase and then create a new branch with the file for a new PR.

[nathanshammah]

Closing this issue at the moment as the topic is included in the MEP in #611, we can discuss/contribute there. Feel free to reopen if needed.

[purva-thakre]

Reopening this because previously linked MEP was not well thought out.

[github-actions]

This issue had no activity for 2 months, and will be closed in one week unless there is new activity. Cheers!

[purva-thakre]

no, don't close

[github-actions]

This issue had no activity for 2 months, and will be closed in one week unless there is new activity. Cheers!

[github-actions]

This issue had no activity for 4 months, and will be closed in 2 weeks unless there is new activity. Cheers!

[natestemen]

@purva-thakre I think we can close this now, right?