Pam verify bug fixes #192
Pam verify bug fixes #192
Conversation
| @@ -82,10 +82,11 @@ async def run(self, circuit: Circuit, data: PassData) -> None: | |||
| if not subgraph.is_fully_connected(): | |||
| raise RuntimeError('Cannot route circuit on disconnected qudits.') | |||
|
|
|||
| pi = data.initial_mapping | |||
| pi = [i for i in range(circuit.num_qudits)] | |||
There was a problem hiding this comment.
pi is the permutation of the initial mapping we are solving for? So it gets modified by the forward and backwards passes? Might be helpful to comment this
There was a problem hiding this comment.
Layout is also called after ApplyPlacement correct? So what good does changing the placement do here?
There was a problem hiding this comment.
Oh wait, ok, in the test_sabre I see that ApplyPlacement is called last, do we need to change this in other workflows?
There was a problem hiding this comment.
Yeah, good questions. A few points:
- The initial and final mappings are always with respect to the original circuit (mapping from original to current), so until the circuit gets modified (ApplyPlacement, Routing), they shouldn't be changed.
- The current placement tracks the current placement of the current
circuitqudits tomodelqudits, so layout and routing need to start with this information - pi always starts as [0, 1, 2, 3, ...], because the placement info is encoded into the
data.connectivitycall, the actual coupling graph is permuted there to account for it
Yes, ApplyPlacement should be called after SABRE layout and routing. What other workflows are you referring to?
Also, Rather than running GreedyPlacement, another valid placement strategy would be to ApplyPlacement before mapping to "extend" the circuit to the model size, then running layout and hoping SABRE finds a good placement. This is sort of the strategy we take with PAM. We are definitely lacking in the placement department tho
There was a problem hiding this comment.
Oh ok, so even before we were calling ApplyPlacement before and after PAMLayout and PAMRouting.
| else: | ||
| pi = [i for i in range(circuit.num_qudits)] | ||
|
|
||
| pi = [i for i in range(circuit.num_qudits)] |
There was a problem hiding this comment.
So is the initial mapping always going to 0,1,2,3,... and all of the actual mapping information is in placement? Do we even need initial mapping anymore?
There was a problem hiding this comment.
Yeah, the initial mapping gets updated when we actually apply the placement. Until then, the circuit's input qubit ordering actually doesn't change
| @@ -38,12 +39,17 @@ def test_simple(compiler: Compiler) -> None: | |||
| GreedyPlacementPass(), | |||
| GeneralizedSabreLayoutPass(), | |||
| GeneralizedSabreRoutingPass(), | |||
| ApplyPlacement(), | |||
| ] | |||
|
|
|||
| cc, data = compiler.compile(circuit, workflow, True) | |||
| pi = data['initial_mapping'] | |||
| pf = data['final_mapping'] | |||
| PI = PermutationMatrix.from_qubit_location(5, pi) | |||
| PF = PermutationMatrix.from_qubit_location(5, pf) | |||
There was a problem hiding this comment.
How did some qudits become inactive? Not sure I understand
There was a problem hiding this comment.
When you apply the placement, the logical, input circuit size is extended to fit the physical, output machine model. So in this workflow, this means a good portion of them won't be used.
| @@ -82,10 +82,11 @@ async def run(self, circuit: Circuit, data: PassData) -> None: | |||
| if not subgraph.is_fully_connected(): | |||
| raise RuntimeError('Cannot route circuit on disconnected qudits.') | |||
|
|
|||
| pi = data.initial_mapping | |||
| pi = [i for i in range(circuit.num_qudits)] | |||
There was a problem hiding this comment.
Oh ok, so even before we were calling ApplyPlacement before and after PAMLayout and PAMRouting.
No description provided.