You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DecompositionGraph can be solved with work wire constraint (#7963)
**Context:**
This is a follow-up to
#7861, updating the
decomposition graph so that it can be solved under a maximum number of
work wires constraint.
**Assumptions**
- The same number of work wires is available to every operator at the
top level of the circuit.
- All work wires will be allocated from this initial pool of wires, no
borrowing algorithmic wires (whatever that means) or reallocation of
wires not yet deallocated.
- If a decomposition rule requests work wires, these wires are kept
until the end of the decomposition. Even if the decomposition rule
deallocates these wires early in its internal implementation, since
there is currently no way to specify this, we must assume that these
wires cannot be used in further decompositions of operators within.
**Algorithm**
Before dynamic wire allocation, work wires are specified as an operator
property, and included in an operator's resource params. Two operators
with different work wire budgets (I use the term work wire budget to
mean how many work wires is available for the decomposition of an
operator) are stored as two separate nodes in the graph. With dynamic
wire allocation, the number of available work wires is no longer an
operator property, so two operators with different work wire budgets
will have identical resource representations. Therefore, we cannot use
`CompressedResourceOp` as graph nodes anymore, because it's now missing
a crucial piece of information.
The first step is to define a `_OperatorNode` class, which contains both
the `CompressedResourceOp` and the number of available work wires
(previously a part of the `CompressedResourceOp`), and use this as nodes
in the graph. The number of work wires available to each operator is
tracked during the graph construction process. Imagine passing a
`work_wires` argument to every operator at the top level of the circuit,
and each decomposition takes the wires that it needs, and pass the rest
of the work wires to every op within.
**Optimizations**
There are a few inefficiencies with this approach:
1. The graph must be constructed with a maximum work wire budget. If it
changes, the entire graph must be reconstructed with a new work wire
budget.
**Solution**: throughout the graph, we track not the number of work
wires available to an operator, but the number of work wires NOT
available to an operator. The top level operators all have
`num_work_wires_not_available=0`, indicating that they have access to
all the available work wires. If a decomposition of a top level operator
uses 2 work wires, then all operators produced from this decomposition
has `num_work_wires_not_available=2`. This allows the graph to be
constructed once and solved multiple times with different work wire
budgets.
2. The number of nodes in the graph grows significantly. Imagine every
operator now comes with a `work_wires` property. Sometimes, two
operators with different work wire budgets do not necessarily need to be
two separate nodes in the graph. For example, an `RX` with 1 work wire
available and an `RX` with 2 work wires available should not be two
separate nodes.
**Solution**: during graph construction, we track not only the number of
work wires available, but also whether any decomposition rules of an
operator, or any operator produced from any of the decompositions,
depend on work wires. Since the graph construction is recursive and
depth-first, when we first encounter an operator, and build the
sub-graph with all of its decompositions, we label this operator node as
either work-wire dependent or not. The next time we encounter the same
operator with a different work wire budget, we create a new node for
this operator only if this operator was previously marked as work-wire
dependent. This significantly reduces the number of nodes.
**Related GitHub Issues:**
[sc-94400]
---------
Co-authored-by: Isaac De Vlugt <[email protected]>
Co-authored-by: Mudit Pandey <[email protected]>
Copy file name to clipboardExpand all lines: doc/releases/changelog-dev.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -255,6 +255,7 @@
255
255
256
256
* With :func:`~.decomposition.enable_graph()`, dynamically allocated wires are now supported in decomposition rules. This provides a smoother overall experience when decomposing operators in a way that requires auxiliary/work wires.
* A :class:`~.decomposition.decomposition_graph.DecompGraphSolution` class is added to store the solution of a decomposition graph. An instance of this class is returned from the `solve` method of the :class:`~.decomposition.decomposition_graph.DecompositionGraph`.
0 commit comments