Skip to content

pecos-neo: SkipGate on a batched two-qubit command suppresses every pair, not just the leaked one #807

Description

@ciaranra

Summary

In pecos-neo, a noise channel's SkipGate response suppresses the whole GateCommand. When a two-qubit command carries several pairs, one leaked pair suppresses every pair in the command, including healthy ones.

How batched commands reach the runner

CommandBuilder emits one command per pair, so builder-generated queues are unaffected. The engines adapter does not split: byte_message_to_command_queue in exp/pecos-neo/src/adapter.rs converts a multi-pair core Gate through GateCommand::try_from(gate), keeping all qubits in one command. Anything arriving via ByteMessage (engines, QASM, PHIR, Selene traces) can therefore hand the runner a 4-, 6-, ... qubit CX.

What was tried and rejected

While fixing the per-pair fault draws (#791, #792), splitting the command into per-pair dispatch inside CircuitRunner::execute_queue_command / execute_gate was implemented and then reverted: it changes what batch-sensitive channels observe. With four active qubits, X(0), X(2), guaranteed global crosstalk leakage, and CX[(0,1),(2,3)], the second target's measurement flipped, because crosstalk treated the other pair's qubits as spectators and leaked them before their own gate ran, and CorrelatedNoiseChannel reset its state between pairs.

The channel-level fixes (TwoQubitChannel::handle_after_gate and PerGatePauliChannel::apply_after_gate now draw per pair) are in place; only suppression remains whole-command.

Expected

SkipGate (and LeakageChannel's before-gate suppression) applies to the pair that triggered it. The other pairs execute and receive their own after-gate noise. Batch-sensitive channels (crosstalk, correlated, idle) still see the whole command as one event.

Two shapes to consider: a per-pair suppression mask in NoiseResponse that the runner applies when executing a batched command, or having the adapter split commands and giving batch-sensitive channels a tick-level view instead of a command-level one. The first is local; the second is a wider design change.

Provenance

Found during #791/#792 by an independent review arm that reproduced the crosstalk change by execution.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingrustPull requests that update rust codeseverity:mediumDegraded or awkward behavior with a workaround

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions