Add loss policies to NoiseConfig to express different kinds of behavior on lost qubits#3302
Add loss policies to NoiseConfig to express different kinds of behavior on lost qubits#3302orpuente-MS wants to merge 21 commits into
NoiseConfig to express different kinds of behavior on lost qubits#3302Conversation
orpuente-MS
requested review from
billti,
idavis,
minestarks and
swernli
as code owners
| @pytest.mark.parametrize("sim_type", LOSS_POLICY_SIM_TYPES) | ||
| def test_on_loss_swap_skip_keeps_state_but_swaps_loss_flag(sim_type): | ||
| # Overriding `swap.on_loss` to SKIP skips the SWAP unitary, but the loss | ||
| # flag is still exchanged. qs[0] keeps its reset |0> and qs[1] becomes lost. |
There was a problem hiding this comment.
This one is interesting. Worth discussing more. Seems odd you would skip the unitary (which swaps the state) but still swap which is lost. Not sure if that would be physically possible.
There was a problem hiding this comment.
Mmh, maybe the behavior here should be:
SKIPdoesn't apply the unitary nor exchanges loss flags.APPLY_ANYWAYapplies the unitary and exchanges the loss flags.
There was a problem hiding this comment.
I came up with a simple principle: no matter the policy, we should never recover a qubit that was lost. Following this rule of thumb, I created the following table describing the behavior of SWAP under each policy:
| Policy | apply unitary | exchange loss flags | extra behavior |
|---|---|---|---|
| SKIP | no | no | no |
| PROPAGATE | no | no | loose other qubit |
| DEGRADE | no | no | no |
| RESIDUAL_S_DAGGER | yes | yes | apply S_ADJ to survivor |
| APPLY_ANYWAY | yes | yes | no |
There was a problem hiding this comment.
That table doesn't look right. You do apply the unitary for DEGRADE I thought, just to the other qubit. And 'exchange loss flags' being 'yes' on RESIDUAL_S_DAGGER seems wrong.
There was a problem hiding this comment.
Degrade is meant to express the current behavior of Rxx, Ryy, and Rzz in our simulators, and doesn't make much sense for CX, CY, CZ, or SWAP. For example, what is the degradation of physically swapping two qubits in a neutral atom machine? Or what is the degradation of virtually relabeling two qubits?
About RESIDUAL_S_DAGGER, if we apply the unitary, we are changing the state of the two qubits in the simulator; if we don't swap the loss flags after that, we now have access to the state of a lost qubit, which doesn't seem right.
… remaining qubits
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| // 3. An exchange of information by doing three CX. | ||
| // | ||
| // This method is concerned with the kinds (1) and (2), since (3) | ||
| // gets decomposed into other instructions before making it to the simulator. |
There was a problem hiding this comment.
We should definitely doc these assumption, else I can see the behavior/assumptions being confusing to some users.
| self.state.apply_permutation(&[1, 0], &[q1, q2]); | ||
| self.residual_s_dagger(lost_qubit); | ||
| self.loss.swap(q1, q2); | ||
| } |
There was a problem hiding this comment.
Should it still also apply the swap if the loss policy is ResidualSDagger and not ApplyAnyway?
There was a problem hiding this comment.
In this case I think it makes sense. I don't see any reason why a relabel or physical exchange of atoms would completely skip because one of the qubits is lost.
3 participants
With this change, users are able to specify how gates should behave if at least one of their qubit operands is lost. Below is a comprehensive example, showing all 5 loss policies.