Simulation, Emulation, and Digital Twins — Operating Quantum Computers

Simulation is not a fallback for teams that cannot access a QPU. It is the control surface for designing experiments, estimating cost, validating compilers, training decoders, and protecting scarce quantum capacity.

A mature quantum organization treats simulators, emulators, and digital twins as production dependencies.

37.1 Simulation levels

Diagram loads as you read

37.1 Simulation levels · Figure 1

View diagram source

flowchart TB
    Idea[Experiment idea] --> Logical[Logical model]
    Logical --> Circuit[Circuit simulation]
    Circuit --> Noise[Noisy device simulation]
    Noise --> Pulse[Pulse or dynamics simulation]
    Pulse --> Control[Control-stack emulation]
    Control --> Facility[Facility digital twin]
    Facility --> QPU[Physical QPU run]

Level	Question
logical model	is the algorithm concept coherent?
circuit simulation	does the circuit implement the intended operation?
noisy simulation	how sensitive is the workload to realistic error?
pulse or dynamics simulation	are control assumptions plausible?
control-stack emulation	will timing and orchestration work?
facility digital twin	can the physical environment support the run?

Qiskit Aer and IBM Quantum documentation cover noisy simulations and noise-model construction; Amazon Braket documents managed simulators and local-mode debugging for hybrid jobs [R68, R69]. These are not only developer conveniences. They are admission-control tools.

37.2 Use simulation to protect QPU time

Diagram loads as you read

37.2 Use simulation to protect QPU time · Figure 2

View diagram source

flowchart TD
    Candidate[Candidate workload] --> Static[Static checks]
    Static --> Sim[Ideal simulation gate]
    Sim --> Noise[Noise sensitivity gate]
    Noise --> Cost[Cost and shot estimate]
    Cost --> QPU{QPU eligible?}
    QPU -- no --> Revise[Revise workload]
    QPU -- yes --> Execute[Execute on QPU]
    Execute --> Update[Update twin]
    Update --> Candidate

QPU time should be spent on experiments that have already passed local validation. A workload that fails under a reasonable noise model should not consume scarce device access unless the goal is explicitly to study that failure.

37.3 Digital twins are not perfect copies

A digital twin is a decision tool, not a claim of perfect fidelity. It should state where it is valid and where it is not.

Diagram loads as you read

37.3 Digital twins are not perfect copies · Figure 3

View diagram source

classDiagram
    class DigitalTwin {
      backend_id
      topology
      calibration_snapshot
      noise_model
      timing_model
      queue_model
      validity_window
    }
    class Experiment {
      circuit_set
      shot_plan
      compiler_version
      mitigation_policy
    }
    class Evidence {
      prediction
      observed_result
      residual
      update_decision
    }
    DigitalTwin --> Experiment
    Experiment --> Evidence
    Evidence --> DigitalTwin

Twin validity record:

Illustrative listing · yaml

digital_twin_validity:
  twin_id: string
  backend_id: string
  calibration_snapshot_id: string
  valid_from: timestamp
  valid_until: timestamp
  supported_circuit_family: string
  unsupported_features:
    - dynamic_branching
    - pulse_level_control
  known_biases:
    - underestimates_readout_crosstalk

37.4 Noise models must be versioned

A noise model without a version is a rumor. The same circuit run against two noise models may produce different conclusions.

Diagram loads as you read

37.4 Noise models must be versioned · Figure 4

View diagram source

flowchart LR
    Calibration[Calibration snapshot] --> NoiseModel[Noise model]
    Backend[Backend topology] --> NoiseModel
    Compiler[Compiler assumptions] --> NoiseModel
    NoiseModel --> Prediction[Predicted distribution]
    QPU[QPU results] --> Residual[Prediction residual]
    Prediction --> Residual
    Residual --> Revise[Revise model]

Minimum fields:

Field	Purpose
calibration snapshot	ties model to measured device state
topology	constrains routing and crosstalk assumptions
basis gates	avoids simulating impossible circuits
error channels	declares what the model can represent
validity window	prevents stale models from controlling decisions
residual history	records where the model failed

37.5 QEC simulation is its own discipline

Fault-tolerant planning introduces detector-error models, syndrome streams, decoders, and logical error curves. Stim focuses on high-performance stabilizer-circuit simulation for QEC-style workloads, and PyMatching provides a minimum-weight perfect-matching decoder interface for graphlike detector-error models [R63, R64].

Diagram loads as you read

37.5 QEC simulation is its own discipline · Figure 5

View diagram source

flowchart TB
    Circuit[QEC circuit] --> DEM[Detector error model]
    DEM --> Samples[Detection-event and logical-observable samples]
    Samples --> Decoder[Decoder]
    Decoder --> Compare[Compare predicted and sampled logical flips]
    Samples --> Compare
    Compare --> Logical[Logical error estimate]
    Logical --> Sweep[Distance and noise sweep]
    Sweep --> Plan[Resource plan]

For each simulated shot, compare the decoder's predicted logical-observable flips with the sampled logical-observable flips. Detection events alone do not reveal whether decoding succeeded. Report the trial count and statistical uncertainty with the resulting logical error rate. [R63] [R64]

QEC simulation outputs:

logical error curves,
decoder latency estimates,
syndrome bandwidth estimates,
sensitivity to correlated errors,
memory versus compute tradeoffs,
code-distance breakpoints.

37.6 Resource estimation links simulation to strategy

Microsoft's Azure Quantum resource estimator documents a workflow for estimating logical and physical resources for fault-tolerant programs [R49]. The important operating move is to connect this style of estimate to portfolio planning, not to treat it as a one-off notebook result.

Diagram loads as you read

37.6 Resource estimation links simulation to strategy · Figure 6

View diagram source

flowchart LR
    Algorithm[Algorithm] --> LogicalProgram[Logical program]
    LogicalProgram --> Estimate[Resource estimate]
    Estimate --> Cost[Cost and runtime model]
    Estimate --> Roadmap[Hardware roadmap dependency]
    Cost --> Portfolio[Portfolio decision]
    Roadmap --> Portfolio

Resource-estimation output should feed:

Consumer	Use
product	decide whether a use case is credible
hardware	identify physical-qubit and error-rate targets
finance	budget capacity and facility investment
security	assess cryptographic timelines
research	prioritize algorithms with plausible resource paths

37.7 CI/CD for quantum experiments

Diagram loads as you read

37.7 CI/CD for quantum experiments · Figure 7

View diagram source

flowchart TD
    PR[Experiment change] --> Lint[QASM/circuit lint]
    Lint --> Deterministic[Deterministic simulator]
    Deterministic --> Noise[Noisy regression]
    Noise --> Cost[Shot and cost budget]
    Cost --> Approval{Within policy?}
    Approval -- no --> Block[Block release]
    Approval -- yes --> Queue[Eligible for hardware]

CI gates should include:

schema validation,
exact simulation for small cases,
known-answer tests,
noisy regression windows,
compiler-diff review,
cost and shot-budget checks,
reproducibility checks,
provenance completeness.

37.8 The twin update loop

Diagram loads as you read

37.8 The twin update loop · Figure 8

View diagram source

sequenceDiagram
    participant Run as QPU run
    participant Store as Artifact store
    participant Twin as Digital twin
    participant Owner as Model owner
    Run->>Store: raw results and telemetry
    Store->>Twin: compare prediction with observation
    Twin->>Owner: residual report
    Owner->>Twin: accept, reject, or adjust model
    Twin->>Store: new twin version

Never update a production twin automatically without recording why. Silent twin drift can make the organization believe its validation pipeline is stable while its assumptions have changed.

Additional technical sources: [R261].