Running the quantum and classical workflows

A reproducible quantum experiment is a pipeline, not a single API call. The circuit, simulator, compiler, backend, timing definition and analysis target all have to remain connected. This repository implements that pipeline in stages that can be checked independently.

Stage 1: freeze the mathematical instance

The QASM file is the experiment’s source of truth. A manifest records its hash, expected width, gate structure and topology. Before simulation or hardware execution, run:

python scripts/random_graph_sampling_runner.py inspect
python scripts/random_graph_sampling_runner.py validate

This catches accidental edits, parser differences and topology changes. Reproducibility starts by proving which circuit is being discussed.

Stage 2: establish exact small anchors

Run induced circuits small enough for an exact statevector. These anchors answer basic questions:

  • Does Qiskit parse the gate sequence correctly?
  • Does an independent simulator produce the same state?
  • Does measurement return bit strings in the expected qubit order?
  • Does an MPS agree when its bond dimension is large enough?

The repository’s smoke test automates these checks. Because it deletes gates crossing the selected interval, it validates software and local structure, not the full circuit’s marginal distribution.

Stage 3: define the classical task before timing it

“Classical simulation” can mean several different outputs:

Method Natural output Main limitation
Statevector Exact amplitudes and samples Memory grows exponentially
MPS Approximate state and samples Accuracy depends on bond dimension
Extended stabilizer Approximate non-Clifford sampling Cost grows with magic and requested accuracy
Majorana propagation Selected observables Not a full-distribution sampler

A fair benchmark must predeclare whether the target is a bit-string sample, a probability, a parity observable or a fidelity estimate. It must also define an error tolerance. Timing different outputs without this contract produces a large number but not a scientific speed comparison.

Stage 4: plan and validate hardware without executing

The networked runner separates read-only and mutating operations:

  1. probe finds a compatible backend;
  2. plan validates the source and constructs a portable payload;
  3. validate checks provider compatibility without running the quantum circuit;
  4. submit requires an explicit hardware acknowledgement;
  5. status and retrieve can only read an existing action.
python scripts/random_graph_sampling_hardware_runner.py plan \
  --mode shallow-bare \
  --entangling-layers 4 \
  --shots 256 \
  --output results/random_graph_sampling/plan.json \
  --qasm-output results/random_graph_sampling/plan.qasm

Start with a shallow width test, inspect the compiled circuit, and only then choose the explicit full-bare mode. This prevents a transport or layout problem from consuming a large hardware allocation.

Stage 5: keep timing layers separate

Quantum execution time, provider running time, queue time and end-to-end wall time answer different operational questions. The same applies classically: state construction, sampling and observable evaluation are separate costs. Reports should preserve these layers instead of choosing whichever produces the most dramatic ratio.

Stage 6: retrieve immutable evidence

A completed run is linked back to the validated plan through circuit fingerprints and provider identifiers. The analysis then produces compact public summaries while keeping large raw payloads and credentials out of the website. This makes the result auditable without turning the article into a dump of receipts.

Part 7 uses this workflow to state the project’s actual conclusion in a few numbers and, more importantly, to identify the experiment that would turn the candidate into a quality-matched comparison.