One or more of the following people are relevant to this code:

• @Qiskit/terra-core

I ran an asv comparison (since the benchmarks needed to change to show the improvement here it's not a direct comparison) and this is showing a improvement of the previous twirling benchmark written in python from taking 254±4ms to 6.38±0.3ms with the twirl_circuit function in this PR:

| Change   | Before [54fe09b2] <lint_incr_latest~1>   | After [33b4bde2] <twirl-for-paul>   |   Ratio | Benchmark (Parameter)                                 |
|----------|------------------------------------------|-------------------------------------|---------|-------------------------------------------------------|
| x        | 254±4ms                                  | 6.38±0.3ms                          |    0.03 | manipulate.TestCircuitManipulate.time_DTC100_twirling |

The "Change" X is because asv detected the benchmark changed and the results may not be comparable.

Pull Request Test Coverage Report for Build 11479816454

Details

• 398 of 410 (97.07%) changed or added relevant lines in 8 files are covered.
• 13 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.05%) to 88.731%

Totals
Change from base Build 11476806715:	0.05%
Covered Lines:	75293
Relevant Lines:	84855

💛 - Coveralls

@jakelishman PT is not something that fits into our current circuit transformation pipelines. It basically has to be a middle step between two passmanagers. One to map to HW, followed by PT, and then another that does cleanup of the 1Q gates and casts back into the HW basis set (usually over a set of circuits generated by PT). This is one of the motivations for #13326

If it doesn't really fit in Qiskit's models right now (and I agree, it doesn't particularly), then it feels like we're trying to merge such a function into the core library that'll never really fit in. If we're asking users to start using this now as part of the core library, they're going to find it far more awkward in the future if we say "actually, don't do this anymore and instead use this transpiler pass". That'll alienate our users, who already don't like the amount of changes we make.

Making the compiler multi-in, multi-out is interesting, and something we already do internally in the IBM backends (I wrote it), but it's hugely fragile in the current pass-manager system, and it's tricky to make it better without compromising performance. We can get away with it in the backends because there's far tighter control over what passes are in the pipelines and when a pass might trigger such fan-out behaviour.

We'll have a chance to do that better when we move more of the pass-manager infrastructure into Rust; we'll have more opportunities to make prior state in the PropertySet copy-on-write, rather than potentially eagerly copying large amounts of data at the point of fan-out, or being smarter about invalidating stale data in the PropertySet. Both of those would make an internal IR that's fan-out aware easier to make safe (the main concern) and performant (the next most important), but we're not there yet.

If this is only ever meant to be an intermediate-term thing, I'm most worried about how we'll present this narratively to users, especially when we need to shift them to something else.

On another narrative note: are we intending to present twirling as something that all users will need to do, and not the domain of a primitive implementer? Adding twirling as something we do on a single circuit, outside the context of the estimator observables and potential lightcone analysis might accidentally cause primitives implementations to have to do more work and have the user do more work to reconstruct their final results, since now a user might well end up passing a much larger broadcast matrix as their estimator inputs.

If it doesn't really fit in Qiskit's models right now (and I agree, it doesn't particularly), then it feels like we're trying to merge such a function into the core library that'll never really fit in

But this is equiv to kicking the can down the road to a undetermined time frame, and features that have value will likely never see the light of day, waiting for the ideal conditions for implementation. Perhaps latter a pass can just call this same function that remains exposed to users as well, who knows.

Twirling has value for Qiskit outside of the IBM primitives. Note that no other provider outside of IBM has a primitives interface that supports twirling. So there is value to other HW providers, and in addition there is value for users who want to see (and perhaps save) the exact circuits they are executing.

I am not sure there is any major downside on the primitives side save for perhaps extra work to be done that otherwise didn't need to be done, e.g. twirl twice if that was an automatic option. However, I am pretty sure there is an option for that.

A later pass can never call this function, because it's defined on the wrong types of inputs. Besides, that doesn't help the user, who would still have to switch what they're doing.

Yes, I am proposing step back and think through what a joined-up interface to Qiskit from the user right through to hardware looks like, rather than us adding things in that implement one overly-specific microbenchmark more efficiently. We can't really claim either performance and stability if that's how we go about additions to the core library. I'm not saying twirling isn't important, or even that we shouldn't put it in right now, I'm saying that software engineering is more than just throwing interfaces at a wall to see what sticks. That works well in the early days of open-source work, but not for a product whose guiding principles are meant to be stability, performance and utility.

For example, if the purpose is that this will always be used as a post-compilation pipeline where it's immediately followed by an Optimize1qGates pass, then the interface of this function probably should change in some manner that allows the twirling itself to inline the optimal 1q gate sequence for a particular backend. That will be more performant than this current implementation, because it won't need an additional transpiler pass to come later. Using the current interface over optimises for the microbenchmark, which isn't representative of the work that actually needs to be done - it elevates a subroutine of one particular (inefficient) choice of implementation to be a standard we should hit.

I am not sure there is any major downside on the primitives side save for perhaps extra work to be done that otherwise didn't need to be done.

If we promote that you should do your twirling from within Qiskit, this takes away important information that a primitives implementation can use to reduce the number of QPU hours and shot-loops necessary, because now the user is supplying many different Estimator inputs (one per twirl). That means that the same light-cone analysis now has to be done for each separate input, whereas with twirling done in the primitive implementations, it can be done before the twirling is. If the primitive is doing any other additional error learning or error mitigation, it'll likely now end up doing the same learning for each of the different input circuits, which could severely impact the number of QPU hours spent. It also means that the user has more data come back that they now have to merge together, which means more data the user has to send over the wire to us, and more data we have to send over the wire back to the user.

There are ways around these problems, but again, they mean stepping back and thinking through a joined-up interface, in conjunction with implementers of the primitives. For example, my problem of knowing when two multi-qubit potentially parametric blocks implement the same operation can be eased by additional boxes with annotations, which is something I'm currently in active discussions with the primitives teams about. However, if that's the way we go, then this function needs to be designed in such a way that it outputs those boxes, and we need to build the interface around that.

I do totally agree that this could have utility outside IBM primitives implementations as well, but if so, we need to really think through how those other users should use this, and how we'll design our interfaces so that users will, by default and by using the most natural forms, get the experience that is most performant and most pleasant end-to-end.

I guess if you want to future proof it a bit then you should implement as a transpiler pass that only does a single twirl. In that case the current usage would require two pass managers still, but the input to the second would be something like post_pm.run([qc]*num_twirls). Then you could probably extend it to one-in many-out in a fairly seamless manner. That would also leave the 1Q optimization separate, which is more in the spirit of the passes doing basic things

This is just why I wanted to talk about things - if the intention of this function is to just be a short-term, low-level post-transpile thing, then we can still have a function like what's currently implemented, it just means we tweak the interface so it's more efficient, and we need to take care about how we teach users about it.

If I'm understanding right, then the two proposed use cases for this function are:

• illustrate what Pauli twirling does
• multiply twirl a post-compilation circuit, without concern for how efficiently that will be executable on a primitive (possibly because it'll be given to a non-primitive direct-access BackendV2.run, which might not be an IBM one).

In that case, maybe we work in an interface where we have an optional argument that's either None or an instance of Optimize1qDecomposition. If we're given the optimiser, the twirler can run along the 1q runs ahead of each twirled gate, then give that run and the twirling gate to the optimiser, and inline the output of that. That allows both use cases: for use case one, you don't pass the optimiser, and for use case two, you do. In the second use case, we're now more efficient than anything else proposed here, because there's no need for a follow-up passmanager at all.

Also if that's the case, then that impacts the interface promises we should make about the output circuit w.r.t. propagating any stored TranspileLayout, the register structure, and so on. Again, easy enough to do, we just needed to really hone in on what the purpose and use-case of the function is in order to know that.

The concerns about this interacting poorly in general with how efficient Estimators will want to work are still there, but that can generally be handled by documentation. That of course wouldn't be the case if this was intended to be used before input to a primitive, but that's what I want to make sure we're thinking about.

The workflow is the following:

1. Transpile circuit as best as possible

2. Take this best circuit and generate num_twirls versions that have been twirled, and then do a 1Q cleanup on the return set

3. Execute (perhaps with things like DD added as well after twirling) using whatever execution pipeline a provider has

4. Aggregate counts and compute desired quantities of interest.

The twirling could be a function, or a TransformationPass with the latter generating only a single twirl at the moment. Then one could combine the 1Q optimization pass in a post_pm as done above and get the desired output.

Step three is the big question to me: is this not something that narratively we promote is what a primitives implementer might do for you? How does adding this function interact with that? Can you expand on why you have to do this manually, when this is something that IBM primitives definitely can do?

Knowing your step 2 is important, because then we can make the function better - having "twirl" be a standalone step isn't necessarily even the best interface for your workflow, because you have to do a full 1q post-optimize, while we can do that more efficiently on-the-fly (since 1q optimisation is pretty simple and a peephole optimisation).

I'd like to know more about what other users' use-cases for manual twirling are - you're presenting one use case, but it might not be the only reason people are twirling themselves, and I wouldn't want the interface to get in the way of that. I know that there's a few people out there who've written things approximately similar to what's here, but I don't know for what purposes they've done that.

I am not sure that Qiskit has to promote anything that a singular primitive does as its preferred workflow. However, a quick glance at the Qiskit docs shows only Runtime examples, so perhaps Qiskit SDK IS now promoting a singular providers interface for execution.

That being said, there are several reasons why one would like to have circuits in hand. 1) Reproducibility - I want to run exactly the same circuits over again. 2) Time saving - why waste time repeatedly twirling on every call to a primitive. 3) I want to run twirled circuits on something other than IBM hardware. 4) I want to mix error suppression techniques in a manner not available within a primitive.

If making a function version, as done here, then sure one can combine the steps. The twirling would not be explicitly clear, but it would be there logically and in a form better suited for further manipulation or execution.