Qiskit / qiskit-fermions / 30071413551

98%

push

github

fix(transpiler): compensate JW Z-string for interleaved peeled modes in Slater synthesis (#206)

The peeling optimization in GivensDecompositionSlaterDeterminantSynthesis
prepared the wrong Slater determinant whenever a peeled unit-orbital sat
between two kept mixing modes.

The reduced Givens sweep emits rotations adjacent in reduced-local (kept-mode)
indexing, but the kept_modes remap can place a rotation's physical endpoints
across one or more peeled modes -- yielding an XXPlusYYGate on physically
non-adjacent qubits. The framework relies on a nearest-neighbor XXPlusYYGate
being the correct Jordan-Wigner fermionic hop with no explicit Z-string; a
non-adjacent gate omits the Z-string over the intervening modes. Since every
peeled mode is an occupied unit-orbital, each one strictly between the
endpoints contributes a JW sign, so an odd number of them flips the hop's
sign and corrupts the prepared state (e.g. overlap 0.0784 instead of 1.0).

Fold that sign back in: for each emitted rotation, count the peeled modes
strictly between the physical endpoints and set the sign of the XXPlusYYGate
phase's pi/2 offset from that parity (-pi/2 for even, +pi/2 for odd -- the two
differ by pi, and the gate is 2pi-periodic in its phase). This adds zero gates
and preserves the full peeling benefit. Only peeled modes need counting -- any
kept mode between the endpoints is itself swept, so its Z-string is already
carried implicitly by the nearest-neighbor chain in reduced-local space.

The existing Rust oracle (reconstruct_slater) reconstructs the single-particle
orbital-coefficient matrix and is blind to fermionic parity, so it could not
catch this. The regression tests therefore compare the synthesized statevector
against the faithful InitializeModes + OrbitalRotation reference (the trusted
square path never peels, so it is Z-string-correct): an odd-parity interleaved
repro, an even-parity guard proving the compensation stays inert, and a seeded
randomized sweep acr... (continued)

3 of 3 new or added lines in 1 file covered. (100.0%)

9921 of 10156 relevant lines covered (97.69%)

324.7 hits per line