← Work 01 / 04
Project 01

Coherent Ising machine simulator

If you want to argue that light can do useful computation, you have to be able to say exactly where the argument breaks. So I built the thing that breaks it.

RoleSole author
StatusPending
StackPython, NumPy, SciPy
RelationUnderpins GB 2607326.2

The question

Coherent Ising machines solve combinatorial optimisation by letting a network of optical parametric oscillators settle into a low-energy spin configuration. The physics is appealing and the literature is optimistic. What the literature is less forthcoming about is how quickly the advantage evaporates once you put real loss, real noise, and real coupling limits into the machine.

I wanted a simulator honest enough to tell me that — one where I could turn hardware imperfection up until the answer got worse, and watch where my advantages materialise.

How it was built

Six phases, each one a working artefact rather than a step toward one. Nothing advanced until the previous phase reproduced a known result.

  • Phase 0 — a bare Ising substrate in NumPy. Spin glass instances, exact solutions on small lattices, energy bookkeeping that could be checked by hand.
  • Phase 1 — classical annealing baselines, so that later claims had something to be better than.
  • Phase 2 — the mean-field CIM equations, integrated as a continuous dynamical system rather than a discrete update rule.
  • Phase 3 — measurement-feedback dynamics, where the coupling is computed electronically between round trips.
  • Phase 4 — noise: vacuum fluctuations, pump amplitude drift, detector shot noise.
  • Phase 5 — hardware fidelity. Finite cavity loss, limited coupling precision, and the timing constraints an actual optical loop imposes.

What came out of it

The useful output was not a speedup claim. It was a map of which hardware parameters actually govern solution quality, and a defensible sense of where the engineering effort has to go, which is the input the inference architecture in the patent was designed against. The headline was that the binding constraint sits in the physical uniformity of the oscillator network rather than in the annealing schedule, which is the opposite of where a software-first reading of the literature points you. That reorders the hardware priorities: the thing worth engineering is the substrate's consistency, not the cleverness of the control loop. The advantage was real but bounded, and the boundary moved with the coupling density rather than with node count alone.

What I'd do differently

The early phases used dense coupling matrices well past the point where sparsity would have paid for itself, which capped the tractable problem size for longer than it should have. The staging discipline was right; the data structure choice inside it was not optimal.