Part IV. Protocols and Algorithms · Chapter 34
Hamiltonian Simulation
Simulating quantum dynamics is the oldest and most natural job proposed for a quantum computer. This chapter turns that intuition into an auditable engineering question: which Hamiltonian, which observable, which precision, and what will the run actually cost?
In this chapter 9 sections
Reader question. What does it mean to simulate a quantum Hamiltonian, and which parameters determine the circuit cost and accuracy?
Given a Hamiltonian H, evolution time t, input state, and error tolerance ε, the task is to approximate e^{-iHt}; cost depends on structure, norm, decomposition method, time, precision, state preparation, and measured observable, not merely the number of simulated particles.
- This chapter does not treat all chemistry as Hamiltonian simulation or promise application value from asymptotic simulation complexity alone.
- It does not compare every modern simulation algorithm or publish unsourced resource estimates.
Specify the evolution target
Define H, t, input, observable, and error metric.
Hamiltonian simulation asks a quantum computer to reproduce the time evolution of a quantum system; a molecule, a material, a field theory reduced to a lattice. The idea predates most of quantum computing: nature already computes this evolution, so a controllable quantum device should be able to as well, without paying the classical cost of tracking an exponentially large state.
That intuition is sound, and it is also where rigor usually stops. Representing a system "naturally" does not tell you how many qubits the encoding needs, how deep the circuit runs, or how many measurements the answer requires. Those numbers decide whether a given simulation is a product, a research program, or a fantasy. A claim that cannot state them is not yet an engineering claim.
So the central question is never "can quantum computers simulate molecules?" It is always: which Hamiltonian, which observable, which precision, which runtime, under which hardware assumptions?
Evidence boundary. Quantum simulation targets unitary evolution generated by a Hamiltonian. [Richard P. Feynman] [Seth Lloyd]
One Pauli Hamiltonian is exactly solvable
Derive e^{-iθZ} and its circuit.
A closed quantum system evolves under its Hamiltonian according to:
The simulation task is to prepare , approximate the operator as a circuit, and measure an observable; an energy, a correlation, a reaction rate proxy. Product formulas split into pieces you can implement and alternate them in short steps, as in the figure. Qubitization and phase-estimation methods cost more per step but scale better with precision. Each choice trades gate count, error tolerance, and circuit depth differently.
The second half of the model is the translation from the algorithm's requirements to hardware:
physical_qubits approximately logical_qubits * physical_per_logical
A credible estimate starts from logical qubits, logical depth, precision, and error tolerance; then expands through an error-correction assumption into physical hardware, where physical_per_logical can be hundreds or thousands. Skipping that expansion is how a two-day laptop demo gets compared against a fault-tolerant machine that does not exist yet.
Evidence boundary. Product-formula methods approximate evolution of sums of noncommuting terms with error/cost tradeoffs. [Seth Lloyd] [Michael A. Nielsen]
Noncommuting terms create approximation error
Apply first-order product formulas to X+Z.
Evidence boundary. Application relevance requires state preparation, observable estimation, precision, and classical baseline accounting. [National Academies of Sciences] [Yudong Cao et al.] [John Preskill]
Notation contract: H Hermitian; U(t)=e^{-iHt}; ℏ=1 declared; operator norm/error metric named; r product-formula segments; Pauli ordering fixed.
Step count trades gates for accuracy
Measure error as segments increase.
For first-order product formulas, splitting into steps gives ; noncommuting terms create an error that falls as r grows under an explicit bound. Each added step multiplies gate cost. Compare against exact evolution on the same state and metric, and verify unitarity separately so numerical drift is not misreported as algorithmic error.
The classic trap is treating "quantum simulates quantum" as a complete argument. It tells you why the application class exists; it says nothing about encoding cost, precision, noise, measurement overhead, or the classical method you must beat. Each of those can sink the advantage on its own.
Resource account: the algorithm ends at an observable
Include sampling and state-preparation costs.
| Resource | Record before claiming advantage |
|---|---|
| Encoding and preparation | Logical qubits, preparation gates, depth, overlap or fidelity, and failed preparations. |
| Evolution | Algorithm family, segment/query count, synthesized gates, routed depth, and approximation error. |
| Observable estimation | Measurement groups, shots, variance, confidence interval, and repeated circuit executions. |
| Classical work | Hamiltonian construction, compilation, aggregation, and comparator runtime at the same tolerance. |
| Physical expansion | Logical error target, code overhead, cycle time, and wall-clock estimate when fault tolerance is assumed. |
Hamiltonian simulation is a workload-definition problem long before it is an implementation problem. You parse the model, choose a representation, select an algorithm, estimate resources, and define how the result will be validated. The artifact that comes out of that work should contain:
- the input model and its Hamiltonian representation,
- the target observable and precision target,
- the algorithm choice and its logical resource estimate,
- the mapping onto physical hardware assumptions,
- the classical baseline, and
- a validation plan.
That document is worth more than any application slogan, because someone else can check it, rerun it, and update it when hardware assumptions move.
A simulation claim ledger
Record structure, norm, precision, resources, and classical baseline.
A reproducible claim names the Hamiltonian representation, coefficient units, system size, evolution time, target observable, error metric and tolerance, input-state preparation, algorithm family, oracle or block-encoding assumptions, logical resources, sampling cost, and classical baseline. Change any one of these and the meaning of 'simulation advantage' can change; the ledger prevents cross-instance comparisons by headline qubit count.
Hamiltonian simulation error laboratory
| Field | Reader-visible record |
|---|---|
| Format | Notebook comparing exact exponentiation and product formulas with resource ledger |
| Verification | Tests one commuting and one noncommuting Hamiltonian, verifies error scaling over segment counts, and records gate/sample costs. |
| Availability | Source-embedded acceptance record; no separate download is claimed |
{
"artifact": "Hamiltonian simulation error laboratory",
"format": "Notebook comparing exact exponentiation and product formulas with resource ledger",
"acceptance_test": "Tests one commuting and one noncommuting Hamiltonian, verifies error scaling over segment counts, and records gate/sample costs.",
"publication_state": "source-embedded contract and worked fixture"
}Executable reference fixture
Run with Python 3.11 or later. The final assertion is the chapter-level pass condition for this small instance.
import cmath, math
def mm(A,B): return [[sum(A[i][k]*B[k][j] for k in range(2)) for j in range(2)] for i in range(2)]
I=((1+0j,0j),(0j,1+0j)); X=((0j,1+0j),(1+0j,0j)); Z=((1+0j,0j),(0j,-1+0j))
def exp_pauli(P,t): return [[math.cos(t)*I[i][j]-1j*math.sin(t)*P[i][j] for j in range(2)] for i in range(2)]
def trotter(n):
if type(n) is not int or n <= 0: raise ValueError("step count must be positive")
step=mm(exp_pauli(X,1/n),exp_pauli(Z,0.3/n)); out=[list(r) for r in I]
for _ in range(n): out=mm(step,out)
return out
def delta(A,B): return sum(abs(A[i][j]-B[i][j])**2 for i in range(2) for j in range(2))**0.5
r=math.sqrt(1.09); exact=[[math.cos(r)*I[i][j]-1j*math.sin(r)*(X[i][j]+0.3*Z[i][j])/r for j in range(2)] for i in range(2)]
errors=[delta(trotter(n),exact) for n in (1,2,4)]
invalid_rejected=False
try: trotter(0)
except ValueError: invalid_rejected=True
assert errors[2] < errors[1] < errors[0]
assert invalid_rejected
print(f"PASS: 34 Hamiltonian simulation Trotter_errors={[round(value, 6) for value in errors]} invalid_steps={invalid_rejected}")Scope boundary
- This chapter does not treat all chemistry as Hamiltonian simulation or promise application value from asymptotic simulation complexity alone.
- It does not compare every modern simulation algorithm or publish unsourced resource estimates.
Depth commitment. One exact Hamiltonian, one noncommuting case, four segment counts, and one claim ledger.
Practice problem
Approximate e^{-it(X+Z)} at t=1 with first-order product formulas for r=1,2,4,8 and compare with exact evolution.
- Deliverable
- Circuit/gate counts, matrix or state error table, and observed scaling.
- Pass condition
- The notebook regenerates exact and approximate unitaries, computes the declared norm error, and matches every row.
Verification record
Expected solution form. Exact diagonalization versus product-formula report with plotted error.
Model answer. For H=X+Z, exact evolution uses frequency sqrt(2). The first-order product U_r=(exp(-iX/r)exp(-iZ/r))^r is unitary for every r; its chosen matrix-norm error decreases across r=1,2,4,8. The ordered product and error metric must be held fixed when claiming the trend.
Model result and check. CI reruns all segment counts and verifies monotonic trend within the chosen metric.
Acceptance test. The notebook regenerates exact and approximate unitaries, computes the declared norm error, and matches every row.
Companion work
Artifacts for this chapter
These entries resolve to checked-in local source. Commands are reproduced exactly from the chapter manifest, and source-embedded fixtures are exported as direct downloads.
algorithm fixture
Hamiltonian simulation error laboratory
Reproduce or test
python3 tools/validate_briefs.py --briefs data/editorial_briefs_00_35.json --from 0 --through 35 --check-rewritten-sources --execute-artifacts
Provenance
Sources and review
- Richard P. Feynman. Simulating physics with computers. International Journal of Theoretical Physics. 1982primary paper
- Seth Lloyd. Universal quantum simulators. Science. 1996primary paper
- Michael A. Nielsen and Isaac L. Chuang. Quantum Computation and Quantum Information. Cambridge University Press. 2010textbook
- National Academies of Sciences, Engineering, and Medicine. Quantum Computing: Progress and Prospects. National Academies Press. 2019consensus study report
- Yudong Cao et al.. Quantum Chemistry in the Age of Quantum Computing. Chemical Reviews. 2019peer-reviewed review
- John Preskill. Lecture Notes for Physics 219: Quantum Computation. California Institute of Technology. 2018graduate lecture notes
The load-bearing claims in the chapter are mapped inline to this registered source set. A citation supports only the bounded claim beside it.