Qiskit / qiskit-fermions / 36866772315

98%

Build Type

push

github

Committed by web-flow

Commit Message

feat: support barrier instructions on FermionicCircuit (#365)

The optimization passes fuse neighboring gates wherever they can, and there was
no way to tell them not to: MergeOrbitalRotations collapses a run of rotations
and MergeSlaterDeterminantPreparation folds an InitializeModes into the rotation
that follows it, with no user-facing escape hatch. A barrier is the standard
Qiskit idiom for that boundary, so re-expose it rather than inventing one.

Using Qiskit's own Barrier, instead of a FermionicGate subclass, is what makes
this small. Both fusion passes key on op-node structure rather than gate type
(collect_runs by name, _immediately_follows over predecessor op nodes), so a
Barrier already splits a run and already blocks a fusion; RelabelModes, count_ops,
draw and decompose likewise already handle it. Only two paths actually broke, and
Barrier becomes the one sanctioned exception to the FermionicGate-only invariant.

The fermion-to-qubit lowering places the barrier on every qubit of each mapped
register it touched, not on the qubits encoding the modes it was placed on. An
F2QLayout relates whole registers and the two sides may differ in size, so mode i
has no per-qubit image in general; spanning the register is correct under any
layout. This also deliberately bypasses map_node_single_register, which returns
per-mode indices and rejects nodes spanning several registers (a default
circ.barrier() spans all of them).

Skipping barriers in the apply-unitary DAG walk keeps barrier-carrying circuits
simulatable, which would otherwise make the feature a trap: a barrier is
unitarily the identity, so it has nothing to contribute to a state vector.

Closes #266

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Coverage Stats

10 of 10 new or added lines in 2 files covered. (100.0%)

1 existing line in 1 file now uncovered.

12147 of 12399 relevant lines covered (97.97%)

525629.46 hits per line