← Back to Dashboard

18. Photovoltaics

Stage C - Calibrated

Quantum walk exciton transport with 20-run calibration ensemble. 47k physical qubits, 12 logical.

Algorithm
Quantum Walk (Exciton Transport)
Logical Qubits
3
Framework
Modern QDK (qsharp 1.31.0)

Resource Estimation (Azure Quantum RE)

Physical Qubits
47.2k
Logical Qubits
12
T-Gates
Rotations
10
Runtime
1.8ms

Resource Breakdown

Calibration Evidence (20-Run Ensemble)

Mean Value
2.314
95% CI
± 0.070
Runs
20
Std Dev
0.160

Noise Resilience (Depolarizing Simulation)

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

p = 0.001
98.7%
p = 0.01
85.7%
p = 0.05
48.6%

Cross-Platform Emulator Results (100 shots)

These histograms predate the current kernel

This run was recorded in April 2026 against a quantum-walk kernel whose position never depended on its coin, rewritten in September 2026. 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, 0]
99% of shots
Rigetti QVM
[1, 0, 0]
100% 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
Potential exponential for transport simulation; not established
Classical Competitor
Lindblad master equation / Monte Carlo
Honest Assessment (Troyer Framework)

Exciton transport in photosynthetic systems is inherently quantum, but the open-system dynamics of light-harvesting complexes of the size studied so far are routinely simulated classically, with hierarchical equations of motion or Lindblad master equations. An advantage would need systems large and strongly coupled enough to defeat those methods.

These two numbers describe different programs

The resource estimate below is for Main.RunExcitonWalk(10, 0.5, 1), the algorithm at utility scale. The Azure Quantum runs executed QuantumWalkKernel(), 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 10 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 6.0x the qubits cuts runtime to 0.36x.

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_code9,75212
Trapped Ion (μs, 1e-4)surface_code9,75212
Superconducting (ns, 1e-3)surface_code47,18812
Trapped Ion (μs, 1e-3)surface_code47,18812

Problem Documentation

Problem 18 · Quantum Photovoltaics

Overview

Maximizing photovoltaic conversion efficiency hinges on balancing light absorption, carrier extraction, and recombination pathways. This scaffold pairs a reproducible classical baseline based on a simplified Shockley-Queisser style radiative limit with multi-junction heuristics, while reserving space for Q# experiments that explore excitonic transport and quantum-enhanced light harvesting. The objective is to compare classical efficiency projections against quantum-inspired proposals for coherent exciton management.

Directory Layout


18_photovoltaics/
├── estimates/                        # JSON artifacts from classical / quantum workflows
├── instances/                        # Bandgap selections, temperatures, recombination parameters
├── plots/                            # Generated figures from analyze.py
├── python/
│   ├── classical_baseline.py         # Shockley–Queisser style efficiency estimator
│   └── analyze.py                    # Visualization of efficiency and voltage trends
└── qsharp/
    ├── qsharp.json            # Modern QDK project file
    └── Program.qs                    # Stubbed quantum workflow

Quick Start


cd problems/18_photovoltaics

# Classical efficiency baseline
python python/classical_baseline.py

# Plot efficiency vs. bandgap and temperature 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. Excitonic Network Encoding – Map donor-acceptor lattices into qubit graphs for coherent transport studies.

2. Open Quantum Dynamics – Model phonon-assisted hopping using Lindblad style channels or variational ansätze.

3. Light-Harvesting Circuits – Prototype quantum walk or cavity-assisted absorption kernels.

4. Resource Estimation – Track qubit counts and Trotter depths against realistic cell architectures.

This scaffold keeps the classical photovoltaic baseline reproducible while we explore quantum coherence for next-generation solar materials.

Objective Maturity Gate

  • **Current gate**: **Stage C complete** (hardware-aware validation evidence in place: quantum walk exciton-transport 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 Lindblad master-equation baseline, residual risks for naturally-quantum open-system transport, claim category locked).

Stage C evidence references for this problem:

  • Calibration ensemble: `estimates/quantum_calibration_ensemble.json`, regenerated on 2026-09-25 after the walk was corrected. Until then the conditional shift swapped the two position qubits whichever way the coin pointed, so the walker never depended on the coin and every run ended on site 1; `estimates/calibration_evidence.json` (2026-03-25) records that defect as 100% at site 1 across three runs.
  • 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`. Both versions of the walk use two Toffoli-class gates and one rotation per step, so the resource estimate, which counts non-Clifford operations, is unchanged.
  • Cross-platform OpenQASM export: `estimates/quantum_walk.qasm`, the same circuit as `qsharp/HardwareKernel.qs`.
  • Azure smoke validation: `estimates/azure_smoke_report_small_d1.md`, `estimates/azure_job_manifest_small_d1.json` (2026-03-06, the kernel before the correction; the corrected kernel has not been submitted).

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/18_photovoltaics 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 →