← Back to Dashboard

14. Materials Discovery

Stage C - QPE (upgraded from VQE)

QPE band gap of a toy tight-binding dimer (10 phase bits). 755k physical qubits, 35 logical. A two-level model, not a real material.

Algorithm
QPE Band Gap Estimation
Logical Qubits
5
Framework
Modern QDK (qsharp 1.31.0)

Resource Estimation (Azure Quantum RE)

Physical Qubits
754.7k
Logical Qubits
35
T-Gates
54
Rotations
163.9k
Runtime
27.2s

Resource Breakdown

Calibration Evidence (20-Run Ensemble)

Mean Value
4.393
95% CI
± 0.011
Runs
20
Std Dev
0.025

Noise Resilience (Depolarizing Simulation)

Ideal outcome: [One, Zero] (66% probability)

p = 0.001
98.7%
p = 0.01
79.4%
p = 0.05
84.3%

Cross-Platform Emulator Results (100 shots)

These histograms predate the current kernel

This run was recorded in April 2026 against a VQE kernel that has since been replaced by phase estimation. The shot distribution below is a real measurement, but it is a measurement of a program that no longer exists in this repository, and it has not been re-run against the current kernel.

Quantinuum H2-1E
[1, 0]
70% of shots
Rigetti QVM
[1, 0]
69% of shots
✓ Cross-platform agreement: both simulators find the same dominant outcome
H2-1E Distribution
Rigetti QVM Distribution

Troyer Utility-Scale Classification

Quantum Simulation (Native Advantage Potential)
Quantum Speedup
Exponential over exact diagonalization if the initial states overlap the target states well; not established against the best classical methods
Classical Competitor
DFT / GW approximation
Honest Assessment (Troyer Framework)

Upgraded to QPE for strongly-correlated materials (e.g., high-Tc superconductors), where DFT is unreliable. Simulating the dynamics of correlated electrons is believed to be classically hard in general, but for ground-state and gap estimation QPE's advantage depends on preparing states that overlap the target states well. Our instance is a labelled toy model.

These two numbers describe different programs

The resource estimate below is for Main.BandGapQPE(1.0, -0.5, 0.8, 0.3, 10, 1), the algorithm at utility scale. The Azure Quantum runs executed MaterialsQPEKernel(), a small kernel sized to fit today's hardware. Qubit counts and runtimes from the estimate are not measurements of the run, and the run histogram is not a sample of the estimated circuit.

Pareto Frontier: Qubits vs Runtime

The estimator returns 4 viable configurations, not one answer. Every headline figure on this page comes from the leftmost point, which uses the fewest qubits and is therefore also the slowest. Buying 1.2x the qubits cuts runtime to 0.76x.

qubit_gate_ns_e3 with surface_code, error budget 1e-3. Points are Pareto-optimal: no other configuration is better on both axes.

Multi-Model Resource Comparison

Physical qubit requirements across 6 qubit technologies × 2 QEC schemes (inspired by Troyer Architecture Series, Part 3).

■ Gate-based + Surface code (blue)
Qubit ModelQECPhysical QubitsLogical Qubits
Superconducting (ns, 1e-4)surface_code43,99535
Trapped Ion (μs, 1e-4)surface_code43,99535
Superconducting (ns, 1e-3)surface_code754,71535
Trapped Ion (μs, 1e-3)surface_code754,71535

Problem Documentation

Problem 14 · Quantum Materials Discovery

Overview

Designing next-generation battery cathodes requires exploring a vast space of material compositions and crystal structures. This scaffold provides a reproducible classical baseline that scores candidate compositions using simplified cluster expansions and a Q# project whose hardware kernel runs quantum phase estimation for band gaps and defect energetics.

Directory Layout


14_materials_discovery/
├── estimates/                        # JSON artifacts from classical / quantum workflows
├── instances/                        # Candidate composition grids (small/medium/large)
├── plots/                            # Generated figures from analyze.py
├── python/
│   ├── classical_baseline.py         # Surrogate energy/stability scoring for battery materials
│   └── analyze.py                    # Visualization of Pareto fronts and composition trends
└── qsharp/
    ├── qsharp.json            # Modern QDK project file
    └── Program.qs                    # Stubbed quantum workflow

Quick Start


cd problems/14_materials_discovery

# Classical surrogate baseline
env PYTHONPATH=../../.. python python/classical_baseline.py

# Visualize stability vs. voltage trends
python python/analyze.py

# Quantum placeholder (uses modern QDK  qsharp Python package)
python -c "import qsharp; qsharp.init(project_root='qsharp'); print('Build OK')"
 python tooling/run_all_qsharp.py  # runs via qsharp Python package

Next Quantum Milestones

1. Hamiltonian Construction – Encode tight-binding or Hubbard-like operators for candidate lattices.

2. Variational Ansätze – Develop chemistry-informed ansätze for defect and conduction band evaluations.

3. Cost Function Calibration – Integrate quantum outputs with classical thermodynamic models.

4. Resource Estimation – Quantify qubit counts and logical depth for realistic band-gap predictions.

This scaffold keeps the classical materials-surrogate baseline reproducible while laying the groundwork for quantum-assisted materials discovery. 🔋⚛️

Objective Maturity Gate

  • **Current gate**: **Stage C complete** (hardware-aware validation evidence in place: QPE band-gap kernel runnable, calibration ensemble across runs, backend assumptions documented, dual-model estimator profile, OpenQASM export, Azure smoke validation).
  • **Next gate target**: **Stage D** (advantage evidence package: fairness review against DFT/GW for strongly-correlated materials, residual risks for high-Tc / Mott regimes, claim category locked).

Stage C evidence references for this problem:

  • Calibration ensemble: `estimates/quantum_calibration_ensemble.json` and `estimates/calibration_evidence.json`.
  • Backend assumptions: `estimates/backend_assumptions.md`.
  • Estimator profile (ns-e3 + surface-code-generic): `estimates/estimator_profile_summary.md`, `estimates/latest_qubit_gate_ns_e3.json`, `estimates/latest_surface_code_generic_v1.json`.
  • Cross-platform OpenQASM export: `estimates/vqe_bandgap.qasm`.
  • Azure smoke validation: `estimates/azure_smoke_report_small_d1.md`, `estimates/azure_job_manifest_small_d1.json`.

DiVincenzo Readiness (Stage C/D Overlay)

| Criterion | Status | Evidence / Notes |

|---|---|---|

| Scalable qubit system | partial | Problem-scoped instance baselines are in place; full hardware-scale projections are tracked as Stage C work. |

| Initialization | partial | Input/state initialization path is defined for current workflows, with backend-ready loading fidelity still to be hardened. |

| Coherence vs gate time | not-yet | Backend-calibrated coherence-vs-depth evidence is pending and required for Stage C/D promotion. |

| Universal gate set | partial | Q# scaffold/build path exists; gate-basis decomposition and transpilation evidence remain Stage C tasks. |

| Qubit-specific measurement | partial | Measurement outputs are defined for current validation flows; hardware readout characterization is pending. |

Advantage Claim Contract

  • **Claim category (current)**: `theoretical`.
  • **Problem class and regime**: Problem-specific challenge instances defined in this directory.
  • **Fair baseline**: Problem-local classical baseline in `python/` outputs.
  • **Quantum resource scaling claim**: Expected asymptotic advantage depends on algorithm family and implementation assumptions; no hardware-demonstrated speedup claim yet.
  • **Data-loading and I/O assumptions**: Must be documented alongside future advantage claims.
  • **Noise/error model assumptions**: Backend-specific model and calibration assumptions to be added at Stage C.
  • **Confidence/uncertainty method**: To be reported using shot-based confidence intervals or equivalent statistical bounds.
  • **Residual risks**: Oracle/state-preparation/transpilation overhead may dominate for near-term instance sizes.

Reproduce It

cd problems/14_materials_discovery make classical # Run classical baseline make analyze # Generate plots make build # Validate Q# compilation make run # Run Q# entry point

Key Files

  • qsharp/src/Main.qs Quantum algorithm implementation
  • qsharp/HardwareKernel.qs Azure-submittable QIR kernel
  • python/classical_baseline.py Classical reference implementation
  • estimates/classical_baseline.json Baseline metrics
View on GitHub →