RFC for Boxes #1
Conversation
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
0022-circuit-block.md
Outdated
| - They use (a convenience method built around) a new transpiler pass that collects circuit's gates into blocks, with the ability of specifying different collection strategies. | ||
| - They submit their job. | ||
| 2. The workflow for power users: | ||
| - Users initialize a `QuantumCircuit` adding blocks manually as they wish. |
There was a problem hiding this comment.
What does as they wish mean specifically? For a regular user, the workflow implies the blocks get added after the circuit is mapped to an ISA circuit. Is the idea that a power user could specify the circuit and blocks at the ISA level or block the circuit before the mapping?
There was a problem hiding this comment.
Yes, exactly.
It's not hard to directly write a circuit that complies directly with ISA requirements, you just need to use the right gates and have the correct coupling map in front of you. Power users can do this, or also, apply their own passes to the sub-circuits and then inserting them into the bigger circuit as blocks
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
…nto circuit-block
0022-circuit-block.md
Outdated
|
|
||
| ## `Block`: Definition and use cases | ||
|
|
||
| A `Block` represents an isolated block of `CircuitInstruction`s that is treated as a single unit in the context of twirling and mitigation. In more detail, when a circuit contains blocks: |
There was a problem hiding this comment.
| A `Block` represents an isolated block of `CircuitInstruction`s that is treated as a single unit in the context of twirling and mitigation. In more detail, when a circuit contains blocks: | |
| A `Block` represents an isolated block of `CircuitInstruction`s that is treated as a single unit in the context of twirling and mitigation. A circuit executor, such as the runtime primitives, should implement all like blocks acting on the same set of qubits in the same way. In more detail, when a circuit contains blocks: |
0022-circuit-block.md
Outdated
| ## `Block`: Definition and use cases | ||
|
|
||
| A `Block` represents an isolated block of `CircuitInstruction`s that is treated as a single unit in the context of twirling and mitigation. In more detail, when a circuit contains blocks: | ||
| - Twirling targets the blocks and ignores all the circuit instructions that live outside of the blocks. |
There was a problem hiding this comment.
However, the twirling interpreter responsible for execution will need to look at things outside the block and do things like single-qubit gate merging, no?
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
> Co-authored-by: Samuele Ferracin <sam.ferracin@ibm.com>
| @@ -272,21 +272,58 @@ class BackendV3: | |||
| This might naturally extend to such a `BackendV3` providing the additional information that is needed for Qiskit SDK to safely transpile entire sampler and estimator pubs; the compilation of a pub _also_ implies further processing will be done by a quantum computer, just like an annotation remaining in a single circuit. | |||
|
|
|||
|
|
|||
| ## Case study: twirling, noise learning, and mitigation with `qiskit-ibm-runtime` | |||
| ## Case study: twirling, noise learning, and mitigation | |||
There was a problem hiding this comment.
Maybe out of scope but could also talk about how PEA can be represented in this way? That is, emitting a Pauli error with rates multiplied by num_amplifications?
I remember there was some work @SamFerracin did where only a subset of entangling gates were amplified, this could be a way of specifying said subset (though deterministically as opposed to randomized here).
Co-authored-by: joshuasn <53916441+joshuasn@users.noreply.github.com>
…nto circuit-block
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
…nto circuit-block
0022-circuit-block.md
Outdated
| @abstractmethod | ||
| def sample(self, sampler_pub_likes) -> SamplerJob: ... | ||
| @abstractmethod | ||
| def estimate(self, estimator_pub_likes) -> EstimatorJob: ... |
There was a problem hiding this comment.
My biggest concern here is perceived whiplash from users who were migrated away from backend.run to separate primitive classes, only to be ushered back to backend execution methods.
I do agree, however, that having the correspondence QuantumComputer feature set <-> Backend, QPU feature set<-> Target is nice and clean.
There was a problem hiding this comment.
I need to remove this bit that mentions mixing-in of the "execution" methods (sample, estimate) - it was part of what helped me structure things in my mind on the first pass, but leaving the text there is just going to be a huge distraction from the RFC. As you say, we can't actually put the execution methods back onto the Backend class unless we wanted to alienate every user who just migrated.
| * a group of non-overlapping (but potentially nested) circuit instructions, | ||
| * which introduces a new scope for declared variables, | ||
| * which can have internal scheduling within itself, but is scheduled atomically within the circuit (i.e. all wires touched within the box are delayed to match the critical path length), | ||
| * which forbids optimisations from crossing from outside to inside the box or vice-versa, but permits optimisations across the entire box, |
There was a problem hiding this comment.
The regular and power workflows below assume that optimization happens before the assignment of boxes.
There was a problem hiding this comment.
Although we want the boxes for twirling and mitigation, this RFC defines them more generally, as a core generic construct in qiskit. So the workflows below are specific to the use-case of twirling, but the construct itself needs to have this sort of generic interaction with the transpiler well-defined.
add section about dynamical decoupling with boxes
|
I'll come back and fix up all the bits that were waiting for me while I was out tomorrow morning. |
These were hypothetical anyway, and should not be part of a new `BackendV3`; there is no necessity, and it would be unacceptable API whiplash for users anyway.
|
I've now responded to Ian's review in #5. |
Co-authored-by: Ian Hincks <ian.hincks@gmail.com>
Respond to Ian's review
|
From my side, I'm happy to open this to a wider audience. |
No description provided.